RE: Standard Library Interest?

RE: Standard Library Interest?

[Beard, Frank Randolph CIV]

-----Original Message-----
From: Jeff C,

> Vendors that I think still have active products include:
>
> ACT
> RR
> Rational
> DDC-I
> Greenhills
> OC Systems
> Concurrent Computer Corp
> ICC
> 
> It at least appears as if these products are still being support.
> It will be interesting to see who invests the money to move forward to Ada
> 0x.

Aonix

We received a letter from Aonix earlier this year reaffirming their
commitment to Ada, and stating the company has been split.  There was
Aonix Critical Systems Division (CSD), eBIS, and Select product
divisions.  The company split into Aonix (CSD side) and Select
Business Solutions (eBIS and Select product side).  Aonix claims
we will be pleased with their new focused company and the future plans
for the Ada, TeleUSE, and StP product lines, supported by new external
investment.

Sounds promising (I just wish they would monitor comp.lang.ada).

Frank

RE: Standard Library Interest?

[Martin Krischik]

Beard, Frank Randolph CIV wrote:

> Sounds promising (I just wish they would monitor comp.lang.ada).

Every Ada vendor should at least have on employee look at comp.lang.ada.
There loss it they don't.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Standard Library Interest?

[Marin David Condic]

So if you're an Aonix supported customer, perhaps you could inquire with 
them about getting a standard library? Point them at C.L.A. or my recent 
article in Ada Letters and let them know that as a supported customer, 
you would like to see a standard library of some sort.

MDC


Beard, Frank Randolph CIV wrote:
> 
> We received a letter from Aonix earlier this year reaffirming their
> commitment to Ada, and stating the company has been split.  There was
> Aonix Critical Systems Division (CSD), eBIS, and Select product
> divisions.  The company split into Aonix (CSD side) and Select
> Business Solutions (eBIS and Select product side).  Aonix claims
> we will be pleased with their new focused company and the future plans
> for the Ada, TeleUSE, and StP product lines, supported by new external
> investment.
> 
> Sounds promising (I just wish they would monitor comp.lang.ada).
> 
> Frank


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Ed Falis]

Frank,

I don't know whether you intended this question to go to c.l.a, or to be a 
private message.  However, your best bet for thoughts on this would be to 
contact Greg Gicca at Aonix.  I believe his email is 
ada_marketing@aonix.com or adamarketing@aonix.com.  I'm sure he'd be happy 
to discuss with you.

- Ed

Standard Library Interest?

[chris]

Hi,

Recent discussions with Marin David Condic /suggest/ the development of 
some kind of standard library independant of the ARM, but hopefully 
endorsed by vendors and the ARG, would be a worthwhile endeavour. 
Assuming such a library could be created and was attractive to the 
community, vendors and the ARG what would people want of such a library?

What would you want to see available that wasn't going to feature in the 
next language revision and didn't quite fit with the long revision times 
for the standard?  What would you like available that was portable 
across platforms for software development?

I wasn't going to suggest anything as a) I don't want to put words/ideas 
in peoples' mouths/heads and b) my interests are highly multimedia 
orientated but perhaps including some of the following:

XML support
Unicode processing library
Support for common image formats*
Support for common audio formats and audio playback* (free formats)

*with the ability to extend support for other formats.

XML and Unicode support don't quite fit within the language standard 
because they change more frequently, but IMO it'd be nice to have some 
standardised support for both of these things.  Note with unicode I am 
thinking about things like normalisation, etc.

The idea is to have something that developers can look to on compilers 
for general software development, particularly on the desktop.  If 
developers need it, it will be there and they don't have to look around 
as much for the facilities they need.  So, what facilities do you need 
that perhaps could go in such a library?


Chris

Re: Standard Library Interest?

[Robert I. Eachus]

chris wrote:

> XML and Unicode support don't quite fit within the language standard 
> because they change more frequently, but IMO it'd be nice to have some 
> standardised support for both of these things.  Note with unicode I am 
> thinking about things like normalisation, etc.

Huh?  Read the RM:   <i>The predefined type Wide_Character is a 
character type whose values correspond to the 65536 code positions of 
the ISO 10646 Basic Multilingual Plane (BMP). Each of the graphic 
characters of the BMP has a corresponding character_literal in 
Wide_Character. The first 256 values of Wide_Character have the same 
character_literal or language-defined name as defined for Character. The 
last 2 values of Wide_Character correspond to the nongraphic positions 
FFFE and FFFF of the BMP, and are assigned the language-defined names 
FFFE and FFFF. As with the other language-defined names for nongraphic 
characters, the names FFFE and FFFF are usable only with the attributes 
(Wide_)Image and (Wide_)Value; they are not usable as enumeration 
literals. All other values of Wide_Character are considered graphic 
characters, and have a corresponding character_literal.</i>

The BMP character set is identical to Unicode.  There are additional 
functions which are part of the Unicode definition.  Some of them can be 
found in A.3.2 and A.4.7. If there is something you think should be 
added, let me know.  (I already have a "little list" for Ada 0Y.) Also, 
don't get misled by some people (including me! ;-) saying that the Ada 
standard has a slow revision cycle.  Technically, the standard is 
considered for revision every five years, but in practice if there are 
problems, the ARG will fix them as soon as possible.  Unicode/ISO10646 
is a perfect case in point.  I could tell you the (highly boring) 
changes that have been made in ISO 10646 and Unicode since they 
converged.  (If you are really interested, look here: 
http://www.unicode.org/versions/Unicode4.0.0/

Just to give you a flavor:  "1,226 new character assignments were made 
to the Unicode Standard, Version 4.0 (over and above what was in Unicode 
3.2). These additions include currency symbols, additional Latin and 
Cyrillic characters, the Limbu and Tai Le scripts; Yijing Hexagram 
symbols, Khmer symbols, Linear B syllables and ideograms, Cypriot, 
Ugaritic, and a new block of variation selectors (especially for future 
CJK variants). Double diacritic characters were added for dictionary use."

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[chris]

Robert I. Eachus wrote:

> The BMP character set is identical to Unicode.  There are additional 
> functions which are part of the Unicode definition.  Some of them can be 
> found in A.3.2 and A.4.7. If there is something you think should be 
> added, let me know.  (I already have a "little list" for Ada 0Y.) Also, 
> don't get misled by some people (including me! ;-) saying that the Ada 
> standard has a slow revision cycle.  Technically, the standard is 
> considered for revision every five years, but in practice if there are 
> problems, the ARG will fix them as soon as possible.  

I do know that and have seen the ARG fix things in the past, but for 
things that are a bit of a moving target (like XML) it'd be best to keep 
them out the standard.  Unicode wasn't the best suggestion for something 
like this.



 > Unicode/ISO10646
> is a perfect case in point.  I could tell you the (highly boring) 
> changes that have been made in ISO 10646 and Unicode since they 
> converged.  (If you are really interested, look here: 
> http://www.unicode.org/versions/Unicode4.0.0/

I knew the language had some support for unicode, but I was thinking of 
routines for normalising strings which is useful for simple comparisons 
on unicode strings.  I will look at A.3.2 and A.4.7 and explore a bit 
more, see what's *really* there.



Chris

Re: Standard Library Interest?

[Marin David Condic]

Yes, its true that the ARG will fix problems, but please be fair about 
it. The ARG wouldn't, for example, discover that Java just added a 
library branch to cover Computational Fluid Dynamics that was proving to 
be wildly popular and decide that this was a "problem" for Ada and 
release a CFD library of their own within 6 months. So realistically, 
you're looking at a ten year cycle before a new library branch could be 
added.

Also, it might be technically true that the language comes up for 
revision review on a 5 year cycle, but given that it is almost 2004, 
we'd have Ada83..Ada95..Ada04 - looks pretty much like 10 years to me, 
plus or minus a little. So while the review of Ada95 should have started 
in 2000, it isn't at all realistic to presume that we're going to start 
the next review cycle in 2005 when we have not yet got Ada0x out the door.

I'm not criticizing the ARG or its efforts or the value of the standard. 
It definitely *needs* some stability and a long review cycle and careful 
consideration given to each item included in it and extreme detail 
outlined to make each item validatable. What I'm saying is that when you 
want to provide features or functionality that doesn't require a 
revision of the compiler and you want to react quickly to market 
demands, the standard is *not* the place to go because it simply takes 
too long. Hence my appeal to get a library outside of the ARM.

MDC


Robert I. Eachus wrote:
> standard has a slow revision cycle.  Technically, the standard is 
> considered for revision every five years, but in practice if there are 
> problems, the ARG will fix them as soon as possible.  Unicode/ISO10646 



-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Robert I. Eachus]

Marin David Condic wrote:

> Also, it might be technically true that the language comes up for 
> revision review on a 5 year cycle, but given that it is almost 2004, 
> we'd have Ada83..Ada95..Ada04 - looks pretty much like 10 years to me, 
> plus or minus a little. So while the review of Ada95 should have started 
> in 2000, it isn't at all realistic to presume that we're going to start 
> the next review cycle in 2005 when we have not yet got Ada0x out the door.

Yes, the intention is to only make significant changes every other 
cycle.  But don't let that trick you into ignoring the fact that the 
standard has changed since 1995.  Get a copy of Technical Corrigendum 1 
(ISO/IEC 8652:1995/COR1:2000, or look at it on line.  Found it: 
http://www.ada-auth.org/ai-files/grab_bag/Corrigendum.html  I think you 
will find that even though this was an official ISO revision of the 
standard in 2000, there is not much in their to get excited about.  (But 
the ARG does anyway, or pretends to. ;-)

> I'm not criticizing the ARG or its efforts or the value of the standard. 
> It definitely *needs* some stability and a long review cycle and careful 
> consideration given to each item included in it and extreme detail 
> outlined to make each item validatable. What I'm saying is that when you 
> want to provide features or functionality that doesn't require a 
> revision of the compiler and you want to react quickly to market 
> demands, the standard is *not* the place to go because it simply takes 
> too long. Hence my appeal to get a library outside of the ARM.

Believe me, I am NOT saying that you shouldn't do exactly that. 
Packages will only get added to the standard if they are available and 
widely used.   So if you want something added, you need to get a version 
out and in use.  Especially if you think that the packages should be in 
the standard.

I am just trying to make clear that there is a normal progression. 
Including something in the standard too soon is wrong, and deciding on 
theorectical grounds that something should never be in the standard is 
just as wrong.  When things like database interfaces are in flux and 
there is no agreement on how it should be done--they don't belong in the 
standard.  The various contending approaches belong in vendor supplied 
packages.  When the user base finds the differences in naming 
conventions more troubling than the differences in approach between the 
implementions, then it is time for standardization.  And throughout this 
process of evolution, users will gripe.  It is their nature.

Seriously, listening to gripes is part of the ARG's job, and there will 
always be gripes.  Our job is to listen to the gripers, and also listen 
to the silence from those who are satisfied with the current situation. 
  Then only make changes that reduce the overall griping level.

Oh, and realize that we are all frustrated language developers.  The fun 
part of the job for all of us is when we do get to commit language 
design.  The restraint we have to intellectualy accept is part of the 
price.  Just look at Tucker's current proposal to change the freezing 
rules for generics to see this tension manifest.  I'm tempted to say 
that every ARG member has said that Tucker's proposal is way to radical, 
then gone ahead and made a different radical proposal of their own. ;-)

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Martin Dowie]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F8035B0.7080902@noplace.com...
> Also, it might be technically true that the language comes up for
> revision review on a 5 year cycle, but given that it is almost 2004,
> we'd have Ada83..Ada95..Ada04 - looks pretty much like 10 years to me,
> plus or minus a little. So while the review of Ada95 should have started
> in 2000, it isn't at all realistic to presume that we're going to start
> the next review cycle in 2005 when we have not yet got Ada0x out the door.

But we did have the TC in 2000

Re: Standard Library Interest?

[Marin David Condic]

I didn't say you didn't. What I said was that Ada has a 10 year cycle 
(more or less) for revising the standard. Do you think it likely that 
the next revision review will start in 2005 given that there is, as of 
yet, no Ada0x and at best it would be Ada04? Hence, I take exception to 
the notion that there is really a 5 year cycle. Its more like 5 years 
*after* a language standard has been issued a new review will be 
initiated. But then you've got maybe another 5 years of reviewing, etc., 
before the *next* standard would be issued.

Mind you, I'm not being critical or trying to say it is a bad thing. A 
standard needs some kind of stability or the compiler writers would be 
shooting at a moving target and the developers would have no clue as to 
what they could count on.

What I *am* saying is that if Ada is going to have some kind of 
Conventional Ada Library full of tools, that the Ada language standard 
is the entirely wrong place to put it. (At least initially - the 
standard could accept parts of it down the road if it was viewed as 
stable and something that belonged in the standard.) A library needs to 
be able to be revised and extended *QUICKLY* (relative to the standard - 
say quarterly or semi-annualy) in order to react to rapidly changing 
events in the computer biz. If someone comes up with a new communication 
interface or file format or internet protocol and your library is 
supporting the general concept around that, you need to make additions 
or changes to your library to accommodate it or you're dead in the water 
with a useless product. If someone comes up with some whiz-bang new 
Internet thingie and Ada says "Yeah, that's cool. We'll have an 
interface for that in *TEN YEARS* when the new ARM comes out..." what 
will the users do? They'll go to Java or C++ or whoever is the first one 
to give them the interface.

Ada has *got* to find a way to provide lots more utility to the end-user 
and it needs to do so *quickly*. If it isn't with a Conventional Ada 
Library, then make it something else. Basically, I think we end up in 
the dustbin of history if we don't find a way to make Ada more useful 
and react quickly to customer demands. The users *have* and *will* go 
elsewhere if you don't provide what they want.

MDC


Martin Dowie wrote:
> 
> 
> But we did have the TC in 2000
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Martin Dowie]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F816A35.4030108@noplace.com...
> What I *am* saying is that if Ada is going to have some kind of
> Conventional Ada Library full of tools, that the Ada language standard
> is the entirely wrong place to put it. (At least initially - the

Secondary standards have already been tried and I don't think they
have been very successful, e.g. ISO/IEC 13813.

It seems that the Ada community isn't active enough to go and root
out and use other things if it's not in the RM, it doesn't exist!

I hope that the APIWG can get some momentum behind it and we
need to promote it more in cla.

Just my $0.02

Re: Standard Library Interest?

[Marin David Condic]

O.K. Maybe we have a difference of opinion, but that's all right. I'm 
willing to be persuaded, but I think that *some* scheme for a library is 
a good thing. How would you address the concern that if you make it part 
of the standard, it is etched in stone and you can't do anything about 
adding to it or fixing it for ten years? How would you create a climate 
wherein a developer can count on getting *something* but isn't frozen 
out of new developments, good ideas, enhancements, etc.?

You can have an absolute standard that is good for stability or you can 
have a totally fluid environment that reacts quickly to changes. 
Somewhere in the middle should be a useful compromise.

MDC


Martin Dowie wrote:
> 
> Secondary standards have already been tried and I don't think they
> have been very successful, e.g. ISO/IEC 13813.
> 
> It seems that the Ada community isn't active enough to go and root
> out and use other things if it's not in the RM, it doesn't exist!
> 
> I hope that the APIWG can get some momentum behind it and we
> need to promote it more in cla.
> 
> Just my $0.02
> 
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Stephane Richard]

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


"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F81FBEC.9010103@noplace.com...
> O.K. Maybe we have a difference of opinion, but that's all right. I'm
> willing to be persuaded, but I think that *some* scheme for a library is
> a good thing. How would you address the concern that if you make it part
> of the standard, it is etched in stone and you can't do anything about
> adding to it or fixing it for ten years? How would you create a climate
> wherein a developer can count on getting *something* but isn't frozen
> out of new developments, good ideas, enhancements, etc.?
>
> You can have an absolute standard that is good for stability or you can
> have a totally fluid environment that reacts quickly to changes.
> Somewhere in the middle should be a useful compromise.
>
> MDC
>

Maybe I read it wrong, but to me what should be in the ARM as a standard
shouldn't define the end of life, but how life should begin (cheap attempt
at a metaphore here...awaiting flying tomatoes ;-).

By that I mean that the standard from what I've seen don't tell you the end
of the language's possibilities, but ranther the beginning of them, on which
to build enhancements.  And that any addition to the standard should reflect
the definition of the language itself.

Let's take an example here, say we wanted to adda  GUI library to Ada as a
standard, I would be more tempted to add say wxWindows, or maybe GTK ada
because the follow in the phylosophy of ada as being multiplatform,
expandable, etc etc..if we were to code our own GUI library independant of
all existing ones, it would have to be exactly the same, multiplatform,
expandable, and everything else that is expected of Ada.  This may not be
the best example, but it is an example that reflects my thoughts :-).

To me that's what a standard should define, and it is what it defines so
far, not the end of things, but their beginnings.  As such, of course a good
strong stable foundation is always better to build on than a weak one.

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[Marin David Condic]

All right. But this would not be incompatible with my notion of having a 
Conventional Ada Library. Suppose that the ARM defines a package called 
CAL and underneath it, the arm defines some things like CAL.Containers 
and CAL.OS_Iterface, etc. Maybe these are stable enough to be in the ARM 
(I doubt it, but lets accept that for a moment). So long as the ARM 
allows the extension of this package, then you've got an "Official" 
ballpark in which to play. (Note that you are not allowed to modify or 
extend the package Ada - so this is the dead-wrong place in which to put 
a library.)

So once you have this CAL package tree defined and allowed to be 
extended, you've got the basis for a library. The ARG, vendors, SIGAda, 
etc, could come up with a reference implementation of it and provide it 
in source to everyone/anyone - ship it along with the compiler, etc. If 
you have some sort of organization that maintains it, they can find a 
mechanism to argue over what should be in it and add new things over 
time as needed. The next cycle of the ARM revision can take a look at 
what has "grown" in the library and decide if any of it should be 
declared to be "Standard". If its "Non-Standard" a developer knows it 
might be subject to change in a later release. (No big deal because he 
has source. A new release that changes things need not pick up some 
branch he doesn't want - he can use the source from the older release, 
cobble together anything else he wants, etc.)

The key is that you've got to have some way of saying "I want this new 
thing added to the library and I don't want to wait TEN YEARS (that's 
practically *forever* in computer years!) to get it." I'm not opposed to 
the standard, but you need faster reaction time than this for a library.

MDC


Stephane Richard wrote:
> 
> 
> Maybe I read it wrong, but to me what should be in the ARM as a standard
> shouldn't define the end of life, but how life should begin (cheap attempt
> at a metaphore here...awaiting flying tomatoes ;-).
> 
> By that I mean that the standard from what I've seen don't tell you the end
> of the language's possibilities, but ranther the beginning of them, on which
> to build enhancements.  And that any addition to the standard should reflect
> the definition of the language itself.
> 
> Let's take an example here, say we wanted to adda  GUI library to Ada as a
> standard, I would be more tempted to add say wxWindows, or maybe GTK ada
> because the follow in the phylosophy of ada as being multiplatform,
> expandable, etc etc..if we were to code our own GUI library independant of
> all existing ones, it would have to be exactly the same, multiplatform,
> expandable, and everything else that is expected of Ada.  This may not be
> the best example, but it is an example that reflects my thoughts :-).
> 
> To me that's what a standard should define, and it is what it defines so
> far, not the end of things, but their beginnings.  As such, of course a good
> strong stable foundation is always better to build on than a weak one.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Stephane Richard]

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

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F82B4A4.5060301@noplace.com...
> All right. But this would not be incompatible with my notion of having a
> Conventional Ada Library. Suppose that the ARM defines a package called
> CAL and underneath it, the arm defines some things like CAL.Containers
> and CAL.OS_Iterface, etc. Maybe these are stable enough to be in the ARM
> (I doubt it, but lets accept that for a moment). So long as the ARM
> allows the extension of this package, then you've got an "Official"
> ballpark in which to play. (Note that you are not allowed to modify or
> extend the package Ada - so this is the dead-wrong place in which to put
> a library.)
>
> So once you have this CAL package tree defined and allowed to be
> extended, you've got the basis for a library. The ARG, vendors, SIGAda,
> etc, could come up with a reference implementation of it and provide it
> in source to everyone/anyone - ship it along with the compiler, etc. If
> you have some sort of organization that maintains it, they can find a
> mechanism to argue over what should be in it and add new things over
> time as needed. The next cycle of the ARM revision can take a look at
> what has "grown" in the library and decide if any of it should be
> declared to be "Standard". If its "Non-Standard" a developer knows it
> might be subject to change in a later release. (No big deal because he
> has source. A new release that changes things need not pick up some
> branch he doesn't want - he can use the source from the older release,
> cobble together anything else he wants, etc.)
>
> The key is that you've got to have some way of saying "I want this new
> thing added to the library and I don't want to wait TEN YEARS (that's
> practically *forever* in computer years!) to get it." I'm not opposed to
> the standard, but you need faster reaction time than this for a library.
>
> MDC
>
Well yes 10 years is a long time....We'd need something like the Linux
system. By that I mean.  Some one develops a new thing, suggests it to
makers of Ada (like in linux they give it to the makers of linux) for
acceptance into the next release (which typically doesn't take 10 years in
most cases).  by the end of 10 years if enough makers of Ada have it as part
of their compiler then the revision can't overlook it.  if it's that popular
aside some terminology changes (say you didn't use the underscore in your
names and Ada guidelines recommend you should, etc etc).  then it gets added
into the next revision.....

I do agree that 10 years is a very long time and that might be part of the
reason which slows down Ada's progress on the popularity charts.  it's
strength (truely standard language) is also it's qeakness (way too long
revision period).  I would say either the revisions need to be closer
together (a year max instead of 10 years) or allow a principle of ammendment
to the standard that could be revised periodically and whatever makes it to
that revision would be part of the "official revisison".  or some system so
that we dont have to wait that long.

hence the standard commity either need to be more present and accessible to
the Ada community, or form a team of members or non members that could do
this regular interval thing.

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[Marin David Condic]

Well, yes, that's pretty much compatible with the idea I've been putting 
forward. If you have some group or organization overseeing some 
updatable library, people could contribute what they thought would be 
useful. The organization could arrive at some decision about its 
suitability and include it if it seemed to warrant it. (They would be 
playing the job of "Editor/Publisher" - work with a developer to get 
something suitable and add it to the next scheduled release as deemed 
necessary. That's how you'd resolve style issues and other things you 
might care about, like documentation.) You'd have a release cycle with 
sufficient frequency to give the language a means of rapidly reacting to 
a changing world without locking something into the ARM that might prove 
to be a "Bad Idea" or unstable or unproven. You get a more market-driven 
language capability without absolute standardization (the ARM) or 
absolute chaos (grabbing random libraries from the Internet.)

If the vendors are on board with it, they pick up new releases and 
distribute them with their compilers. They'd have the final say about 
what they wanted to accept. They'd be responsible if there were any 
portability issues to resolve. (Hopefully, few.) Ultimately pieces that 
are added might or might not make it into the ARM, but so what? You've 
got source code and if you like it, you use it with some guarantee that 
it is common across implementations. I don't see how this is 
undesirable. You get more functionality in a portable and standard way. 
Long term, it may be an ARM feature if it is popular and stable enough.

MDC


Stephane Richard wrote:
> 
> Well yes 10 years is a long time....We'd need something like the Linux
> system. By that I mean.  Some one develops a new thing, suggests it to
> makers of Ada (like in linux they give it to the makers of linux) for
> acceptance into the next release (which typically doesn't take 10 years in
> most cases).  by the end of 10 years if enough makers of Ada have it as part
> of their compiler then the revision can't overlook it.  if it's that popular
> aside some terminology changes (say you didn't use the underscore in your
> names and Ada guidelines recommend you should, etc etc).  then it gets added
> into the next revision.....
> 
> I do agree that 10 years is a very long time and that might be part of the
> reason which slows down Ada's progress on the popularity charts.  it's
> strength (truely standard language) is also it's qeakness (way too long
> revision period).  I would say either the revisions need to be closer
> together (a year max instead of 10 years) or allow a principle of ammendment
> to the standard that could be revised periodically and whatever makes it to
> that revision would be part of the "official revisison".  or some system so
> that we dont have to wait that long.
> 
> hence the standard commity either need to be more present and accessible to
> the Ada community, or form a team of members or non members that could do
> this regular interval thing.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Larry Hazel]

Marin David Condic wrote:

> Well, yes, that's pretty much compatible with the idea I've been putting 
> forward. If you have some group or organization overseeing some 
> updatable library, people could contribute what they thought would be 
> useful. The organization could arrive at some decision about its 
> suitability and include it if it seemed to warrant it. (They would be 
> playing the job of "Editor/Publisher" - work with a developer to get 
> something suitable and add it to the next scheduled release as deemed 
> necessary. That's how you'd resolve style issues and other things you 
> might care about, like documentation.) You'd have a release cycle with 
> sufficient frequency to give the language a means of rapidly reacting to 
> a changing world without locking something into the ARM that might prove 
> to be a "Bad Idea" or unstable or unproven. You get a more market-driven 
> language capability without absolute standardization (the ARM) or 
> absolute chaos (grabbing random libraries from the Internet.)
> 
> If the vendors are on board with it, they pick up new releases and 
> distribute them with their compilers. They'd have the final say about 
> what they wanted to accept. They'd be responsible if there were any 
> portability issues to resolve. (Hopefully, few.) Ultimately pieces that 
> are added might or might not make it into the ARM, but so what? You've 
> got source code and if you like it, you use it with some guarantee that 
> it is common across implementations. I don't see how this is 
> undesirable. You get more functionality in a portable and standard way. 
> Long term, it may be an ARM feature if it is popular and stable enough.
> 
> MDC
> 
> 
> Stephane Richard wrote:
> 
>>
>> Well yes 10 years is a long time....We'd need something like the Linux
>> system. By that I mean.  Some one develops a new thing, suggests it to
>> makers of Ada (like in linux they give it to the makers of linux) for
>> acceptance into the next release (which typically doesn't take 10 
>> years in
>> most cases).  by the end of 10 years if enough makers of Ada have it 
>> as part
>> of their compiler then the revision can't overlook it.  if it's that 
>> popular
>> aside some terminology changes (say you didn't use the underscore in your
>> names and Ada guidelines recommend you should, etc etc).  then it gets 
>> added
>> into the next revision.....
>>
>> I do agree that 10 years is a very long time and that might be part of 
>> the
>> reason which slows down Ada's progress on the popularity charts.  it's
>> strength (truely standard language) is also it's qeakness (way too long
>> revision period).  I would say either the revisions need to be closer
>> together (a year max instead of 10 years) or allow a principle of 
>> ammendment
>> to the standard that could be revised periodically and whatever makes 
>> it to
>> that revision would be part of the "official revisison".  or some 
>> system so
>> that we dont have to wait that long.
>>
>> hence the standard commity either need to be more present and 
>> accessible to
>> the Ada community, or form a team of members or non members that could do
>> this regular interval thing.
>>
> 
> 
Even if it were not distributed with compilers, having everything in one 
place as "The Ada Library" rather than bits and pieces here and there, 
it would be a great improvement over what we have now.

Re: Standard Library Interest?

[Stephane Richard]

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

> Even if it were not distributed with compilers, having everything in one
> place as "The Ada Library" rather than bits and pieces here and there,
> it would be a great improvement over what we have now.
>

I like the sound of that.  We'd need a central place where all reusable
libraries, maybe that could be a good addition to Ada World (The Ada Oracle)
perhaps for a name :-)  or simply the Ada Library and I could host them all,
without a problem. :-).

I'd like some input on this from people.  See for instance,

1. what could be part of it?  do we limit ourselves to platform independant
reusable libraries?
2. Do we include such things as AdaCL and such data structure based
libraries?
3. Do we go OS specific in different fields.  For example.  A binding to
PDCurses, one for conio to allow for specific functionalities available on
each OS/Platform?

And others too, what would you guys put in The Ada Library ?  And why...see
if we can filter out a list that could please everyone.

Awaiting comments, ideas and suggestions :-)
-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[Stephen Leake]

"Stephane Richard" <stephane.richard@verizon.net> writes:

> > Even if it were not distributed with compilers, having everything in one
> > place as "The Ada Library" rather than bits and pieces here and there,
> > it would be a great improvement over what we have now.
> >
> 
> I like the sound of that.  We'd need a central place where all reusable
> libraries, maybe that could be a good addition to Ada World (The Ada Oracle)
> perhaps for a name :-)  or simply the Ada Library and I could host them all,
> without a problem. :-).

www.adapower.com tried that, with very limited success. Before that,
www.adahome.com had a similar idea. How is your site going to be
better?

Part of the problem is that just because an Ada package is on a web
site doesn't mean it's a _good_ Ada package. So people don't want to
use it. 

The Ada APIWG has the same issue; they need to do lots of reviewing of
packages in order to give some value added, so people have a reason to
trust the code. However, they have no way to pay people for the time
spent reviewing, so it won't happen.

I try to address this with my code by including unit tests. That
doesn't seem to be enough.

> I'd like some input on this from people. See for instance,
> 
> 1. what could be part of it?  

Anything anyone ever found useful; someone else will need that same
thing again. 

Of course, that leads to lots of code, and you need a really smart
search engine to find anything. Which is another problem plaguing
adapower.com; the search engine isn't very smart. 

> do we limit ourselves to platform independant
> reusable libraries?

Not "limit", but certainly state a "preference", and include that info
in the searchable keywords.

> 2. Do we include such things as AdaCL and such data structure based
> libraries?

Of course. They are useful. But allow all of them; Booch, Charles,
SAL, Grace, etc.

> 3. Do we go OS specific in different fields.  For example.  A binding to
> PDCurses, one for conio to allow for specific functionalities available on
> each OS/Platform?

If someone finds it useful, then yes.

> And others too, what would you guys put in The Ada Library ? And
> why...see if we can filter out a list that could please everyone.

Why should we "please everyone"?! The only person that needs to be
"pleased" is the person that finds something useful in the library,
and manages to use it, saving development time. If that person turns
out to be "everyone", so much the better.

The fact that some people like Charles, and would never use SAL, and
other people make the opposite choice, is an argument for including
_both_ Charles and SAL, not for excluding both!


If you are suggesting some sort of review process, where people commit
time to reviewing and approving stuff that goes into the library, then
you do need to get agreement on what deserves reviewing. That's what
the ARG is doing for proposed additions to the Ada standard. Those
guys are getting paid (at least in part) to do that. If you want a
reviewed library, you need to pay the reviewers, in some way; it's a
lot of work.

One way to pay reviewers is to get the companies they work for to
allow them to spend company time reviewing code. I could do that for
some packages that are related to my work; anyone else out there in
the same situation?

-- 
-- Stephe

Re: Standard Library Interest?

[Stephane Richard]

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


"Stephen Leake" <Stephe.Leake@nasa.gov> wrote in message
news:uad8cbxhy.fsf@nasa.gov...
>
> www.adapower.com tried that, with very limited success. Before that,
> www.adahome.com had a similar idea. How is your site going to be
> better?
>
<snip>

A very justifiable question, because of the history of adapower and
adahome.(I didn't know adahome had such an idea, but then again I haven't
been in the Ada field long enough I suppose.

My idea of a centralized repository of libraries.  is really as it's name
implies.  I'd like to build, in essense, a hierarchy if libraries...where
users can go look (by any way they want) for what they need and looking for.
I plan on searching from more than one point of view  as in present the
library many different ways based on if and how much they know about what
they want.

A curious eye might not search the same way as someone looking for a
specific library or binding.  If I could I would give it a taxonomy chart of
some sort too for the sake of classification. :-).  whatever needs to be
done.  (again open to suggestions on how to search within the the Library) I
got ideas on my own and a good deal of em, but it dont mean I got every
"good" way there could be :-).

I want a database, of course for library records, but these records would
merely point to files in the server (possibly organized the same way as the
taxonomy chart.  sousers could quickly do research in the library either
based on a series of keywords, or based on categories or based on
name/pattern matching, based on dates (if they just want to know what's new
in the last week or so, etc etc...

I think the picture I got in my head is much clearer than what's in these
past paragraphs but I think I explained it clear enough.  :-).

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com








> Part of the problem is that just because an Ada package is on a web
> site doesn't mean it's a _good_ Ada package. So people don't want to
> use it.
>
> The Ada APIWG has the same issue; they need to do lots of reviewing of
> packages in order to give some value added, so people have a reason to
> trust the code. However, they have no way to pay people for the time
> spent reviewing, so it won't happen.
>
> I try to address this with my code by including unit tests. That
> doesn't seem to be enough.
>
> > I'd like some input on this from people. See for instance,
> >
> > 1. what could be part of it?
>
> Anything anyone ever found useful; someone else will need that same
> thing again.
>
> Of course, that leads to lots of code, and you need a really smart
> search engine to find anything. Which is another problem plaguing
> adapower.com; the search engine isn't very smart.
>
> > do we limit ourselves to platform independant
> > reusable libraries?
>
> Not "limit", but certainly state a "preference", and include that info
> in the searchable keywords.
>
> > 2. Do we include such things as AdaCL and such data structure based
> > libraries?
>
> Of course. They are useful. But allow all of them; Booch, Charles,
> SAL, Grace, etc.
>
> > 3. Do we go OS specific in different fields.  For example.  A binding to
> > PDCurses, one for conio to allow for specific functionalities available
on
> > each OS/Platform?
>
> If someone finds it useful, then yes.
>
> > And others too, what would you guys put in The Ada Library ? And
> > why...see if we can filter out a list that could please everyone.
>
> Why should we "please everyone"?! The only person that needs to be
> "pleased" is the person that finds something useful in the library,
> and manages to use it, saving development time. If that person turns
> out to be "everyone", so much the better.
>
> The fact that some people like Charles, and would never use SAL, and
> other people make the opposite choice, is an argument for including
> _both_ Charles and SAL, not for excluding both!
>
>
> If you are suggesting some sort of review process, where people commit
> time to reviewing and approving stuff that goes into the library, then
> you do need to get agreement on what deserves reviewing. That's what
> the ARG is doing for proposed additions to the Ada standard. Those
> guys are getting paid (at least in part) to do that. If you want a
> reviewed library, you need to pay the reviewers, in some way; it's a
> lot of work.
>
> One way to pay reviewers is to get the companies they work for to
> allow them to spend company time reviewing code. I could do that for
> some packages that are related to my work; anyone else out there in
> the same situation?
>
> -- 
> -- Stephe

Re: Standard Library Interest?

[Marin David Condic]

But we've been there and done that numerous times. That's why it needs 
some kind of "Official Standing" and probably some high level of 
integration, consistency, orthogonality, documentation, etc., etc. 
*Anybody* can pull together a bunch of existing stuff from the internet. 
Getting it accepted as "The Thing" requires something more.

MDC



Stephane Richard wrote:
> 
> A very justifiable question, because of the history of adapower and
> adahome.(I didn't know adahome had such an idea, but then again I haven't
> been in the Ada field long enough I suppose.
> 
> My idea of a centralized repository of libraries.  is really as it's name
> implies.  I'd like to build, in essense, a hierarchy if libraries...where
> users can go look (by any way they want) for what they need and looking for.
> I plan on searching from more than one point of view  as in present the
> library many different ways based on if and how much they know about what
> they want.
> 
> A curious eye might not search the same way as someone looking for a
> specific library or binding.  If I could I would give it a taxonomy chart of
> some sort too for the sake of classification. :-).  whatever needs to be
> done.  (again open to suggestions on how to search within the the Library) I
> got ideas on my own and a good deal of em, but it dont mean I got every
> "good" way there could be :-).
> 
> I want a database, of course for library records, but these records would
> merely point to files in the server (possibly organized the same way as the
> taxonomy chart.  sousers could quickly do research in the library either
> based on a series of keywords, or based on categories or based on
> name/pattern matching, based on dates (if they just want to know what's new
> in the last week or so, etc etc...
> 
> I think the picture I got in my head is much clearer than what's in these
> past paragraphs but I think I explained it clear enough.  :-).
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Martin Krischik]

Marin David Condic wrote:

> But we've been there and done that numerous times. That's why it needs
> some kind of "Official Standing" and probably some high level of
> integration, consistency, orthogonality, documentation, etc., etc.
> *Anybody* can pull together a bunch of existing stuff from the internet.
> Getting it accepted as "The Thing" requires something more.

Yes, a critical mass. The Library need to be big enough and have enough
developer support so that everybody wants it.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Standard Library Interest?

[Marin David Condic]

A "critical mass" of users? Ada is still looking for one itself. :-) Or 
a "critical mass" of code? There's lots of code out there - probably 
more than enough to be of interest to and useful for the average 
developer. But its all a jumble of stuff of mixed quality, etc. Pulling 
it together in one place doesn't change that. A few million lines of 
random code doesn't make a library anyone wants to use.

If it expects to gain some widespread use, it has to be a *good* library 
that is well integrated and well documented. I don't think it could be 
cobbled together from a bunch of packages found on the Internet.

MDC


Martin Krischik wrote:
> Marin David Condic wrote:
> 
> 
>>But we've been there and done that numerous times. That's why it needs
>>some kind of "Official Standing" and probably some high level of
>>integration, consistency, orthogonality, documentation, etc., etc.
>>*Anybody* can pull together a bunch of existing stuff from the internet.
>>Getting it accepted as "The Thing" requires something more.
> 
> 
> Yes, a critical mass. The Library need to be big enough and have enough
> developer support so that everybody wants it.
> 
> With Regards
> 
> Martin
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Stephen Leake]

Marin David Condic <nobody@noplace.com> writes:

> A "critical mass" of users? Ada is still looking for one itself. :-)

That's not true, by any sense of the word. "critical mass" means
"enough to sustain itself". ACT and other vendors are making a profit,
and expect to do so for the forseeable future; that meets the
definition of "critical mass".

I see the smiley, but this is too close to what many people say about
Ada; I didn't want to let it go uncorrected.

> Or a "critical mass" of code? There's lots of code out there -
> probably more than enough to be of interest to and useful for the
> average developer. But its all a jumble of stuff of mixed quality,
> etc. Pulling it together in one place doesn't change that. A few
> million lines of random code doesn't make a library anyone wants to
> use.

Right. A "critical mass" of users of the library is essential; that
means people find it useful, and will do word-of-mouth advertising.

> If it expects to gain some widespread use, it has to be a *good*
> library that is well integrated and well documented. I don't think
> it could be cobbled together from a bunch of packages found on the
> Internet.

Note that ACT is doing this "library" thing already; that's what all
the Gnat.* packages are.

-- 
-- Stephe

Re: Standard Library Interest?

[Martin Dowie]

"Stephen Leake" <Stephe.Leake@nasa.gov> wrote in message
news:ur81lgnvp.fsf@nasa.gov...
> Right. A "critical mass" of users of the library is essential; that
> means people find it useful, and will do word-of-mouth advertising.

I think the key phrase here is "people find it" :-)

You'd ba amazed who many Ada users aren't even aware of things
like ASIS!

Re: Standard Library Interest?

[Marin David Condic]

And that's a really critical issue for any library. You can't just count 
on its existence - or even its distribution with a compiler - to make it 
  well known and used. It has to satisfy some needs for the programmer 
(I think ASIS appeals to a particular market segment, but is not of much 
use to the general world - hence lack of visibility to most Ada users), 
it has to be well documented so the programmer can figure out what to do 
with it and it has to be actively *promoted* in some manner.

Even Coke buys ads all the time, despite its market dominance. Why? They 
want to keep their name in front of the public so they will *stay* at 
the top. If you want to get a library adopted, its going to take some 
kind of promotion to make it known to the world. Not all of that costs 
money, but one way or another, it ought to be part of the plan.

MDC


Martin Dowie wrote:
> 
> You'd ba amazed who many Ada users aren't even aware of things
> like ASIS!
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Martin Dowie]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F8810C0.3080506@noplace.com...
> And that's a really critical issue for any library. You can't just count
[snip]
> money, but one way or another, it ought to be part of the plan.

here here!

Re: Standard Library Interest?

[Marin David Condic]

With your "snip" I can't tell if you agree with me or are poking fun of 
me. :-) ("You can't just count money...")

Assuming you agree, here's the reason I show concern for the monetary 
aspects. No matter *how* a library gets built, *someone* is going to 
pay. Even if it was totally a volunteer effort - the volunteers end up 
funding it with their sweat equity. Even if the vendors get the library 
"free" (as in "free beer"), it still costs them money because they have 
to pay someone to incorporate it into their releases, make sure it 
compiles & runs, answer questions about it when customers call, etc. So 
even when no obvious $$$ change hands, $$$ are expended.

Given that no matter what you do, you will be dealing with an outflow of 
$$$, it would be wise to figure out how that's going to work up front. 
Volunteer efforts only go so far before everyone's wife starts insisting 
that you stop wasting time in front of the computer (mine is doing that 
as we speak! :-) and your kids want to go visit the Magic Kingdom. 
Volunteers tend to build whatever it is *they* want to whatever 
standards and quality *they* find acceptable. If you want to get a 
library that meets various expectations for style, quality, schedule, 
etc., its going to help a hell of a lot if there is some money in there 
greasing the skids. If you want to insure that the library is going to 
see continuous support and enhancement, some money thrown at it is going 
to do a lot more to insure that than all the idealistic volunteering 
we're likely to see. Long term success means it probably needs to be 
able to generate enough cash to pay a few salaries or it will likely 
flounder.

There are any nunmber of ways a library might be funded and not all of 
them involve someone writing a huge check up front. I discussed one 
option in the article I wrote for Ada Letters. It certainly isn't the 
only way to go - just one possible way. But whatever happens, I think 
those concerned with getting a library ought to put some thought into 
ways to fund its development and long term support.

MDC

Martin Dowie wrote:
> "Marin David Condic" <nobody@noplace.com> wrote in message
> news:3F8810C0.3080506@noplace.com...
> 
>>And that's a really critical issue for any library. You can't just count
> 
> [snip]
> 
>>money, but one way or another, it ought to be part of the plan.
> 
> 
> here here!
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Marin David Condic]

Stephen Leake wrote:
 >
 > That's not true, by any sense of the word. "critical mass" means
 > "enough to sustain itself". ACT and other vendors are making a
 > profit, and expect to do so for the forseeable future; that meets the
 >  definition of "critical mass".
 >
Critical mass to keep the language alive, or Critical Mass to make the
language a dominant force in the programming arena? Yeah, there's
probably enough mass out there to keep some compiler vendors alive for a
long stretch of years. But that was true of Jovial as well. If you want
to discuss some "serious market share" - like, oh, say 30% of "general
programming"? - That would be a "Critical Mass" big enough to make sure
that Ada had a long-term expanding future in the general world of
programming rather than a nice comfortable "retirement fund" of existing
programs in the DoD and some other areas where it still hangs on.


 >
 > Right. A "critical mass" of users of the library is essential; that
 > means people find it useful, and will do word-of-mouth advertising.
 >
Yeah, but I'd say we're a little far away from worrying about that just
yet. Figure out how to build a *good* library that has general
acceptance by the vendors and can react quickly to market demands. Do
some market research to find out what end-users really want and need in
a library. Get that far, and "Critical Mass" might just take care of
itself. Build a better mousetrap....

As for word-of-mouth advertising? That works sometimes, but it sure
wouldn't hurt at all to have an active campaign to get it noticed and
tried. How to do that is TBD - especially with a limited budget.


 >
 >
 > Note that ACT is doing this "library" thing already; that's what all
 > the Gnat.* packages are.
 >
I made note of that in my article in Ada Letters. You can read it and
find out what sort of issues there are with that. I don't object to the 
Gnat.Packages, but that's only good for Gnat.Users. What about Aonix, 
RR, DDC-I, Rational, et alia? Other vendors won't likely adopt something 
  from Gnat - at least not unless something is done to make it more of a 
"Group Project" where everyone has some ownership.

MDC
-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Stephen Leake]

Marin David Condic <nobody@noplace.com> writes:

> Stephen Leake wrote:
>  >
>  > That's not true, by any sense of the word. "critical mass" means
>  > "enough to sustain itself". ACT and other vendors are making a
>  > profit, and expect to do so for the forseeable future; that meets the
>  >  definition of "critical mass".
>  >
> Critical mass to keep the language alive, 

This.

> or Critical Mass to make the language a dominant force in the
> programming arena? 

Why should I care about this? As long as _I_ get to use Ada, other
people can make their own choices.

-- 
-- Stephe

Re: Standard Library Interest?

[Marin David Condic]

Why? Simple! The more people using Ada, the healthier and more 
long-lived it will be. The healthier Ada is, the more tools and 
utilities there will be to support it. A single compiler vendor with a 
single wealthy client could keep Ada "Alive" - but that doesn't mean 
that *you* have a compiler or any of the other spiffy things that might 
go with it. That's why I'd like to see Ada find some segment of the 
general computing population as its market - a big enough market means 
more cool stuff for everyone at prices that one might afford. And let's 
not even bring up "jobs" as another reason - but give that some thought.

MDC



Stephen Leake wrote:

> 
> Why should I care about this? As long as _I_ get to use Ada, other
> people can make their own choices.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Stephen Leake]

Marin David Condic <nobody@noplace.com> writes:

> Why? Simple! The more people using Ada, the healthier and more
> long-lived it will be. 

Healthy _enough_ is good enough for me. I (well, the US Government)
pay $18,000 or so a year to ACT to maintain their health. Enough
people currently do that to ensure the long-term viability of Ada, so
I don't have to do any more.

> The healthier Ada is, the more tools and utilities there will be to
> support it. A single compiler vendor with a single wealthy client
> could keep Ada "Alive" - but that doesn't mean that *you* have a
> compiler or any of the other spiffy things that might go with it.

True, but we are currently a long way from that.

> That's why I'd like to see Ada find some segment of the general
> computing population as its market - a big enough market means more
> cool stuff for everyone at prices that one might afford. 

Mmm. If "cool stuff" is things like I see advertised in Dr Dobbs, I'll
stick with the "nitch market stuff" I currently have, thank you.

I guess I'm saying I _like_ Ada having a small, but healthy, market
share. 

> And let's not even bring up "jobs" as another reason - but give that
> some thought.

That's a good point. It is a fact that managers make decisions based
on market share, not technical merit. So if the Ada market gets too
small, I might be forced to work in another language, no matter how
much proof I give of improved productivity with Ada.


I'm willing to participate in and contribute to a realistic, viable
Common Ada Library. But until someone says "I've got a large chunk of
change to invest in this business plan", I'm not going to give it
serious attention. For now, I'll stick with my Ada library on my
website.

-- 
-- Stephe

Re: Standard Library Interest?

[Marin David Condic]

At this point, nobody is proposing a business plan. I respect what 
you're saying because it soumds an awful lot like what I've been saying 
about volunteer efforts. Most people (myself included) have some amount 
of time they might kick in to build something if they thought there was 
soem reasonably charitable goal - like helping Ada to grow. But 
something like a CAL that was anything more than a container library 
(and thus a small, bounded project) is going to require a level of 
effort that is not likely to come from pure volunteerism. It certainly 
won't produce a high level of quality & consistency on anything 
resembling a schedule.

So I think it takes some kind of funding to get there. A "Business 
Venture" is one way of doing the funding, but that may be problematic. 
Someone would have to see a way of making money from the venture itself 
and that could get in the way of the library gaining widespread 
adoption. OTOH, a joint-venture of some form on the part of the compiler 
vendors, where the vendors treat it more as an R&D thing and don't 
expect it to generate huge amounts of cash on its own - that might be a 
workable answer. Or see if there's any government money left to back up 
Ada research. Or perhaps find some university support. One way or 
another, I think it would take a small handful of salaries to oversee 
the endeavor long enough to get something working in place. How to do 
that? I don't know, but it would take some level of act-of-will on the 
part of the vendors.

MDC


Stephen Leake wrote:
> 
> 
> I'm willing to participate in and contribute to a realistic, viable
> Common Ada Library. But until someone says "I've got a large chunk of
> change to invest in this business plan", I'm not going to give it
> serious attention. For now, I'll stick with my Ada library on my
> website.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Marin David Condic]

BTW: This is a fine example of why Ada would be better off if it had a 
more mainstream following and a large market share. If Ada were 30% of 
all software development, the vendors would look at a "paltry" $10 to 
$20 million in R&D money and not bat an eyelash. You'd have a full-up 
library of professional quality within 6 months and it would get 
continuing support and growth for years. With only a tiny niche (And one 
who's loyalty may at times be questionable - e.g. the DoD) your average 
vendor would likely want to look really carefully at even a fraction of 
that sum before expending it on any given R&D project.

MDC

Marin David Condic wrote:

> Ada research. Or perhaps find some university support. One way or 
> another, I think it would take a small handful of salaries to oversee 
> the endeavor long enough to get something working in place. How to do 
> that? I don't know, but it would take some level of act-of-will on the 
> part of the vendors.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Martin Krischik]

Marin David Condic wrote:

> If it expects to gain some widespread use, it has to be a *good* library
> that is well integrated and well documented. I don't think it could be
> cobbled together from a bunch of packages found on the Internet.

True. But It could be a starting point. You have to start somewhere or give
up and return to using C++.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Standard Library Interest?

[Stephane Richard]

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

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:1432352.H7KnUpQB8m@linux1.krischik.com...

> True. But It could be a starting point. You have to start somewhere or
give
> up and return to using C++.
>

I'm affraid I have to agree with Marin David Condic on this one. if we don't
start it the right way we can't expect it to finish the right way either.
Code wise well I'm sure that even if we dont all use the "Ada quality And
Style" standards and suggestions, we all write decent code as in good
variable naming, clear function names, etc etc....so maybe we can used that
code itself, or play with it to make it comply to a given standard.  But
documentation wise, it's a different story.  As Warren said on one of his
messages, a lot of code I've seen to can't even answer the question "Why do
I need this thing?"  Others aren't clear as to how to use it, what are the
pre requesits, and other "what I deem essential" information on the package
and it's contents.

I agree to not reinvent the wheel.  But for the sake of the quality of the
whole library, maybe we can take a chizel and pick at that wheel a little?
:-).  (again another cheap attempt at a metaphore ;-).  The question is
where do we draw the line?  As in sure there's code outthere to sort an
array many different ways, how do we determine that code is bad? Code should
be acceptable provided it has clear names throughout the library for
variables, procedures, functions, package names, task names etc etc....a
minimal source code commenting scheme, and  a minimal documentation (that is
detailed enough so that anyone can read it and use the given library as it
was meant to be used.

What we could do perhaps is in teh revision process take anycode out there
and first see how bad or good it is, see what needs to be added (comment
wise) see what the doc says and conclude of it's viability as a library
component.  I dont know how everyone codes, but those that I do know how
they code, so far, I'd throw their code right in the library with both my
eyes closed :-).  Documentation wise?  Well that can vary from library to
library.   Sure that means more work for bigger packages, but for the sake
of the quality of the whole library, this process should be close to
mandatory.

For documentation it doesn't really need to be a document file, could be a
sample program that is documented comment wise enough to explain the where
and how to's then either the author of the code or anyone that feels like it
really could take that sample program, and form a decent documentation from
it.....what the document should state?  well that we can work on :-)....but
as a basis it should say,
What it is,
How it's organized (a text hierarchy of packages might be quickly done and
clear enough).
Relationships between the parts
Quick listing of procedures and function (as per the spec file).  perhaps
AdaBrowse can do a fine job of that without changes.
How to's (how to use it)
Discrepencies (if any)
Pre-requisites to using the library...as such
    - Which OS it is supposed to work for
    - Which version of the OS and the Compiler

basically. :-)

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[Martin Krischik]

Stephane Richard wrote:

> "Martin Krischik" <krischik@users.sourceforge.net> wrote in message
> news:1432352.H7KnUpQB8m@linux1.krischik.com...
> 
>> True. But It could be a starting point. You have to start somewhere or
> give
>> up and return to using C++.

> I agree to not reinvent the wheel.  But for the sake of the quality of the
> whole library, maybe we can take a chizel and pick at that wheel a little?

Shure. If we use a CVS archive we could first add the lib to the CVS and
then chizel and pick at that wheel a little and then release it.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Standard Library Interest?

[Stephane Richard]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:11465909.GRNmmDTdgE@linux1.krischik.com...
> Stephane Richard wrote:
>
> > "Martin Krischik" <krischik@users.sourceforge.net> wrote in message
> > news:1432352.H7KnUpQB8m@linux1.krischik.com...
> >
> >> True. But It could be a starting point. You have to start somewhere or
> > give
> >> up and return to using C++.
>
> > I agree to not reinvent the wheel.  But for the sake of the quality of
the
> > whole library, maybe we can take a chizel and pick at that wheel a
little?
>
> Shure. If we use a CVS archive we could first add the lib to the CVS and
> then chizel and pick at that wheel a little and then release it.
>
> With Regards
>
> Martin
>
> -- 
> mailto://krischik@users.sourceforge.net
> http://www.ada.krischik.com
>

Well that sounds like a good M.O. (Method Of Operation) to me :-).

Re: Standard Library Interest?

[Marin David Condic]

First off, if you start with a sow's ear, you'll never get a silk purse. 
Cobbling something together from random bits of code collected from the 
internet is never going to get you a well-integrated, cvonsistent 
library. It is, and always will be, a bunch of disjointed parts that 
don't have anything to do with each other - except possibly that you got 
them all off the same disk.

Second off, this random collection of code has been on the Internet for 
years. Nobody has adopted it as a "Standard Library" despite its 
availability. Why is that? Could it be that there might be good reasons 
not to? I think there are good reasons not to.

Anyway, *IF* there was a general will to have a Conventional Ada Library 
and the vendors got on board with that, I don't think that 
implementation from the ground-up would be that much of a problem. Once 
you've laid the founation, you could start looking at things that came 
from assorted existing libraries and see if they could be adapted. That 
might be possible - but you need the foundation first.

MDC


Martin Krischik wrote:
> 
> True. But It could be a starting point. You have to start somewhere or give
> up and return to using C++.
> 
> With Regards
> 
> Martin
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Ching Bon Lam]

Marin David Condic <nobody@noplace.com> wrote in
news:3F836447.1000800@noplace.com: 

> But we've been there and done that numerous times. That's why it needs
> some kind of "Official Standing" and probably some high level of 
> integration, consistency, orthogonality, documentation, etc., etc. 
> *Anybody* can pull together a bunch of existing stuff from the
> internet. Getting it accepted as "The Thing" requires something more.

I haven't been there :) Could you name a couple examples? And what did go 
wrong that it didn't get accepted?

CBL

Re: Standard Library Interest?

[Marin David Condic]

Years ago in Ada83 there was an effort by (I think?) Richard Conn? It 
was affiliated with some university - it may even still be out there. He 
was assembling all sorts of Ada code and trying to classify it for easy 
reuse. A noble effort. I think it suffered from a couple of factors: 1) 
The "Not Invented Here" syndrome - which makes it tough for any library 
(but can be overcome). 2) The general inconsistency from one package of 
stuff to the next - no integration. 3) Often poor quality of what was 
there - things might or might not even compile, much less run. 4) 
Varying styles & interfaces - nothing you saw in one package was going 
to be mirrored in another package. ) Lack of documentation - or at least 
spotty and inconsistent. You might have the code but you might not be 
able to figure out what to do with it.

These are just some guesses on my part as to why this didn't gain any 
sort of huge acceptance on the part of the Ada community. I'm sure 
people used it & it had some value, but it never caught on like it 
should have.

You can also look at the various Ada websites that are out there and all 
the assorted libraries of stuff that is offered up. Yes, people use it, 
but there is a lot of overlap, inconsistency, lack of integration, lack 
of documentation, varying quality, varying styles, etc. There is no 
overall consensus that any one particular library for any one particular 
capability is "The Thing".

Adding yet another library out there with no "Official" standing or 
endorsement is doing just that - adding another library to the mess. It 
may or may not have a large group of followers. It may or may not have a 
high level of integration and consistency. It may or may not be well 
documented. There's no reason to believe that it would become so 
"Dominant" that the vendors would be clamoring to put it on their 
distribution disks.

But as I've said elsewhere, anyone who wants to is free to go ahead and 
try. I even hope they might succeed. I just won't waste my time on 
something that doesn't at least start with some level of acceptance by 
the ARG and the vendors.

MDC


Ching Bon Lam wrote:
> 
> 
> I haven't been there :) Could you name a couple examples? And what did go 
> wrong that it didn't get accepted?
> 
> CBL


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> Years ago in Ada83 there was an effort by (I think?) Richard Conn? It 
> was affiliated with some university - it may even still be out there. He 
> was assembling all sorts of Ada code and trying to classify it for easy 
> reuse. A noble effort. I think it suffered from a couple of factors: 1) 
> The "Not Invented Here" syndrome - which makes it tough for any library 
> (but can be overcome). 2) The general inconsistency from one package of 
> stuff to the next - no integration. 3) Often poor quality of what was 
> there - things might or might not even compile, much less run. 4) 
> Varying styles & interfaces - nothing you saw in one package was going 
> to be mirrored in another package. ) Lack of documentation - or at least 
> spotty and inconsistent. You might have the code but you might not be 
> able to figure out what to do with it.

Everyone wants something "ready to go". This isn't a bad thing, since
I like that too ;-)

But getting there is difficult, it seems. If I was to take on a package
integrator role, focusing only on the GNAT world (for example), here
are some of the challenges that I would face:

- Ada is not a preprocessed language, yet there must be some code
   tweaks for each environment:

   - Different pragma Linker_Options depending upon platform (for
     linker convenience)
   - C macro value insertion (by various means)
   - Some language constructs don't compile, due to version specific
     GNAT bugs.

   This is addressable with gnatprep, but it adds a layer of complexity
   to the task at hand (and maintenance). This adds some layer of
   complication when it comes to users reporting bugs (you must relate
   the installed source line back to the original "template" source).

- Some distributions must be distributed in original, unmodified form.

   This requires you to work out "patches" that can be applied at
   install time (not a show stopper, but it adds "work"). Actually, this
   is perhaps the best thing that can be done, but it does require extra
   effort.

- GNAT installation challenges:

   Different versions of GNAT have different *.ali file format differences.
   This one drives me crazy.  I am now in the midst of producing a
   APQ binary release for GNAT-3.15p, because I have discovered that
   my GNAT-3.14p binary release won't work for 3.15p users (win32).

   That means that I have to produce different binary installs for the
   same win32 environment, just to accomodate different
   flavours of GNAT. How many flavours of GNAT should you support?

   - Then add the never ending thrashing of changes from M$, on the
     win32 side.

- Platform related installation challenges:

   No registry in Linux/UNIX/*BSD. So different install scripts/processes
   must be tested and documented. Often shells differ in their support.
   Even the same shell, but different versions have various bugs that
   can get in the way (bash).

   - The biggest annoyance that I have on a *NIX platform, is where is
     the correct place to put Ada packages?   Where do all those *.ali
     files belong?

     It would be nice to have
     a "STANDARD" or "accepted practice" answer to this question.

     Should it be under /opt somewhere? The LSB never mentions Ada, that
     I am aware of.

     I use the GNAT environment variables ADA_INCLUDE_PATH/ADA_OBJECTS_PATH,
     but what if the user does not have these defined?  Then what?

     Should I use gnatls -v output to guide the install?

- Documentation: Libraries tend not to get used if they lack proper
   classification and documentation. For me, the first thing I look for
   is the answer to "why do I need this package/function?"

   So much documentation out there, fails to answer this basic question.

- TESTING. This one is big, IMHO.

   - The user needs confidence that it is "ready to go". The only way
     this assurance can be there, is that there are some tests that
     can be used to measure this in a limited way.  This is a major
     undertaking for some packages.

Just some points to ponder (I am not suggesting the idea is hopeless). ;-)


AS A SIDE NOTE, I wish that GNAT would allow you to package
all of those pesky *.ali files into a libever.ali.a archive file, using
ar. But GNAT would need to be enhanced to do this. Is Robert lurking
out there? ;-)

Warren.

Re: Standard Library Interest?

[tmoran]

Some comments from the experience of making the Claw library on
four different Ada compilers:

> - Ada is not a preprocessed language, yet there must be some code
>   tweaks for each environment:
>   - Different pragma Linker_Options depending upon platform (for
>     linker convenience)
>   - Some language constructs don't compile, due to version specific
>     GNAT bugs.
  Sometimes the changes are needed in the package specs, not just
the bodies.  For instance, one version of Gnat required a whole bunch
of stuff to get moved from private to public, with appropriate order
of declaration changes.  On a large library like Claw, it took a lot
of work to find and fix all occurrences.  IIRC we had to use a tool
that parsed the specs and figured out the inheritance pattern and
flagged the problematic cases.  And no, we couldn't use ASIS because
Gnat wouldn't compile, and thus wouldn't produce ASIS databases, for
the relevant packages.

>  Different versions of GNAT have different *.ali file format differences.
  This doesn't directly apply to Claw, since it's distributed as source
code, but there are other changes needed every year when there's a new
Gnat release.  Most recently, they changed the default behavior of
elaboration so we could either tell all users to add -gnatE to their
compile lines, an option unlikely to be greeted with applause, or go
through the entire Claw library inserting specific pragma Elaborate's.
And of course the library and tests must all be recompiled and run with
each vendor's new compiler release.  When there are new bugs, they may be
non-trivial to find and work around, and may require significant knowledge
of the inner workings of the library.  This work is of course proportional
to the number of versions and vendors of Ada compilers.  (Of course if the
vendors supported the Standard Library, they would have done this before
releasing a new compiler version.  :)

Re: Standard Library Interest?

[Frank]

Hi!

If we cant achieve an optimal solution, why not try (one of the) second best
solutions:

My idea of a second best solution would be that
-urge the community members not to reinvent weels (like building then-th
container library) in your projects, resuse exisiting libraries (a fairly
well know "best practice" for programmers)
-throw your semi-completed projects (those that you gave up because of lack
of time or interest) on the net (perhaps adaworld could provide a "junkyard"
or "dead code" - folder for such things) - giving others who come across the
same inspiration the possibility to continue (if possible :-)). Sourceforge
and similar
is not on my mind, I imagine something very much less "official".(How to
handle copyrights I dont know :-)

Frank

Re: Standard Library Interest?

[chris]

Frank wrote:
> Hi!
> 
> My idea of a second best solution would be that
> -urge the community members not to reinvent weels (like building then-th
> container library) in your projects, resuse exisiting libraries (a fairly
> well know "best practice" for programmers)

Good idea.

> -throw your semi-completed projects (those that you gave up because of lack
> of time or interest) on the net (perhaps adaworld could provide a "junkyard"
> or "dead code" - folder for such things) - giving others who come across the
> same inspiration the possibility to continue (if possible :-)). Sourceforge
> and similar is not on my mind, 

I'd rather use Savannah than SF for anything.  SF keep changing their 
T&C's and I've lost track of what's what on there.

 > I imagine something very much less "official".(How to
> handle copyrights I dont know :-)

I would be willing to submit some of my work provided I got the ability 
to work on it and extend it.  I would even be willing to hand over my 
copyright, again providing I got the ability to play with it (also some 
credit) and it was some kind of group.

I will be working in C and Java at Uni (oh, and Hydra), so Ada related 
work will fall quite considerably.  It'd be good if someone else could 
contribute as the code is likely to be in the "junkyard" for a while.

Right now I'm working on a simple raster based graphics lib (no 
convolutions/filtering, just the ability to manipulate single/groups of 
pixels), and am almost ready to load and save bitmaps.  After that I'm 
going to finish libpng and add support for that.


Chris

Re: Standard Library Interest?

[Robert I. Eachus]

Marin David Condic wrote:
> Years ago in Ada83 there was an effort by (I think?) Richard Conn? It 
> was affiliated with some university - it may even still be out there. He 
> was assembling all sorts of Ada code and trying to classify it for easy 
> reuse. A noble effort. I think it suffered from a couple of factors: 1) 
> The "Not Invented Here" syndrome - which makes it tough for any library 
> (but can be overcome). 2) The general inconsistency from one package of 
> stuff to the next - no integration. 3) Often poor quality of what was 
> there - things might or might not even compile, much less run. 4) 
> Varying styles & interfaces - nothing you saw in one package was going 
> to be mirrored in another package. ) Lack of documentation - or at least 
> spotty and inconsistent. You might have the code but you might not be 
> able to figure out what to do with it.

The Ada Repository on SIMTEL20.  Later moved several times
http://www.decus.org/libcatalog/document_html/vs0091_25.html
I think that most of the Ada Repository software is in Ada Basis:
http://www.iste.uni-stuttgart.de/ps/ada-software/ada-software.html
which is somewhat more up to date.


-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Stephen Leake]

"Stephane Richard" <stephane.richard@verizon.net> writes:

> "Stephen Leake" <Stephe.Leake@nasa.gov> wrote in message
> news:uad8cbxhy.fsf@nasa.gov...
> >
> > www.adapower.com tried that, with very limited success. Before that,
> > www.adahome.com had a similar idea. How is your site going to be
> > better?
> >
> <snip>
> 
> A curious eye might not search the same way as someone looking for a
> specific library or binding.  If I could I would give it a taxonomy chart of
> some sort too for the sake of classification. :-).  whatever needs to be
> done.  (again open to suggestions on how to search within the the Library) I
> got ideas on my own and a good deal of em, but it dont mean I got every
> "good" way there could be :-).
> 
> I want a database, of course for library records, but these records would
> merely point to files in the server (possibly organized the same way as the
> taxonomy chart.  sousers could quickly do research in the library either
> based on a series of keywords, or based on categories or based on
> name/pattern matching, based on dates (if they just want to know what's new
> in the last week or so, etc etc...

You are describing a huge amount of work. Cataloging random code is
hard. Do you really have the resources to keep doing that for the next
20 years? How are you currently getting paid?

Marin has an article in the current Ada Letters that goes into some of
this; good reading.

-- 
-- Stephe

Re: Standard Library Interest?

[Stephane Richard]

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

> You are describing a huge amount of work. Cataloging random code is
> hard. Do you really have the resources to keep doing that for the next
> 20 years? How are you currently getting paid?
>
> Marin has an article in the current Ada Letters that goes into some of
> this; good reading.
>
> -- 
> -- Stephe

Indeed I am aren't I?  if it's what it takes it's what I'll do, and as for
getting paid, call it all (website and the Ada Library should it happen) my
contribution to the free community :-).  I'm doing this for free. And the
resources I currently use for it (web space and development) are my own.
it's my endeavour to Ada and it's community.  All the software I use is
OpenSource and requires but my time :-)  not my money.

Before I go ahead and do that, I'm getting in touch with a few key peole
right now to see if there's another way or perhaps something already started
or done (and still active) that we may or may not know about. that we could
harnest or consult in a reasonable fashion.  Whether I make it or I use (if
something's viable somewhere) I dont mind either way, but I do like the idea
of having one.

As for querying the database and producing expected results, I already have
a lot of it done based on other projects I did, so I'd be lying to say I'll
be creating 100% of it all :-)....but I will be creating a good part of it
however. :-).


-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[Marin David Condic]

Did that come out already? I had not seen it yet. Well, O.K. I *did* see 
it. ;-) I just didn't see it in Ada Letters. Maybe the mail is late.

MDC


Stephen Leake wrote:
> 
> Marin has an article in the current Ada Letters that goes into some of
> this; good reading.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Hyman Rosen]

Marin David Condic wrote:
> Did that come out already? I had not seen it yet.

Yes. Your article is badly formatted, I'm afraid.
There are many words with wide internal spaces.

Re: Standard Library Interest?

[Robert I. Eachus]

Stephane Richard wrote:

> My idea of a centralized repository of libraries.  is really as it's name
> implies.  I'd like to build, in essense, a hierarchy if libraries...where
> users can go look (by any way they want) for what they need and looking for.
> I plan on searching from more than one point of view  as in present the
> library many different ways based on if and how much they know about what
> they want.

Let me propose a baby step forward.  If we do this right we are going to 
need a central registrar of top level library names.  The ARG has 
implicitly grabbed Ada, Interfaces, and System, plus all the names of 
things declared directly in Standard.  I want to work with others on 
what belongs in Statistics, and as far as I am concerned, any name in 
Eachus is mine, all mine. ;-)

But it would be nice to have a central repository of all these names, 
with links to where the sources can be found (or purchased), and a 
protocol for allocating names and adjudicating conflicts.  And yes, I'm 
working on getting my useful libraries organized, documented and 
available on the web.  If no one else volunteers, I'll start work on it. 
  But please! wait until we can get a group of people to handle this, 
and a central web site, perhaps at www.ada-auth.org.  If people do like 
this idea, then eventually it should become a part of WG9.  There are 
lots of such registries under ANSI and ISO, so that, for example, every 
Ethernet  device has a unique ID.

> A curious eye might not search the same way as someone looking for a
> specific library or binding.  If I could I would give it a taxonomy chart of
> some sort too for the sake of classification. :-).  whatever needs to be
> done.  (again open to suggestions on how to search within the the Library) I
> got ideas on my own and a good deal of em, but it dont mean I got every
> "good" way there could be :-).

> I want a database, of course for library records, but these records would
> merely point to files in the server (possibly organized the same way as the
> taxonomy chart.  sousers could quickly do research in the library either
> based on a series of keywords, or based on categories or based on
> name/pattern matching, based on dates (if they just want to know what's new
> in the last week or so, etc etc...

> I think the picture I got in my head is much clearer than what's in these
> past paragraphs but I think I explained it clear enough.  :-).

A few years ago, in a project that for all I know is still groaning 
along somewhere, I said that with books, we had libraries and librarians 
for over a thousand years before moveable type, with hypertext, we were 
trying to do it the other way around.  Text search engines for the World 
  Wide Web have made it possible to find things for now.  And I think 
the right approach going forward is to design the registration records 
as web pages with (hopefully!) the right (XML?) tags to help people find 
what they are looking for.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Stephen Leake]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> Let me propose a baby step forward.  If we do this right we are going
> to need a central registrar of top level library names.  

Good point.

> The ARG has implicitly grabbed Ada, Interfaces, and System, plus all
> the names of things declared directly in Standard. I want to work
> with others on what belongs in Statistics, and as far as I am
> concerned, any name in Eachus is mine, all mine. ;-)

Hmm. I've grabbed SAL, but that was a deliberate pun; it means
"Stephe's Ada Library" _or_ "Standard Ada Library" :).

> But it would be nice to have a central repository of all these names,
> with links to where the sources can be found (or purchased), and a
> protocol for allocating names and adjudicating conflicts.  And yes,
> I'm working on getting my useful libraries organized, documented and
> available on the web.  If no one else volunteers, I'll start work on
> it. But please! wait until we can get a group of people to handle
> this, and a central web site, perhaps at www.ada-auth.org.  

I think that's the right place to do it. Randy?

-- 
-- Stephe

Re: Standard Library Interest?

[Marin David Condic]

I could agree that "Baby Steps" are important and that there would be 
some value in setting up some kind of central repository & name 
registry, but two questions:

1) Would the ARG & Vendors be receptive to the end result? They don't 
have to agree to endorse/distribute it up front, but if such a library 
were to exist & meet some expectations, would they get on board? Would 
they be willing to participate to the level of saying what it is they 
want to see in an end product? Would they be willing to sit in on 
periodic reviews to discuss direction, etc.? I'd want to see the effort 
produce something that the ARG and Vendors would *want* to put some 
stamp of approval on and distribute - but I'm not a mind reader.

2) Who is going to play "Editor/Publisher" to make sure that what comes 
in meets some sort of standards of acceptability? It can't be a 
free-for-all with anybody building anything they like with whatever 
style they like and to whatever quality they like, etc. I'd think that 
an editor (or small group of editors) could work with prospective 
authors to make sure they are working on the "right" things and to the 
"right" guidelines. Otherwise, its just another inconsistent mess - but 
all under one roof.

I could see other questions like licensing, etc. coming into the mix 
rather quickly, but for now, I'd just like to see #1 and #2 answered.

BTW: I'd propose "CAL" as the root package name and from there, you can 
have "CAL.Statistics". But be sure to build the statistics stuff 
utilizing whatever comes under "CAL.Containers". ;-)

MDC


Robert I. Eachus wrote:
> 
> Let me propose a baby step forward.  If we do this right we are going to 
> need a central registrar of top level library names.  The ARG has 
> implicitly grabbed Ada, Interfaces, and System, plus all the names of 
> things declared directly in Standard.  I want to work with others on 
> what belongs in Statistics, and as far as I am concerned, any name in 
> Eachus is mine, all mine. ;-)
> 
> But it would be nice to have a central repository of all these names, 
> with links to where the sources can be found (or purchased), and a 
> protocol for allocating names and adjudicating conflicts.  And yes, I'm 
> working on getting my useful libraries organized, documented and 
> available on the web.  If no one else volunteers, I'll start work on it. 
>  But please! wait until we can get a group of people to handle this, and 
> a central web site, perhaps at www.ada-auth.org.  If people do like this 
> idea, then eventually it should become a part of WG9.  There are lots of 
> such registries under ANSI and ISO, so that, for example, every 
> Ethernet  device has a unique ID.
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Stefan Lucks]

I like the baby-step proposal. 

However, such a standard library would rather be a collection of different
sublibraries (typically packages), and the interfaces would not always be
consistent. That is unavoidable, and most programmers could live with
that. (Even e.g. the JAVA library is not always consistent, though its
designers did seriously try ...)

One problem with any library is that you may be using different versions
on different platforms. Another problem is that if you fetch the library
from some web site (which is assumed for the baby-step propoal), you may
first want to check if it runs in your environment at all.

[...]
> to the "right" guidelines. Otherwise, its just another inconsistent mess
[...]

One thing that might significantly improve the acceptance for such a
collection of (sub-)libraries would be to support a *standartised*
*interface* at least for

  1. a unit test for the package and

  2. checking the current version number of package

This would help people to actually integrate these library packages into
their stuff, doing automatic unit and integration tests ...

Also, this does not seem to hinder the integration of already existing
libraries into the standard library:

  --  Dealing with the version number is trivial, anyway.

  --  Assuming the authors of the already existing library did implement 
      unit tests for their library at all, writing one additional 
      procedure for doing the full unit test can't be too difficult.


Consider you *with'ed* the package "some.weird.package_name" from the 
standard library. Without having to look into either source code or other 
documentation, I'd like to compile and then run a unit test by calling:

	some.weird.package_name.Full_Self_Test(0);

The "0" indicates "accept no errors", see below.

Checking the version number should be done similarly. You can't always
prevent version skew, but can automatically detect potential problems.


> BTW: I'd propose "CAL" as the root package name and from there, you can 
> have "CAL.Statistics". But be sure to build the statistics stuff 
> utilizing whatever comes under "CAL.Containers". ;-)

Here an example (using "CAL" as the root package):

CAL.Containers.Bags.Full_Self_Test(expected_number_of_errors => n);
  -- raises an exception if not exactly n tests fail 
  --   (usually: n=0, but sometimes you may want to "with" a package
  --    even though you know that the unit test reveals some bugs)

CAL.Containers.Bags.Require_Version_Number(3, 14, or_newer => true);
  -- raises an exception if version of CAL.Containers.Bags is 3.13 or 
  -- older; does not raise for newer versions, such as 3.15 or 4.2
  -- if or_newer is false (default), then Require_Version_Number raises if 
  -- the version number is not exactly 3.14. 

-- now start doing your real stuff, e.g.:

CAL.Containers.Bags.Insert(the_bag => my_bag, the_item => my_item);


The above is just an example. Perhaps some of you have better ideas for
the actual interface to do a unit test and to check the version number.

Note that both unit test and version number deal with CAL.Containers.Bags
in the above example, (i.e., with the "innermost" package) not with
CAL.Containers or even CAL itself. I am not sure, whether a package should
be hold responsible for its child packages. A package such as
CAL.Containers may not even know all of its child packages, right?

In other words, for CAL and CAL.Containers we should avoid to call (or 
even implement) Full_Self_Test and Require_Version_Number ...

-- 
Stefan Lucks      Th. Informatik, Univ. Mannheim, 68131 Mannheim, Germany
            e-mail: lucks@th.informatik.uni-mannheim.de
            home: http://th.informatik.uni-mannheim.de/people/lucks/
------  I  love  the  smell  of  Cryptanalysis  in  the  morning!  ------

Re: Standard Library Interest?

[Stephen Leake]

Stefan Lucks <lucks@th.informatik.uni-mannheim.de> writes:

> I like the baby-step proposal. 
> 
> However, such a standard library would rather be a collection of different
> sublibraries (typically packages), and the interfaces would not always be
> consistent. That is unavoidable, 

Perhaps "really expensive", or "hard to achieve". It is _not_
"unavoidable". I hate all absolutes :).

> and most programmers could live with that. (Even e.g. the JAVA
> library is not always consistent, though its designers did seriously
> try ...)

Which is one reason I don't like the Java libraries. But a lot of
programmers do live with them. 

It would be a great selling point if the Ada library did _not_ have
that problem!

> One problem with any library is that you may be using different
> versions on different platforms. 

Why would that happen? The Gnu tools manage many platforms with no
version problems. Well, some poorly-supported platforms may take a
while to catch up to the latest version, but "gcc 2.8.1" means the
same thing on all platforms.

> Another problem is that if you fetch the library from some web site
> (which is assumed for the baby-step propoal), you may first want to
> check if it runs in your environment at all.

Yes, which is why all library packages must come with complete tests.
Again, the Gnu tools typically come with tests (well, the compiler
doesn't, but the others do). Yes, this is more work, but it is what
makes the library usable.

> One thing that might significantly improve the acceptance for such a
> collection of (sub-)libraries would be to support a *standartised*
> *interface* at least for
> 
>   1. a unit test for the package and

I find Aunit to be a good unit test framework (see
http://savannah.nongnu.org/projects/grace/ for a working example).
 
>   2. checking the current version number of package

We could require each top-level package to provide a Version function,
that returns a string. Also follow the Gnu convention of including
that string in the tar.gz file name for distributions.

> This would help people to actually integrate these library packages into
> their stuff, doing automatic unit and integration tests ...

yes. Note that SAL (http://www.toadmail.com/~ada_wizard/) does this.
So let's all just use SAL :).

> Also, this does not seem to hinder the integration of already existing
> libraries into the standard library:
> 
>   --  Dealing with the version number is trivial, anyway.
> 
>   --  Assuming the authors of the already existing library did implement 
>       unit tests for their library at all, writing one additional 
>       procedure for doing the full unit test can't be too difficult.

Well, switching from one unit test framework to another is painful.
For example, most of the SAL unit tests do _not_ use the Aunit
framework, because I discovered that late in the process. The
non-Aunit tests write output files, which are diffed (by the Makefile)
against known-good output files. It is a _major_ amount of work to
change those tests to Aunit style. But as long as the Makefile can
return a Pass/Fail status, it doesn't matter too much.

More important are things like standard names for common operations;
do we "Add" an element to a container, or "Insert" it? That's a major
problem for integrating existing code. SAL attempts to do this, but
doesn't fully succeed.

> Consider you *with'ed* the package "some.weird.package_name" from
> the standard library. Without having to look into either source code
> or other documentation, I'd like to compile and then run a unit test
> by calling:
> 
> 	some.weird.package_name.Full_Self_Test(0);

The unit test code does _not_ belong in the package itself. If it is,
it would be included in every delivered executable; major waste of
space. It should be in a child package.

But it's really not reasonable to define unit tests at this level.
Many unit tests require auxiliary packages, which should _not_ be
children (see SAL for examples). Providing a Makefile that runs the
tests and produces a pass/fail is much more reasonable.

> Checking the version number should be done similarly. You can't always
> prevent version skew, but can automatically detect potential
> problems.

Hmm. I guess you mean one package depends on specific versions of
other packages, and you want to check that at run-time (or better,
compile time). That problem is solved by tools like Redhat Package
Manager (rpm); it's a big problem, and we should not try to invent new
solutions. 

Just an example of the kinds of discussions an integrated library
committee will be having ...

-- 
-- Stephe

Re: Standard Library Interest?

[Stephane Richard]

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

>
> Perhaps "really expensive", or "hard to achieve". It is _not_
> "unavoidable". I hate all absolutes :).
*** I hate absolutes too, except for my depts (Abs(-whatever) is Whatever)
so my dept would be cleared hhehehe...

>
> Why would that happen? The Gnu tools manage many platforms with no
> version problems. Well, some poorly-supported platforms may take a
> while to catch up to the latest version, but "gcc 2.8.1" means the
> same thing on all platforms.
>
*** I agree here.  perhaps we could keep a history somehwere of versions
that have been released before so that they could access them....\archives
folder in each package's folder, or something? if one really wants to use a
previous version.

>
> I find Aunit to be a good unit test framework (see
> http://savannah.nongnu.org/projects/grace/ for a working example).
>
*** I heard of that one, it does look pretty good as a testing unit...but I
wouldn't limit it to one as they are more than one testing engines that do a
good job...all we really need is to know that it has been tested and the
results of that test and I would be contended.

> We could require each top-level package to provide a Version function,
> that returns a string. Also follow the Gnu convention of including
> that string in the tar.gz file name for distributions.
>
*** that would and could work :-).   or at least a file with a version
history (with the top most line being the most recent version ... something
clear somewhere to say that "this is the one you want"/

>
> More important are things like standard names for common operations;
> do we "Add" an element to a container, or "Insert" it? That's a major
> problem for integrating existing code. SAL attempts to do this, but
> doesn't fully succeed.

*** I second that motion, probably because of my non ada background (shame
on me :-).  but if we consider "polymorphism"  indeed a true library should
use consistent names for similar functions and procedure.  again do we Open
a file or do we Load a file, do we Save or Store a file?  anything in the
library that saves a file (log file, report file, any file at all) should
use the same name.

*** likewise any package/library that has the ability to display itself on
the screen should have standard names ... do we show the form, display the
form, do we use a property like Visible set to True, pick one and stick to
it. :-).

*** Definitaly reduces the learning curve of the whole library this way.  I
have to agree with that :-).

>
> But it's really not reasonable to define unit tests at this level.
> Many unit tests require auxiliary packages, which should _not_ be
> children (see SAL for examples). Providing a Makefile that runs the
> tests and produces a pass/fail is much more reasonable.

*** How about an independant file for the testing?  as in
you have SAL and all its ramifications which represent the package/binding
whichever it may be.
and you have SAL_Test which would be a program that with's the SAL library
and performes the tests?
or somekind of standard.  maybe based on folders too (sorta like boost
library).
\src        <-  has the source code of the package itself (adn sub packages.
\test       <-  has source and/or binaries of the SAL_Test program.
\demos  <-  for demonstration programs of what the unit can do
etc etc.  maybe a  \docs for documents (which should be in one format only
somthing platform independant like HTML perhaps).

and the list goes on :-) for whichever and depending on the type of library
and/or binding.



>
> Hmm. I guess you mean one package depends on specific versions of
> other packages, and you want to check that at run-time (or better,
> compile time). That problem is solved by tools like Redhat Package
> Manager (rpm); it's a big problem, and we should not try to invent new
> solutions.

*** I second that motion.

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[Marin David Condic]

It is also an example of why you need some sort of "Editor/Publisher" to 
establish rules for style and content. It is also an example of why an 
"All Volunteer" effort is difficult to make work. For example, I like 
the notion of version numbering. (I incorporated it into my own personal 
library of stuff - its difficult to get it right - especially if things 
like containers have persistence) I also like the notion of built in 
tests. If the library establishes that it wants those sorts of things 
but a given "Volunteer" decides he doesn't like the idea or doesn't want 
to invest the time, how are you going to squeeze him to get it done? You 
can refuse to accept the work until it meets some standards - but then 
maybe you don't get much work to accept. Volunteers are always free to 
pick up their marbles and go home - or start their *own* standard library.

Its tricky to make something like this work and getting it right is time 
consuming - possibly expensive. That's why you want to be sure you're 
likely to meet with some acceptance of whatever you pull together before 
you go down that road.

MDC


Stephen Leake wrote:
> 
> Just an example of the kinds of discussions an integrated library
> committee will be having ...
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Stefan Lucks]

On 9 Oct 2003, Stephen Leake wrote:

> Stefan Lucks <lucks@th.informatik.uni-mannheim.de> writes:

> >   1. a unit test for the package and
> 
> I find Aunit to be a good unit test framework (see
> http://savannah.nongnu.org/projects/grace/ for a working example).

You missed my point! 

Think of a "customer" (i.e., any programmer who wants to "with" the
library) and call her A. A somehow (perpaps by downloading it from the web
site) gets her hands on the source code of some library packages. The very
first thing she will (or at least should) do is to ask each package: "Are
you okay?" ("Is this package compiling under my compiler and running on my
target platform under my target platform's configuration?")

The best way to answer this question is to run the entire battery of unit
tests which have been used by the author of the library package. I would 
want to provide A with a simple button to fire the test battery. And this 
button should be at the same place and have the same shape and color for 
all packages of the standard library!

It is a non-issue for A, which test framework has been used by the author 
of the library package. 


> >   2. checking the current version number of package

> We could require each top-level package to provide a Version function,
> that returns a string. 

I had been thinking of that. However, natural sting comparison is 
different from comparing version numbers:
     "14.3" < "3.14"   (Ouch!)

> Also follow the Gnu convention of including that string in the tar.gz
> file name for distributions.

I agree, this is a good convention. But my point is: Allow A to check 
version numbers automatically, either at compile time or (early) when 
testing. The Ada compiler is an extremely powerful tool, so use it. 

> > 	some.weird.package_name.Full_Self_Test(0);
> 
> The unit test code does _not_ belong in the package itself. If it is,
> it would be included in every delivered executable; major waste of
> space. It should be in a child package.

OK, so use

	some.weird.package_name.Self_Test.Full_Self_Test(0);

instead. (However, I don't quite buy your wast-of-space reason. Any 
decent linker is able to throw away unused subprograms, right?)

> But it's really not reasonable to define unit tests at this level.
> Many unit tests require auxiliary packages, which should _not_ be
> children (see SAL for examples). Providing a Makefile that runs the
> tests and produces a pass/fail is much more reasonable.

Didn't Lady Ada free us from using makefiles? :-)

And who said that the auxiliary packages should be children? Just "with" 
them, when implementing your tests. If this does not compile because the 
"with"ed toolbox is not available, A has no chance to do these tests by 
herself anyway, even if she'd run make. 

(I can imagine some special cases and exceptional circumstances, where
your test needs external files, system- or platform-specific information,
...  This prevents providing the full test battery, i.e. Full_Self_Test
can't be implemented. Sometimes, even a reduced test battery could be
useful -- call it Main_Self_Test instead of Full_...)


> Hmm. I guess you mean one package depends on specific versions of
> other packages, 

I think, you missed my point again. Think as a "customer" A.

Consider an application with-ing some library package X version y.z. It
has compiled fine, passed all tests, and perhaps it has even passed some
code-reviews. Now it is compiled again, either for a different platform, 
or under a different compiler, or it has been modified/extended, ... 

There is an implementation of X available, and its version number is v(X).

If v(X) = y.z, then fine!

If v(X) < y.z, this may indicate great trouble. (However, perhaps A can 
download and install a more recent version of X.)

A's reaction on v(X) > y.z, may depend on her trust in the
upward-compatibility of the development of X ... At least for saftety- or
security-critical programs (and that is still the area where Ada is best
for), it would be prudent to check for things that may be broken by using
a version of X which is newer than y.z. The least thing I'd do would be to
read the changes-log of X.

My point is, I don't want A to *manually* compare y.z with v(X). (There
may be many Xs, and thus many pairs (v(X),y.z).) It is much better to do
these tests automatically, either at compile time or at least (early) at
test time. The Ada compiler is a great tool, so use it to simplify your 
life! :-)


> Just an example of the kinds of discussions an integrated library
> committee will be having ...

Ackn!

-- 
Stefan Lucks      Th. Informatik, Univ. Mannheim, 68131 Mannheim, Germany
            e-mail: lucks@th.informatik.uni-mannheim.de
            home: http://th.informatik.uni-mannheim.de/people/lucks/
------  I  love  the  smell  of  Cryptanalysis  in  the  morning!  ------

Re: Standard Library Interest?

[Stephen Leake]

Stefan Lucks <lucks@th.informatik.uni-mannheim.de> writes:

> On 9 Oct 2003, Stephen Leake wrote:
> 
> > Stefan Lucks <lucks@th.informatik.uni-mannheim.de> writes:
> 
> > >   1. a unit test for the package and
> > 
> > I find Aunit to be a good unit test framework (see
> > http://savannah.nongnu.org/projects/grace/ for a working example).
> 
> You missed my point! 

Well, I didn't. There are two points here; 

1) how to write the unit tests

2) how to invoke the unit tests.

Aunit is an answer to point 1.

> Think of a "customer" (i.e., any programmer who wants to "with" the
> library) and call her A. A somehow (perpaps by downloading it from
> the web site) gets her hands on the source code of some library
> packages. The very first thing she will (or at least should) do is
> to ask each package: "Are you okay?" ("Is this package compiling
> under my compiler and running on my target platform under my target
> platform's configuration?")
> 
> The best way to answer this question is to run the entire battery of unit
> tests which have been used by the author of the library package. 

Yes. That's point 2).

> I would want to provide A with a simple button to fire the test
> battery. And this button should be at the same place and have the
> same shape and color for all packages of the standard library!

Yes. My answer is "from you normal command line, run 'make test'".
Your answer appears to be "somehow run code that invokes
Foo.Self_Test".

> It is a non-issue for A, which test framework has been used by the
> author of the library package.

Well, it matters a little, if it affects the answer to point 2). But
it mostly doesn't matter.

> > >   2. checking the current version number of package
> 
> > We could require each top-level package to provide a Version function,
> > that returns a string. 
> 
> I had been thinking of that. However, natural sting comparison is 
> different from comparing version numbers:
>      "14.3" < "3.14"   (Ouch!)

Ah. I missed that you wanted them at runtime. Yes, that would require
two or three integers. Or convert to float first :).

> OK, so use
> 
> 	some.weird.package_name.Self_Test.Full_Self_Test(0);
> 
> instead. (However, I don't quite buy your wast-of-space reason. Any 
> decent linker is able to throw away unused subprograms, right?)

In a perfect world, yes. But no current linker (that I use or am aware
of) does this.

There's also the information hiding and general code organization
issue; unit test code is a different beast than implementation code,
and doesn't belong in the same package.

> Didn't Lady Ada free us from using makefiles? :-)

From parts of them, yes; the makefile no longer has to specify the Ada
source file dependencies. But as I have said before here, there is
much more to a real project than the Ada source code.

> And who said that the auxiliary packages should be children? Just
> "with" them, when implementing your tests. If this does not compile
> because the "with"ed toolbox is not available, A has no chance to do
> these tests by herself anyway, even if she'd run make.

Sometimes you need visibility into the private part to implement a
good unit test; that means at least some of the unit test has be a
child package.

> (I can imagine some special cases and exceptional circumstances, where
> your test needs external files, system- or platform-specific information,
> ...  This prevents providing the full test battery, i.e. Full_Self_Test
> can't be implemented. Sometimes, even a reduced test battery could be
> useful -- call it Main_Self_Test instead of Full_...)

I don't accept that a full unit test "can't be provided". If you can't
test it, it doesn't do anything real :). Maybe it's hard or expensive;
that's different. That would have to be one of the library policies;
how expensive can the unit tests be?

> > Hmm. I guess you mean one package depends on specific versions of
> > other packages, 
> 
> I think, you missed my point again. Think as a "customer" A.
> 
> Consider an application with-ing some library package X version y.z. 

Ada can't say "version y.z" in a with clause (and no, I don't think we
want a language extension for that :). But I think I know what you
mean. Let's call the Application Y; the last time Y was tested, it
used X version y.z.

> There is an implementation of X available, and its version number is v(X).
> 
> If v(X) = y.z, then fine!

Right. Hopefully, this is tested at configure time (pre compile-time;
I'm thinking Gnu configure, or rpm).

> If v(X) < y.z, this may indicate great trouble. (However, perhaps A can 
> download and install a more recent version of X.)

Right.

> A's reaction on v(X) > y.z, may depend on her trust in the
> upward-compatibility of the development of X ... At least for saftety- or
> security-critical programs (and that is still the area where Ada is best
> for), it would be prudent to check for things that may be broken by using
> a version of X which is newer than y.z. The least thing I'd do would be to
> read the changes-log of X.

Right.

> My point is, I don't want A to *manually* compare y.z with v(X). (There
> may be many Xs, and thus many pairs (v(X),y.z).) It is much better to do
> these tests automatically, either at compile time or at least (early) at
> test time. 

Right. That's what rpm does. I haven't used it much, but it seems to
do it well. And it does it before compile time, which is even better.

> The Ada compiler is a great tool, so use it to simplify your life!
> :-)

Um, the Ada compiler can't do this. Unless we extend Ada with "pragma
Version" or something. Is that what you are proposing?

You can write code that uses the Foo.Version function, and compares it
against an expected version. Maybe that's what you are proposing. But
that's at run-time, which is way too late.

I would only use Foo.Version in a Help | About box, and in error logs.

-- 
-- Stephe

Re: Standard Library Interest?

[Ed Falis]

On 10 Oct 2003 10:59:05 -0400, Stephen Leake <Stephe.Leake@nasa.gov> wrote:

>> I would want to provide A with a simple button to fire the test
>> battery. And this button should be at the same place and have the
>> same shape and color for all packages of the standard library!
>
> Yes. My answer is "from you normal command line, run 'make test'".
> Your answer appears to be "somehow run code that invokes
> Foo.Self_Test".
>
>> It is a non-issue for A, which test framework has been used by the
>> author of the library package.
>
> Well, it matters a little, if it affects the answer to point 2). But
> it mostly doesn't matter.


Note that part of the point of AUnit is to allow composition of test 
suites, so that it's relatively straightforward to execute groupings of 
them with a single command. (Noted that this is different than the build 
issue).


>> And who said that the auxiliary packages should be children? Just
>> "with" them, when implementing your tests. If this does not compile
>> because the "with"ed toolbox is not available, A has no chance to do
>> these tests by herself anyway, even if she'd run make.
>
> Sometimes you need visibility into the private part to implement a
> good unit test; that means at least some of the unit test has be a
> child package.

Right.  Generally, if I find mysef in this situation (usually in the form 
of needing additional queries for unit testing), I add a child of the unit 
under test to provide those queries.

- Ed

Re: Standard Library Interest?

[Warren W. Gay VE3WWG]

Stefan Lucks wrote:
> On 9 Oct 2003, Stephen Leake wrote:
>>Stefan Lucks <lucks@th.informatik.uni-mannheim.de> writes:
>>>  1. a unit test for the package and
>>
>>I find Aunit to be a good unit test framework (see
>>http://savannah.nongnu.org/projects/grace/ for a working example).
> 
> You missed my point! 
> 
> Think of a "customer" (i.e., any programmer who wants to "with" the
> library) and call her A. A somehow (perpaps by downloading it from the web
> site) gets her hands on the source code of some library packages. The very
> first thing she will (or at least should) do is to ask each package: "Are
> you okay?" ("Is this package compiling under my compiler and running on my
> target platform under my target platform's configuration?")
> 
> The best way to answer this question is to run the entire battery of unit
> tests which have been used by the author of the library package. I would 
> want to provide A with a simple button to fire the test battery. And this 
> button should be at the same place and have the same shape and color for 
> all packages of the standard library!
> 
> It is a non-issue for A, which test framework has been used by the author 
> of the library package. 

The general idea is good (provision for testing), but I don't like
the child package idea. It enjoys a different visibility as a child
package, than the consumer of the package would enjoy. Thus, I don't
think the tests would be accurate to the "user experience" as they
need to be.

I would suggest that the test packages and programs, fall under their
own heirarchy, complete and separate from the library units. After all,
if I test the libraries at install time, I may want to dispense with
the test files after the fact. It is easy to dispense with the test
packages, if they are separated from the end product.

Warren.

Re: Standard Library Interest?

[Simon Wright]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

> The general idea is good (provision for testing), but I don't like
> the child package idea. It enjoys a different visibility as a child
> package, than the consumer of the package would enjoy. Thus, I don't
> think the tests would be accurate to the "user experience" as they
> need to be.

The tests need to make sure the unit under test works right. Some
tests will involve the interface, some need to get at the insides,
some need to do both.

> I would suggest that the test packages and programs, fall under
> their own heirarchy, complete and separate from the library
> units. After all, if I test the libraries at install time, I may
> want to dispense with the test files after the fact. It is easy to
> dispense with the test packages, if they are separated from the end
> product.

The directory hierarchy and the unit hierarchy don't need to match
(with GNAT, anyway, & OA almost for sure). So you can put child units
(for peering at internals) in the test code directory.

One impact of this style is that you may have to put things in the
private part of the spec that you would otherwise put in the body --
but if you can't test the code you need to inspect[0] it and that can
be a much more expensive process. Of course your standards may require
inspection anyway in which case there's no difference -- in theory,
though personally I'm much more comfortable with a good test suite
than inspection[1] (this is heresy, by the way, don't let on!).

[0] Fagan inspection

[1] especially for iterative development & code whose requirements
change

Re: Standard Library Interest?

[Robert I. Eachus]

Stephen Leake wrote:

> Yes, which is why all library packages must come with complete tests.
> Again, the Gnu tools typically come with tests (well, the compiler
> doesn't, but the others do). Yes, this is more work, but it is what
> makes the library usable.

Agreed.  I don't think that "built-in" test is necessarily a good idea 
for all libraries, but I definitely like the idea of having a standalone 
test program that does the sanity checks and diagnostics.  Note that 
this can't be boolean pass or fail in many cases.

Which brings up another point.  For many packages a tuning program is 
just as important as a test procedure.  It doesn't need to be as 
elaborate as ATLAS for BLAS in many cases, but it is often needed.  For 
example, I have a lot of random-number generators that depend on 
computing X**2 mod N fast for particular values of N.  Of course, for 
most cases a type that is appropriate for storing X mod N, is not going 
to work for computing the square.  (If System.Max_Nonbinary_Modulus is 
big enough, no problem.  Otherwise workarounds are needed.)

I've written three or four workarounds, some that are fine if they compile:

type Big_Int is range -2**(2*My_Int'Size-1)..2**(2*My_Int'Size-1)-1;

Others depend on properties of the floating point types.  A program 
designed to test these workarounds that also does timings would
be a great help to people porting the package.

> We could require each top-level package to provide a Version function,
> that returns a string. Also follow the Gnu convention of including
> that string in the tar.gz file name for distributions.

Hmmm.  Let me flesh this out a bit.

1) There must be a Version function in the top level package.
2) There may be a Version function in lower level packages.
3) There may be Current_Version string in package specifications.
4) The Version function will normally return a string of the form 
x{.y{.z}} where x, y, and z are integers, optionally followed by a date.
5) The format of the date, if present, is not specified.  But the values 
shall be such that the String comparison operations ">", etc. return the 
right results.

That last sounds complicated, but all it means is that:

     "1.2.3 May 3, 2002" and "1.2.4 March 12, 2003" are perfectly fine, 
but an additional 1.2.4 version such as "1.2.4 April 1, 2003" might not 
be.  The developer of course may have lots of candidate 1.2.4 versions 
before he releases one.  But once he does, it is better if the next 
version has a new number.

Note that even though the Version function is in the package spec, the 
implementation will be in the body.  Which is fine, since the body 
version can change more frequently.  A rule that said that changing the 
package specification should change the first component of the version 
might be nice, but I hardly think it is necessary.

Now do we encourage the ARG to do the same with Ada, System and 
Interfaces, and if so what version strings should be returned. ;-)

> Hmm. I guess you mean one package depends on specific versions of
> other packages, and you want to check that at run-time (or better,
> compile time). That problem is solved by tools like Redhat Package
> Manager (rpm); it's a big problem, and we should not try to invent new
> solutions. 

Um, it is solved for distribution of software in RPM form.  But if I 
post a short program on comp.lang.ada and it depends on a particular 
revison or later of a library, it would be nice to include the one line 
check in the soure.  If the Version function were more carefully 
specified that check could be optimized away.  Hmmm.  Maybe we need two 
version functions, one that returns a string, and another that returns 
just an integer reflecting the spec version...

> Just an example of the kinds of discussions an integrated library
> committee will be having ...

Aren't we already having these discussions?

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Stephen Leake]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> Stephen Leake wrote:
> 
> > Just an example of the kinds of discussions an integrated library
> > committee will be having ...
> 
> Aren't we already having these discussions?

yes, but we aren't the formal library committee, so I'm not being very
rigorous, and sometimes I just ignore things.

I was trying to point out that being on the formal library committee
will be a pain, and take a lot of time. If I'm on it, I want to get
paid, in some way.

Maybe we could form a corporation, like Boost.

Has anyone offered to pay for support for the Booch libraries, or any
other existing library (the answer is no for SAL)?

-- 
-- Stephe

Re: Standard Library Interest?

[Robert I. Eachus]

Marin David Condic wrote:

> 1) Would the ARG & Vendors be receptive to the end result? They don't 
> have to agree to endorse/distribute it up front, but if such a library 
> were to exist & meet some expectations, would they get on board? Would 
> they be willing to participate to the level of saying what it is they 
> want to see in an end product? Would they be willing to sit in on 
> periodic reviews to discuss direction, etc.? I'd want to see the effort 
> produce something that the ARG and Vendors would *want* to put some 
> stamp of approval on and distribute - but I'm not a mind reader.

You really don't want to ask the ARG.  We have a specific role under 
WG9, and if this was made a NWI (new work item), it might be assigned to 
  some other RG, probably one set up for the purpose.


> 2) Who is going to play "Editor/Publisher" to make sure that what comes 
> in meets some sort of standards of acceptability? It can't be a 
> free-for-all with anybody building anything they like with whatever 
> style they like and to whatever quality they like, etc. I'd think that 
> an editor (or small group of editors) could work with prospective 
> authors to make sure they are working on the "right" things and to the 
> "right" guidelines. Otherwise, its just another inconsistent mess - but 
> all under one roof.

Good idea. WG9 would probably need to assign a sucker er, technical 
editor anyway, and there would be periodic dead tree versions published. 
  Of course no one with any sense would use other than the on-line 
version. ;-)

> I could see other questions like licensing, etc. coming into the mix 
> rather quickly, but for now, I'd just like to see #1 and #2 answered.

That's why I suggested keeping the focus on the first level naming.  The 
actual source could be public domain, copyrighted under various terms, 
or even licensed for big bucks.  But having a central repository of 
names would insure that conflicts did not arise.

> BTW: I'd propose "CAL" as the root package name and from there, you can 
> have "CAL.Statistics". But be sure to build the statistics stuff 
> utilizing whatever comes under "CAL.Containers". ;-)

You meant Ada.Containers, right?  Of course, if it is necessary, one 
could be a renaming of the other.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Marin David Condic]

Robert I. Eachus wrote:
 >
 > You really don't want to ask the ARG.  We have a specific role under
 >  WG9, and if this was made a NWI (new work item), it might be
 > assigned to some other RG, probably one set up for the purpose.
 >
It can live under any group you like so long as there is some sort of
agreed-upon acceptance from the vendors and anyone else that matters
that somehow or other this is going to be distributed with Ada compilers.

 >
 > That's why I suggested keeping the focus on the first level naming.
 > The actual source could be public domain, copyrighted under various
 > terms, or even licensed for big bucks.  But having a central
 > repository of names would insure that conflicts did not arise.
 >
Before charging off and starting a library tree of names even, I'd like
to see what sort of requirements and/or organization the vendors would
like to have. What would make such a project acceptable to them? What do
they want in it? How would they want it played out? Names are relatively
easy to hammer out. Once you know what sort of things the vendors want,
you create a tree of names that lines up with that and get everybody to
say O.K. Assuming its under control of some editor/publisher and you
want to get a statistics library in there, you talk to the editor and if
he agrees, he gives you a branch name to work under.


 >
 > You meant Ada.Containers, right?  Of course, if it is necessary, one
 >  could be a renaming of the other.
 >
Nope. Nothing under Ada unless the ARM explicitly makes it legal to
extend things under the root package Ada. There are times I'd have liked 
to extend things under the root package Ada - except its illegal to do 
that. If you've got an Ada.Containers, you'd like some end user to a) 
have source for Ada.Containers and b) be able to tweak or adjust it or 
extend it with whatever good ideas he may have. (Like maybe 
Ada.Containers.Realtime? Or Ada.Containers.Bounded?) If this is 
difficult to allow, then start another tree that is totally independent 
and under which it *is* possible to extend.

Naturally, if you modify the source for some package that is distributed 
by your vendor, you assume the risk of managing any changes. But the 
whole idea of a library outside of the ARM is to be able to make it more 
flexible, so you want people playing with it and extending it. Thats 
where the new "Good Ideas" are going to come from.

MDC

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> Robert I. Eachus wrote:
>  >
>  > You really don't want to ask the ARG.  We have a specific role under
>  >  WG9, and if this was made a NWI (new work item), it might be
>  > assigned to some other RG, probably one set up for the purpose.
>  >
> It can live under any group you like so long as there is some sort of
> agreed-upon acceptance from the vendors and anyone else that matters
> that somehow or other this is going to be distributed with Ada compilers.

I believe this will happen as a natural consequence of doing this
important work. The vendor won't want to incurr extra work, unless
there is some wild advantage to them doing so.

I believe that this effort merely needs to organize the naming
conventions such that it is not likely to stomp on some existing
vendor naming convention. Surely industry experience can steer
us away from most of these problem areas without waiting for
vendors?

>  > That's why I suggested keeping the focus on the first level naming.
>  > The actual source could be public domain, copyrighted under various
>  > terms, or even licensed for big bucks.  But having a central
>  > repository of names would insure that conflicts did not arise.
>  >
> Before charging off and starting a library tree of names even, I'd like
> to see what sort of requirements and/or organization the vendors would
> like to have. What would make such a project acceptable to them? What do
> they want in it? How would they want it played out? Names are relatively
> easy to hammer out. Once you know what sort of things the vendors want,
> you create a tree of names that lines up with that and get everybody to
> say O.K. Assuming its under control of some editor/publisher and you
> want to get a statistics library in there, you talk to the editor and if
> he agrees, he gives you a branch name to work under.

I think you are on a different fork then some of the others in this
thread are on. You are looking at the (1) "what do we & and vendors
want in functionality?"

There are others that are saying (2) "I have this to offer, but where should
I put it (name it)?"

Both issues need to be dealt with. The easiest way to get started is
to address the naming conventions, and this should naturally address
#2 as a consequence, and work towards the issue #1 as it progresses.

But I would suggest, that we do not wait for the vendors to do
something. I think this was the whole point of the idea in this
thread. Baby steps: let's at least get the egg made, and hope
that a chicken shows up later. ;-)

Warren.

Re: Standard Library Interest?

[Marin David Condic]

It won't work. It hasn't worked.

If you can at *minimum* get the vendors to give you a nod that says 
"Yes, if such a thing were done under the control of this organization 
and with this sort of license and to some level of acceptable quality, 
we'd get on board and distribute it...", then you've got something. They 
don't have to commit to the library and wouldn't want to until they saw 
the net result.

But if the answer is "No. We will not now, nor will we ever distribute a 
library built by this organization with that license, etc., - not unless 
it is totally rammed down our throats by the end users...", then the 
game is over.

Don't waste time trying to get some organization together and get a 
project started unless you know from the start that the ultimate 
authority on acceptance is at least willing to consider it a 
possibility. So far, I have no indication that this is the case.

MDC


Warren W. Gay VE3WWG wrote:
> 
> I believe this will happen as a natural consequence of doing this
> important work. The vendor won't want to incurr extra work, unless
> there is some wild advantage to them doing so.
> 
> I believe that this effort merely needs to organize the naming
> conventions such that it is not likely to stomp on some existing
> vendor naming convention. Surely industry experience can steer
> us away from most of these problem areas without waiting for
> vendors?
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> It won't work. It hasn't worked.
> 
> If you can at *minimum* get the vendors to give you a nod that says 
> "Yes, if such a thing were done under the control of this organization 
> and with this sort of license and to some level of acceptable quality, 
> we'd get on board and distribute it...", then you've got something. They 
> don't have to commit to the library and wouldn't want to until they saw 
> the net result.
> 
> But if the answer is "No. We will not now, nor will we ever distribute a 
> library built by this organization with that license, etc., - not unless 
> it is totally rammed down our throats by the end users...", then the 
> game is over.

IFF you get this kind of answer from some, most or all of the vendors,
then I would agree that you have a "point". But IMHO, this is unlikely
first of all (its not in their interest to go against what the user
base wants), and certainly not a foregone conclusion. Note the "FF"
in "IFF".

What drives the vendors, is what the "users want". Get them using
your stuff. Get them wanting more of your stuff. IOW, get the users
hooked first (a very time honoured principle). The vendors will
fall in line from there. Demand usually drives business. Only in
creative things like the Segway (sp?) where people didn't know they
wanted one, does it work the other way. But I don't think the
vendors are going to have any kind of a surprise for anyone on
this front. ;-)
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Standard Library Interest?

[Ed Falis]

On Wed, 15 Oct 2003 12:24:37 -0400, Warren W. Gay VE3WWG 
<ve3wwg@cogeco.ca> wrote:
> .. But I don't think the
> vendors are going to have any kind of a surprise for anyone on
> this front. ;-)

Well, I dunno, we Ada vendors brought the world many development systems 
for Ada, including GNAT, and most of the world didn't seem to know they 
wanted any of them ...

;-)

- Ed

Re: Standard Library Interest?

[Warren W. Gay VE3WWG]

Ed Falis wrote:
> On Wed, 15 Oct 2003 12:24:37 -0400, Warren W. Gay VE3WWG 
> <ve3wwg@cogeco.ca> wrote:
>> .. But I don't think the
>> vendors are going to have any kind of a surprise for anyone on
>> this front. ;-)
> 
> Well, I dunno, we Ada vendors brought the world many development systems 
> for Ada, including GNAT, and most of the world didn't seem to know they 
> wanted any of them ...
> 
> ;-)
> 
> - Ed

They were'nt surprised enough ;-)
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Standard Library Interest?

[Mark A. Biggar]

Warren W. Gay VE3WWG wrote:

> Marin David Condic wrote:
> 
>> It won't work. It hasn't worked.
>>
>> If you can at *minimum* get the vendors to give you a nod that says 
>> "Yes, if such a thing were done under the control of this organization 
>> and with this sort of license and to some level of acceptable quality, 
>> we'd get on board and distribute it...", then you've got something. 
>> They don't have to commit to the library and wouldn't want to until 
>> they saw the net result.
>>
>> But if the answer is "No. We will not now, nor will we ever distribute 
>> a library built by this organization with that license, etc., - not 
>> unless it is totally rammed down our throats by the end users...", 
>> then the game is over.
> 
> 
> IFF you get this kind of answer from some, most or all of the vendors,
> then I would agree that you have a "point". But IMHO, this is unlikely
> first of all (its not in their interest to go against what the user
> base wants), and certainly not a foregone conclusion. Note the "FF"
> in "IFF".
> 
> What drives the vendors, is what the "users want". Get them using
> your stuff. Get them wanting more of your stuff. IOW, get the users
> hooked first (a very time honoured principle). The vendors will
> fall in line from there. Demand usually drives business. Only in
> creative things like the Segway (sp?) where people didn't know they
> wanted one, does it work the other way. But I don't think the
> vendors are going to have any kind of a surprise for anyone on
> this front. ;-)

The other issue that the vendors will have is the support issue.  If
they distribute it, then they will have to provide some level of support 
for it, if only training their support people on how to say "distributed
as is, we don't support it".  And vendor don't like to do that, as it
causes "Good Will" problems with their customers.

So even if you have the best thing sense Turing machines, some vendors
may not distribute it, because they don't see any benefit in the
increase in support costs.

Anything that isn't in the standard can have this problem.

-- 
mark@biggar.org
mark.a.biggar@comcast.net

Re: Standard Library Interest?

[Marin David Condic]

Right. I can see that and anticipat that objection on the part of the 
vendors. But at the end of the day, you are not going to get something 
for nothing. We could jam a whole gigantic library into the standard and 
they'd have to support it or admit they don't have a "Full" Ada 
compiler. (I've already observed why we *don't* want it in the standard, 
but assume for a minute it was there in order to *force* the vendors 
into providing it.) They could each pay the cost of building that huge 
library and each pay the cost of supporting that library and each suffer 
individually.

***OR***

The vendors could work as a team on this and share the expense. Form up 
some sort of organization to take care of the library and support it. It 
comes from a single source and they could relatively easily point any 
customer support issues to that source. Its even conceivable that the 
organization they start could become self-sustaining - generating 
revenue out of their own support contracts or software sales or 
royalties or whatever else they might provide.

Here's the thing: Nobody is going to ge a Conventional Ada Library free. 
*Someone* is going to bear the cost of producing it and maintaining it. 
Even if that "Someone" is a bunch of volunteers. If you want to have 
reasonable control over the library and get it done on a schedule and 
have it meet various expectations, that's going to cost something. 
However, that doesn't mean the cost has to be huge or back-breaking for 
each vendor. Some sort of cooperative effort and creative licensing 
might enable it to get constructed and supported without having to incur 
huge costs.

MDC


Mark A. Biggar wrote:
> 
> 
> The other issue that the vendors will have is the support issue.  If
> they distribute it, then they will have to provide some level of support 
> for it, if only training their support people on how to say "distributed
> as is, we don't support it".  And vendor don't like to do that, as it
> causes "Good Will" problems with their customers.
> 
> So even if you have the best thing sense Turing machines, some vendors
> may not distribute it, because they don't see any benefit in the
> increase in support costs.
> 
> Anything that isn't in the standard can have this problem.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> Right. I can see that and anticipat that objection on the part of the 
> vendors. But at the end of the day, you are not going to get something 
> for nothing. We could jam a whole gigantic library into the standard and 
> they'd have to support it or admit they don't have a "Full" Ada 
> compiler. (I've already observed why we *don't* want it in the standard, 
> but assume for a minute it was there in order to *force* the vendors 
> into providing it.) They could each pay the cost of building that huge 
> library and each pay the cost of supporting that library and each suffer 
> individually.
> 
> ***OR***
> 
> The vendors could work as a team on this and share the expense. Form up 
> some sort of organization to take care of the library and support it. It 
> comes from a single source and they could relatively easily point any 
> customer support issues to that source. Its even conceivable that the 
> organization they start could become self-sustaining - generating 
> revenue out of their own support contracts or software sales or 
> royalties or whatever else they might provide.
> 
> Here's the thing: Nobody is going to ge a Conventional Ada Library free. 
> *Someone* is going to bear the cost of producing it and maintaining it. 
> Even if that "Someone" is a bunch of volunteers. If you want to have 
> reasonable control over the library and get it done on a schedule and 
> have it meet various expectations, that's going to cost something. 
> However, that doesn't mean the cost has to be huge or back-breaking for 
> each vendor. Some sort of cooperative effort and creative licensing 
> might enable it to get constructed and supported without having to incur 
> huge costs.
> 
> MDC

And at the end of the fiscal year, the cost will be passed back
to you and me. After all, nobody's just going to eat the charges
"just because". So I think that is a given.

The point is how to get it all rolling. IMO, which is obviously
a bit different than yours, you'll not get things rolling waiting
for the vendor to initiate this effort. Especially if it involves
in multiple vendors working together. Not impossible mind you, just
unlikely. That is like trying to reach consensus in a meeting
with 15 people in it, vs a small group of three.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Standard Library Interest?

[Marin David Condic]

Warren W. Gay VE3WWG wrote:
> 
> 
> And at the end of the fiscal year, the cost will be passed back
> to you and me. After all, nobody's just going to eat the charges
> "just because". So I think that is a given.
> 
Yes. But so what? You volunteer time and hence you pay with labor. You 
purchase support (and get the direct benefits thereof) and you pay for 
further development. In the former case, there is little to no control 
over quality or style or deliverables or schedule. In the latter case, 
you get some ability to direct the effort and make sure that things are 
done "right" - at least from the perspective of the consumer of the end 
product (That being the vendors and their immediate customers.)


> The point is how to get it all rolling. IMO, which is obviously
> a bit different than yours, you'll not get things rolling waiting
> for the vendor to initiate this effort. Especially if it involves
> in multiple vendors working together. Not impossible mind you, just
> unlikely. That is like trying to reach consensus in a meeting
> with 15 people in it, vs a small group of three.

I agree that the point is to get it all rolling. I'm agitating, aren't 
I? :-)

Keep in mind that I've served in efforts to get something like this 
going before and fould little to no results from the volunteer efforts. 
Hence, I'm agitating to see if a different approach might actually work 
better. I think if customers were to start asking their vendors to 
supply a library and that it be semi-standard between compilers, etc., 
they'd hear that message. I doubt that they have no idea I'm out here 
agitating for a library or suggesting that they get on board. 
*INITIALLY* it might even get somewhere as a volunteer effort - provided 
the vendors simply gave it a nod and a wink and a little guidance as to 
what they might want. I think long-term - much as with the Ada standard 
itself - they'd have to be "Owners" of it in some way. They fund the 
development of the standard by participating in the ARG, etc., and 
devoting staff time to looking over the changes, suggesting 
improvements, and so on. This is really just an extension of that same 
process. They'd be participating in a similar effort to get a 
Conventional Ada Library built - and getting what they wanted rather 
than something they'd likely turn their noses up at.

Ultimately, there are dozens or maybe even hundreds of ways to organize 
something that might produce and maintain a library. I think that if 
such a library were to thrive and gain acceptance in a wide way, it 
ought to get some kind of involvment of the vendors. It seems you want 
to go organize an effort that would build one without the vendor's 
involvement in the hope of getting that involvement later. It *could* 
work - we just have not seen that happen yet despite numerous other 
attempts to do it that way. I wouldn't try to stop you - I'd just wait 
to see where it got before I'd spend my time on it because I've seen 
similar efforts fall apart.

MDC




-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> Warren W. Gay VE3WWG wrote:
...
> Ultimately, there are dozens or maybe even hundreds of ways to organize 
> something that might produce and maintain a library. I think that if 
> such a library were to thrive and gain acceptance in a wide way, it 
> ought to get some kind of involvment of the vendors. It seems you want 
> to go organize an effort that would build one without the vendor's 
> involvement in the hope of getting that involvement later. It *could* 
> work - we just have not seen that happen yet despite numerous other 
> attempts to do it that way. I wouldn't try to stop you - I'd just wait 
> to see where it got before I'd spend my time on it because I've seen 
> similar efforts fall apart.
> 
> MDC

I guess our faith is in the different parties. ;-)

You are willing to trust that the vendors will get things going.
I am too skeptical/cynical to have that kind of trust, beyond
anything more than the GNAT.* packages.

My faith is more in the development side. *WE* have the invested
interest. *WE* can more easily *do* something. Vendors have to
budget, plan and justify. Vendors are less likely to do "extreme
programming"/skunkworks type of things to see if an idea will fly.

*WE* don't have to answer to anyone (as open source/hobby). That
allows us to do R&D, where the vendor (and/or our employer) would
have trouble with.

So, yes, you're right. I would favour "organize an effort", rather
than pleading with vendors. ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Standard Library Interest?

[Marin David Condic]

Warren W. Gay VE3WWG wrote:
 >
 > I guess our faith is in the different parties. ;-)
 >
 > You are willing to trust that the vendors will get things going. I am
 >  too skeptical/cynical to have that kind of trust, beyond anything
 > more than the GNAT.* packages.
 >
No, I *don't* trust them to "get things going". That's why I'm nagging,
complaining, whining, pleading, etc. I expect that people with support
contracts with various vendors might send them a note saying "I want a
Conventional Ada Library that does X, Y and Z..." A lone voice crying
out in the wilderness occasionally can have an impact. :-) However, I
doubt I'm alone.

As for the GNAT packages - that might actually make a really good start 
for a Conventional Ada Library. There is visible evidence that ACT is 
out there actively enhancing their Ada product line, so they would be 
one of the vendors most likely to do something with a CAL. Are any of 
the other vendors doing anything with their Ada product lines to enhance 
them? Or are they just selling what they've got and sitting on their 
hands, so to speak, with any new development? If ACT was the only one - 
or perhaps the dominant one - then making ACT happy would be key to 
success. Starting with what they've already got would be a good way to 
do it.




 > My faith is more in the development side. *WE* have the invested
 > interest. *WE* can more easily *do* something. Vendors have to
 > budget, plan and justify. Vendors are less likely to do "extreme
 > programming"/skunkworks type of things to see if an idea will fly.
 >
I didn't say that *WE* wouldn't necessarily have something to do with
it. What I said was that the vendors need to be involved early on in
some manner or whatever *WE* do is going to be a waste of time. I just
absolutely, 100% see a total of ZERO evidence of any of the existing
library attempts getting to any sort of point of "general acceptance"
that got the vendors interested in packaging it with their compilers or
got the ARG to declare it "Standard Ada". Yet there have been dozens -
or more - attempts to get various libraries of stuff started. What
evidence do you have that starting Yet Another Library Project is going
to meet with any better success unless you do something strategically
different this time?

Sorry if I sould "angry" - I'm not. Just excited. :-) I'm trying to get
across the point that if we really want a library effort of some sort to
succeed, we'd better look at all the ones that have "failed" in the past
and try to make a different set of mistakes. You're not the firt one to
get charged up and say "Well, lets go start writing a library..." I'm
suggesting you look at why the other efforts failed and figure out a way
around that.



 > *WE* don't have to answer to anyone (as open source/hobby). That
 > allows us to do R&D, where the vendor (and/or our employer) would
 > have trouble with.
 >
Yes, but just recall all the other various and sundry "Open Source" /
Volunteer oriented projects of any stripe that get started out there.
(Should we start a list?)

I'd bet that if you actually surveyed, you'd find that 90% of them
colapse before they ever produce anything at all useful. The remainder
might make something that works, but that it is mostly produced over a
*very* long stretch of time and that it really doesn't take on the
qualities of a "Finished Product" (more like some kid's sience fair
project, usually) until there is some commercial effort out there making
money on supporting it. The few that get "Commercialized" might start 
reacting fairly well and at reasonable speed to perceived needs, but it 
takes them a really long time to get to that point.

What is in your plan to start building a library that is going to make 
that different?



 > So, yes, you're right. I would favour "organize an effort", rather
 > than pleading with vendors. ;-)
 >
Please go right ahead. I'll watch the effort from the sidelines. I'd
love to see you or anybody else get a library together that won some
kind of acceptance from the general Ada community and got some kind of
interest from the vendors and eventually had some sort of official
standing. I'm just betting it won't work - and I'm not a pessimist by
nature. I've just seen it fail too many times in the past to want to go
off and make the same mistakes all over again. At least, let's be
creative and make some *different* mistakes this time. :-)

Or maybe you have a *different* plan? Something other than an
all-volunteer, open source, free for the world, "Let's all get together
and build something good & wonderful for Ada and give it away hoping it
will be adopted by everyone..." effort? I'd like to see the plan, if
that's the case.

MDC
-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> Warren W. Gay VE3WWG wrote:
>  >
>  > I guess our faith is in the different parties. ;-)
>  >
>  > You are willing to trust that the vendors will get things going. I am
>  >  too skeptical/cynical to have that kind of trust, beyond anything
>  > more than the GNAT.* packages.
>  >
> No, I *don't* trust them to "get things going". That's why I'm nagging,
> complaining, whining, pleading, etc. I expect that people with support
> contracts with various vendors might send them a note saying "I want a
> Conventional Ada Library that does X, Y and Z..." A lone voice crying
> out in the wilderness occasionally can have an impact. :-) However, I
> doubt I'm alone.

OK, I phrased it wrong. You trust in the nagging of users to the
vendors to help push it along. I'm not criticizing; just trying
to boil the point into its most basic elements. ;-)

BTW, I finally received my printed copy of the Ada Letters last
week. Good work on the article.

> As for the GNAT packages - that might actually make a really good start 
> for a Conventional Ada Library. There is visible evidence that ACT is 
> out there actively enhancing their Ada product line, so they would be 
> one of the vendors most likely to do something with a CAL. Are any of 
> the other vendors doing anything with their Ada product lines to enhance 
> them? Or are they just selling what they've got and sitting on their 
> hands, so to speak, with any new development? If ACT was the only one - 
> or perhaps the dominant one - then making ACT happy would be key to 
> success. Starting with what they've already got would be a good way to 
> do it.

There seems to be several good indications coming from ACT. One of
which is the support of the Win32Ada binding that comes with the
Windows port. The other is that I noticed somewhere that they have
accepted the maintenance of FLORIST, for which I was able to successfully
submit a bug report (that did not bounce ;-). Both of these two
areas alone are big areas of maintenance. So kudos to ACT for taking
these progressive steps. This level of support may push other vendors
into doing something similar.

>  > My faith is more in the development side. *WE* have the invested
>  > interest. *WE* can more easily *do* something. Vendors have to
>  > budget, plan and justify. Vendors are less likely to do "extreme
>  > programming"/skunkworks type of things to see if an idea will fly.
>  >
> I didn't say that *WE* wouldn't necessarily have something to do with
> it. 

I know that. Don't be too sensitive ;-)

> What I said was that the vendors need to be involved early on in
> some manner or whatever *WE* do is going to be a waste of time. I just
> absolutely, 100% see a total of ZERO evidence of any of the existing
> library attempts getting to any sort of point of "general acceptance"
> that got the vendors interested in packaging it with their compilers or
> got the ARG to declare it "Standard Ada". 

Apart from standards and the ARG, what about Win32Ada and FLORIST. I
do believe that _some_ evidence does exist. FLORIST was started outside
of ACT, though I don't know about the Win32Ada binding.

> Yet there have been dozens -
> or more - attempts to get various libraries of stuff started. What
> evidence do you have that starting Yet Another Library Project is going
> to meet with any better success unless you do something strategically
> different this time?

How many competing designs where there for the Ada language, before one
was "accepted"?  For a container library, I think there is room for
several attempts before getting it "right". After all, Ada programmers
are much fussier about the quality and the design than in other languages. I
think one needs to leave room for evolution and experimentation. Eventally,
an emerging accepted defacto standard is bound to emerge. I think, you
would agree that we would like it to happen a little sooner, that's
all!

> Sorry if I sould "angry" - I'm not. Just excited. :-) 

Thats OK.  We could use some excitement here. ;-)

> I'm trying to get
> across the point that if we really want a library effort of some sort to
> succeed, we'd better look at all the ones that have "failed" in the past
> and try to make a different set of mistakes. You're not the firt one to
> get charged up and say "Well, lets go start writing a library..." I'm
> suggesting you look at why the other efforts failed and figure out a way
> around that.

I'm all in favour of examination of historical attempts. I mean, why
invent yet another of the same thing that failed. But based upon the
discussions that I have seen here, there seems to be a lack of
concensus about what it should be.

Another factor now is, what "could there be?" after Ada 200Y is
adopted? Once some of the issues have been solved, and the enhancements
added that deal with interfaces (and/or MI) are in place, this could
substantially change the landscape for such development. For many
projects, this shouldn't matter, but for a container library this
could be "key".

So, I would suggest, let's attack some of the problems along the
way. Some of the larger problems may become easier to solve later.
Bug the vendors for sure, but don't entirely depend upon this.

I have always taken the approach of learning from doing. So I would
not discourage people from trying something new. Many projects may
end up as throw-aways in the end, but that does not mean the effort
is a wasted one. You seem to be worried about wasted effort(s).

But people learn from these projects, and they
should be regarded as research projects rather than wasted efforts.
In the corporate world, this becomes harder to justify, but
R&D is still required there also. We just don't hear about all
of the discarded projects in IT, but you can be sure that
lessons were learned (or should have been). ;-)


>  > *WE* don't have to answer to anyone (as open source/hobby). That
>  > allows us to do R&D, where the vendor (and/or our employer) would
>  > have trouble with.
>  >
> Yes, but just recall all the other various and sundry "Open Source" /
> Volunteer oriented projects of any stripe that get started out there.
> (Should we start a list?)

As I've pointed out earlier, a failed project is never completely
a failure. Someone/people have learned lessons from those undertakings,
even if it is just to understand their own level of commitment ;-)

> I'd bet that if you actually surveyed, you'd find that 90% of them
> colapse before they ever produce anything at all useful. 

How many mutated species survive? Do these numbers matter?

I think you are concerned that Ada resources are thinner, and so
you don't want to see that resource wasted. A valid concern. But
a certain amount of this so called "waste" is a necessary part of
any R&D.

> The remainder
> might make something that works, but that it is mostly produced over a
> *very* long stretch of time and that it really doesn't take on the
> qualities of a "Finished Product" (more like some kid's sience fair
> project, usually) until there is some commercial effort out there making
> money on supporting it. 

This is true. In the book the "Mythical Man Month", the author points
out that it takes 9 times the "in the garage" effort, to take a
project from one small program, to integrate it into a system of
programs and to make it a finished product. Most projects take a
long time to reach that point, if ever. Agreed. But note the
word "most".

> The few that get "Commercialized" might start 
> reacting fairly well and at reasonable speed to perceived needs, but it 
> takes them a really long time to get to that point.

Even commercial products can take eons to reach that polished
state.. some never get there ;-)

> What is in your plan to start building a library that is going to make 
> that different?

Well, I think that multiple teams could be assembled (resources
and interest permitting), that could address a critical need. Like
the Ada language competition, I think that something could emerge.

>  > So, yes, you're right. I would favour "organize an effort", rather
>  > than pleading with vendors. ;-)
>  >
> Please go right ahead. I'll watch the effort from the sidelines. I'd
> love to see you or anybody else get a library together that won some
> kind of acceptance from the general Ada community and got some kind of
> interest from the vendors and eventually had some sort of official
> standing. I'm just betting it won't work - and I'm not a pessimist by
> nature. I've just seen it fail too many times in the past to want to go
> off and make the same mistakes all over again. At least, let's be
> creative and make some *different* mistakes this time. :-)

I am in favour of doing "different mistakes". There is nothing gained
by repeating what we already have, unless you are trying to avoid
a copyright issue.

I'd be willing to participate as a member of a team in some capacity,
but I am already overbooked with 3 other major open sourced projects
at this time to do any more. Will my work be accepted? Heck if I know,
but I am doing this to scratch my own itch, and hope in the process
it will scratch a few other itches out there, in the process. Perhaps
I need to take a different approach, and organize group efforts.

For the container library, IMHO, we'll probably want to be patient
with that one. Given that it's too late to affect the 200Y standard,
it can also wait until 200Y is settled. From what I saw in the Ada
Letters were some interesting issues, that could give any new
container library effort some nice new options to work with.

> Or maybe you have a *different* plan? Something other than an
> all-volunteer, open source, free for the world, "Let's all get together
> and build something good & wonderful for Ada and give it away hoping it
> will be adopted by everyone..." effort? I'd like to see the plan, if
> that's the case.
> 
> MDC

Well, I don't really have a plan (shrink), other than what I've
posted in earlier posts in this thread. You raised some interesting
ideas in your Ada Letters article, which might work. It would be
nice in fact, if that would work. Maybe I am showing my own
skepticism here, but I think for that to succeed, you'll need some
Richard Stallman type that is willing to lead that charge. It will
take a strong minded, vision incensed person to make sure that it
is realized. Are you leading that charge? Perhaps you are holding
out on us? ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Standard Library Interest?

[Marin David Condic]

Warren W. Gay VE3WWG wrote:
> 
> BTW, I finally received my printed copy of the Ada Letters last
> week. Good work on the article.
> 
Thanks.

Maybe I ought to author something else related to that?

> 
> 
> I know that. Don't be too sensitive ;-)
> 
Sorry. Not "sensitive" - just excitable.

> 
> Apart from standards and the ARG, what about Win32Ada and FLORIST. I
> do believe that _some_ evidence does exist. FLORIST was started outside
> of ACT, though I don't know about the Win32Ada binding.
> 
Except that neither one of those was some sort of "All Volunteer" effort 
divorced from the vendors. Thus demonstrating exactly what I am hoping 
ought to happen. Win32Ada was something that was built (I believe) By 
Tucker Taft who was doing it for Averstar? Softech? 
Somebodyorotherwhowasalsoacompilervendor? It had some buy-in from the 
vendors who were putting out Windows compilers - hence it is a 
semi-standard thing. Florist has some ACT buy-in now and maybe had some 
connection there I'm not aware of. But it (afaik) is not "The Thing" 
with more than ACT, so you're not portable to other vendors. If a couple 
of other vendors were hip to it, then you'd have something there. 
Otherwise, it is no different than had it been named GNAT.Florist.

> 
> 
> How many competing designs where there for the Ada language, before one
> was "accepted"?  For a container library, I think there is room for
> several attempts before getting it "right". After all, Ada programmers
> are much fussier about the quality and the design than in other 
> languages. I
> think one needs to leave room for evolution and experimentation. Eventally,
> an emerging accepted defacto standard is bound to emerge. I think, you
> would agree that we would like it to happen a little sooner, that's
> all!
> 

BIG DIFFERENCE! The ultimate *CUSTOMER* was sponsoring the competition. 
They went off and recruited designers to develop the designs. The 
*customer* said "Here's what I have in mind - show me what your proposal 
is..." What you are suggesting doing is charging off without an 
identifiable customer or an identifiable set of requirements and 
building something with the hope that sooner or later a customer will 
stand up and say "Here I am..." and that the customer will then just so 
happen to have an *identical* set of requirements to whatever 
assumptions you made. I'm suggesting a) Get an identifiable customer up 
front to say "Yes, I'm interested in getting a library" and b) Get from 
them some set of desired requirements - even if its back-of-the-envelope 
sort of stuff. Do that *FIRST* before wasting time building something 
that perhaps nobody wants.



> 
> So, I would suggest, let's attack some of the problems along the
> way. Some of the larger problems may become easier to solve later.
> Bug the vendors for sure, but don't entirely depend upon this.
> 
Baby steps are fine. I just think the first and formost baby step needs 
to be "Find out which vendors are planning to continue developing their 
Ada compilers and find out if they want there to be some sort of CAL 
that they are willing to accept and play a role in developing." The rest 
can start to fall out of there. I think vendor participation is a 
necessary condition to starting anything.


> I have always taken the approach of learning from doing. So I would
> not discourage people from trying something new. Many projects may
> end up as throw-aways in the end, but that does not mean the effort
> is a wasted one. You seem to be worried about wasted effort(s).
> 

Because efforts have been wasted before and I want to make a *different* 
set of mistakes this time around. If you keep trying to get through a 
wall by running headlong into it, would you be surprised if someone says 
"This is foolish. Why not look for a door or window before charging at 
the wall again..." These efforts have been tried before and the evidence 
is right out there in the Internet to look at. You can compare all the 
attempts and compare all the Ada implementations and you see that the 
attempts are not found in Ada implementations. If you want to go that 
route again - its your head that is going to hit the wall while I'm 
feeling around for the doornob. ;-)


>> Yes, but just recall all the other various and sundry "Open Source" /
>> Volunteer oriented projects of any stripe that get started out there.
>> (Should we start a list?)
> 
> 
> As I've pointed out earlier, a failed project is never completely
> a failure. Someone/people have learned lessons from those undertakings,
> even if it is just to understand their own level of commitment ;-)

Yes, and from my "failed" projects, I've learned that you need to get 
the customer involved very early on. ;-)

> 
> I think you are concerned that Ada resources are thinner, and so
> you don't want to see that resource wasted. A valid concern. But
> a certain amount of this so called "waste" is a necessary part of
> any R&D.
> 
But we've *Done* the "Waste" part already. Let's *Learn* from that and 
get the customer involved in it *Early* to avoid more waste.



> 
> Well, I don't really have a plan (shrink), other than what I've
> posted in earlier posts in this thread. You raised some interesting
> ideas in your Ada Letters article, which might work. It would be
> nice in fact, if that would work. Maybe I am showing my own
> skepticism here, but I think for that to succeed, you'll need some
> Richard Stallman type that is willing to lead that charge. It will
> take a strong minded, vision incensed person to make sure that it
> is realized. Are you leading that charge? Perhaps you are holding
> out on us? ;-)
> 

Well, I don't know what I'm leading here if anything. But if a few folks 
representing vendors were to come to me and say "Please, Marin, with 
your sublime wisdom and vast vision, could you somehow or other find 
some way to devote some time to this???" I might be tempted to do so. I 
suspect they have their own visionaries they could count on better. :-) 
Why? You think they want to offer me a job?

My premise is that if the vendors wanted to drive an effort to get a 
library, they could get one. If they are looking for volunteers, they 
could find some - but probably not enough to get it to market in a 
reasonable lenght of time or meeting requirements unless they have some 
paid-guidance overseeing the effort. The ideal situation would be to pay 
for the whole thing so you get exactly what you want and when you want 
it. If you don't have that kind of cash, then get creative about how to 
do it on a shoestring. A solution does exist. Do the vendors see it as a 
problem they want to solve? Is there interest in taking up the challenge?

MDC


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> Warren W. Gay VE3WWG wrote:
>> BTW, I finally received my printed copy of the Ada Letters last
>> week. Good work on the article.
>>
> Thanks.
> 
> Maybe I ought to author something else related to that?

If it ends up provoking some sort of "action", then
why not?

>> Apart from standards and the ARG, what about Win32Ada and FLORIST. I
>> do believe that _some_ evidence does exist. FLORIST was started outside
>> of ACT, though I don't know about the Win32Ada binding.
>>
> Except that neither one of those was some sort of "All Volunteer" effort 
> divorced from the vendors. Thus demonstrating exactly what I am hoping 
> ought to happen. Win32Ada was something that was built (I believe) By 
> Tucker Taft who was doing it for Averstar? Softech? 

That one, I am not really surprised by, due to the extent of the
work that would is involved in that. Not to mention the maintenance
of the same.

> Florist has some ACT buy-in now and maybe had some 
> connection there I'm not aware of. But it (afaik) is not "The Thing" 
> with more than ACT, so you're not portable to other vendors. If a couple 
> of other vendors were hip to it, then you'd have something there. 
> Otherwise, it is no different than had it been named GNAT.Florist.

No disagreement here really. Just don't forget however, that if
people start depending upon FLORIST to be there for all of those
Linux/UNIX projects out there, that the other vendors will at some
point say, we need a port of that as well, because customers will
be asking for it. Otherwise, I have no disagreement with your point.


>> How many competing designs where there for the Ada language, before one
>> was "accepted"?  For a container library, I think there is room for
>> several attempts before getting it "right". After all, Ada programmers
>> are much fussier about the quality and the design than in other 
>> languages. I
>> think one needs to leave room for evolution and experimentation. 
>> Eventally,
>> an emerging accepted defacto standard is bound to emerge. I think, you
>> would agree that we would like it to happen a little sooner, that's
>> all!
>>
> 
> BIG DIFFERENCE! The ultimate *CUSTOMER* was sponsoring the competition. 

You are correct about that. But I maintain that you can still have
a "bake off", without sponsorship, or even a limited sponsorship
could work (maybe some sort of prize).

> They went off and recruited designers to develop the designs. 

Open source leaves out designers?

> The 
> *customer* said "Here's what I have in mind - show me what your proposal 
> is..." 

OK, so we are back to the concensus thing.

> What you are suggesting doing is charging off without an 
> identifiable customer or an identifiable set of requirements and 

Whoa, there matie!  Remember earlier, I suggested that some guidelines
for the bake-off needed to be specified up front (aka specification), from
some sort of identifiable group of interested parties (aka "customer").
But let the project groups refine and polish the specs, with the hope
of being selected as winner.

I never promote the idea of charging off to face the windmills! Some
Open Sourced development works that way, but it hardly needs to be
that way.

 > Get an identifiable customer up
> front to say "Yes, I'm interested in getting a library" 

That has already been clearly identified.

> and b) Get from 
> them some set of desired requirements - even if its back-of-the-envelope 
> sort of stuff. 

Right. I am not saying we just form teams to come up with a
design, without some sort of guidelines. You can't have a
meaningful contest that way. ;-)  You are trying to put words
in my mouth, and they don't taste too good.

> Do that *FIRST* before wasting time building something 
> that perhaps nobody wants.

I'm not disagreeing. In fact, I think we're in agreement on
this point. You just said yourself that "even if its
back-of-the-envelope sort of stuff", which is possibly enough
to start a competition. That is exactly the idea I was promoting,
but you keep accusing me of charging off and wasting effort. ;-)

> Baby steps are fine. I just think the first and formost baby step needs 
> to be "Find out which vendors are planning to continue developing their 
> Ada compilers 

And what if the answer is that most of them are not? Are you
going to stop pushing?

What if you can't get an honest answer to that question? Are
you going to stop trying?

I think this is a reasonable thing to know, but I am just a little
skeptical that you'll get an answer, or the one you want to hear.

> and find out if they want there to be some sort of CAL 
> that they are willing to accept and play a role in developing." The rest 
> can start to fall out of there. I think vendor participation is a 
> necessary condition to starting anything.

Your point is a valid one, but let's just agree to see things
differently. The way I personally see it, the customer demand
can drive this point, without starting with the vendors.

>> I have always taken the approach of learning from doing. So I would
>> not discourage people from trying something new. Many projects may
>> end up as throw-aways in the end, but that does not mean the effort
>> is a wasted one. You seem to be worried about wasted effort(s).
> 
> Because efforts have been wasted before and I want to make a *different* 
> set of mistakes this time around. 

No disagreement here.

> If you keep trying to get through a 
> wall by running headlong into it, would you be surprised if someone says 
> "This is foolish. Why not look for a door or window before charging at 
> the wall again..." 

Well, if someone chooses to recreate a past mistake, then that
reflects on the person or team. Not the need for a solution.

> These efforts have been tried before and the evidence 
> is right out there in the Internet to look at. 

Which is why it is not necessarily a foregone conclusion that
any next effort has to be a waste. Hopefully, people/teams can
learn from what's available on the Internet. You seem to be
implying that people don't or can't learn from history. You might
even be right, but I don't quite see it this way. ;-)

> You can compare all the 
> attempts and compare all the Ada implementations and you see that the 
> attempts are not found in Ada implementations. 

I am not sure what you're saying here. Are you talking about
failed Ada container libraries here, vs where they have succeeded
else where? Please clarify.

> If you want to go that 
> route again - its your head that is going to hit the wall while I'm 
> feeling around for the doornob. ;-)

No, I have no personal plans to bang my head against the wall. I
used to do that when I was 4 years of age, until my mother finally
cured me of it by saying "Go ahead! Bang it again!"  I think I can
honestly say that I am cured for life ;-)

>>> Yes, but just recall all the other various and sundry "Open Source" /
>>> Volunteer oriented projects of any stripe that get started out there.
>>> (Should we start a list?)
>>
>> As I've pointed out earlier, a failed project is never completely
>> a failure. Someone/people have learned lessons from those undertakings,
>> even if it is just to understand their own level of commitment ;-)
> 
> Yes, and from my "failed" projects, I've learned that you need to get 
> the customer involved very early on. ;-)

No disagreement. But surely, *we* as the customer can *know* what
we want. Reaching concensus might be challenging, but that is part
of a necessary process.

> Well, I don't know what I'm leading here if anything. But if a few folks 
> representing vendors were to come to me and say "Please, Marin, with 
> your sublime wisdom and vast vision, could you somehow or other find 
> some way to devote some time to this???" I might be tempted to do so. I 
> suspect they have their own visionaries they could count on better. :-) 
> Why? You think they want to offer me a job?

I can't dismiss that possibility, but I was thinking more of
someone leading the charge with the "Let's set up a Ada Corporation
for shared software" type of thing, that you described in your article
(which I'm not articulating from memory very well here). I think
someone will have to lead the charge with a Stallman like vision, and
determination. Vision without determination is likely to fade away.

> My premise is that if the vendors wanted to drive an effort to get a 
> library, they could get one. 

The problem with this is that the vendors don't really care, unless
they see some pot of gold at the end of that rainbow. For them, I
see this as only an incremental gain, unless one looks at a long
range successful forecast.

The big payoff is in the customer's court. This is why the customer
wants it. For the vendors, it just means more to support, and a
little more to charge for (some balance between customer need and
cost has to be reached).

> If they are looking for volunteers, they 
> could find some - but probably not enough to get it to market in a 
> reasonable lenght of time or meeting requirements unless they have some 
> paid-guidance overseeing the effort. The ideal situation would be to pay 
> for the whole thing so you get exactly what you want and when you want 
> it. If you don't have that kind of cash, then get creative about how to 
> do it on a shoestring. A solution does exist. Do the vendors see it as a 
> problem they want to solve? Is there interest in taking up the challenge?
> 
> MDC

I can only really speak from a GNAT perspective, and the signs seem
encouraging from ACT. Is this enough? Will it drive the other vendors
to follow? These are tough questions to answer.

I think we are not that far apart in our thinking, but perhaps where
we place our trust is different. I prefer to take the reins approach,
where you are happy to put it in the hands of the vendors,
with a channel for input.

I could live with either approach, as long as it sees results.

But I know that your point is partly that we're all tired of
waiting for a solution.

So I guess if I was to summarize my point in response it would be
simply this: "don't dismiss the open sourced route, simply because
it has been tried, and been unfunded.  While the past is often an
indicator of what is likely, it does not necessarily predispose
it to failure." I think the last sentence is where we mostly
disagree. ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Standard Library Interest?

[Ed Falis]

On Wed, 22 Oct 2003 12:46:53 -0400, Warren W. Gay VE3WWG 
<ve3wwg@cogeco.ca> wrote:

>> Except that neither one of those was some sort of "All Volunteer" 
>> effort divorced from the vendors. Thus demonstrating exactly what I am 
>> hoping ought to happen. Win32Ada was something that was built (I 
>> believe) By Tucker Taft who was doing it for Averstar? Softech?
>
> That one, I am not really surprised by, due to the extent of the
> work that would is involved in that. Not to mention the maintenance
> of the same.

Actually, Mitch Gart did that binding, when he worked at Intermetrics, 
prior to the Averstar absorption of the former.

- Ed

Re: Standard Library Interest?

[Marin David Condic]

Wasn't it auto-generated from some sort of C-Header-File-To-Ada 
Translator? I was under the impression it was done that way to make it 
easy to generate new releases as Micro$oft (a.k.a. The Borg) issued new 
releases of their Win32api.

MDC


Ed Falis wrote:
> 
> Actually, Mitch Gart did that binding, when he worked at Intermetrics, 
> prior to the Averstar absorption of the former.
> 
> - Ed


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Ed Falis]

On Thu, 23 Oct 2003 05:23:51 GMT, Marin David Condic <nobody@noplace.com> 
wrote:

> Wasn't it auto-generated from some sort of C-Header-File-To-Ada 
> Translator? I was under the impression it was done that way to make it 
> easy to generate new releases as Micro$oft (a.k.a. The Borg) issued new 
> releases of their Win32api.

I believe it turned out that there was a fair amount of post-massaging to 
do to it, which inkibited keeping it up to date.  I had the same kind of 
problem with the JDK bindings I did for use with AppletMagic.

- Ed

Re: Standard Library Interest?

[Marin David Condic]

O.K. I'm not dismissing an Open Source route, and I'm not dismissing an 
all-volunteer, unpaid, organically grown route either. What I *am* 
dismissing is the idea that we can somehow survey all the Ada users out 
there and come up with a coherent set of requirements on which to base 
it. I'm dismissing the notion that once implemented, all those Ada users 
are then going to drop what they *are* using in favor of the library put 
out there. I'm further dismissing the idea that the vendors will then 
see the light and get on board and start distributing it.

We've been down a route that was some version of "Lets get everyone's 
consensus on what they want and then try to come up with something that 
will be adopted by all..." Its been tried more than once. There is no 
standard library being shipped by vendors as a result of that. That's 
why I'm saying lets try a *different* route - one that would be to get 
the *vendors* to act as "Customer Representatives" and stipulate what it 
is they want to see done. (Think of it as a Republic rather than a 
Democracy) The vendors are in a good position to know what sort of 
requirements their customers might have and - rather than try to get a 
consensus from a few thousand users - you get it from a handful of 
representatives.

Given that you might get requirements from the vendors as customer 
representatives, one would presume that they would bundle it and ship it 
to their customers once built. Doing that would go an *IMENSE* way 
towards making the library a de-facto standard because people tend to 
use what they get with their compiler rather than try to go use 
something they just glommed off the Internet. They might complain that 
it wasn't done the way they wanted it done (I do that here from time to 
time, don't I?) or that it could have been better or that it excluded 
their pet features - but they'd USE IT because it was there and of good 
quality.

That's where I see the critical difference and where it is that we 
apparently disagree - you want to start with a few hundred or more 
requirements writers and hope that consensus across a few thousand (or 
more) users is going to result, thus bringing the vendors on board. I 
want to start with 2, 3, 4 vendors and let them bring the customers/end 
users on board. Your approach has been tried a number of times and not 
resulted in much. Mine has yet to be tried and may fail for a whole 
different batch of reasons - but they will be *different*. :-)

MDC



Warren W. Gay VE3WWG wrote:
> 
> So I guess if I was to summarize my point in response it would be
> simply this: "don't dismiss the open sourced route, simply because
> it has been tried, and been unfunded.  While the past is often an
> indicator of what is likely, it does not necessarily predispose
> it to failure." I think the last sentence is where we mostly
> disagree. ;-)
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> O.K. I'm not dismissing an Open Source route, and I'm not dismissing an 
> all-volunteer, unpaid, organically grown route either. What I *am* 
> dismissing is the idea that we can somehow survey all the Ada users out 
> there 

But you don't need _all_. Vendors won't get all users input either.

> and come up with a coherent set of requirements on which to base 
> it. 

This is not unachievable either. Pleasing everyone is unachievable,
but surely some sort of compromise can be reached.

> I'm dismissing the notion that once implemented, all those Ada users 
> are then going to drop what they *are* using in favor of the library put 
> out there. 

Yes, but so what? This is totally irrelevant, IMO.

> I'm further dismissing the idea that the vendors will then 
> see the light and get on board and start distributing it.

Now there's a point. I don't believe it, but you obviously
do. Maybe you're even right about this, but because this
is not carved in stone, I don't see it as a reason to pause.

> We've been down a route that was some version of "Lets get everyone's 
> consensus on what they want and then try to come up with something that 
> will be adopted by all..." Its been tried more than once. 

I've seen the same process worked through major corporations.
If you insist that _all_ interested parties agree on a
set of requirements, the project is then almost doomed to
failure.

One way to get a better concensus is to form smaller teams.
Solicit input from the entire community, yes. But at the
project level, only allow the contributors to the project
deem what is going to be accepted, or not, or to require
more R&D.

You must eliminate those that only raise obsticals, from
holding the progress of the project up. Sadly, many IT
people are good at raising issues/problems, but few are
willing to make good suggestions (and even fewer, to
contribute to those suggestions). So I would suggest,
those that are not contributing, do not have a direct
say in the project (again, input is OK, but they do not
hold things back).

> There is no 
> standard library being shipped by vendors as a result of that. 

Well, I don't think it is quite that simple. One firm is
not going to develop and ship a toolset, if another is going
to develop and ship a different set. So in the end, nobody
does. There are probably a number of other reasons as well.

> That's 
> why I'm saying lets try a *different* route 

Agreed.

> - one that would be to get 
> the *vendors* to act as "Customer Representatives" and stipulate what it 
> is they want to see done. (Think of it as a Republic rather than a 
> Democracy) The vendors are in a good position to know what sort of 
> requirements their customers might have and - rather than try to get a 
> consensus from a few thousand users - you get it from a handful of 
> representatives.

I'm not against this, but only skeptical of it. ;-)

> Given that you might get requirements from the vendors as customer 
> representatives, one would presume that they would bundle it and ship it 
> to their customers once built. 

But how are you going to get the vendors to make it a priority,
and work together with other vendors?

> That's where I see the critical difference and where it is that we 
> apparently disagree - you want to start with a few hundred or more 
> requirements writers and hope that consensus across a few thousand (or 
> more) users is going to result, thus bringing the vendors on board. I 
> want to start with 2, 3, 4 vendors and let them bring the customers/end 
> users on board. Your approach has been tried a number of times and not 
> resulted in much. Mine has yet to be tried and may fail for a whole 
> different batch of reasons - but they will be *different*. :-)
> 
> MDC

I am not convinced (yet) that all has been tried on the volunteer
side. You might be right in saying there is not enough volunteer
resources (Ada-wise) and you might be right in saying we can't
reach a concensus. But I am not convinced that it otherwise that
it could not work. 8-)

I do applaud your efforts for trying to get something to
happen.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Standard Library Interest?

[Marin David Condic]

Well, we've had a variety of all volunteer efforts aimed at developing 
something that had some community acceptance that would eventually get 
the vendors on board. As I've observed, despite these efforts, we don't 
have a library. That's why I remain skeptical of another effort to get a 
bunch of guys together and develop another library on speculation with 
no indication from the vendors or the ARG or anybody else in a position 
to impose a standard that they'd even be remotely interested. If the 
answer is "No" from the start, I don't want to waste my time.

I applaud anyone who wants to develop a library. I'm suggesting that if 
the people in a position to actually make such a library into a 
"standard" were interested, it would get a lot further.

MDC


Warren W. Gay VE3WWG wrote:
> 
> I am not convinced (yet) that all has been tried on the volunteer
> side. You might be right in saying there is not enough volunteer
> resources (Ada-wise) and you might be right in saying we can't
> reach a concensus. But I am not convinced that it otherwise that
> it could not work. 8-)
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "So if I understand 'The Matrix Reloaded' correctly, the Matrix is
     basically a Microsoft operating system - it runs for a while and
     then crashes and reboots. By design, no less. Neo is just a
     memory leak that's too hard to fix, so they left him in... The
     users don't complain because they're packed in slush and kept
     sedated"

         --  Marin D. Condic
======================================================================

Re: Standard Library Interest?

[Marin David Condic]

Warren W. Gay VE3WWG wrote:
> 
> IFF you get this kind of answer from some, most or all of the vendors,
> then I would agree that you have a "point". But IMHO, this is unlikely
> first of all (its not in their interest to go against what the user
> base wants), and certainly not a foregone conclusion. Note the "FF"
> in "IFF".
> 
Yeah, but AFAIK, they have not said what they *do* want and (assuming 
they are the initial "customers" you're trying to satisfy) charging off 
to build something on pure speculation without knowing what the customer 
wants is a most profound - if not outright sinful - waste of time.

Like I've observed elsewhere - we have libraries out there already. Any 
one of them could be adopted as the basis on which to build. This has 
not happened. There must be *something* about that path that the vendors 
are not terribly fond of. So before building Yet Another Ada Library and 
hoping to get all the Booch and Charles and Etc., users to switch to 
that and show the vendors that they must get on board because all their 
customers are doing so, why not just ask the vendors what they'd want to 
see done first?


> What drives the vendors, is what the "users want". Get them using
> your stuff. Get them wanting more of your stuff. IOW, get the users
> hooked first (a very time honoured principle). The vendors will
> fall in line from there. Demand usually drives business. Only in
> creative things like the Segway (sp?) where people didn't know they
> wanted one, does it work the other way. But I don't think the
> vendors are going to have any kind of a surprise for anyone on
> this front. ;-)

Yes. Absolutely. The vendors will be driven by customer demand. But 
right now, there are a dozen or so libraries out there and absolutely NO 
consensus on which one should be adopted as "The Thing". I think 
customers if surveyed, would indicate that they would want *some* kind 
of library. They already seem to like getting things like Ada.Strings... 
and Ada.Numerics... But perhaps they can't agree on which of several 
existing ones to adopt. Would you propose throwing Yet Another Ada 
Library into that fray to further divide the pie? If we could agree to 
adopt one of the existing ones as the basis & start building from there, 
fine. Except it hasn't happened. If none of these are "Good Enough" then 
perhaps we can build one that *is* going to meet with acceptance. But 
who's acceptance and what are their criteria? That's what the vendors 
could decide and settle.

This whole thing is a vicious circle. The vendors are waiting for some 
clear mandate from their customers. The customers are waiting to see 
which library will start shipping with their favorite compiler before 
going through the pain of switching out whatever they're using now in 
favor of something else. The standards bodies are waiting for both of 
these groups to settle on something so they can put their Imprimatur on 
it. So who's going to be the first one to get the ball rolling?

I just can't see starting another volunteer effort to charge off and 
build some new library when we have had plenty of that already and it 
hasn't worked. Someone with some "clout" has to drive the development 
and I see that as being the vendors. If you could get even *ONE* vendor 
to say "All right, we'll go down this path and start shipping this 
library if you guys go off and build something that meets these 
guidelines...." then it stands a chance of getting off of bottom dead 
center. But without even ONE vendor standing up and saying "This is what 
I'd like to see built....", I don't think its going to get very far.

MDC

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> Warren W. Gay VE3WWG wrote:
>> IFF you get this kind of answer from some, most or all of the vendors,
>> then I would agree that you have a "point". But IMHO, this is unlikely
>> first of all (its not in their interest to go against what the user
>> base wants), and certainly not a foregone conclusion. Note the "FF"
>> in "IFF".
>>
> Yeah, but AFAIK, they have not said what they *do* want and (assuming 
> they are the initial "customers" you're trying to satisfy) charging off 
> to build something on pure speculation without knowing what the customer 
> wants is a most profound - if not outright sinful - waste of time.

Agreed, but *you* are a customer, and *I* am a customer in the
open sourced sense. *We* know what we *want*, and certainly should
be in some position to understand what *others* like *us* want.

That says to me, that we are favourably positioned for some involvement
here ;-)

> Like I've observed elsewhere - we have libraries out there already. Any 
> one of them could be adopted as the basis on which to build. 

Yes and no. Not everyone is good at designing "libraries" for
general use, and so I would suggest that in a library sense,
some *are* more suitable for others. This of course, depends
upon agreed upon criteria...

> This has 
> not happened. There must be *something* about that path that the vendors 
> are not terribly fond of. 

Yes, agreed. If comp.lang.ada history is any indication, it
seems to be a general lack of agreement! Some want:

  - for embedded use (no dynamic memory allocation)
  - SPARK like qualities
  - C++ like qualities/idioms
  - easy to use (few instantiations of generics)
  - maximum flexibility (with more use of generics,
    but harder to use)

and there are probably more directions. I would add that there needs
to be a more "general purpose computing" focus, to get Ada into
more mainstream use.

But if *we* can't *agree* about what we *want*, then the rest
is a dead end.  My memory is foggy about the GRACE components
effort, but what I recall of it was a wide range of opinions
of what it should and shouldn't be.

I don't have any silver bullet for this problem, but one
suggestion might be to assemble a few respected and interested
parties (individuals that is), and build concensous amongst
themselves. Let them go away and build a spec, a pilot maybe,
and come out of it with a "like it or lump it" approach,
allowing for tweaks.

If there is enough other interested parties, then perhaps a
"competition" of sorts between different teams could be
arranged (I want to be on the green team ;-). Then pick a
winner, and tweak and live with that winner.

But IMHO, the biggest stumbling block here has always been
about building a common vision.

> So before building Yet Another Ada Library and 
> hoping to get all the Booch and Charles and Etc., users to switch to 
> that and show the vendors that they must get on board because all their 
> customers are doing so, why not just ask the vendors what they'd want to 
> see done first?

If you can get all vendors to ship the same thing, no matter
what it was, you can be sure people will use it. After all, the
GNAT packages get used that way. BUT, I don't think this
is likely to happen.

>> What drives the vendors, is what the "users want". Get them using
>> your stuff. Get them wanting more of your stuff. IOW, get the users
>> hooked first (a very time honoured principle). The vendors will
>> fall in line from there. Demand usually drives business. Only in
>> creative things like the Segway (sp?) where people didn't know they
>> wanted one, does it work the other way. But I don't think the
>> vendors are going to have any kind of a surprise for anyone on
>> this front. ;-)
> 
> Yes. Absolutely. The vendors will be driven by customer demand. But 
> right now, there are a dozen or so libraries out there and absolutely NO 
> consensus on which one should be adopted as "The Thing". 

Yes, consensus seems to be the problem.

> I think 
> customers if surveyed, would indicate that they would want *some* kind 
> of library. 

That much seems to be agreed on here in comp.lang.ada.

> They already seem to like getting things like Ada.Strings... 
> and Ada.Numerics... But perhaps they can't agree on which of several 
> existing ones to adopt. Would you propose throwing Yet Another Ada 
> Library into that fray to further divide the pie? If we could agree to 
> adopt one of the existing ones as the basis & start building from there, 
> fine. Except it hasn't happened. If none of these are "Good Enough" then 
> perhaps we can build one that *is* going to meet with acceptance. But 
> who's acceptance and what are their criteria? That's what the vendors 
> could decide and settle.

I like the idea of small teams that are capable of consensus, and
the idea that a competition with a winning design should be
adopted. Where this seems to fall down, is that the very people
that should be involved, do not have the time to allocate to this.

So then, perhaps we should be more open minded to what other
eager teams might be able to produce, with perhaps a senior
member to help guide their efforts in an advisory fashion.

> This whole thing is a vicious circle. The vendors are waiting for some 
> clear mandate from their customers. The customers are waiting to see 
> which library will start shipping with their favorite compiler before 
> going through the pain of switching out whatever they're using now in 
> favor of something else. The standards bodies are waiting for both of 
> these groups to settle on something so they can put their Imprimatur on 
> it. So who's going to be the first one to get the ball rolling?

I agree, but I prefer to focus on the reason why nothing is
happening. Lack of consensus, as you've said yourself. So let's
attack that. How do we fix that?

Smaller groups have a greater chance at consensus. But one group
may not achieve the best result.

Take the "Ada approach", and allow teams to submit competing
designs.

The question is, do we have enough interest to develop more than
one team?  This to me is the most doubtful factor.

> I just can't see starting another volunteer effort to charge off and 
> build some new library when we have had plenty of that already and it 
> hasn't worked. 

Any competition, does not _have_ to start from scratch. Let's
bring on a competiton where new and existing stuff is worked
and re-worked in competition.

You'll need to keep the final panel of judges small enough, or
some other democratic way of selecting a winner (voting?) As
long as the rules are clearly stated up front, and the parameters
properly planned, any "volunteer effort charging off" can
spur good results (if only by competition).

The real issue is consensus and enthusiasm. I think the former can
be achieved, but can we get enough participants to push the
competition forwared?

> Someone with some "clout" has to drive the development 
> and I see that as being the vendors. 

We can give "clout" to anyone, any "body" for judging or
voting purposes. The objective is to get general buy in,
and this may be a problem, because I suspect most Ada
users are most interested in embedded processing rather
than for general purpose use (but I would be happy to be
wrong about that).

If we have a clear winner at the end, then hopefully we
then *know* what we want, and get vendor interest. We
might also have a working implementation in GPL/PD form.

> If you could get even *ONE* vendor 
> to say "All right, we'll go down this path and start shipping this 
> library if you guys go off and build something that meets these 
> guidelines...." then it stands a chance of getting off of bottom dead 
> center. But without even ONE vendor standing up and saying "This is what 
> I'd like to see built....", I don't think its going to get very far.
> 
> MDC

I think getting ONE vendor is achievable, and certainly a baby-step.

Competition anyone? ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Standard Library Interest?

[Stephane Richard]

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



-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com


"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
news:JnAjb.8680$cT6.421284@news20.bellglobal.com...

> Agreed, but *you* are a customer, and *I* am a customer in the
> open sourced sense. *We* know what we *want*, and certainly should
> be in some position to understand what *others* like *us* want.
>
> That says to me, that we are favourably positioned for some involvement
> here ;-)
>



> Yes and no. Not everyone is good at designing "libraries" for
> general use, and so I would suggest that in a library sense,
> some *are* more suitable for others. This of course, depends
> upon agreed upon criteria...

*** define library?  not everyone is good at designing a library or not
every is good at designing a set of reusable components?  In a library such
as CAL things should be as reusable as possible in my book.

>
> Yes, agreed. If comp.lang.ada history is any indication, it
> seems to be a general lack of agreement! Some want:
>
>   - for embedded use (no dynamic memory allocation)
>   - SPARK like qualities
>   - C++ like qualities/idioms
>   - easy to use (few instantiations of generics)
>   - maximum flexibility (with more use of generics,
>     but harder to use)
>
> and there are probably more directions. I would add that there needs
> to be a more "general purpose computing" focus, to get Ada into
> more mainstream use.

*** Agreed, I think what we could do is go by the other "popular" languages,
the first thing would be to fill in the gap as in What do the other language
have that ada doesn't have?  as a first brainstorming reusable or not, but
what makes the other languages (any and all of them) popular and give that
to Ada.
>
> But if *we* can't *agree* about what we *want*, then the rest
> is a dead end.  My memory is foggy about the GRACE components
> effort, but what I recall of it was a wide range of opinions
> of what it should and shouldn't be.
>
*** I'm not sure about GRACE, haven't heard enough about the project to say
a word, but does it meant hat GRACE didn't have a basis for a good lbirary
foundation?  Perhaps it did and got lost in the confusion of it's creators
:-).  As others mentionned before if we dont have to reinvent the wheel we
shouldn't :-).  Have you looked at my proposed hierarchy I gave elsewhere on
this NG?  I tried to be as General as possible but detailed enough to give
an orentation to the library so to speak....from that tree we could see if
anyone's existing code can fit in there and get ready to do the rest.  Of
course that's a first draft of the hierarchy and should be worked on but it
is a first step :-).

http://www.adaworld.com/cal/cal_library.txt


> I don't have any silver bullet for this problem, but one
> suggestion might be to assemble a few respected and interested
> parties (individuals that is), and build concensous amongst
> themselves. Let them go away and build a spec, a pilot maybe,
> and come out of it with a "like it or lump it" approach,
> allowing for tweaks.
>
*** To me that seems like a good approach and I'm all for it. :-)

> If there is enough other interested parties, then perhaps a
> "competition" of sorts between different teams could be
> arranged (I want to be on the green team ;-). Then pick a
> winner, and tweak and live with that winner.
>
> But IMHO, the biggest stumbling block here has always been
> about building a common vision.
>
*** I think we all have a good common vision of what the library should
offer that's doesn't seem to be the problem right now. the major problem is
starting the work without getting paid so to speak.  Like I mentionned
elsewhere I'd be lying if I didn't wanna get paid for this effort especially
if it's gonna help the vendors.  I'm a developer and like all developers,
getting paid for something is somewhat motivational :-).   But I'm not
stopping at that for this project.  Ada needs it there's no doubt and I'm
willing to give it :-).  so you got me as an interested and already involved
party :-).

*** As for competition I wonder, if time wouldn't be better spent forming
teams that could work on different parts of the library instead of competing
in the same one as far as acheiving the ultiamate goal goes.   Sure if
someone looks at a stack algorithm and knows it can be done better then fine
do it and suggest it if it's faster/more stable, etc etc...then it gould go
in :-).


> If you can get all vendors to ship the same thing, no matter
> what it was, you can be sure people will use it. After all, the
> GNAT packages get used that way. BUT, I don't think this
> is likely to happen.

*** Not likely, but not impossible especially if our library doesn't
conflict with any packages offered by  the vendors already.  Ultimately we
could all associate and become the first 3rd party library vendor for Ada?
:-)

>
> >> What drives the vendors, is what the "users want". Get them using
> >> your stuff. Get them wanting more of your stuff. IOW, get the users
> >> hooked first (a very time honoured principle). The vendors will
> >> fall in line from there. Demand usually drives business. Only in
> >> creative things like the Segway (sp?) where people didn't know they
> >> wanted one, does it work the other way. But I don't think the
> >> vendors are going to have any kind of a surprise for anyone on
> >> this front. ;-)
> >
> > Yes. Absolutely. The vendors will be driven by customer demand. But
> > right now, there are a dozen or so libraries out there and absolutely NO
> > consensus on which one should be adopted as "The Thing".
>
> Yes, consensus seems to be the problem.
>
> > I think
> > customers if surveyed, would indicate that they would want *some* kind
> > of library.
>
> That much seems to be agreed on here in comp.lang.ada.
>
> > They already seem to like getting things like Ada.Strings...
> > and Ada.Numerics... But perhaps they can't agree on which of several
> > existing ones to adopt. Would you propose throwing Yet Another Ada
> > Library into that fray to further divide the pie? If we could agree to
> > adopt one of the existing ones as the basis & start building from there,
> > fine. Except it hasn't happened. If none of these are "Good Enough" then
> > perhaps we can build one that *is* going to meet with acceptance. But
> > who's acceptance and what are their criteria? That's what the vendors
> > could decide and settle.
>
> I like the idea of small teams that are capable of consensus, and
> the idea that a competition with a winning design should be
> adopted. Where this seems to fall down, is that the very people
> that should be involved, do not have the time to allocate to this.
>
> So then, perhaps we should be more open minded to what other
> eager teams might be able to produce, with perhaps a senior
> member to help guide their efforts in an advisory fashion.
>
> > This whole thing is a vicious circle. The vendors are waiting for some
> > clear mandate from their customers. The customers are waiting to see
> > which library will start shipping with their favorite compiler before
> > going through the pain of switching out whatever they're using now in
> > favor of something else. The standards bodies are waiting for both of
> > these groups to settle on something so they can put their Imprimatur on
> > it. So who's going to be the first one to get the ball rolling?
>
> I agree, but I prefer to focus on the reason why nothing is
> happening. Lack of consensus, as you've said yourself. So let's
> attack that. How do we fix that?
>
> Smaller groups have a greater chance at consensus. But one group
> may not achieve the best result.
>
> Take the "Ada approach", and allow teams to submit competing
> designs.
>
> The question is, do we have enough interest to develop more than
> one team?  This to me is the most doubtful factor.
>
> > I just can't see starting another volunteer effort to charge off and
> > build some new library when we have had plenty of that already and it
> > hasn't worked.
>
> Any competition, does not _have_ to start from scratch. Let's
> bring on a competiton where new and existing stuff is worked
> and re-worked in competition.
>
> You'll need to keep the final panel of judges small enough, or
> some other democratic way of selecting a winner (voting?) As
> long as the rules are clearly stated up front, and the parameters
> properly planned, any "volunteer effort charging off" can
> spur good results (if only by competition).
>
> The real issue is consensus and enthusiasm. I think the former can
> be achieved, but can we get enough participants to push the
> competition forwared?
>
> > Someone with some "clout" has to drive the development
> > and I see that as being the vendors.
>
> We can give "clout" to anyone, any "body" for judging or
> voting purposes. The objective is to get general buy in,
> and this may be a problem, because I suspect most Ada
> users are most interested in embedded processing rather
> than for general purpose use (but I would be happy to be
> wrong about that).
>
> If we have a clear winner at the end, then hopefully we
> then *know* what we want, and get vendor interest. We
> might also have a working implementation in GPL/PD form.
>
> > If you could get even *ONE* vendor
> > to say "All right, we'll go down this path and start shipping this
> > library if you guys go off and build something that meets these
> > guidelines...." then it stands a chance of getting off of bottom dead
> > center. But without even ONE vendor standing up and saying "This is what
> > I'd like to see built....", I don't think its going to get very far.
> >
> > MDC
>
> I think getting ONE vendor is achievable, and certainly a baby-step.
>
> Competition anyone? ;-)
>
> -- 
> Warren W. Gay VE3WWG
> http://home.cogeco.ca/~ve3wwg
>

Re: Standard Library Interest?

[Stephane Richard]

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

Sorry but my daughter accidentaly sent my last post before I finished
answering all the issues so I continue here :-).  (2 years old and she can
already send an email sheesh hehe).

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

"Stephane Richard" <stephane.richard@verizon.net> wrote in message
news:h3Bjb.17267$zw4.9742@nwrdny01.gnilink.net...
>
>
> -- 
> St�phane Richard
> "Ada World" Webmaster
> http://www.adaworld.com
>
>
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
> news:JnAjb.8680$cT6.421284@news20.bellglobal.com...
>
> > Agreed, but *you* are a customer, and *I* am a customer in the
> > open sourced sense. *We* know what we *want*, and certainly should
> > be in some position to understand what *others* like *us* want.
> >
> > That says to me, that we are favourably positioned for some involvement
> > here ;-)
> >
>
>
>
> > Yes and no. Not everyone is good at designing "libraries" for
> > general use, and so I would suggest that in a library sense,
> > some *are* more suitable for others. This of course, depends
> > upon agreed upon criteria...
>
> *** define library?  not everyone is good at designing a library or not
> every is good at designing a set of reusable components?  In a library
such
> as CAL things should be as reusable as possible in my book.
>
> >
> > Yes, agreed. If comp.lang.ada history is any indication, it
> > seems to be a general lack of agreement! Some want:
> >
> >   - for embedded use (no dynamic memory allocation)
> >   - SPARK like qualities
> >   - C++ like qualities/idioms
> >   - easy to use (few instantiations of generics)
> >   - maximum flexibility (with more use of generics,
> >     but harder to use)
> >
> > and there are probably more directions. I would add that there needs
> > to be a more "general purpose computing" focus, to get Ada into
> > more mainstream use.
>
> *** Agreed, I think what we could do is go by the other "popular"
languages,
> the first thing would be to fill in the gap as in What do the other
language
> have that ada doesn't have?  as a first brainstorming reusable or not, but
> what makes the other languages (any and all of them) popular and give that
> to Ada.
> >
> > But if *we* can't *agree* about what we *want*, then the rest
> > is a dead end.  My memory is foggy about the GRACE components
> > effort, but what I recall of it was a wide range of opinions
> > of what it should and shouldn't be.
> >
> *** I'm not sure about GRACE, haven't heard enough about the project to
say
> a word, but does it meant hat GRACE didn't have a basis for a good lbirary
> foundation?  Perhaps it did and got lost in the confusion of it's creators
> :-).  As others mentionned before if we dont have to reinvent the wheel we
> shouldn't :-).  Have you looked at my proposed hierarchy I gave elsewhere
on
> this NG?  I tried to be as General as possible but detailed enough to give
> an orentation to the library so to speak....from that tree we could see if
> anyone's existing code can fit in there and get ready to do the rest.  Of
> course that's a first draft of the hierarchy and should be worked on but
it
> is a first step :-).
>
> http://www.adaworld.com/cal/cal_library.txt
>
>
> > I don't have any silver bullet for this problem, but one
> > suggestion might be to assemble a few respected and interested
> > parties (individuals that is), and build concensous amongst
> > themselves. Let them go away and build a spec, a pilot maybe,
> > and come out of it with a "like it or lump it" approach,
> > allowing for tweaks.
> >
> *** To me that seems like a good approach and I'm all for it. :-)
>
> > If there is enough other interested parties, then perhaps a
> > "competition" of sorts between different teams could be
> > arranged (I want to be on the green team ;-). Then pick a
> > winner, and tweak and live with that winner.
> >
> > But IMHO, the biggest stumbling block here has always been
> > about building a common vision.
> >
> *** I think we all have a good common vision of what the library should
> offer that's doesn't seem to be the problem right now. the major problem
is
> starting the work without getting paid so to speak.  Like I mentionned
> elsewhere I'd be lying if I didn't wanna get paid for this effort
especially
> if it's gonna help the vendors.  I'm a developer and like all developers,
> getting paid for something is somewhat motivational :-).   But I'm not
> stopping at that for this project.  Ada needs it there's no doubt and I'm
> willing to give it :-).  so you got me as an interested and already
involved
> party :-).
>
> *** As for competition I wonder, if time wouldn't be better spent forming
> teams that could work on different parts of the library instead of
competing
> in the same one as far as acheiving the ultiamate goal goes.   Sure if
> someone looks at a stack algorithm and knows it can be done better then
fine
> do it and suggest it if it's faster/more stable, etc etc...then it gould
go
> in :-).
>
>
> > If you can get all vendors to ship the same thing, no matter
> > what it was, you can be sure people will use it. After all, the
> > GNAT packages get used that way. BUT, I don't think this
> > is likely to happen.
>
> *** Not likely, but not impossible especially if our library doesn't
> conflict with any packages offered by  the vendors already.  Ultimately we
> could all associate and become the first 3rd party library vendor for Ada?
> :-)
>
> > Yes, consensus seems to be the problem.

*** Indeed but that's because libraries were started without being discussed
first I think.  At least it's usually the result of developing without
discussing :-).

> >
> > > I think
> > > customers if surveyed, would indicate that they would want *some* kind
> > > of library.
> >
> > That much seems to be agreed on here in comp.lang.ada.

*** I second that ;-)

> >
> > I like the idea of small teams that are capable of consensus, and
> > the idea that a competition with a winning design should be
> > adopted. Where this seems to fall down, is that the very people
> > that should be involved, do not have the time to allocate to this.
> >
> > So then, perhaps we should be more open minded to what other
> > eager teams might be able to produce, with perhaps a senior
> > member to help guide their efforts in an advisory fashion.
> >

*** Perhaps, where are those senior members? :-).


> >
> > I agree, but I prefer to focus on the reason why nothing is
> > happening. Lack of consensus, as you've said yourself. So let's
> > attack that. How do we fix that?
> >
*** Good question. :-)  only way to fix it is to reach the given consensus.
Like I said I think we all have a pretty similar vision of what the library
should have.  so perhaps that's not where the problem lies.  Getting paid
for it seems to be an issue to some Getting support from vendors or
organizations seems to be another (by support I mean someone somewhere
saying we're on teh right track and here's why.

*** What do these other lbirary projects have?  maybe that should be our
"Not To Do" list to start with? Although someof them we'd need like standard
data structures (stacks queues etc etc).  but other than that what's missing
in the other lbirary projects?

*** As I mentionned on another post, I gave a pretty good list of what I
wanted (not the hierarchy I started but another list of missing I noticed
from Ada.  perhaps we can start from that too or add that to the list of
things to do?


> > Smaller groups have a greater chance at consensus. But one group
> > may not achieve the best result.
> >
> > Take the "Ada approach", and allow teams to submit competing
> > designs.
> >
> > The question is, do we have enough interest to develop more than
> > one team?  This to me is the most doubtful factor.

***  You sure seem to be, I am definitaly, Marin is too for a nominal fee
;-)....Robert seems to be interested too.  I talked to a few people at APIWG
and other SIG Ada Group members that like the idea (not sure how much time
they could or would invest but they do think it's a good idea :-).
> >
> > Any competition, does not _have_ to start from scratch. Let's
> > bring on a competiton where new and existing stuff is worked
> > and re-worked in competition.
> >
> > You'll need to keep the final panel of judges small enough, or
> > some other democratic way of selecting a winner (voting?) As
> > long as the rules are clearly stated up front, and the parameters
> > properly planned, any "volunteer effort charging off" can
> > spur good results (if only by competition).
> >
> > The real issue is consensus and enthusiasm. I think the former can
> > be achieved, but can we get enough participants to push the
> > competition forwared?
> >
*** Again here would it be competition or elaborating different parts of the
library instead?  which would be a better usage of our time? :-)

> > We can give "clout" to anyone, any "body" for judging or
> > voting purposes. The objective is to get general buy in,
> > and this may be a problem, because I suspect most Ada
> > users are most interested in embedded processing rather
> > than for general purpose use (but I would be happy to be
> > wrong about that).

*** I'm all for general use, it's my foundation for participating in the
library in the first place.  That's a big chunk of what's missing in Ada,
general purpose lbiraries and components to build software that please a
more general population (business and people alike).  As in For games, maybe
tools to help build business applications, (database and reporting tighly
integrated somehow).  And various other fields of applications.

> >
> > If we have a clear winner at the end, then hopefully we
> > then *know* what we want, and get vendor interest. We
> > might also have a working implementation in GPL/PD form.
> >
> > > If you could get even *ONE* vendor
> > > to say "All right, we'll go down this path and start shipping this
> > > library if you guys go off and build something that meets these
> > > guidelines...." then it stands a chance of getting off of bottom dead
> > > center. But without even ONE vendor standing up and saying "This is
what
> > > I'd like to see built....", I don't think its going to get very far.
> > >
> > > MDC
> >
> > I think getting ONE vendor is achievable, and certainly a baby-step.

*** I'm talking to ACT and seeing what can be done about it, I'll have to
keep you posted or maybe at that point they'll keep us all posted if all
goes well :-).

> >
> > Competition anyone? ;-)
> >
*** Got my gear ready :-).

> > -- 
> > Warren W. Gay VE3WWG
> > http://home.cogeco.ca/~ve3wwg
> >
>
>

Re: Standard Library Interest?

[Robert I. Eachus]

Stephane Richard wrote:

> ***  You sure seem to be, I am definitaly, Marin is too for a nominal fee
> ;-)....Robert seems to be interested too.  I talked to a few people at APIWG
> and other SIG Ada Group members that like the idea (not sure how much time
> they could or would invest but they do think it's a good idea :-).

I have probably spent more time talking here than I should, and less 
time actually working on a library (or a registry).  Getting the 
concepts right, and the library design right is worth a lot of effort, 
but too many decent efforts have died from too much discussion and not 
enough commitment. (In the sense of putting something on the table and 
either voting to accept it, or deciding how to improve it.)
-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Stephane Richard]

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


"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:3F8F3986.7000107@comcast.net...
> Stephane Richard wrote:
>
> > ***  You sure seem to be, I am definitaly, Marin is too for a nominal
fee
> > ;-)....Robert seems to be interested too.  I talked to a few people at
APIWG
> > and other SIG Ada Group members that like the idea (not sure how much
time
> > they could or would invest but they do think it's a good idea :-).
>
> I have probably spent more time talking here than I should, and less
> time actually working on a library (or a registry).  Getting the
> concepts right, and the library design right is worth a lot of effort,
> but too many decent efforts have died from too much discussion and not
> enough commitment. (In the sense of putting something on the table and
> either voting to accept it, or deciding how to improve it.)
> -- 
>                                                      Robert I. Eachus
>
> "Quality is the Buddha. Quality is scientific reality. Quality is the
> goal of Art. It remains to work these concepts into a practical,
> down-to-earth context, and for this there is nothing more practical or
> down-to-earth than what I have been talking about all along...the repair
> of an old motorcycle."  -- from Zen and the Art of Motorcycle
> Maintenance by Robert Pirsig
>

You're right Robert.  Absolutely Right.  It's one of the reasons I create
that hierarchy.  To have something to start with...it's made to be deleted
from, added to, rebranched, whatever it takes to get a basis of something we
can all work on :-)

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[Marin David Condic]

Well, I could quit talking about it and maybe even devote some time to 
building it. Why not start with the Booch components? Or Grace? Or 
Charles? Or PragmAda? Or any of the others I've forgot to mention? Would 
the vendors get on board and say "If you guys shut up and start 
programming on top of XYZ library, we'll put it into our next release 
and start calling it the Conventional Ada Library..." I could get with 
that program, but I'd like to see some of the folks that matter say 
something about what they'd accept or reject. If none of those is 
suitable, then lets hear them say that - and then say something about 
what they *would* accept.

I don't even think it would need to be all the vendors. Look at it this 
way: Some of the vendors are out there actively developing their 
compilers and looking to improve their toolsets. Others are content to 
"milk the cash-cow" - they have an Ada compiler to sell but don't see it 
as an important future product so they do as little as is necessary to 
support it. They may not even see enough potential there to make it 
worth their time to upgrade it to Ada0x, so do they even count? How many 
of the vendors fall into the first category? Who are they? What if we 
got just those vendors to discuss it and express some opinions on what 
they'd like?

I don't think I'm asking for the moon and the sun and the stars here. 
Just some minimal display of interest and some guidance on 
priorities/requirements on the part of a small handful of vendors who 
stand to benefit by having their product improved at little to no cost 
to them - at least initially. Does that seem so unreasonable?

I'd be happy to discuss it with them off-line. All it takes is to send 
me an e-mail.

MDC



Robert I. Eachus wrote:
> 
> 
> I have probably spent more time talking here than I should, and less 
> time actually working on a library (or a registry).  Getting the 
> concepts right, and the library design right is worth a lot of effort, 
> but too many decent efforts have died from too much discussion and not 
> enough commitment. (In the sense of putting something on the table and 
> either voting to accept it, or deciding how to improve it.)


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Stephane Richard]

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

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F8F487E.80405@noplace.com...
> Well, I could quit talking about it and maybe even devote some time to
> building it. Why not start with the Booch components? Or Grace? Or
> Charles? Or PragmAda? Or any of the others I've forgot to mention? Would
> the vendors get on board and say "If you guys shut up and start
> programming on top of XYZ library, we'll put it into our next release
> and start calling it the Conventional Ada Library..." I could get with
> that program, but I'd like to see some of the folks that matter say
> something about what they'd accept or reject. If none of those is
> suitable, then lets hear them say that - and then say something about
> what they *would* accept.

*** yes that would be a neat little insight to build on.  no doubt about it.
Is this the only sure way to go in the right direction?  what do we aim with
this library?  To have something that can put Ada back in it's fair share of
the market, whether embedded or general purpose wise.  Am I right?  as a
general statement of course. :-)

*** If I am right, then a simple comparison of the "popular" language's
libraries and the ones for ada should be enough to elaborate a complete and
detailed list of what's missing in Ada to at least provide the same feautres
as the "popular" languages. no?

*** In that frame of mind.  We definitaly need libraries of all kinds, not
just data structures like Charles, Mats Weber's Ada Component Library and
the likes.  what's missing? as far as bindings are concerned?  well yes
MIDI/Audio bindings (thin and more so a thick MIDI and DIgital Audio
binding) for one.  in the same field, bindings to popular Linux Sounds
architectures like ALSA woudl be a good idea too so that Ada developers can
exploit those fields of development.  We have Engine_3D, AdaOpenGL, AdaSDL
for the graphic side...how about libraries of 3D animated graphics?  usign
those bindings so that they can be exploited too.  We got APQ right now for
a Database BInding, it's getting pretty good too.  But there's more to be
done, and Database in the industry is a must and should be considered.
There's no way that these ideas wouldn't help the outcome of the library
itself because they are sought after features of the "popular" languages.

>
> I don't even think it would need to be all the vendors. Look at it this
> way: Some of the vendors are out there actively developing their
> compilers and looking to improve their toolsets. Others are content to
> "milk the cash-cow" - they have an Ada compiler to sell but don't see it
> as an important future product so they do as little as is necessary to
> support it. They may not even see enough potential there to make it
> worth their time to upgrade it to Ada0x, so do they even count? How many
> of the vendors fall into the first category? Who are they? What if we
> got just those vendors to discuss it and express some opinions on what
> they'd like?
>
*** well since we do aim to have the library distributed with the compilers,
we'd definitaly need some feed back from the vendors.  No doubt about that
either.  we need to know from anyone (vendors and/or organizations) that
we're heading in the right direction.  but my first guess is that if we give
Ada what it's missing when compared to the "popular" languages.  It would be
hard for anyone to say we're not on the right track.  If not sooner in the
library's development then later but these missing features should
definitaly be implemented.

*** and that's just as far as libraries go.  There's other parts missing as
well.  At least some parts that need fine tuning at least :-)....Ada Core
Technologies has GPS which seems to be a good all around Ada IDE that seems
to integrate a good set of features expected in an IDE, but perhaps there 's
more that could be integrated.  and other tools (aplications) that could be
developed to give ada developers even more flexibility and integration as
per Ada and related technologies.


> I don't think I'm asking for the moon and the sun and the stars here.
> Just some minimal display of interest and some guidance on
> priorities/requirements on the part of a small handful of vendors who
> stand to benefit by having their product improved at little to no cost
> to them - at least initially. Does that seem so unreasonable?
>
*** I can't help but agree that sooner or later, the vendors will have to
get busy with this project.  at least the ones that do plan on moving to
Ada0X :-).  They'll need to step in for two reasons.

1. The library is aimed at giving the compilers more features, hence more
selling points.
2. To make sure we don't waste months developing something they already have
in their currently added libraries/features.  or their future projects too.
And if there is a conflict they'll have to reach the decision to either tell
us they got that side covered or redirect their efforts into a new project
and use ours as long as no one (us or them) waste time doing the same thing.

> I'd be happy to discuss it with them off-line. All it takes is to send
> me an e-mail.
>
> MDC
>
>
>


-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[Marin David Condic]

Stephane Richard wrote:
> 
> *** yes that would be a neat little insight to build on.  no doubt about it.
> Is this the only sure way to go in the right direction?  what do we aim with
> this library?  To have something that can put Ada back in it's fair share of
> the market, whether embedded or general purpose wise.  Am I right?  as a
> general statement of course. :-)
> 
The primary gopal ought to be to give the developer as much leverage as 
possible. The reason for that goal is to make Ada more attractive to 
select as the language of implementation on new products. It isn't the 
only thing that would make Ada more popular, but it is a significant thing.


> *** If I am right, then a simple comparison of the "popular" language's
> libraries and the ones for ada should be enough to elaborate a complete and
> detailed list of what's missing in Ada to at least provide the same feautres
> as the "popular" languages. no?
> 
It doesn't hurt to generate ideas. Looking at existing libraries (those 
provided by other languages and those that are provided separate from 
the language) The problem is that you've got to be careful not to put 
the cart before the horse. You may want a stack of ideas to present to 
the vendors & their customers so they could pick from the list what 
their priorities would be, but you don't want to start designing or 
developing until you have done that critical step.


> *** In that frame of mind.  We definitaly need libraries of all kinds, not
> just data structures like Charles, Mats Weber's Ada Component Library and
> the likes.  what's missing? as far as bindings are concerned?  well yes
> MIDI/Audio bindings (thin and more so a thick MIDI and DIgital Audio
> binding) for one.  in the same field, bindings to popular Linux Sounds
> architectures like ALSA woudl be a good idea too so that Ada developers can
> exploit those fields of development.  We have Engine_3D, AdaOpenGL, AdaSDL
> for the graphic side...how about libraries of 3D animated graphics?  usign
> those bindings so that they can be exploited too.  We got APQ right now for
> a Database BInding, it's getting pretty good too.  But there's more to be
> done, and Database in the industry is a must and should be considered.
> There's no way that these ideas wouldn't help the outcome of the library
> itself because they are sought after features of the "popular" languages.
> 
Yes, libraries to cover all sorts of programming needs - not just data 
structures. But a) Data structures are what you're going to build the 
rest of the stuff on top of, so its an important foundation and b) you 
have to be careful not to get too ambitious and kill this with too much 
work.

Here's a few relevant points:

The ARG may get around to sticking some sort of container library into 
Ada0x. If they do that, we'd be wasting our time implementing something 
else or implementing anything that might be using containers. Better to 
find out what is likely to happen with the ARG *FIRST* before writing a 
single line of code.

If you get to grandeose in the list of things to implement, it divides 
the attention and nothing will get done. Pick *one* thing to build as a 
first step. The rest of the list can be kept in your back pocket for 
when you've got something successfully built and in use. Given that it 
is not intuitively obvious to even the most casual observer what that 
one thing should be, you need to have the ARG/Vendors *tell* you what 
they want first. (Containers? Math? Network support? What isn't going to 
be in Ada0x and what is next on the vendors'/customer's wish list?)

This is why I keep harping on the need to have early involvement by the 
vendors. If they *won't* tell you what they want or they *won't* accept 
what you build, you're going to go off and build a million lines of code 
that nobody in particular wants and its not going to accomplish 
anything. I don't have that kind of spare time in my life to waste. I 
want to make sure that if I *do* put forth some effort on this, that it 
stands a chance of succeeding.

> 
> *** well since we do aim to have the library distributed with the compilers,
> we'd definitaly need some feed back from the vendors.  No doubt about that
> either.  we need to know from anyone (vendors and/or organizations) that
> we're heading in the right direction.  but my first guess is that if we give
> Ada what it's missing when compared to the "popular" languages.  It would be
> hard for anyone to say we're not on the right track.  If not sooner in the
> library's development then later but these missing features should
> definitaly be implemented.
> 
But what is available in other languages (like C) is a *huge* amount of 
territory. The sheer magnitude of it is part of what makes it "popular". 
  What customers are buying is the hugeness - in part. So let's think 
about this: In order to provide Ada users with what makes other 
languages popular, we have to develop a million lines of code. After 
devoting a few man-years to the effort, we find out that the vendors 
have no interest in the library because it doesn't meet their 
expectations. We've all quit our jobs and built this thing on 
speculation and are in divorce court over it, and the vendors don't want 
it?????

That's why I'd refuse to write so much as a single line of code until I 
knew there was an interested customer out there. We're not talking about 
just a linked-list package here. Its got to be ***BIG*** to be useful 
and unlike a linked-list package, ***BIG*** is going to take more than a 
handfull of evenings and weekends to build.

Note that Boeing doesn't just start building 747's "On Spec" and 
inventory them while waiting to see if any airlines want to buy them. 
They don't even start the engineering on a 747 without first talking to 
the airlines about what they're likely to want. You don't throw time and 
money into a big project without *FIRST* getting the customer on board 
with it.



> *** and that's just as far as libraries go.  There's other parts missing as
> well.  At least some parts that need fine tuning at least :-)....Ada Core
> Technologies has GPS which seems to be a good all around Ada IDE that seems
> to integrate a good set of features expected in an IDE, but perhaps there 's
> more that could be integrated.  and other tools (aplications) that could be
> developed to give ada developers even more flexibility and integration as
> per Ada and related technologies.
> 
There's a whole lot of stuff that it would be good for Ada to have. 
However, what you're talking about here is what software companies would 
view as a whole product line. I absolutely am not against developing a 
whole product line. Libraries, GUI builders, IDEs, Developmental 
Tools,Operating Systems, End-User Applications, etc. But I have to 
*work* for a living and this is too much to consider on any sort of 
part-time, uncompensated volunteer work basis. I also am not going to go 
about doing fine quality engineering work for the benefit of some vendor 
as a "charity" cause - I'll go work in a soup kitchen and give my 
charity to the poor.

Beyond getting something started, this job becomes *WAY* too big to be 
done strictly by uncompensated volunteers. It will need some kind of 
funding, but as I've observed, that need not be a huge amount and there 
might be ways of making it pay for itself. But until you discuss that 
with the potential "buyers" you have no clue and you're setting it up 
for failure.

How you fund it is an open question, but I think if the vendors don't 
want to pay for it outright, they need to consider some other form of 
"back-end" compensation. See Robert Leif's "Ada Developers Cooperative 
License" articles in Ada Letters and some of the related things on 
http://www.softdevelcoop.org/ This may not be the ultimate answer, but 
it provokes some ideas about how the development might be funded with 
payment coming to the developers after it is actually successful.




> 
> *** I can't help but agree that sooner or later, the vendors will have to
> get busy with this project.  at least the ones that do plan on moving to
> Ada0X :-).  They'll need to step in for two reasons.
> 

***!!!SOONER!!!*** not "Later". If you wait until later, you are a) 
going to waste lots of time and effort doing things you shouldn't be 
doing and b) set the whole thing up for failure because you didn't do 
what the vendors wanted.

I won't stop anyone who wants to go off and build a library on 
speculation. I'll just give odds and take bets on its ultimate success 
and make a pile of money when it fails. My advice would be: "Go ahead 
and do the job - but be sure to do it in a way that optimizes the 
chances of success." That means getting the vendors involved early in 
the game.

MDC
-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Marin David Condic]

But who should pick the "Winning Design"? I'd think that ought to be the 
vendors. Hence, I'd imagine them running the show and agreeing to 
deliver the end result. Otherwise, you're free to submit a design to me 
and I'll pronounce it "The Winner" and declare it to be "The Official 
Conventional Ada Library. What does that accomplish?

Get something going with the vendors and I think you'll see a library 
result that starts to get shipped with compilers and used as "The 
General Answer" by most developers. I don't think it matters if the 
vendors form up a R&D group and fund it to do the job or get a SIGAda 
committee going and donate some of their staff to it or contract the job 
out or pick some volunteer effort as "The Winner" and start building on 
it. Long term, I think they're going to have to spend a few bucks to 
keep it going, but they're doing that already in most respects via the 
ARM and their own libraries. I see them as the key to picking a 
direction and adopting something to go there and making it be "The 
Standard Thing". Without their involvement, we'll just see more of the same.

MDC


Warren W. Gay VE3WWG wrote:
> 
> I like the idea of small teams that are capable of consensus, and
> the idea that a competition with a winning design should be
> adopted. Where this seems to fall down, is that the very people
> that should be involved, do not have the time to allocate to this.
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Jacob Sparre Andersen]

Marin David Condic wrote:

> But who should pick the "Winning Design"? I'd think that ought to be the 
> vendors.

That would definitely be a good solution.

Another one, not quite as effective, would be if those who have written 
the current competing libraries agreed to do it - and to promote the 
winning design in favor of their own old libraries.  If both the SAL, 
Grace, LGL and PragmARC (as well as all the one I have forgotten) 
web-sites promoted the winning design, it would be very likely that lazy 
programmers like me switched.

What do the competing library maintainers say to that suggestion?

Jacob
-- 
�But you have to be a bit wary of a ship that collects
  snowflakes.�                                  -- Diziet Sma

Re: Standard Library Interest?

[Robert I. Eachus]

Jacob Sparre Andersen wrote:

> Another one, not quite as effective, would be if those who have written 
> the current competing libraries agreed to do it - and to promote the 
> winning design in favor of their own old libraries.  If both the SAL, 
> Grace, LGL and PragmARC (as well as all the one I have forgotten) 
> web-sites promoted the winning design, it would be very likely that lazy 
> programmers like me switched.

I guess I favor evolution, not revolution.  One of the nice features of 
having a registry like I proposed is that you would be able to easily 
mix components from multiple libraries without problems.  So I think 
that having ONE set of naming conventions and consistancy in hierarchies 
would be a big step forward.  If there is a "best of breed" selection 
process that results in some of these components being considered THE 
Ada library, and others considered older versions or alternatives we 
won't have thirty competing container libraries, but instead will have 
two or three good alternatives for a much wider set of capabilities.

This is not to say that there won't eventually be one way to do some 
things, just that if we define a good process that will last for a 
decade or so, we will be much better off than with one more unmaintained 
library.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:
> Jacob Sparre Andersen wrote:
> 
>> Another one, not quite as effective, would be if those who have 
>> written the current competing libraries agreed to do it - and to 
>> promote the winning design in favor of their own old libraries.  If 
>> both the SAL, Grace, LGL and PragmARC (as well as all the one I have 
>> forgotten) web-sites promoted the winning design, it would be very 
>> likely that lazy programmers like me switched.
> 
> I guess I favor evolution, not revolution.  One of the nice features of 
> having a registry like I proposed is that you would be able to easily 
> mix components from multiple libraries without problems.  So I think 
> that having ONE set of naming conventions and consistancy in hierarchies 
> would be a big step forward.  If there is a "best of breed" selection 
> process that results in some of these components being considered THE 
> Ada library, and others considered older versions or alternatives we 
> won't have thirty competing container libraries, but instead will have 
> two or three good alternatives for a much wider set of capabilities.

I fully agree that this is an important first step. No matter what
the design and adoption process is, the naming of the packages and
hierarchy is very important to agree upon.

> This is not to say that there won't eventually be one way to do some 
> things, just that if we define a good process that will last for a 
> decade or so, we will be much better off than with one more unmaintained 
> library.

I fully agree with this.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Standard Library Interest?

[Stephane Richard]

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

"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:3F941DE0.50906@comcast.net...
> Jacob Sparre Andersen wrote:
>
> > Another one, not quite as effective, would be if those who have written
> > the current competing libraries agreed to do it - and to promote the
> > winning design in favor of their own old libraries.  If both the SAL,
> > Grace, LGL and PragmARC (as well as all the one I have forgotten)
> > web-sites promoted the winning design, it would be very likely that lazy
> > programmers like me switched.
>
> I guess I favor evolution, not revolution.  One of the nice features of
> having a registry like I proposed is that you would be able to easily
> mix components from multiple libraries without problems.  So I think
> that having ONE set of naming conventions and consistancy in hierarchies
> would be a big step forward.  If there is a "best of breed" selection
> process that results in some of these components being considered THE
> Ada library, and others considered older versions or alternatives we
> won't have thirty competing container libraries, but instead will have
> two or three good alternatives for a much wider set of capabilities.
>
> This is not to say that there won't eventually be one way to do some
> things, just that if we define a good process that will last for a
> decade or so, we will be much better off than with one more unmaintained
> library.
>
> -- 
>                                                      Robert I. Eachus
>
> "Quality is the Buddha. Quality is scientific reality. Quality is the
> goal of Art. It remains to work these concepts into a practical,
> down-to-earth context, and for this there is nothing more practical or
> down-to-earth than what I have been talking about all along...the repair
> of an old motorcycle."  -- from Zen and the Art of Motorcycle
> Maintenance by Robert Pirsig
>
A big "I Agree to the whole contents of this message :-)

Even to your Quality is Buddha phrase ;-)
-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> But who should pick the "Winning Design"? I'd think that ought to be the 
> vendors. Hence, I'd imagine them running the show and agreeing to 
> deliver the end result. Otherwise, you're free to submit a design to me 
> and I'll pronounce it "The Winner" and declare it to be "The Official 
> Conventional Ada Library. What does that accomplish?

You are of course, entitled to that opinion. However, I would suggest
that it not _necessarily_ be run that way. The vendor still will need
to know what the users prefer. It seems to me that the users of the
winning design should be involved in picking the winning design. A
vendor is might just pick the path of least resistance, or lowest
support cost design, while the user may be interested in a higher
functionality profile etc.

In the end the users must be satisfied, because they will not just
swallow and use anything the vendors happen to provide.

> Get something going with the vendors and I think you'll see a library 
> result that starts to get shipped with compilers 

Perhaps this much..

> and used as "The 
> General Answer" by most developers. 

I don't agree that this necessarily follows, except perhaps out
of a developer path of least resistance.

> I don't think it matters if the 
> vendors form up a R&D group and fund it to do the job or get a SIGAda 
> committee going and donate some of their staff to it or contract the job 
> out or pick some volunteer effort as "The Winner" and start building on 
> it. Long term, I think they're going to have to spend a few bucks to 
> keep it going, but they're doing that already in most respects via the 
> ARM and their own libraries. I see them as the key to picking a 
> direction and adopting something to go there and making it be "The 
> Standard Thing". Without their involvement, we'll just see more of the 
> same.
> 
> MDC

The only thing I see as being critical to the winning design, is a
reference implementation. After all, any grandiose design can have
the trappings of being the best on paper, but be a dog in binary
form.

Given an effective reference implementation, it is mostly
up to the users what they really want. If the users tell the vendors
they want X, then the vendors won't have any trouble with X if it
is indeed practical to provide and support. It obviously helps if
the vendords love it, but I hardly think this is a requirement.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Standard Library Interest?

[Robert I. Eachus]

Marin David Condic wrote:

>  > You meant Ada.Containers, right?  Of course, if it is necessary, one
>  >  could be a renaming of the other.
>  >
> Nope. Nothing under Ada unless the ARM explicitly makes it legal to
> extend things under the root package Ada. There are times I'd have liked 
> to extend things under the root package Ada - except its illegal to do 
> that. If you've got an Ada.Containers, you'd like some end user to a) 
> have source for Ada.Containers and b) be able to tweak or adjust it or 
> extend it with whatever good ideas he may have. (Like maybe 
> Ada.Containers.Realtime? Or Ada.Containers.Bounded?) If this is 
> difficult to allow, then start another tree that is totally independent 
> and under which it *is* possible to extend.

That is why I mentioned renaming.  But if there is an Ada.Containers, 
then I think it should be used in preference to CAL.Containers.

By the way, the ARM A.2(4) says that: "In the standard mode, it is 
illegal to compile a child of package Ada."

But don't take that to mean what it doesn't say.  The AARM adds a 
reason, a ramification, and an Implementation Note:

Reason: The intention is that mentioning, say, Ada.Text_IO in a 
with_clause is guaranteed (at least in the standard mode) to refer to 
the standard version of Ada.Text_IO. The user can compile a root library 
unit Text_IO that has no relation to the standard version of Text_IO.

Ramification: Note that Ada can have non-language-defined grandchildren, 
assuming the implementation allows it. Also, packages System and 
Interfaces can have children, assuming the implementation allows it.

Implementation Note: An implementation will typically support a 
nonstandard mode in which compiling the language defined library units 
is allowed. Whether or not this mode is made available to users is up to 
the implementer.

The reason and the ramification are very important here.  In standard 
mode, you are guaranteed that Ada.Text_IO is the standard Ada.Text_IO. 
But if there is a container library in Ada, adding children, especially 
children that extend the original package is allowed.  (Incidently, the 
real, intended, rule is that vendors should have a special mode for 
recompiling the standard libraries, and replacing library units and 
their children defined in the RM should not otherwise be possible.)
-- 
                                         Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Marin David Condic]

I understand and anticipated that there would be a valid reason for not 
allowing extensions to Ada. That's why I raised the issue and was 
looking for something that would get around that.

Note that the ARM doesn't appear to say "Thou shalt provide a mode under 
which a common, ordinary, garden-variety user can extend and modify 
packages under Ada...". Hence there may not be. There may be no source 
delivered for things under Ada. There may be no method provided to 
recompile the source even if it is provided. The source may not even be 
in Ada - it could be in C or assembler or in Jovial for all that the 
standard has to say about it.

I think its essential that the end user have the library in source code 
and be allowed to play with it. If you figure out a way that this can be 
done, I'll accept that. I just want a guarantee that whatever tree it 
gets built under, I get the whole source for the tree and can modify or 
extend anything in that tree. Is that a reasonable requirement for a 
library?

MDC


Robert I. Eachus wrote:
> 
> That is why I mentioned renaming.  But if there is an Ada.Containers, 
> then I think it should be used in preference to CAL.Containers.
> 
> By the way, the ARM A.2(4) says that: "In the standard mode, it is 
> illegal to compile a child of package Ada."
> 
> But don't take that to mean what it doesn't say.  The AARM adds a 
> reason, a ramification, and an Implementation Note:
> 
> Reason: The intention is that mentioning, say, Ada.Text_IO in a 
> with_clause is guaranteed (at least in the standard mode) to refer to 
> the standard version of Ada.Text_IO. The user can compile a root library 
> unit Text_IO that has no relation to the standard version of Text_IO.
> 
> Ramification: Note that Ada can have non-language-defined grandchildren, 
> assuming the implementation allows it. Also, packages System and 
> Interfaces can have children, assuming the implementation allows it.
> 
> Implementation Note: An implementation will typically support a 
> nonstandard mode in which compiling the language defined library units 
> is allowed. Whether or not this mode is made available to users is up to 
> the implementer.
> 
> The reason and the ramification are very important here.  In standard 
> mode, you are guaranteed that Ada.Text_IO is the standard Ada.Text_IO. 
> But if there is a container library in Ada, adding children, especially 
> children that extend the original package is allowed.  (Incidently, the 
> real, intended, rule is that vendors should have a special mode for 
> recompiling the standard libraries, and replacing library units and 
> their children defined in the RM should not otherwise be possible.)


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Stephane Richard]

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



"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F8816EB.1010009@noplace.com...
> I understand and anticipated that there would be a valid reason for not
> allowing extensions to Ada. That's why I raised the issue and was
> looking for something that would get around that.
>
> Note that the ARM doesn't appear to say "Thou shalt provide a mode under
> which a common, ordinary, garden-variety user can extend and modify
> packages under Ada...". Hence there may not be. There may be no source
> delivered for things under Ada. There may be no method provided to
> recompile the source even if it is provided. The source may not even be
> in Ada - it could be in C or assembler or in Jovial for all that the
> standard has to say about it.
>
> I think its essential that the end user have the library in source code
> and be allowed to play with it. If you figure out a way that this can be
> done, I'll accept that. I just want a guarantee that whatever tree it
> gets built under, I get the whole source for the tree and can modify or
> extend anything in that tree. Is that a reasonable requirement for a
> library?
>
> MDC
>

I think so, seems reasonable for me, but shouldn't it basically depend on
the licence?  or would anything in there have the same licence?  or an
OpenSource Based licence so to speak so that it is available?
-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[Robert I. Eachus]

I said:

 > By the way, the ARM A.2(4) says that: "In the standard mode, it is
 > illegal to compile a child of package Ada."

 > But don't take that to mean what it doesn't say.  The AARM adds a
 > reason, a ramification, and an Implementation Note...

Marin David Condic said:

>Note that the ARM doesn't appear to say "Thou shalt provide a mode under
>which a common, ordinary, garden-variety user can extend and modify
>packages under Ada...". Hence there may not be. There may be no source
>delivered for things under Ada. There may be no method provided to
>recompile the source even if it is provided. The source may not even be
>in Ada - it could be in C or assembler or in Jovial for all that the
>standard has to say about it.

Um, yes, the ARM doesn't say that, and I like it that way.  But I do 
think the paragraph I pointed to needs fixing, and I think that we will 
definitely end up with an Ada.Containers hierarchy that vendors--and 
users--should be allowed to extend.  There are a couple of places where 
vendors are currently encouraged to add packages to Ada or modify the 
standard packages. It might be worthwhile to pull all of those together 
in one place, as well as their current locations:

A.3.3(31): "An implementation may provide additional packages as 
children of Ada.Characters, to declare names for the symbols of the 
local character set or other character sets."

A.5.1(48): "The nongeneric equivalent packages may, but need not, be 
actual instantiations of the generic package for the appropriate 
predefined type."

A.15(21): "An alternative declaration is allowed for package 
Command_Line if different functionality is appropriate for the external 
execution environment."

Stephane Richard wrote:
> I think so, seems reasonable for me, but shouldn't it basically depend on
> the licence?  or would anything in there have the same licence?  or an
> OpenSource Based licence so to speak so that it is available?

I don't think that is an issue.  If the specifications are in the 
standard, then providing an additional child package does not 
necessarily require knowing the contents of the package body, or even, 
to some extent, the contents of the private part of the package.

So I think we are okay leaving this undefined.  If a compiler vendor 
wants to make it difficult for a user to extend a package defined in the 
standard, they can.  But I don't expect the situation to come up.  Most 
"sensible" extensions to Ada will be in places like Ada.Characters.XXX, 
Ada.Strings.XXX, Ada.Numerics.XXX, etc.  These packages don't have a 
private part.

-- 
                                               Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Marin David Condic]

Just an observation: This basically says that the *vendor* can extend or 
tinker with particular parts of the package Ada and its offspring. (Q: 
Does that make them "Bastards?" Perhaps the way to extend the standard 
Ada packages is to add a new keyword: "bastard package 
Ada.Marins_Cool_Ideas is...."  The process of making some child an 
official part of the ARM is  "legitimizing the bastard"? :-)

There isn't anything there that says a normal user without the near 
godlike powers of a compiler-writer is allowed to do so, nor that an 
implementation must give him access to these powers, nor even the source 
with which to do so. It might be a reasonable compromise to have a 
separate tree that looks like any garden variety library an end-user 
might build and then worry about incorporating parts in the Ada tree at 
a later point - perhaps as you suggest with a renaming.

I just want to be sure that anything we might do is open to lots of 
flexibility and innovation without making it at all difficult for the 
end user to play games and make things better for themselves. Sticking 
things under the package Ada, seems like it might raise too many 
problems unless there are some rule changes.

MDC

Robert I. Eachus wrote:
> 
> 
> Um, yes, the ARM doesn't say that, and I like it that way.  But I do 
> think the paragraph I pointed to needs fixing, and I think that we will 
> definitely end up with an Ada.Containers hierarchy that vendors--and 
> users--should be allowed to extend.  There are a couple of places where 
> vendors are currently encouraged to add packages to Ada or modify the 
> standard packages. It might be worthwhile to pull all of those together 
> in one place, as well as their current locations:
> 
> A.3.3(31): "An implementation may provide additional packages as 
> children of Ada.Characters, to declare names for the symbols of the 
> local character set or other character sets."
> 
> A.5.1(48): "The nongeneric equivalent packages may, but need not, be 
> actual instantiations of the generic package for the appropriate 
> predefined type."
> 
> A.15(21): "An alternative declaration is allowed for package 
> Command_Line if different functionality is appropriate for the external 
> execution environment."
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Marin David Condic]

A license is something to worry about down the road. That's something 
the vendors would have to say something about anyway. At this point I'm 
concerned about the idea expressed by Robert Eachus that a Conventional 
Ada Library be a branch (or several) under the standard library "Ada". 
That is, "Ada.Containers" and "Ada.Statistics" and so on. This would be 
a wonderful thing since it provides something really natural. Except 
that under "normal" rules you are not allowed to extend the package 
"Ada" and you may not have everything you need to do it if you could. 
That's why I'm objecting. Put it under a separate library or change the 
rules for the "Ada" tree so that this is possible to extend and required 
that you get source.

At this point, I'm just stating a perceived requirement that is 
something near and dear to my heart - and possibly others: For a 
Conventional Ada Library, I want to get the source code and I want to be 
able to modify/extend it at will with no special limitations. (Much like 
any of the existing container libraries floating around out there.) If 
Robert Eachus or someone else who is smarter than me (And Robert really 
is *way* smarter than me! :-) can figure out some rule change for the 
package "Ada" that gets me this requirement, I'm happy as a pig in 
fewmets. :-) If that's not possible, then I think a Conventional Ada 
Library ought to exist under its own tree.

I suppose that Robert's suggestion about renamings might be a good 
compromise. Make some "Official" root (Let's call it "CAL") and start 
adding branches (like "CAL.Containers" and "CAL.Statistics") They go 
through some editor/publisher to make sure they meet requirements and 
are released with everyone's compiler in full Ada source. If at a later 
date, the ARG decides that, e.g. CAL.Containers, ought to be part of the 
Ada standard, you just do a "renames" to Ada.Containers (keeping the 
original) and now it is a fully standard, entirely official part of Ada, 
complete with its own chapter in the ARM and a full validation suite. 
That seems like something that ought to work reasonably well. Do you 
think? (It might have problems if it still exists in CAL and the 
end-user can modify it. Leave that to the language lawyers to sort out. 
*That* problem is *waaaaaay* down the road. We can burn that bridge when 
we get to it.)

MDC


MDC

Stephane Richard wrote:
> 
> I think so, seems reasonable for me, but shouldn't it basically depend on
> the licence?  or would anything in there have the same licence?  or an
> OpenSource Based licence so to speak so that it is available?


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Stephane Richard]

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

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F88A577.5000803@noplace.com...
> A license is something to worry about down the road. That's something
> the vendors would have to say something about anyway. At this point I'm
> concerned about the idea expressed by Robert Eachus that a Conventional
> Ada Library be a branch (or several) under the standard library "Ada".
> That is, "Ada.Containers" and "Ada.Statistics" and so on. This would be
> a wonderful thing since it provides something really natural. Except
> that under "normal" rules you are not allowed to extend the package
> "Ada" and you may not have everything you need to do it if you could.
> That's why I'm objecting. Put it under a separate library or change the
> rules for the "Ada" tree so that this is possible to extend and required
> that you get source.
>
> At this point, I'm just stating a perceived requirement that is
> something near and dear to my heart - and possibly others: For a
> Conventional Ada Library, I want to get the source code and I want to be
> able to modify/extend it at will with no special limitations. (Much like
> any of the existing container libraries floating around out there.) If
> Robert Eachus or someone else who is smarter than me (And Robert really
> is *way* smarter than me! :-) can figure out some rule change for the
> package "Ada" that gets me this requirement, I'm happy as a pig in
> fewmets. :-) If that's not possible, then I think a Conventional Ada
> Library ought to exist under its own tree.

*** Would we need to stipulate that all you do need to do is rename it to
make it part of the ada hiearchy?  as in make sure you just globally rename
it and it still works exactly the same?  or do you not see a situation where
this might be conflicting with anything already existing into ada?
 Basically treat CAL as Ada when naming libraries and at that point possibly
making a copy of the Ada hierarchy into the CAL database to make sure they
can't be named the same?  If there's no imminent problems, than that idea is
fine with me :-).  let's see what others think.

>
> I suppose that Robert's suggestion about renamings might be a good
> compromise. Make some "Official" root (Let's call it "CAL") and start
> adding branches (like "CAL.Containers" and "CAL.Statistics") They go
> through some editor/publisher to make sure they meet requirements and
> are released with everyone's compiler in full Ada source. If at a later
> date, the ARG decides that, e.g. CAL.Containers, ought to be part of the
> Ada standard, you just do a "renames" to Ada.Containers (keeping the
> original) and now it is a fully standard, entirely official part of Ada,
> complete with its own chapter in the ARM and a full validation suite.
> That seems like something that ought to work reasonably well. Do you
> think? (It might have problems if it still exists in CAL and the
> end-user can modify it. Leave that to the language lawyers to sort out.
> *That* problem is *waaaaaay* down the road. We can burn that bridge when
> we get to it.)

*** Yes I believe that's a good way to go about it.  Licenses will be
licenses when they are licenses :-) .

>
> MDC


-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[Marin David Condic]

Stephane Richard wrote:
 >
 >
 > *** Would we need to stipulate that all you do need to do is rename
 > it to make it part of the ada hiearchy?  as in make sure you just
 > globally rename it and it still works exactly the same?  or do you
 > not see a situation where this might be conflicting with anything
 > already existing into ada? Basically treat CAL as Ada when naming
 > libraries and at that point possibly making a copy of the Ada
 > hierarchy into the CAL database to make sure they can't be named the
 > same?  If there's no imminent problems, than that idea is fine with
 > me :-).  let's see what others think.
 >

Let's get that cart *behind* the horse. :-)

Suppose you had a package spec called "CAL.Containers.Lists" and it
provided a simple, basic, run-of-the-mill linked list data structure. It
gets packaged and shipped with every Ada compiler and might be
periodically updated to fix bugs or add a few new features. No problem.
Its not in the ARM, so nobody is going to get their panties in a bunch
because the changes are "non-standard". Ultimately, you're no worse off
than if you are hooking up to the Win32api - Micro$oft issues a new
release and something changed and you've got to potentially go fix your
code. No big deal - its done every day.

Ten years from now when the ARM is getting revised again, ACT, Aonix,
RR, et alia, all sit around in the smoke-filled room of the ARG
headquarters and say, "We think that CAL.Containers.Lists needs to be
incorporated into the standard and become "Ada.Containers.Lists"..."
What's the problem? The ARM simply copies the spec, changes the names
and adds a whole bunch of words that says "Ada.Containers.Lists must
behave in this manner..." How you get it there is an implementation
detail. Since the vendors already have CAL, they could copy & rename the
source as needed. They could use a renames if they wanted to. It doesn't
matter.

In the mean time, the CAL library still contains a CAL.Containers.Lists
and the editors of CAL have to decide what to do about it. They could
declare it to be a feature that is superceded by the ARM and discontinue
any modifications to it - basically pointing at its counterpart and
advising you to use that as its successor for all new development. They
could continue to modify and extend it to see if some new features
become desirable & perhaps impact the next ARM. They could delete it and
tell their users to either go with an earlier version of the library or
convert to the ARM version. Its an incredibly TBD issue and it really
doesn't matter today what direction it goes down. The point is that A
Solution Does Exist, so don't try to figure it out *today*.




 >
 >
 > *** Yes I believe that's a good way to go about it.  Licenses will be
 >  licenses when they are licenses :-) .
 >
Ultimately, if the vendors are distributing it, they will have all sorts
of interest in exactly what license is used. They may all want the 
GMGPL. They may want it all in the public domain. They may want it with 
some kinds of restrictions so it can serve as a revenue source. 
(*Someone* has to pay to build it & maintain it. You'd better figure out 
how that's going to work because it will affect how you structure the 
deal & the license.) So get an understanding that says "Yeah, we're hip 
to this and want to do it..." Let them argue about what sort of license 
to put it under once they decide they want it.

MDC
-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Robert I. Eachus]

Marin David Condic wrote:

> Suppose you had a package spec called "CAL.Containers.Lists" and it
> provided a simple, basic, run-of-the-mill linked list data structure. It
> gets packaged and shipped with every Ada compiler and might be
> periodically updated to fix bugs or add a few new features. No problem.
> Its not in the ARM, so nobody is going to get their panties in a bunch
> because the changes are "non-standard". Ultimately, you're no worse off
> than if you are hooking up to the Win32api - Micro$oft issues a new
> release and something changed and you've got to potentially go fix your
> code. No big deal - its done every day.
> 
> Ten years from now when the ARM is getting revised again, ACT, Aonix,
> RR, et alia, all sit around in the smoke-filled room of the ARG
> headquarters and say, "We think that CAL.Containers.Lists needs to be
> incorporated into the standard and become "Ada.Containers.Lists"..."
> What's the problem? The ARM simply copies the spec, changes the names
> and adds a whole bunch of words that says "Ada.Containers.Lists must
> behave in this manner..." How you get it there is an implementation
> detail. Since the vendors already have CAL, they could copy & rename the
> source as needed. They could use a renames if they wanted to. It doesn't
> matter.
> 
> In the mean time, the CAL library still contains a CAL.Containers.Lists
> and the editors of CAL have to decide what to do about it. They could
> declare it to be a feature that is superceded by the ARM and discontinue
> any modifications to it - basically pointing at its counterpart and
> advising you to use that as its successor for all new development. They
> could continue to modify and extend it to see if some new features
> become desirable & perhaps impact the next ARM. They could delete it and
> tell their users to either go with an earlier version of the library or
> convert to the ARM version. Its an incredibly TBD issue and it really
> doesn't matter today what direction it goes down. The point is that A
> Solution Does Exist, so don't try to figure it out *today*.

Very good, but be aware that for Ada.Containers.Lists, the issue is not 
ten years down the road, it is probably December.  In fact, I didn't go 
to the Halifax meeting, and Randy is probably typing busily away to 
provide the minutes and update the AIs to reflect what went on at the 
meeting.  It is possible that the ARG could recommend an "official" 
Ada.Containers heirarchy as early as this December.  If not, it may 
happen at the WG9 meeting in conjunction with Ada Europe next spring.

-- 
                                        Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Marin David Condic]

That's fine. That just means that CAL doesn't need a containers branch. 
(Unless there is some specialized need or Ada.Containers is not 
complete.) So change my previous example to 
"CAL.Statistics.Normal_Distribution" and re-read it. :-)

BTW, if Ada0x is going to have a containers package, this is a good 
reason for avoiding the random inclusion of just anything anyone builds 
into the library: You want any library branch that makes use of 
containers in some form to use the standard ones. This is especially 
true where they are used in parameters or objects that the caller is 
going to see - internal data structures are of somewhat less concern. 
But even there, you want them to exhibit whatever properties are in 
Ada.Containers.

I sure hope someone remembered to make the containers persistent through 
reading/writing to a file and/or converting to a stream.

MDC


Robert I. Eachus wrote:
> 
> Very good, but be aware that for Ada.Containers.Lists, the issue is not 
> ten years down the road, it is probably December.  In fact, I didn't go 
> to the Halifax meeting, and Randy is probably typing busily away to 
> provide the minutes and update the AIs to reflect what went on at the 
> meeting.  It is possible that the ARG could recommend an "official" 
> Ada.Containers heirarchy as early as this December.  If not, it may 
> happen at the WG9 meeting in conjunction with Ada Europe next spring.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Stephane Richard]

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

By the way, regardless of licensing, have you looked at the first draft?
what do you think?

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com


"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F88A577.5000803@noplace.com...
> A license is something to worry about down the road. That's something
> the vendors would have to say something about anyway. At this point I'm
> concerned about the idea expressed by Robert Eachus that a Conventional
> Ada Library be a branch (or several) under the standard library "Ada".
> That is, "Ada.Containers" and "Ada.Statistics" and so on. This would be
> a wonderful thing since it provides something really natural. Except
> that under "normal" rules you are not allowed to extend the package
> "Ada" and you may not have everything you need to do it if you could.
> That's why I'm objecting. Put it under a separate library or change the
> rules for the "Ada" tree so that this is possible to extend and required
> that you get source.
>
> At this point, I'm just stating a perceived requirement that is
> something near and dear to my heart - and possibly others: For a
> Conventional Ada Library, I want to get the source code and I want to be
> able to modify/extend it at will with no special limitations. (Much like
> any of the existing container libraries floating around out there.) If
> Robert Eachus or someone else who is smarter than me (And Robert really
> is *way* smarter than me! :-) can figure out some rule change for the
> package "Ada" that gets me this requirement, I'm happy as a pig in
> fewmets. :-) If that's not possible, then I think a Conventional Ada
> Library ought to exist under its own tree.
>
> I suppose that Robert's suggestion about renamings might be a good
> compromise. Make some "Official" root (Let's call it "CAL") and start
> adding branches (like "CAL.Containers" and "CAL.Statistics") They go
> through some editor/publisher to make sure they meet requirements and
> are released with everyone's compiler in full Ada source. If at a later
> date, the ARG decides that, e.g. CAL.Containers, ought to be part of the
> Ada standard, you just do a "renames" to Ada.Containers (keeping the
> original) and now it is a fully standard, entirely official part of Ada,
> complete with its own chapter in the ARM and a full validation suite.
> That seems like something that ought to work reasonably well. Do you
> think? (It might have problems if it still exists in CAL and the
> end-user can modify it. Leave that to the language lawyers to sort out.
> *That* problem is *waaaaaay* down the road. We can burn that bridge when
> we get to it.)
>
> MDC
>
>
> MDC
>
> Stephane Richard wrote:
> >
> > I think so, seems reasonable for me, but shouldn't it basically depend
on
> > the licence?  or would anything in there have the same licence?  or an
> > OpenSource Based licence so to speak so that it is available?
>
>
> -- 
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/
> My project is: http://www.jsf.mil/NSFrames.htm
>
> Send Replies To: m c o n d i c @ a c m . o r g
>
>      "All reformers, however strict their social conscience,
>       live in houses just as big as they can pay for."
>
>           --Logan Pearsall Smith
> ======================================================================
>

Re: Standard Library Interest?

[Marin David Condic]

I put a list of things I thought might make good topics for a library 
into the Ada Letters article I wrote. You might want to look at that.

At this stage, I'd say that the only important thing is to start 
capturing ideas about what kinds of things *might* be good fodder for 
the CAL. Your list got a little too specific and as I have said 
elsewhere, I don't think much of bindings and I like less the idea of 
grabbing existing things from the Internet and trying to cobble them 
into a "Library". (Think about "why": If you had a dozen different 
existing libraries, what are the odds that they are using a dozen 
different container libraries? If the CAL has a container library, you 
would like everything else in the CAL to use *that* library - especially 
as it relates to interfaces the end user has to program to.)

You're simply brainstorming here - that should be the goal. Think about 
packages or objects or subsystems you'd like to see. Don't worry about 
structure or trees or names - just get down concepts. (e.g. "I think it 
would be cool if in some way, some how, the CAL had a package or 
subsystem that let me parse XML files and build/maintain an XML DOM.") 
Don't worry about specifics and especially don't worry about 
incorporating specific existing libraries. Just get down "Requirements" 
and "Good Ideas" in a very general way.

The reason is this: To do this right, you're not going to rush off and 
start hacking out code. You're going to ask the vendors and some 
potential customers what it is that *THEY* want to see in a library. You 
want to get *THEIR* lists of stuff. You might then hand them your list 
and say, "Is there anything in there that blows your skirt up? If so, 
what would *YOUR* priorities be?" Let the *customer* tell you what they 
want built.

You've got limited resources and you want to build the things that the 
end users really want rather than waste your time putting things in that 
nobody wants to use. The best source for finding that out is to ask the 
vendors and their customers. Do some market research. It will pay in the 
end. After that, write some *requirements*. That will pay off too. By 
the time you've got some requirements, you'll be able to evaluate your 
ideas and existing libraries to see if they meet them. It will keep you 
from wasting lots of time in the end.

MDC


Stephane Richard wrote:
> By the way, regardless of licensing, have you looked at the first draft?
> what do you think?
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Stephane Richard]

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

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F88BD31.6050906@noplace.com...
> I put a list of things I thought might make good topics for a library
> into the Ada Letters article I wrote. You might want to look at that.
>
> At this stage, I'd say that the only important thing is to start
> capturing ideas about what kinds of things *might* be good fodder for
> the CAL. Your list got a little too specific and as I have said
> elsewhere, I don't think much of bindings and I like less the idea of
> grabbing existing things from the Internet and trying to cobble them
> into a "Library". (Think about "why": If you had a dozen different
> existing libraries, what are the odds that they are using a dozen
> different container libraries? If the CAL has a container library, you
> would like everything else in the CAL to use *that* library - especially
> as it relates to interfaces the end user has to program to.)
>
> You're simply brainstorming here - that should be the goal. Think about
> packages or objects or subsystems you'd like to see. Don't worry about
> structure or trees or names - just get down concepts. (e.g. "I think it
> would be cool if in some way, some how, the CAL had a package or
> subsystem that let me parse XML files and build/maintain an XML DOM.")
> Don't worry about specifics and especially don't worry about
> incorporating specific existing libraries. Just get down "Requirements"
> and "Good Ideas" in a very general way.
>
> The reason is this: To do this right, you're not going to rush off and
> start hacking out code. You're going to ask the vendors and some
> potential customers what it is that *THEY* want to see in a library. You
> want to get *THEIR* lists of stuff. You might then hand them your list
> and say, "Is there anything in there that blows your skirt up? If so,
> what would *YOUR* priorities be?" Let the *customer* tell you what they
> want built.
>
> You've got limited resources and you want to build the things that the
> end users really want rather than waste your time putting things in that
> nobody wants to use. The best source for finding that out is to ask the
> vendors and their customers. Do some market research. It will pay in the
> end. After that, write some *requirements*. That will pay off too. By
> the time you've got some requirements, you'll be able to evaluate your
> ideas and existing libraries to see if they meet them. It will keep you
> from wasting lots of time in the end.
>
> MDC
>
Indeed, In most ways, can't really disagree with that.  Although I create a
whole hierarchy, it's exactly what I did really.  Stated a list of things
I'd like to see in the library I just happened to "visualize' they're
position in the hierarchy.

For my list of things I want to see, look around, my list starts with what's
missing in ada that's present in other languages (whether compilable like
Delphi/Lylix, or scripting languages like Ruby and Python) as far as
containers, data structures, libraries, seems GtkAda has taken the lead for
a GUI library, how about a choice?, what else, there's so many.  abd that
just in categories that I have in the hierarchy.

More at a language level, well yes, any containers are always welcome for
one thing :-).  Stacks, queues, dequeues, lists, collections (sorted or
not), data dictionaries and the list goes on and on as far as data
structures go.

Also, perhaps a librarie that allows better control over a DOS or windows
Console screen would be more than welcome :-).  I have a binding to C's
conio standard library that does things like you can do in any other DOS
languages :-) Clear the screen, pick a color, position the cursor, turn the
cursor on and off, etc etc...I'd like that in a standard way as in
CAL.Screen_IO.<insert function name here> kinda fashion.  If that can't be
accomplished in a multiplatform fashion then perhaps based on each OS but
with the same function names so that the code can be compiled and execute on
every platform would be nice.

Graphic wise there's Ada3D, AdaOpenGL, AdaSDL which seem to cover alot of
grounds.  I'm thinking a library similar to Allegro (which offers extreme 3D
graphics rendering and animation) would be a big plus for Ada in the Gaming
industry for example.  With AdaSDL it should give you access to MIDI input /
output (no?) perhaps a thick binding to MIDI and Digital Audio (direct and
Streaming).  woudl be good again for the game industry but the music
industry as well.

I could detail them in a list, sure, but to me, the first two thing that
woudl give Ada a competitive edge are like I said, what's missing as
compared to other languages (for that I could draw up a list of key features
that are sought by developers when looking for a language for the job) I'll
start on that right away, and for vendors (yes) but also other companies to
start developing third party stuff for Ada like they would say for VB and
Delphi, it would be nice since VB adn Delphi are ActiveX languages that they
could add at least specification files for Ada for example :-).

GNATCOM should be pushed further for one idea :-).

Database Bindings are getting better and better Add SQL, SAMeDL, have you
looked at APQ? Not sure hwo many generics and definitions they are, but to
me APQ is somewhat on the right track to say the least :-)....

With databases comes (almost hand in hand) reporting technology too.

Someone mentionned CORBA and having all library elements come with an IDL,
not a bad idea either, but since we're talking about Ada, I'd first
integrate GLADE and develop for it.  As a second phase to that I'd see about
giving it CORBA support.

Add to my list any possible trick and tip to make Ada programming even more
faster.  Gode generators for repetitive tasks for example.  Perhaps a
Windows API based Form designer that generates Ada Code based on perhaps
Win32Ada or some other thin binding to the Windows API.

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[aleistad]

"Stephane Richard" <stephane.richard@verizon.net> wrote in message
news:OIaib.15742$0I6.10158@nwrdny03.gnilink.net...
[snip]
> With AdaSDL it should give you access to MIDI input /
> output (no?) perhaps a thick binding to MIDI and Digital Audio (direct and
> Streaming).  woudl be good again for the game industry but the music
> industry as well.

Unfortunately there's no MIDI support in SDL.

    Are
--

Re: Standard Library Interest?

[tmoran]

>Which is another problem plaguing
>adapower.com; the search engine isn't very smart.
  Try the one at www.adaic.com/site/wide-search.html  You can limit the
search to www.adapower.com or not.

Re: Standard Library Interest?

[Alexandre E. Kopilovitch]

Stephen Leake wrote:

> www.adapower.com tried that, with very limited success. Before that,
> www.adahome.com had a similar idea. How is your site going to be
> better?
>
> Part of the problem is that just because an Ada package is on a web
> site doesn't mean it's a _good_ Ada package. So people don't want to
> use it.
>
> ...
>
> I try to address this with my code by including unit tests. That
> doesn't seem to be enough.
>
> If you are suggesting some sort of review process, where people commit
> time to reviewing and approving stuff that goes into the library, then
> you do need to get agreement on what deserves reviewing. That's what
> the ARG is doing for proposed additions to the Ada standard. Those
> guys are getting paid (at least in part) to do that. If you want a
> reviewed library, you need to pay the reviewers, in some way; it's a
> lot of work.

Note that even a paid review may be not as good - for users. Reviewing for
ARG and reviewing for users are very different things.

Look at Amazon - how they provide information about books, movies etc. Usually
there are very short annotations; occasionally there are professonal reviews
(usually small); but what is most important, often there are *opinions* of
those users who already tasted the product. Perhaps this is a proper way to
deal with the issue.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Standard Library Interest?

[Martin Krischik]

Stephen Leake wrote:

>> 2. Do we include such things as AdaCL and such data structure based
>> libraries?
 
> Of course. They are useful. But allow all of them; Booch, Charles,
> SAL, Grace, etc.

Yes a convinience pack with all of them would be good. Get all with one
download.

Only problem is: how do we get all the developers to drop to drop there own
projects and move to one place (i.E. one cvs archive)?

Mind you, I am pretty happy to do so.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Standard Library Interest?

[Jacob Sparre Andersen]

Stephen Leake wrote:

> One way to pay reviewers is to get the companies they work for to
> allow them to spend company time reviewing code. I could do that for
> some packages that are related to my work; anyone else out there in
> the same situation?

Yes.

Jacob
-- 
"The universe isn't for the likes of me to understand. I only work
  here."

Re: Standard Library Interest?

[Marius Amado Alves]

On Tue, 2003-10-07 at 19:36, Stephane Richard wrote:
> > Even if it were not distributed with compilers, having everything in one
> > place as "The Ada Library" rather than bits and pieces here and there,
> > it would be a great improvement over what we have now.
>
> I like the sound of that.  We'd need a central place where all reusable
> libraries, maybe that could be a good addition to Ada World...

This thread is going in circles! Has it not been established already
that this kind of effort would be "just another Ada website"? First
there was adahome (?), then adapower, now adaworld. These sites were
born and died in succession. Is there something essentially new about
adaworld that will make it avert the same fate?

No. For the 30th time (?), Listen to Marin and myself, for what this
"something" might be: *commitment from Ada BIG players.*

Re: Standard Library Interest?

[Marin David Condic]

Well, there's nothing wrong with someone wanting an Ada website or an 
Ada repository of freebie code and maintaining this as a hobby. It 
certainly doesn't hurt anything. But that's all it will ever be - a hobby.

If the *objective* is to create some sort of Ada library that will gain 
some official standing and become the de facto "Standard" Ada Library, 
then it will be just one more piece of evidence against using that 
approach. There have been people collecting up random bits of freebie 
code and making them available in libraries all the way back to Ada83. 
None of them have been adopted as the Conventional Ada Library. None of 
them have gained any consensus as to being "The Place To Go" to find 
common components. Any new attempts may not be a totally wasted effort, 
but they are about as likely to achieve the objective as all the rest of 
the attempts were.

There's nothing wrong with freebie software or giving it away under the 
GPL and so on - depending on the objectives one has. Its just that when 
one is discussing a large project, the formula works most often only in 
certain circumstances: Someone builds a product that they need within 
their company and because it isn't part of the "Core Business", they 
decide to give it away hoping to gain benefits of sharing the product. 
Someone builds a big product as part of their PhD work and gives it away 
hoping it gains usefullness after the academic purpose was served. 
Someone builds a product in a business that they hope to market and they 
give it away in order to build a customer base for the related services.

In each of the above examples, the software is a *byproduct* of some 
other intention or effort and, generally speaking, the people building 
it were *paid* to build it. You just don't see very many successful 
efforts to construct really large software products being done entirely 
by volunteers with the goal of giving it all away for the benefit of 
others. People have jobs and families and other responsibilities that 
keep them from devoting a thousand man-hours per year to an 
all-volunteer effort at which they will at best receive the undying 
gratitude of those they have benefited. Large software products don't 
get built for the fame and glory of it, nor is it a particularly good 
way to impress girls. :-)

That's why I've been insisting that for a library of any significance to 
succeed, its going to need some kind of backing from the Powers That Be. 
Another all-volunteer "Lets Do It For The Good Of Ada" effort isn't 
going to go anywhere - at least not without *some* kind of support &/or 
acceptance from the vendors.

MDC

Marius Amado Alves wrote:
> 
> This thread is going in circles! Has it not been established already
> that this kind of effort would be "just another Ada website"? First
> there was adahome (?), then adapower, now adaworld. These sites were
> born and died in succession. Is there something essentially new about
> adaworld that will make it avert the same fate?
> 
> No. For the 30th time (?), Listen to Marin and myself, for what this
> "something" might be: *commitment from Ada BIG players.*
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "So if I understand 'The Matrix Reloaded' correctly, the Matrix is
     basically a Microsoft operating system - it runs for a while and
     then crashes and reboots. By design, no less. Neo is just a
     memory leak that's too hard to fix, so they left him in... The
     users don't complain because they're packed in slush and kept
     sedated"

         --  Marin D. Condic
======================================================================

Re: Standard Library Interest?

[Marius Amado Alves]

On Tue, 2003-10-28 at 12:52, Marin David Condic wrote:
> ... That's why I've been insisting that for a library of any significance to 
> succeed, its going to need some kind of backing from the Powers That Be. ...

This terminology is symptomatic of the lack of *one* Ada Consortium.
There is *a lot* of Ada organisations (ARG, AdaIC, Ada-Europe). I can
see a productive path in all these and the compiler providers (and
through them, user representatives) uniting and forming a global Ada
Consortium to deal with things like the CAL. I think Ada is currently
too much "ISO-oriented".

Re: Standard Library Interest?

[Marin David Condic]

I wouldn't expect that an orgainzation oriented towards maintaining a 
"Standard" would jump on some bandwagon quickly. Any organization doing 
that kind of work has to see some stability. But a little guidance as to 
what would be acceptable for a standard would seem to me to be simple 
prudence.

MDC


Marius Amado Alves wrote:
> 
> This terminology is symptomatic of the lack of *one* Ada Consortium.
> There is *a lot* of Ada organisations (ARG, AdaIC, Ada-Europe). I can
> see a productive path in all these and the compiler providers (and
> through them, user representatives) uniting and forming a global Ada
> Consortium to deal with things like the CAL. I think Ada is currently
> too much "ISO-oriented".
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "So if I understand 'The Matrix Reloaded' correctly, the Matrix is
     basically a Microsoft operating system - it runs for a while and
     then crashes and reboots. By design, no less. Neo is just a
     memory leak that's too hard to fix, so they left him in... The
     users don't complain because they're packed in slush and kept
     sedated"

         --  Marin D. Condic
======================================================================

Re: Standard Library Interest?

[Stephane Richard]

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


"Marius Amado Alves" <amado.alves@netcabo.pt> wrote in message
news:mailman.232.1067340398.25614.comp.lang.ada@ada-france.org...
>
> This thread is going in circles! Has it not been established already
> that this kind of effort would be "just another Ada website"? First
> there was adahome (?), then adapower, now adaworld. These sites were
> born and died in succession. Is there something essentially new about
> adaworld that will make it avert the same fate?
>
*** Two things, one from the library itself which will server two different
purposes.  One from the APIWG which could and would use this
library/architecture of ours as a central reference for naming conventions
of their API.  which gives it 3 purposes just on the library/reference side
of things.

> No. For the 30th time (?), Listen to Marin and myself, for what this
> "something" might be: *commitment from Ada BIG players.*

*** Well Ada World is far from dead, it was just born :-).  As for the "Ada
big players" Well in about an hour, I will be in contact with ACT with one
goal, to know what they think of this library, if they see themselves using
it provided it lives up to certain standards (which may or may not be the
same as what governs the standard of Ada itself.  If they are interested in
such a project, what insught they could and/or would give us towards
building a library that would answer more of the user's questions.  I'll let
you know more after I get the phone call.  But to me it shows interest that
they are willing to at least have a talk with me about it. :-)  no?  Curious
at least? ;-)

*** I'm well away of adahome, adapower's efforts towards a central library
and repositories, but in my eye, what we are trying to do here differ from
the past efforts in more than one way.

1. Although part of existing libraries and code out there may be
incorporated into the library, (unless that lart has changed recently) they
wont just be thrown intoa  fiolder somewhere in the hierarchy and considered
"integrated".  They willb e filtered, reformatted, documented to at least a
minimal degree that will render them easy to understand/use proficiently as
a whole or as part of a bigger library.

2. As well as being a library and to be considered as such.  It will also
server as a central database (or other) of what's out there, a central
reference of anything and everything that is out there not necessarily
limited by data structures and bindings, but depending on the purpose of,
maybe even applications.   that can be used not only be the ARG or compiler
vendors, but by aonyone else looking to create a library, binding or other
to assure there is no name conflict which will also assure that the library
has the foundations to grow instead of conflict with itself.

3. On the side of the APIWG there are still discussions and deisions to be
made, but a member has suggested that, and I quote (as per a reply I
received): "What we need is a repository that organizes the APIs in a
generally agreed nomenclature, much like Java does it. A WG
could come up with the nomenclature; you could run the repository".  Just
that side of could be useful too not just to the APIWG, but again to anyone
else wanting to add an API without name conflicts or others.

For these reasons which I'm sure ramifies into a multitude of inter related
other reasons :-).  I see a very different outcome to this effort than those
attempted in the past.  Things are moving along with Robert taking the
initiative to build what he's building right now.

Me, on my side as you can see, I'm looking at Robert's structures as you can
now all do since he posted in to the group, and I'm also trying to see who's
interested and what it could mean for the hence my discussions with ACT, the
APIWG, a few other members from other WGs

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest? (The Big Player ACT)

[Stephane Richard]

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

I just got off the phone with ACT, a very constructive conversation might I
add. There's many things to say so I'll try to be clear.  however I'm french
so if anything sounds foreign to you, let me know and i'll try to rephrase
:-).

Q: How open are they to the idea of the library as it seems to be direting
itself so far?

A:  ACT (which does not speak for other vendors) have a list of preferences
so to speak.

      1. Their first point of research is the WG's hence if we can get the
library (or I suppose parts of it) considered by any relative WG's it would
be a big plus for the life of the library as far as ACT goes and perhaps
it's relativaly safe to assume others as well (but I will confirm that as I
will contact other vendors as well)..  ACT mentionned and recognizes
Charle's library they know it's been submitted (partly I believe) to the ARG
and that really seems to give it a good plus.  Again this is ACT's point of
view, they do not speak for the others.  so I'll find out from the others
themselves :-)

      2. Should their needs not be met by the WG's suggestions they would
then be looking at good quality libraries (well organized, well documented,
good quality code with clear code documentation and coding style reflected
throughout the effort along with test programs or libraries to be able to
test everything out). So just throwing existing code somewhere in the
hierarchy of the library simply wont be looked at.  Although a joint effort
by many programmers, the code style and quality will need to be consistent
thoughout the library.  In the case of ACT they would need to be about to do
two things. 1. Offer a good quality library as you may know, because at that
point it would be a commercial quality library they would expect commercial
quality code and documentation (which at that point makes sense :-).  2.
They would also need to be able to offer full support of the library to
their customers (which of course can't be achieved with poorly
tested/documented code).   If they can't see a possibility of both these
conditions being met by a library effort, it wont be considered.  However if
it does meet these 2 conditions, it could very well be considered for
inclusion with their compilers.

NOTE: What this tells me is that we need to be aiming for the ARG and the
WG's, not the vendors as far as where we throw the library first.  get the
ARG and it's WG's in there and the vendors will "follow" in quotes :-). By
that I dont necessarily mean that they would be standarizing the library
however.  WG's govern what makes the Ada language, it's libraries well maybe
we can talk to Charles about how that works :-).  But ACT would advise in
going the WG way as much as possible because it is their first place to look
at.  And they are ready to do a little trial and error as in take something
built that they find interesting, incorporate it into their distributions
and see if it has success or not.  If yes, great, if not, well at least they
tried :-).  Which I believe answers Marin's financial concerns :-).



Q: Did you, as a compiler vendor conduct any surveys or research, amongst
your clients to see what they could possibly want in a library?

A: Not really, they don't tend to get all that many requests from their
clients in that respect either.  But they did get some.  as a standard
library such things as a library to manage directories and files for
examples...manage lists were asked for.  It seems that no demand has been
made for a very big list of things.  individual things (like the directory
management) is what they seem to get asked for However they don't rule out
the possibility that for example customers might not feel confortable making
this kind of request for any reason.  Also if they haven't so far, they
think they might soon, either existing customers, or new ones could start
making demands also.

To help me describe them the attempt (goal) of the library at least as a
first part, I compared it to the inclusion of the STL as part of todays C++
compilers.

Q: What would they, as compiler vendors, like to see in the library?

A: To them, the library would need to somewhat avoid domain specific
functionalities as a library.  The contents of the library would need to
remain I guess generic as much as possible.  However he seemed open to
business specific libraries built upon the generic standard libraries.  For
example Report generation libraries, statistics etc etc when I suggested
such libraries to him.

He added that perhaps, the reason why they weren't getting many request
could be because in some parts, the clients developed solutions for
themselves to fill in the current gaps that were not met by what was
included in Ada and the included libraries.

I guess here I can add, as per my experience, that if the customers start
demanding for certain things, whether generic or not, if enough of them ask
for it.  it could become corporately viable to see about fulfilling that
need as in (the infamous law of Offer versus Demand) :-).  Like a friend
once told me, he had a business tha tsold computers, and software....someone
came in and asked for 1,000,000 rolls of toilet paper.  There's money to be
made in that so he got him 1,000,000 rolls of toilet paper....Offer and
Demand at work here...:-).

Q: What about more elaborate libraries that are missing when comparing Ada
to such languages as C++, Delphi and the likes?

A:  Well of course anything that fills in a gap that is definitaly missing
from Ada (and respect the quality control conditions mentionned above, good
quality code and possibility of full support from them to their clients)
could be considered.  Again Offer and Demand would also be at play here.

Q: What about even more sophisticated things.  things that could entice
other domains to be interested by Ada and bring new customers and customer
types?

A: They are not against this kind of thing at all.  Who would be? ;-).   As
to what such libraries could contain? they couldn't say as they have not yet
done any research as to what could bring in different types of customers.
So Anything goes in this one.  I talked to him about for example.
Multimedia libraries Music (digital audio and MIDI), 3D engines and other
such things to go get other industries so to speak, he definitaly liked that
idea to see Ada possibly used in fields it's not being used right now.  Very
open to this idea. While maintaining the same 2 points of course, quality
documented code and easily supportable by them to their clients.

As I mentionned, these are the words and thoughts of ACT.  therefore I will
be contacting a couple other vendors to get their perspective on things and
see what their thoughts are on this too.


I think from this, it's looking good to get something worth it started.

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest? (The Big Player IRVINE)

[Stephane Richard]

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

Irvine Ada Compiler's reply to my questionnaire. (a different perspective to
say the least).

>
> 1. How open are they to the idea of the library as it seems to be
directing
> itself so far?

I am very open to the idea of a registry/catalog of existing components.
I think this will quickly lead to improvement of the components by their
own authors, as errors and non-portabilities are highlighted, and it will
quickly lead to improvements in the compilers as compiler errors are
highlighted.  This will correct one of the main current deficiencies, in
that existing components are unlikely to work on any compiler other than
the one they were developed with.

If the registry/catalog is actively maintained (more so than Adapower)
and publicized (more so than AdaIC or Sigada), it will attract
volunteers to develop new components, and volunteers to point out
the existence of missing components, and volunteer reviewers to
identify which compilers work (or don't) on which components.

Users would be much more willing to hunt for reusable components
in such a catalog, than in the existing unmaintained link farms.
This would be true, regardless of whether any of the components
were ever standardized by the ARG, or distributed by compiler
vendors, or somehow made to use a consistent coding style.

> 2. Did you, as a compiler vendor conduct any surveys or research, amongst
> your clients to see what they could possibly want in a library?

No.  Customers don't look to compiler vendors for such things.
They would rather the compiler was less expensive than that it
comes with extra goodies not required by the RM, for which they
can either write their own or find in a free library.

> 3. What would you, as compiler vendors, like to see in the
> library/registry/catalog?  As in something you might know you've never
seen
> before that is crucially missing from Ada as it stands right now.

I'd like to see all the existing Ada software cataloged in one place.
Volunteers will quickly fill in the gaps once the scope is clear.

> 4. What about more elaborate libraries that are missing when comparing Ada
> to such languages as C++, Delphi and the likes?  By this I mean to ask
what,
> according to you, is potentially missing from Ada that comes with the
other
> "popular" languages, what do you think would help Ada's popularity, so to
> speak?

I think the library would naturally evolve to be more elaborate, without
any central planning, or any involvement of the ARG or compiler vendors.

> 5. What about even more sophisticated things.  things that could entice
> other domains industries to be interested by Ada and bring new customers
and
> customer types?

Reliable, inexpensive compilers is what brings in new customers,
particularly if the capabilities of such compilers are plain to see
on a highly visible web site.


I am also awaiting replies from:

- Aonix who have agreed to participate in this survey, I'm just waiting for
the answers to this question).
- Rational Ada (who have received my questions and I'm waiting for a reply.
- Green Hills (same as Rational, awaiting the reply to the questions.  I'll
be posting them as I get them :-).

So keep on readin.  There's more to come.


-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest? (The Big Player IRVINE)

[Marin David Condic]

O.K. So with respect to distributing a Conventional Ada Library along 
with compilers, this is what I'm hearing:

ACT: "Well, *maybe* if it came from a SIGAda group and it was really 
good quality and lots of users already wanted it, we *might* go out and 
distribute it...."

Irvine: "No."

Perhaps some other vendors may come out with a different answer, but it 
isn't looking like they want to start jumping on the bandwagon, does it? 
It wouldn't much matter *how* it got built (all-volunteer or some mix of 
funding, from some TBD sources, etc.) The interest level from the 
vendors is asymptotically approaching zero as far as I can tell.

So maybe a library is a bad idea. (I don't think so) If so, then I hope 
the vendors or ARG can come up with some *other* idea that is going to 
generate some new interest in Ada. Why is it I can hear Danny DiVito in 
the background reciting his speech from "Other People's Money": "I'm 
sure at one time there must have been hundreds of companies out there 
making buggy whips...." (Substitute "Ada Compilers" for "Buggy Whips" ;-)

MDC


Stephane Richard wrote:
> Irvine Ada Compiler's reply to my questionnaire. (a different perspective to
> say the least).
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "So if I understand 'The Matrix Reloaded' correctly, the Matrix is
     basically a Microsoft operating system - it runs for a while and
     then crashes and reboots. By design, no less. Neo is just a
     memory leak that's too hard to fix, so they left him in... The
     users don't complain because they're packed in slush and kept
     sedated"

         --  Marin D. Condic
======================================================================

Re: Standard Library Interest?

[Robert I. Eachus]

Marin David Condic wrote:

> Perhaps some other vendors may come out with a different answer, but it 
> isn't looking like they want to start jumping on the bandwagon, does it? 
> It wouldn't much matter *how* it got built (all-volunteer or some mix of 
> funding, from some TBD sources, etc.) The interest level from the 
> vendors is asymptotically approaching zero as far as I can tell.

> So maybe a library is a bad idea. (I don't think so) If so, then I hope 
> the vendors or ARG can come up with some *other* idea that is going to 
> generate some new interest in Ada. Why is it I can hear Danny DiVito in 
> the background reciting his speech from "Other People's Money": "I'm 
> sure at one time there must have been hundreds of companies out there 
> making buggy whips...." (Substitute "Ada Compilers" for "Buggy Whips" ;-)

I think that in one sense asking the Ada compiler vendors is necessary. 
  But in another it is irrelevant.  If we know what users want and 
provide it, the compiler vendors will be asked by THEIR customers to 
provide and support it.  If the end users don't want it, won't use it, 
or can't use it, then this whole effort is a waste of time.

Of course, to some extent compiler vendors are Ada programmers/users, 
and they are in touch with their customers and their needs.

Some years ago, I worked out the right solution--form an Ada software 
engineering guild, or for that matter a software engineer's guild, and 
one of the functions of the guild would be to provide and support a 
library that could be used by its members.  (Including corporate 
members.)  If you could get the system to insist on only using guild 
licensed programmers in the correct disciplines, and guild software 
engineers on certain types of projects this would finally give software 
engineering a realistic model to work with.

Anyone who really is a software engineer not a glorified programmer, 
knows that the only way software engineering is taught is not in school 
but by mentoring.  And most corporations don't have a mechanism for 
recognizing mentoring effort, and people who have in effect graduated 
from apprentice to journeyman, or from journeyman to master.

But all that is way beyond what we can accomplish here.  But I do feel 
that doing the registry right will give us both a better idea of what 
exists and a way to track what is used or wanted.

Finally, note that once we do get a group well organized to create a 
common Ada library that will be used, we can survey both c.l.a and 
SIGAda to find out what people think they want--and what they currently 
use or have used, etc.

Re: Standard Library Interest?

[Stephane Richard]

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


"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:PomdnQFWG_DaNziiRVn-hQ@comcast.com...
>
>
> Marin David Condic wrote:
>
> > Perhaps some other vendors may come out with a different answer, but it
> > isn't looking like they want to start jumping on the bandwagon, does it?
> > It wouldn't much matter *how* it got built (all-volunteer or some mix of
> > funding, from some TBD sources, etc.) The interest level from the
> > vendors is asymptotically approaching zero as far as I can tell.
>
> > So maybe a library is a bad idea. (I don't think so) If so, then I hope
> > the vendors or ARG can come up with some *other* idea that is going to
> > generate some new interest in Ada. Why is it I can hear Danny DiVito in
> > the background reciting his speech from "Other People's Money": "I'm
> > sure at one time there must have been hundreds of companies out there
> > making buggy whips...." (Substitute "Ada Compilers" for "Buggy Whips"
;-)
>
> I think that in one sense asking the Ada compiler vendors is necessary.
>   But in another it is irrelevant.  If we know what users want and
> provide it, the compiler vendors will be asked by THEIR customers to
> provide and support it.  If the end users don't want it, won't use it,
> or can't use it, then this whole effort is a waste of time.
>
> Of course, to some extent compiler vendors are Ada programmers/users,
> and they are in touch with their customers and their needs.
>
> Some years ago, I worked out the right solution--form an Ada software
> engineering guild, or for that matter a software engineer's guild, and
> one of the functions of the guild would be to provide and support a
> library that could be used by its members.  (Including corporate
> members.)  If you could get the system to insist on only using guild
> licensed programmers in the correct disciplines, and guild software
> engineers on certain types of projects this would finally give software
> engineering a realistic model to work with.
>
> Anyone who really is a software engineer not a glorified programmer,
> knows that the only way software engineering is taught is not in school
> but by mentoring.  And most corporations don't have a mechanism for
> recognizing mentoring effort, and people who have in effect graduated
> from apprentice to journeyman, or from journeyman to master.
>
> But all that is way beyond what we can accomplish here.  But I do feel
> that doing the registry right will give us both a better idea of what
> exists and a way to track what is used or wanted.
>
> Finally, note that once we do get a group well organized to create a
> common Ada library that will be used, we can survey both c.l.a and
> SIGAda to find out what people think they want--and what they currently
> use or have used, etc.
>


Seems I've failed at my goal here :-).  I wanted to cover the vendors side
not only as far as "investments" but also as far as possibility to incude
our effort in they distros, and attempt to get insight on what they want and
what they think their clients want.  I have to agree with IRVINE that
customers aren't really looking at compiler vendors to bring them our
project, however I agree with you that should this first part, the registry,
be done and done right (which I must say is well under way from what I'm
seing in your XML and your frame of mind :-).  it will give is that
information that us and everyone else (vendors alike, SIG Ada and the others
too) a good representation of today's Ada reality as far as what's there,
where is it, and most preciously and ultimately what's left to be done. so
I'm definitally all for this initial phase.

But I've failed at my side so far because the reason I did this survey was
mainly

1. to know possible answers to the every repeating questions I've asked the
vendors maybe try to at least get a hint as to what we should do next....so
far, to me, the registry is the only "logical" next step for both not
reproducing the code, and knowing exactly what to attack next code wise.

2. I've also contacted compiler vendors for the purpose of settling issues
as in those of us who had beliefs of vendors participating financially or
with a good time effort or any other way, see if it could happen and when in
the process of our project it could happen..from what I'm seeing so far,
only at the end or at least at the end of the registry phase.  But I wanted
those that were aslking questions to get their answers :-).  Not raise new
doubts...I got 3 vendors on the wait for their replies we'll have to see
what their answers are (should there even be an answer.  Aoniz agreed to
answer the survey but I've not yet gotten anything.  The oither two well
just waiting...they've been contacted :-).

As er the survey, once the registry is done, like Robert suggests, we'll be
better equited to:

1. Evaluate the work left to be done to amass to a presentable solution.
2. See exactly what in there can be "reasonably" done as per a voluntary
effort.
3. What (if any) can't possible be done by a voluntary effort.
4. See what parts of the registry need to be filled up that could
potentially attract different types of customers and new customers of the
same existing types too
5. Compare what's out there with what's out there for other languages and
maybe attack these areas (which? not sure yet but I'm still thinking what
the other languages offer that Ada does not in terms of libraries.
6. See in the existing code, if there's any dependencies that shoudl be
replaced with non dependant code (should there be a possible non dependant
alternative).

A couple more pieces of information will arise from this registry too that
I'm not thinking of right now but did recently ;-)....

With these, the rest will fall into place as far as work to be done, quality
of documentation required (perhaps by consulting WG's that do documentation
of the standard, perhaps they have tips and tricks to greatly minimize our
effort at good documentation.

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[Marin David Condic]

Its not a failure to discover that the vendors have little to no 
interest in distributing a library. Not for us, at least. (I think its a 
failure for them - they'd better do *something* to make their products 
more attractive & interesting to the general computing world or they'd 
better start developing C++ or Java front-ends for their next generation 
products. Ooops! Some of them already *have*! ;-)

What it means is that we've saved all sorts of effort charging off 
building a library only to discover that the vendors had little to no 
interest in distributing it. The next logical question would be "Is 
there enough interest in the general Ada community in a library built on 
something out there or all-new that provided something bigger than your 
basic container library?" There's no point in persuing it if nobody 
wants anything more than containers and they're happy to use whatever 
flavor of freebie download they like best.

If the vendors don't want a CAL and the ARG doesn't want a CAL then 
there isn't much likelihood that a CAL is going to come about. The best 
you could hope for would be to find a way of funding the development of 
some library and market it as aggressively as you could with the hope 
that *most* users eventually got with it. Maybe ten years from now, the 
vendors or the ARG would get on board with it. If Ada has any users out 
there in another ten years. :-(

MDC


Stephane Richard wrote:
> 
> Seems I've failed at my goal here :-).  I wanted to cover the vendors side
> not only as far as "investments" but also as far as possibility to incude
> our effort in they distros, and attempt to get insight on what they want and
> what they think their clients want.  I have to agree with IRVINE that

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "So if I understand 'The Matrix Reloaded' correctly, the Matrix is
     basically a Microsoft operating system - it runs for a while and
     then crashes and reboots. By design, no less. Neo is just a
     memory leak that's too hard to fix, so they left him in... The
     users don't complain because they're packed in slush and kept
     sedated"

         --  Marin D. Condic
======================================================================

Re: Standard Library Interest?

[Alexandre E. Kopilovitch]

Robert I. Eachus

> Some years ago, I worked out the right solution--form an Ada software 
> engineering guild, or for that matter a software engineer's guild, and 
> one of the functions of the guild would be to provide and support a 
> library that could be used by its members.  (Including corporate 
> members.)  If you could get the system to insist on only using guild 
> licensed programmers in the correct disciplines, and guild software 
> engineers on certain types of projects this would finally give software 
> engineering a realistic model to work with.

I wonder, why those past model and past term? It is simply inadequate to many
current realities (first of all, numbers matter - you can't simply scale the
guild model). Why not propose a suitable curriculum instead? Include enough
engineering disciplines you think important, and you certainly will deter
those who aren't oriented towards engineering. In fact, the main difference
between a curriculum and guild is that a curriculum is explicit and public,
while guild principles, customs and directions are implicit and concealed.

> Anyone who really is a software engineer not a glorified programmer, 
> knows that the only way software engineering is taught is not in school 
> but by mentoring.

I wonder, why do you think that mentoring is more important in software
engineering than in all classical sciences? Or in professions like doctors and
lawyers? There is enough complexity, and safety requirements are often high
enough. And no one of them is organized in guilds now. Even those "social"
sciences that until recently traditionally have competing "schools" (which
somehow resemble guilds) are gradually leaving that way.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Standard Library Interest?

[Robert I. Eachus]

Alexandre E. Kopilovitch wrote:

> I wonder, why do you think that mentoring is more important in software
> engineering than in all classical sciences? Or in professions like doctors and
> lawyers? There is enough complexity, and safety requirements are often high
> enough. And no one of them is organized in guilds now. Even those "social"
> sciences that until recently traditionally have competing "schools" (which
> somehow resemble guilds) are gradually leaving that way.

I've seen and participated in attempts to teach software engineering as 
an academic discipline.  It doesn't work as such.  In practice there are 
several universities in this area that have good work-study programs, 
and when a lucky student does get a good mentor, it works well.  But as 
far as degrees and curricula are concerned they have little to do with a 
student's success or failure in the co-op part of the program.

I've walked both sides of the fence, both teaching at the graduate 
level, and mentoring co-op students in undergrad or graduate programs. 
(I guess the third side is that my daughter is doing just that at the 
University of London.)

I know how to teach Computer Science in a classroom setting.  I have no 
idea how to teach Software Engineering other than to put someone neck 
deep in the middle, then help them to see how to deal with the "Fog of 
War" or whatever.  Most bright students with a decent mentor/adivsor 
"get it," and from then on learn software engineering is just learning 
new areas of application.

But everyone here has had to deal with the students who come out of a 
CompSci program without that experience.  They have been dealing with 
toy problems, and programs, for so long that you will never break them 
of their anti-software engineering habits.

I could probably sit here and reel off a list of the differences between 
a software engineer and a hot-shot programmer, but why bother?  Show the 
list to one of the hot-shot programmers, and they will tell you why 
their way is right, better, or okay since they are "good enough" to get 
away with it.  The software engineer will say, uh huh, uh huh, uh huh, 
oops! you forgot one. Nope, here it is...

In the early days of Ada we used to call that list the "-ilities": 
Readability, Maintainability, Relability, Availability, Portability, 
Reuseability, Verifyability, etc.  The software engineer knows that 
designing from the beginning with the "-ilities" makes difficult jobs 
easy, and impossible jobs possible.  The hot-shot programmer will think 
about adding those things later, "If he has to."

Sorry, you touched a hot button.  As I say, I know how to create good 
software engineers. I don't know how to do it in general in a university 
environment.  (You can mentor a research assistant, but that is really a 
variation on an industrial setting.) I have seen several well-funded and 
supported attempts to do it fail.  (For example, the Wang Institute.)

--
 

                                        Robert I. Eachus

100% Ada, no bugs--the only way to create software.

Re: Standard Library Interest?

[Jeff C,]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:EOqdnSsRiKMNaDiiRVn-iQ@comcast.com...
> Alexandre E. Kopilovitch wrote:
> I've seen and participated in attempts to teach software engineering as
> an academic discipline.  It doesn't work as such.  In practice there are
> several universities in this area that have good work-study programs,
> and when a lucky student does get a good mentor, it works well.  But as
> far as degrees and curricula are concerned they have little to do with a
> student's success or failure in the co-op part of the program.
>

It has been 11+ years since I was in college but I would say that for the
most
part the program I was in really did try to work toward the goal of creating
software engineers and not just "programmers" or "CS Majors".

In general, a program that compiled and executed correctly was only enough
to get
you something like a C (the grade, not the language :). The rest was based
on the structure
of the program. The professor would mark up the code (somewhat like a peer
inspection) and also
gave you and audio tape from the session where he would comment about all
aspects of the code as
he read it. It was VERY useful. Between the in-class examples and this
accelerated trial by fire (which
at the time burned out about 1/2 to 1/3 of the majors). In the higher level
classes, students got to write their
own requirements documents for the large complicated projects and were then
evaluated at how well they
met those requirements.

So, I think it can be done......Granted there will still be aspects that can
not be (or at least were not) taught well but
I think it is possible to do a decent job at this.

Oh yeah.....Until the professor that seemed to be pushing all of this stuff
left the school, Ada was the pimary language.
I imagine by now things have degenerated into the standard CS assignments..

"A bank wants you to build a database using a B-tree.."

or the 21st century version:

"A major coorporation wants you to write custom security patches for their
ASP based webserver" - Cha- ching..Perpetual job security.

Re: Standard Library Interest?

[Robert I. Eachus]

Jeff C, wrote:

> The professor would mark up the code (somewhat like a peer
> inspection) and also
> gave you and audio tape from the session where he would comment about all
> aspects of the code as
> he read it. It was VERY useful. Between the in-class examples and this
> accelerated trial by fire (which
> at the time burned out about 1/2 to 1/3 of the majors). 
> So, I think it can be done......Granted there will still be aspects that can
> not be (or at least were not) taught well but
> I think it is possible to do a decent job at this.

First, sounds like at least one professor was trying to do mentoring for 
fairly large classes.  But second, your 1/3 to 1/2 of the majors "burned 
out" is exactly the inefficiency I am complaining about.  A process that 
  wastes two or three years of both student and professor time is no 
paragon of efficiency.  When I have done mentoring, it took about a day 
to figure out whether a particular mentoree was suited for the task. 
(In a couple of cases incidently, I was able to pass the person off to 
someone who was an expert in another domain that more suited the co-op's 
personality.  In one case, it was to a DBMS project, in the other from a 
compiler front-end/language theory/parsing project to a 
code-generation/pattern matching project.

> Oh yeah.....Until the professor that seemed to be pushing all of this stuff
> left the school, Ada was the pimary language.
> I imagine by now things have degenerated into the standard CS assignments..
> 
> "A bank wants you to build a database using a B-tree.."
> 
> or the 21st century version:
> 
> "A major coorporation wants you to write custom security patches for their
> ASP based webserver" - Cha- ching..Perpetual job security.

The fate, as far as I can tell of all decent university software 
programs.  Don't get me wrong, the collegiate environment is fine for 
turning out programmers.  But "fresh outs" with no software engineering 
mentoring are potential apprentices, not journeymen software engineers. 
  The qualification is because I have had excellent experience both with 
hiring students who when through a co-op program, and with mentoring 
co-op students.  In fact, I would often choose a WPI co-op student over 
a current employee for a job that required software engineering, not 
programming.  (More of my involvement required at first, but usually a 
much better result.)

-- 

                                           Robert I. Eachus

100% Ada, no bugs--the only way to create software.

Re: Standard Library Interest?

[Alexandre E. Kopilovitch]

Robert I. Eachus wrote:

> I've seen and participated in attempts to teach software engineering as 
> an academic discipline.  It doesn't work as such.

I know it perfectly well that it doesn't work, and that it can't work, and why
it can't work. But when I mentioned curriculum I didn't mean passing software
engineering education to formal academic sphere, leaving them without mentoring
about practical issues and practical circumstances.

Proper curriculum is needed for most mentors, not for students. For students
it is useful as a deterrent only - for those who is not oriented towards
engineering. But for many potential mentors such a curriculum is needed as
commonly agreed general guide, framework (susbstitute better word, if you
know it). Note, that you need many mentors, not just several dozens, and that
many good engineers and potentially good mentors do not possess so universal
experience that you probably have. They have good experience in some areas,
and some general outlook on others, but they can't cover all needed areas with
their own experience, and therefore they can't judge what should be taught
anyway, and what may be skipped without too significant loss. You said: the
guild will guide them; and I protested: not a guild, but an explicit and public
curriculum. This is all the difference between our approaches to the problem.

> I could probably sit here and reel off a list of the differences between 
> a software engineer and a hot-shot programmer, but why bother?  Show the 
> list to one of the hot-shot programmers, and they will tell you why 
> their way is right, better, or okay since they are "good enough" to get 
> away with it.  The software engineer will say, uh huh, uh huh, uh huh, 
> oops! you forgot one. Nope, here it is...
>
> ....
>
> Sorry, you touched a hot button.

Well, I understand this perfectly, but you have touched my hot button, which
sits quite near to yours, just on other side of the panel -;) . I believe that
for all differences between programmers and software engineers they have some
very important things in common, they should have some common ground. It is
certainly true that responsibilities of software engineer generally are much
better defined than those of programmers, but this does not mean that programmers
are and should be generally less responsible for their production. And the
concentrated and well-defined responsibilities of software engineers is one
of main sources for understanding the notion of programmer's responsibility.
Also, some acquaintance with problems that naturally belong to software engineering rather
than to programming, significantly contribute to programmer's grasp of their
problems.

So, I see attempts to separate software engineers from programmers by some
high and hard barriers as disastrous for both sides - if these attemps succeed
then programmers will become less responsible and less competemt, while software
engineers will, perhaps, become less creative, less competent and more conservative,
which is not so good in such rapidly changing area, which have so little own
history.

Finally, note, that Ada language itself is a fine example, representing a part
of that common ground for software engineers and programmers. I don't think
that such a thing is possible with hard barriers between those trades.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Standard Library Interest?

[Mark A. Biggar]

Alexandre E. Kopilovitch wrote:

> I wonder, why do you think that mentoring is more important in software
> engineering than in all classical sciences? Or in professions like doctors and
> lawyers? There is enough complexity, and safety requirements are often high
> enough. And no one of them is organized in guilds now. Even those "social"
> sciences that until recently traditionally have competing "schools" (which
> somehow resemble guilds) are gradually leaving that way.

But the other professions DO use a guild system.  Just because they
aren't called apprentices and journeymen any more (they're called
med-students and residents or law-students and associates instead)
doesn't mean those professions don't work that way.  Don't let the fact 
they call themselves the AMA and the BAR and don't use the word guild
anymore fool you, and notice that they control entry into membership
just as fanatically as any medieval guild ever did.

Yes, most good software engineers learned most of what they know from a
few good mentors (and I bless those that mentored me) and it would be
nice if it were a little more formal.

-- 
mark@biggar.org
mark.a.biggar@comcast.net

Re: Standard Library Interest?

[Alexandre E. Kopilovitch]

Mark A. Biggar wrote:

> > I wonder, why do you think that mentoring is more important in software
> > engineering than in all classical sciences? Or in professions like doctors and
> > lawyers? There is enough complexity, and safety requirements are often high
> > enough. And no one of them is organized in guilds now. Even those "social"
> > sciences that until recently traditionally have competing "schools" (which
> > somehow resemble guilds) are gradually leaving that way.
>
> But the other professions DO use a guild system.  Just because they
> aren't called apprentices and journeymen any more (they're called
> med-students and residents or law-students and associates instead)
> doesn't mean those professions don't work that way.  Don't let the fact 
> they call themselves the AMA and the BAR and don't use the word guild
> anymore fool you, and notice that they control entry into membership
> just as fanatically as any medieval guild ever did.

Well, they have various associations, which sometimes may be seen as direct
heirs of old guilds in some respects, but nevertheless they aren't guilds,
they are just professional associations. There are big differences between 
an old-fashioned guild and today's professional association: the former is
compact, homogeneous and execute tight control over activities of its ordinary
members, while the latter is often highly distributed, often heterogeneous,
and as a rule, controls own members loosely only.

Actually, an appropriate kind of organization depends not on general qualification
and skills, but on *role*. A guild of advocates may be quite appropriate,
while a guild of judges is very doubtful, and a guild of prosecutors is absurd.
And general qualification for all them is the same - they all are lawyers.

Likewise, for software engineers I can accept a guild of testers (I mean real
testers for completed complex projects, and not ordinary QA staff), but at the
same time I believe that a guild of software engineers - system designers -
is entirely inappropriate. 

> Yes, most good software engineers learned most of what they know from a
> few good mentors (and I bless those that mentored me) and it would be
> nice if it were a little more formal.

I think I pointed at the same direction when I said about curriculum.
And a guild of software engineers seems to be a move in opposite direction.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Standard Library Interest?

[Robert I. Eachus]

Alexandre E. Kopilovitch wrote:

>>Yes, most good software engineers learned most of what they know from a
>>few good mentors (and I bless those that mentored me) and it would be
>>nice if it were a little more formal.
> 
> 
> I think I pointed at the same direction when I said about curriculum.
> And a guild of software engineers seems to be a move in opposite direction.

I obviously disagree.  If you have a guild, and in this country, the AMA 
for physicians is exactly that, it has a great deal of power.  But the 
philosophy and organization of a guild determines what that power is, 
and how it is used.  IMHO, a guild of software engineers would be like 
trying to herd cats if you tried to say, mandate a particular 
programming language.

But if the guild used its power to insist that safety critical software 
be certified as trustworthy by a guild journeyman or master, I think 
that no real software engineer would have a problem with that. Right now 
  professional engineers sign off on blueprints for large construction 
projects the same way.

We can argue fine lines about whether a guild is a better professional 
approach for software engineering or not.  I think it is.  I think that 
for programmers, the engineering model of educational programs and a 
professional society might be better when programming becomes a 
profession.  But for programmers, that is nowhere near to happening.  As 
for software engineering, in one sense a professional organization is 
overdue.  But efforts to base such a professional organization on 
academic credentials have failed when tried.  I think a guild would work.

More important, I would think that journeymen would have a "journey 
work"  that was free software--in other words, open to inspection by 
anyone--and a master work would be done the same way.  That way, I doubt 
that there would be any questions about whether or not someone really 
was a journeyman or master.  If you have doubts, look at the work posted 
on his website.  (Yes, someone could do work that was masterwork 
quality, but was classified or company proprietary.  Not a problem.  If 
they want to be a recognized journeyman or master, they would have to 
post other work to be judged.)

-- 

                                           Robert I. Eachus

100% Ada, no bugs--the only way to create software.

Re: Standard Library Interest?

[Jeffrey Carter]

Robert I. Eachus wrote:

> But if the guild used its power to insist that safety critical software 
> be certified as trustworthy by a guild journeyman or master, I think 
> that no real software engineer would have a problem with that. Right now 
>  professional engineers sign off on blueprints for large construction 
> projects the same way.

Signing off on blueprints is equivalent to certifying the design, not 
the software. Presumably there are one or more later steps in a large 
construction project to assure that the blueprints are being implemented 
properly, and a safety critical SW project would similarly assure that a 
certified design is implemented properly.

-- 
Jeff Carter
"C's solution to this [variable-sized arrays] has real problems,
and people who are complaining about safety definitely have a point."
Dennis Ritchie
25

Re: Standard Library Interest?

[Alexandre E. Kopilovitch]

Robert I. Eachus wrote:

> If you have a guild, and in this country, the AMA 
> for physicians is exactly that, it has a great deal of power.

I'm not sure that it is true for any guild. Physicians always and everywhere
in history enjoyed a significant power (for obvious reasons), so for them a
guild is just a particular way to organize that power, not to acquire it.
The same is true for lawyers. And this is not true for software engineers so
far,

>  But the 
> philosophy and organization of a guild determines what that power is, 
> and how it is used.

Certainly. But where is that philosophy? - is it formulated and presented in
books, or it is just in minds, perhaps being incomplete and/or inconsistent,
and with unknown number of significant disagreements between different authorities?
Is *software* engineering mature enough to be a subject of consistent philosophy
- not for an indvidual or a small group, but for a guild consisting of many
thousands?

Both physicians and lawyers have history of thousands years - they had enough
time, they went through enormous amount of errors, they had great philosophers
among them. You may say that engineers have all that also - well, perhaps
(although I can't remember philosophers of comparable rank among engineers),
but not *software* engineers. Do you think that this attribute - "software"
isn't too significant?

One little example of a question of that philosophical kind: what is the
general purpose of software engineering - to build (parts of) useful material
things in a form of software, or it is to build software in engineering way,
giving it all good characteristics of a properly engineered thing?
(I suspect that at least one man, quite famous in Ada world, can't be considered
as software engineer if we use the first definition, but he certainly is a
software engineer if we accept the second one).

> We can argue fine lines about whether a guild is a better professional 
> approach for software engineering or not.  I think it is.

Being an outsider for software engineering world, I can't see all aspects
and can't weight them. I see probable harm, but perhaps I underestimate
possible advantages (or can't see them, being an outsider). Possibly you are
right... I just wonder, why the corresponding division of IEEE failed to move
in this direction, if it is so attractive.

>  I think that 
> for programmers, the engineering model of educational programs and a 
> professional society might be better when programming becomes a 
> profession.  But for programmers, that is nowhere near to happening.

Thanks God. Programming surely *is* a profession - there are (and always been)
many professions, where most of workforce is temporary or "guest", that is,
people aren't locked with this profession for life, And programmers do not
need more influence of engineering approach that they already have... current
level of that influence is just fine. More will be worse, and less will be worse.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Standard Library Interest?

[Robert Spooner]

Alexandre E. Kopilovitch wrote:
> ...
> I wonder, why do you think that mentoring is more important in software
> engineering than in all classical sciences? Or in professions like doctors and
> lawyers?
> 

Actually, I think that if you look at how things are handled in this 
country in the sciences and medicine, you will find a lot of mentoring. 
Physicians serve internships and residencies after graduation from 
medical school. Graduate students in the sciences are typically mentored 
by their advisors - sometimes well, sometimes not. They often have to 
take postdoctoral fellowships as well before obtaining a permanent 
position. In the life sciences in particular, it can take years.

Bob

-- 
                             Robert L. Spooner
                      Registered Professional Engineer
                        Associate Research Engineer
                   Intelligent Control Systems Department

          Applied Research Laboratory        Phone: (814) 863-4120
          The Pennsylvania State University  FAX:   (814) 863-7841
          P. O. Box 30
          State College, PA 16804-0030       rls19@psu.edu

Re: Standard Library Interest?

[Dmitry A. Kazakov]

On Mon, 03 Nov 2003 10:14:08 -0500, Robert Spooner <rls19@psu.edu>
wrote:

>Alexandre E. Kopilovitch wrote:
>> ...
>> I wonder, why do you think that mentoring is more important in software
>> engineering than in all classical sciences? Or in professions like doctors and
>> lawyers?
>
>Actually, I think that if you look at how things are handled in this 
>country in the sciences and medicine, you will find a lot of mentoring. 
>Physicians serve internships and residencies after graduation from 
>medical school. Graduate students in the sciences are typically mentored 
>by their advisors - sometimes well, sometimes not. They often have to 
>take postdoctoral fellowships as well before obtaining a permanent 
>position. In the life sciences in particular, it can take years.

In fact software engineering has a large amount of poorly described,
unsystematic, informal knowledge. Often it is even not a knowledge one
can learn, but rather behavioural patterns, or even reflexes, which
one rather trains, first. Then one builds a thick layer of all sorts
of reflections upon that, to justify it. (mostly wrong reflections, of
course (:-)). And so, finally one becomes a true Software Engineer.
This makes software engineering so close to arts, where mentoring is
indispensable.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Standard Library Interest?

[Alexandre E. Kopilovitch]

Robert Spooner wrote:

> > I wonder, why do you think that mentoring is more important in software
> > engineering than in all classical sciences? Or in professions like doctors and
> > lawyers?
> > 
>
> Actually, I think that if you look at how things are handled in this 
> country in the sciences and medicine, you will find a lot of mentoring. 
> Physicians serve internships and residencies after graduation from 
> medical school. Graduate students in the sciences are typically mentored 
> by their advisors - sometimes well, sometimes not. They often have to 
> take postdoctoral fellowships as well before obtaining a permanent 
> position. In the life sciences in particular, it can take years.

But this is exactly what I intended to say - that software engineering needs
mentoring just like other professions that routinely deal with high degree of
complexity. I do not dispute the need of mentoring in all such professions,
including software engineering. I just dislike a guild as a method for providing
and enforcing the mentoring.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Standard Library Interest?

[Marin David Condic]

One way to do it is to organize it in some way as a business venture. As 
I've said, I think the level of work needed to get something beyond 
trivial and of high quality is going to take more effort that will end 
up being done by a few hobbyists on a part time level. It has to end up 
funded in some way so that some small number of staff can devote the 
time needed to it to get it done *right*. Ultimately, its got to 
generate revenue in some form even if it was being distributed through 
the vendors because they aren't a charity either.

Persuant to any business venture, it is absolutely critical to do some 
market analysis to find out if there is sufficient interest in the 
proposed product to make it worth the risk of doing the development, 
etc. So inquiring around with users as to what they would want *AND* 
would they be willing to pay to get it, would be a good idea.

MDC


Robert I. Eachus wrote:
> 
> 
> I think that in one sense asking the Ada compiler vendors is necessary. 
>  But in another it is irrelevant.  If we know what users want and 
> provide it, the compiler vendors will be asked by THEIR customers to 
> provide and support it.  If the end users don't want it, won't use it, 
> or can't use it, then this whole effort is a waste of time.
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "So if I understand 'The Matrix Reloaded' correctly, the Matrix is
     basically a Microsoft operating system - it runs for a while and
     then crashes and reboots. By design, no less. Neo is just a
     memory leak that's too hard to fix, so they left him in... The
     users don't complain because they're packed in slush and kept
     sedated"

         --  Marin D. Condic
======================================================================

Re: Standard Library Interest?

[Marius Amado Alves]

On Tue, 2003-10-28 at 11:25, Marius Amado Alves wrote:
> On Tue, 2003-10-07 at 19:36, Stephane Richard wrote:
> This thread is going in circles! ...

Ooooooooooooooooooooooops... Sorry sorry sorry I though it was a recent
message. I really feel stupid letting my stupid mailer making look
stupid.

Re: Standard Library Interest?

[Marin David Condic]

I think you still need some kind of "Official Blessing" or its just 
another website with just another collection of Ada stuff on it.

MDC


Larry Hazel wrote:

>>
> Even if it were not distributed with compilers, having everything in one 
> place as "The Ada Library" rather than bits and pieces here and there, 
> it would be a great improvement over what we have now.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Stephane Richard]

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

Blessing from?   The revision team?  APIWG ?  Others?

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com


"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F83634E.2090401@noplace.com...
> I think you still need some kind of "Official Blessing" or its just
> another website with just another collection of Ada stuff on it.
>
> MDC
>
>
> Larry Hazel wrote:
>
> >>
> > Even if it were not distributed with compilers, having everything in one
> > place as "The Ada Library" rather than bits and pieces here and there,
> > it would be a great improvement over what we have now.
> >
>
>
> -- 
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/
> My project is: http://www.jsf.mil/NSFrames.htm
>
> Send Replies To: m c o n d i c @ a c m . o r g
>
>      "All reformers, however strict their social conscience,
>       live in houses just as big as they can pay for."
>
>           --Logan Pearsall Smith
> ======================================================================
>

Re: Standard Library Interest?

[Marin David Condic]

We've been there already. My position is that it ultimately needs some 
sort of blessing from the vendors and/or distribution with their 
compilers or its Just Another Ada Library hanging around on the internet 
somewhere along with a few dozen or hundred others that have no general 
acceptance.

But if you want to go create Yet Another Ada Library, go right ahead. In 
my mind, Ada doesn't really need another Quixotic, semi-supported, 
overlapping library with no official standing and an uncertain batch of 
users. I'd prefer not to waste my time by making another library that 
will get mixed reviews and no acceptance as "The Thing". That's why I 
want to see some kind of "Official" standing - and its pretty clear (to 
me at least) who needs to get on board to make it "Official" in some way.

MDC


Stephane Richard wrote:
> Blessing from?   The revision team?  APIWG ?  Others?
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Stephen Leake]

"Stephane Richard" <stephane.richard@verizon.net> writes:

> Blessing from?   The revision team?  APIWG ?  Others?

The APIWG would be a good "official" source of blessing. But they do
not have the funding to do the work needed.

I agree with Marin; only the Ada compiler vendors have the right
combination of clout and funding to do this job. Since they do not
seem to be interested, I don't see much hope for it.

-- 
-- Stephe

Re: Standard Library Interest?

[Marin David Condic]

The APIWG might be a forum in which to build the Reference 
Implementation and be the basic keepers of what it means to be the 
Conventional Ada Library. I just don't know that they see that as their 
goal. That, and it would need some kind of acceptance from the vendors - 
not just a SIGAda "blessing"

The vendors *might* be very interested in it. They might be avoiding 
jumping into the fray until they see which way the wind is blowing 
and/or formulating ideas on how to go about it. I wouldn't take the 
relative silence from the vendors or the ARG to mean they are not in 
favor of it. They have to exercise some caution in what to back and how 
to go about it.

Unless a few of the vendors would care to respond and declare "Yeah" or 
"Nay" on the whole concept? Anybody care to go on record? :-)

MDC


Stephen Leake wrote:
> 
> 
> The APIWG would be a good "official" source of blessing. But they do
> not have the funding to do the work needed.
> 
> I agree with Marin; only the Ada compiler vendors have the right
> combination of clout and funding to do this job. Since they do not
> seem to be interested, I don't see much hope for it.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Martin Dowie]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F82F527.3020101@noplace.com...
> Well, yes, that's pretty much compatible with the idea I've been putting
> forward. If you have some group or organization overseeing some
> updatable library, people could contribute what they thought would be

Isn't this the job of the APIWG? I do believe they are supposed to
be producing ref-imps not just paper APIs.

It would be a Good Idea(tm) if everyone banged on at their compiler
vendor about this...

Re: Standard Library Interest?

[Stephane Richard]

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

"Martin Dowie" <martin.dowie@btopenworld.com> wrote in message
news:blv03f$ko1$1@titan.btinternet.com...
> "Marin David Condic" <nobody@noplace.com> wrote in message
> news:3F82F527.3020101@noplace.com...
> > Well, yes, that's pretty much compatible with the idea I've been putting
> > forward. If you have some group or organization overseeing some
> > updatable library, people could contribute what they thought would be
>
> Isn't this the job of the APIWG? I do believe they are supposed to
> be producing ref-imps not just paper APIs.
>
> It would be a Good Idea(tm) if everyone banged on at their compiler
> vendor about this...
>
>

If the APIWG is there for that, maybe it's them we should bang with emails
:-) ??



-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[Martin Dowie]

"Stephane Richard" <stephane.richard@verizon.net> wrote in message
news:EuEgb.31539> > It would be a Good Idea(tm) if everyone banged on at
their compiler
> > vendor about this...
>
> If the APIWG is there for that, maybe it's them we should bang with emails
> :-) ??

I mean that you have to apply pressure on the compiler venors to support and
include or at least point to _prominently_ within their documentation, the
APIWG web site. It would be up to the user from their.

If you don't advertise these things the average Ada user is going to simply
be
unaware they exist. I'm not saying that I like the average Ada users lack of
gumption but this seems to be the lesson from the previous attempts at
"secondary" standards. :-(

Re: Standard Library Interest?

[Marin David Condic]

I don't know what the APIWG is up to, but if the "API" part of their 
name is any indication it would seem they're aiming at providing an 
"API" - a package spec rather than a spec and body. In other words 
"Every Man For Himself" which has historically been a) expensive and b) 
not entirely successful.

Maybe they *do* want to provide a reference implementation. If so, I 
could get on board with that. But I'd like to see some indication that 
the vendors and/or the ARG has some intention of accepting and blessing 
(and distributing) the net result.

MDC


Martin Dowie wrote:
> 
> Isn't this the job of the APIWG? I do believe they are supposed to
> be producing ref-imps not just paper APIs.
> 
> It would be a Good Idea(tm) if everyone banged on at their compiler
> vendor about this...
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Stephane Richard]

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

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F836528.9020906@noplace.com...
> I don't know what the APIWG is up to, but if the "API" part of their
> name is any indication it would seem they're aiming at providing an
> "API" - a package spec rather than a spec and body. In other words
> "Every Man For Himself" which has historically been a) expensive and b)
> not entirely successful.
>
> Maybe they *do* want to provide a reference implementation. If so, I
> could get on board with that. But I'd like to see some indication that
> the vendors and/or the ARG has some intention of accepting and blessing
> (and distributing) the net result.
>
> MDC

I emailed a contact at the APIWG who also forwarded my email to select
contacts of his through APIWG, WG9 and SIG Ada.  Gotten 4 replies so far and
expecting more on the way.

Thus far, they seem to say that because the standarization process is one of
concensus it's hard to make things happen faster they mentionned that to
treat a library/amendment etc etc...as mature, they believe it should be
running and proven stable in the course of 5 years after which it is deemed
mature. Add to the the initial 5 years for a standard revision (as any
standard based on consensus) and there's your 10 years turnover.  They are
not against a centralized API central (the APIWG would mostly take care of
APIs however they showed interest in other types of libraries such as data
structures, components and the like).  They said that if APIWG won't do
these other libraries that another working group would be able to accomodate
these types of libraries/bindings.

They are not against a sub standard repository either, in which changes
could happen on a daily bases.  As illustrated by some companies already
performing this exercise and developing their own additions to the standard
that they ship with their distributions.  Additions, not changes to the
standards :-).

As quoted: "Standardization is an admittedly slow process, because it is
fundamentally
built on consensus.  On the other hand, there is nothing precluding a group
of users establishing their own reusable libraries, and making them
widely available.  De-facto standards are often just as good, or
even better, than de-jure standards. "   I'm no latin speaking individual
and I'm curious to know the difference between De-Facto and De-Jure :-).
although I have an idea based on the context if this quote hehe..

I dont know if I can get a written and signed blessing document (then
again...ya never know :-) out of it. but so far as per the replies I've
received it, they welcome the idea of a centralized sour of mature libraries
and APIs. Most of those who replied mentionned it right in their emails.

I'll keep you posted as I get more replies and ask all the questions I have
on my mind.

ANd now You're up to date.
-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[Robert I. Eachus]

Stephane Richard wrote:
>                                        I'm no latin speaking individual
> and I'm curious to know the difference between De-Facto and De-Jure :-).
> although I have an idea based on the context if this quote hehe...

Roughly "de facto" = "in fact", and "de jure" = "in law".

In the standards industry, a de facto standard is something most people 
use, even though it is not particularly blessed by some standards 
organization.  Windows is a de facto standard, even if you have no idea 
what will happen when you take some action in Windows, the fact that so 
many people are using it makes it a de facto standard.  Similarly, Linux 
is a de facto standard, and POSIX is a de jure standard.  Is it possible 
for a version of Linux to be POSIX compliant?  Sure.  In fact, Windows 
NT 4.0 was sold as POSIX compliant even if no one other than masochists 
tried to use the POSIX interface. ;-)
-- 
                                            Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Stephane Richard]

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

"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:3F84A3F9.6@comcast.net...
> Stephane Richard wrote:
> >                                        I'm no latin speaking individual
> > and I'm curious to know the difference between De-Facto and De-Jure :-).
> > although I have an idea based on the context if this quote hehe...
>
> Roughly "de facto" = "in fact", and "de jure" = "in law".
>
> In the standards industry, a de facto standard is something most people
> use, even though it is not particularly blessed by some standards
> organization.  Windows is a de facto standard, even if you have no idea
> what will happen when you take some action in Windows, the fact that so
> many people are using it makes it a de facto standard.  Similarly, Linux
> is a de facto standard, and POSIX is a de jure standard.  Is it possible
> for a version of Linux to be POSIX compliant?  Sure.  In fact, Windows
> NT 4.0 was sold as POSIX compliant even if no one other than masochists
> tried to use the POSIX interface. ;-)
> -- 
>                                             Robert I. Eachus

I hear ya on the masochists....I admit I tried using it back then.  but soon
realized that I had 2 choices, go to DOS mode, or die still trying to do any
kind of POSIX....guess which door I chose? hehehe
-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[Marin David Condic]

Except that this didn't answer my question: Is the APIWG seeing itself 
as being in the business of building a library or just endorsing package 
specs?

All the stuff you mentioned about "Standards" is valid and I have no 
complaint. At best, I can read into it that the APIWG might put their 
Nihil Obstat on some library - if and when it had some "general 
acceptance". Which is to say, they are not in the business of building 
and maintaining a library and don't particularly want to be. That moves 
the library mission forward only by a tiny bit - if at all. It is as I 
suspected - the APIWG is not going to be the place to get this done.

So this puts you back at square-one: *IF* you built a library and *IF* 
you could get the vendors to accept/distribute it and *IF* it met with 
general acceptance by the public, *THEN* you get a little gold star on 
your forehead by the APIWG. (At that point, I don't really need the 
APIWG, do I? Its a de facto standard. De facto: a matter of fact. De 
jure: a matter of law)

That's why I'm lobbying for the route that says "Get the vendors and 
possibly the ARG involved at the start." If the vendors were to say 
"Yeah, go ahead and build us something that looks kind of like this and 
we'll distribute it..." then you've got something working towards a de 
facto standard that the ARG and the APIWG and the People For The Ada Way 
and my great uncle George can all go put their little stamp of approval 
on it. Of course, if it got that far, I don't think we'd need anybody's 
approval. If it ships with every Ada compiler and its basically the same 
from one compiler to the next, its part of Ada.

MDC


Stephane Richard wrote:
> "Marin David Condic" <nobody@noplace.com> wrote in message
> news:3F836528.9020906@noplace.com...
> 
>>I don't know what the APIWG is up to, but if the "API" part of their
>>name is any indication it would seem they're aiming at providing an
>>"API" - a package spec rather than a spec and body. In other words
>>"Every Man For Himself" which has historically been a) expensive and b)
>>not entirely successful.
>>
>>Maybe they *do* want to provide a reference implementation. If so, I
>>could get on board with that. But I'd like to see some indication that
>>the vendors and/or the ARG has some intention of accepting and blessing
>>(and distributing) the net result.
>>
>>MDC
> 
> 
> I emailed a contact at the APIWG who also forwarded my email to select
> contacts of his through APIWG, WG9 and SIG Ada.  Gotten 4 replies so far and
> expecting more on the way.
> 
> Thus far, they seem to say that because the standarization process is one of
> concensus it's hard to make things happen faster they mentionned that to
> treat a library/amendment etc etc...as mature, they believe it should be
> running and proven stable in the course of 5 years after which it is deemed
> mature. Add to the the initial 5 years for a standard revision (as any
> standard based on consensus) and there's your 10 years turnover.  They are
> not against a centralized API central (the APIWG would mostly take care of
> APIs however they showed interest in other types of libraries such as data
> structures, components and the like).  They said that if APIWG won't do
> these other libraries that another working group would be able to accomodate
> these types of libraries/bindings.
> 
> They are not against a sub standard repository either, in which changes
> could happen on a daily bases.  As illustrated by some companies already
> performing this exercise and developing their own additions to the standard
> that they ship with their distributions.  Additions, not changes to the
> standards :-).
> 
> As quoted: "Standardization is an admittedly slow process, because it is
> fundamentally
> built on consensus.  On the other hand, there is nothing precluding a group
> of users establishing their own reusable libraries, and making them
> widely available.  De-facto standards are often just as good, or
> even better, than de-jure standards. "   I'm no latin speaking individual
> and I'm curious to know the difference between De-Facto and De-Jure :-).
> although I have an idea based on the context if this quote hehe..
> 
> I dont know if I can get a written and signed blessing document (then
> again...ya never know :-) out of it. but so far as per the replies I've
> received it, they welcome the idea of a centralized sour of mature libraries
> and APIs. Most of those who replied mentionned it right in their emails.
> 
> I'll keep you posted as I get more replies and ask all the questions I have
> on my mind.
> 
> ANd now You're up to date.


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Stephane Richard]

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

> Except that this didn't answer my question: Is the APIWG seeing itself
> as being in the business of building a library or just endorsing package
> specs?
the do API's only.  He showed interest of data structures, components, but
it would be another group that would be taking care of it.  What he did say
is that which group it is (which I will find out) he believed that they
would
prove quite cooperative on the effort.

>
> All the stuff you mentioned about "Standards" is valid and I have no
> complaint. At best, I can read into it that the APIWG might put their
> Nihil Obstat on some library - if and when it had some "general
> acceptance". Which is to say, they are not in the business of building
> and maintaining a library and don't particularly want to be. That moves
> the library mission forward only by a tiny bit - if at all. It is as I
> suspected - the APIWG is not going to be the place to get this done.
>
Nope, I alerady replied him with the "Who is it then?" question hopefully
today I'll get a reply and we can find out.  from what I'm seeing it's one
of
7 possible groups:
- ARG - Ada Rapporteur Group
- ASISRG - Ada Semantics Interface Specification (ASIS) Rapporteur Group
- HRG - Annex H Rapporteur Group
- NRG - Numerics Rapporteur Group
- RRG - Real-Time Rapporteur Group
- SRG - SQL/Ada Rapporteur Group
- URG - Uniformity Rapporteur Group

I'm thinking ARG yes since they seem to deal with Ada in general and not be
limited to a single or group of Annexes.  URG?  I don't but perhaps they
would have valuable information as to how to "create the code" a style
guide, a minimal documentation template or something like that to help
assure a minimal quality of code in teh library.


> So this puts you back at square-one: *IF* you built a library and *IF*
> you could get the vendors to accept/distribute it and *IF* it met with
> general acceptance by the public, *THEN* you get a little gold star on
> your forehead by the APIWG. (At that point, I don't really need the
> APIWG, do I? Its a de facto standard. De facto: a matter of fact. De
> jure: a matter of law)
>
As for vendors, well I'll ask around and see what kind of answer I get.  If
they'd welcome them and so on and so forth.  Again provided, like you said
it is atleast a minimum quality code, with atleast a minimum clarity of
documentation (so any programmer can figure out what to do with it :-). and
if not in naming conventions also see how to integrate them (to a minimum
degree) with at least all related possible "parents" so to speak.  "I still
like my taxonomy chart (or hierarchy) approach to it all.  This way if there
were to be to packange of the same name, doing very different things perhaps
this way the could still be places on different branches of the hierarchy.
if not then perhaps the 2 authors can communicate and see how to fix the
naming conflict.  (that would be for existing code I assume).  we'd have a
lookup available so when creating New code they could know if it exists
somewhere etc etc...

> That's why I'm lobbying for the route that says "Get the vendors and
> possibly the ARG involved at the start." If the vendors were to say
> "Yeah, go ahead and build us something that looks kind of like this and
> we'll distribute it..." then you've got something working towards a de
> facto standard that the ARG and the APIWG and the People For The Ada Way
> and my great uncle George can all go put their little stamp of approval
> on it. Of course, if it got that far, I don't think we'd need anybody's
> approval. If it ships with every Ada compiler and its basically the same
> from one compiler to the next, its part of Ada.

Now if we can get your Uncle George stamp of approval, I call that a
success...;-).

Like I said the APIWG seemed to say that any group would welcome and be
willing to cooeperate.  My next phase is to see to what extent. :-)
>
> MDC
>
>


-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[Robert I. Eachus]

Stephane Richard wrote:
>>Except that this didn't answer my question: Is the APIWG seeing itself
>>as being in the business of building a library or just endorsing package
>>specs?
> 
> the do API's only.  He showed interest of data structures, components, but
> it would be another group that would be taking care of it.  What he did say
> is that which group it is (which I will find out) he believed that they
> would
> prove quite cooperative on the effort.
> 
> 
>>All the stuff you mentioned about "Standards" is valid and I have no
>>complaint. At best, I can read into it that the APIWG might put their
>>Nihil Obstat on some library - if and when it had some "general
>>acceptance". Which is to say, they are not in the business of building
>>and maintaining a library and don't particularly want to be. That moves
>>the library mission forward only by a tiny bit - if at all. It is as I
>>suspected - the APIWG is not going to be the place to get this done.
>>
> 
> Nope, I alerady replied him with the "Who is it then?" question hopefully
> today I'll get a reply and we can find out.  from what I'm seeing it's one
> of
> 7 possible groups:
> - ARG - Ada Rapporteur Group
> - ASISRG - Ada Semantics Interface Specification (ASIS) Rapporteur Group
> - HRG - Annex H Rapporteur Group
> - NRG - Numerics Rapporteur Group
> - RRG - Real-Time Rapporteur Group
> - SRG - SQL/Ada Rapporteur Group
> - URG - Uniformity Rapporteur Group

As far as I know at the current time only the ARG, ASISRG, HRG, and RRG 
still exist.  But I'd have to check...  That was quick. 
http://wwwold.dkuug.dk/JTC1/SC22/WG9/organize.htm#RGs  Cross out the RRG 
as well.

> I'm thinking ARG yes since they seem to deal with Ada in general and not be
> limited to a single or group of Annexes.  URG?  I don't but perhaps they
> would have valuable information as to how to "create the code" a style
> guide, a minimal documentation template or something like that to help
> assure a minimal quality of code in the library.

Please don't assign it to the ARG.  The ARG always has much more work 
than they can handle.  Bringing back the URG or some new group would be 
a better idea.



-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Stephane Richard]

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

>
> Please don't assign it to the ARG.  The ARG always has much more work
> than they can handle.  Bringing back the URG or some new group would be
> a better idea.
>
>
>
> -- 
>                                                      Robert I. Eachus

IF we go the way of a new group, who would we have to talk to to get things
started, get the big wheel turning?

However I think we should have a basis for a structure to suggest first.  So
on your other post to Martin, when you say to create a structure of names
(atleast) I'd say you're right :-)..if not anything else, a text file that
represents an image of a possible end product perhaps?  That wouldn't be too
long too do.  Atleast we'd all see (and be able to agree on) a given layout.
For that I have to agreewith you :-).

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[Marin David Condic]

Start with the vendors. Who is still out there producing Ada compilers 
and with the intention of upgrading them to Ada0x? ACT? Aonix? RR? 
Rational? DDC-I? Which of these vendors (And others? Who else is out 
there?) are still actively interested in enhancing their products?

The vendors who are still actively interested in Ada probably have some 
representation in the ARG. If they are still actively selling Ada, they 
probably have some technical person who could be contacted. Ask them 
what *THEY* want to see happen. Its all a most profound - possibly even 
sinful - waste of time to run off and start putting something together 
if the key players are going to end up saying "No Way". Find out what 
their requirements are and what they want to see happen and maybe we can 
make sure we got something organized that would meet their needs.

With something like a library, Ada has a chance to build a new culture 
of "Customer Orientation" - Lets not just rush off and start building 
things because we think they are theoretically nice or intellectually 
satisfying. Lets build things that will satisfy the customer because we 
bothered to *ASK* the customers what they want. Market Research ought to 
be really key here.

MDC


Stephane Richard wrote:
> 
> IF we go the way of a new group, who would we have to talk to to get things
> started, get the big wheel turning?
> 
> However I think we should have a basis for a structure to suggest first.  So
> on your other post to Martin, when you say to create a structure of names
> (atleast) I'd say you're right :-)..if not anything else, a text file that
> represents an image of a possible end product perhaps?  That wouldn't be too
> long too do.  Atleast we'd all see (and be able to agree on) a given layout.
> For that I have to agreewith you :-).
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Jeff C,]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F86AAE2.4090907@noplace.com...
> Start with the vendors. Who is still out there producing Ada compilers
> and with the intention of upgrading them to Ada0x? ACT? Aonix? RR?
> Rational? DDC-I? Which of these vendors (And others? Who else is out
> there?) are still actively interested in enhancing their products?
>

Vendors that I think still have active products include:

ACT
RR
Rational
DDC-I
Greenhills
OC Systems
Concurrent Computer Corp
ICC

It at least appears as if these products are still being support.
It will be interesting to see who invests the money to move forward to Ada
0x.

Re: Standard Library Interest?

[Marin David Condic]

Is there anybody out there from any of these companies reading this list 
who would care to make some kind of statement on the subject? Even 
"We're looking into it..." is a better answer than nothing at all.

Are these companies represented in the ARG? If so, that's a good reason 
to take the issue to the ARG and ask them to respond. (You've got all 
the suspects in one place - ask them if they want a standard library and 
would be willing to distribute one if it were to be brought about 
somehow...)

You need some feedback that says these guys are on board or whatever 
gets done is going to be at best Just Another Ada Library hanging around 
somewhere on the internet. (And I do mean *AT BEST* because it has been 
tried before and mostly augered in with little to no net results to show 
for it.)

MDC


Jeff C, wrote:
> 
> 
> Vendors that I think still have active products include:
> 
> ACT
> RR
> Rational
> DDC-I
> Greenhills
> OC Systems
> Concurrent Computer Corp
> ICC
> 
> It at least appears as if these products are still being support.
> It will be interesting to see who invests the money to move forward to Ada
> 0x.
> 
> 
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Stephane Richard]

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


"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F88181E.7050200@noplace.com...
> Is there anybody out there from any of these companies reading this list
> who would care to make some kind of statement on the subject? Even
> "We're looking into it..." is a better answer than nothing at all.
>
> Are these companies represented in the ARG? If so, that's a good reason
> to take the issue to the ARG and ask them to respond. (You've got all
> the suspects in one place - ask them if they want a standard library and
> would be willing to distribute one if it were to be brought about
> somehow...)
>
> You need some feedback that says these guys are on board or whatever
> gets done is going to be at best Just Another Ada Library hanging around
> somewhere on the internet. (And I do mean *AT BEST* because it has been
> tried before and mostly augered in with little to no net results to show
> for it.)
> >
>
I got in touch with ACT, they'll be calling me on monday morning so we can
talk about that, the idea itself, what they think about it, any insight, etc
etc.... :-).

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[Robert I. Eachus]

Stephane Richard wrote:

> However I think we should have a basis for a structure to suggest first.  So
> on your other post to Martin, when you say to create a structure of names
> (atleast) I'd say you're right :-)..if not anything else, a text file that
> represents an image of a possible end product perhaps?  That wouldn't be too
> long too do.  Atleast we'd all see (and be able to agree on) a given layout.
> For that I have to agreewith you :-).

It would be nice to have a good proposal and presentation in shape for 
the WG9 meeting in San Diego, and get it on the agenda.  As I have said, 
I think the right approach is to keep the standards related part of this 
small:  An on-line registry of top-level library names.  But notice that 
once you go the standards route, there are potential political issues 
hiding all around.

In this case, I think the right approach is to have a registry which for 
all practical purposes is a de facto listing of all the library names 
that are being used.  But the "official" list would have to pass up the 
approval chain through WG9 every so often, and there would have to be 
procedures for dealing with conflicting registrations and so on.  In 
other words, a search of the list would return all known names that 
matched, with probably a one word status: Registered, Pending, Rejected, 
Withdrawn, Unknown, Delisted.

If I were doing it I would probably set up a nominal registration fee 
for top level names.  It should be small enough not to pain those who 
are doing the registration to contribute to the community, and 
high-enough so that if a cyber-squatter wants to try it, he can fund the 
whole operation, including the clerical overhead of rejecting most or 
all of his requests. ;-)  Or we could just have a rule about the number 
of top level libraries registered by one person or corporation.

If we work at it, it could be in place and working by the San Diego 
meeting on a provisional basis, then Marin can file a registration 
application for CAL that states the current contents and the rules for 
adding to it.  St�phane can register SAL, ACT can register GNAT, and so 
on.  (If I get a vote on who gets approved, I'm going to look for 
libraries that exist, are well documented, include unit tests, and are 
useful.  So get busy. ;-)

-- 
                                         Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Stephane Richard]

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

See my comments amongst yours :-).

"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:3F8706CA.7040704@comcast.net...

> It would be nice to have a good proposal and presentation in shape for
> the WG9 meeting in San Diego, and get it on the agenda.  As I have said,
> I think the right approach is to keep the standards related part of this
> small:  An on-line registry of top-level library names.  But notice that
> once you go the standards route, there are potential political issues
> hiding all around.
*** Which makes the deadline which date ?

*** I would think the idea is to keep away from the Ada branch (except if we
want to add basic functionality to any of the standard Ada packages, like
you said, in that case we could let it be known that it exists in our
library but it would be the WG9's role to accept it, reject it, etc etc
since it is under the Ada standard hierarchy.  Ultimately we could have an
Ada top level name that would serve just for that purpose perhaps.  or a
"Standard" branch as to not conflict with the Ada name itself.  But a branch
just for that might be a good idea.

>
> In this case, I think the right approach is to have a registry which for
> all practical purposes is a de facto listing of all the library names
> that are being used.  But the "official" list would have to pass up the
> approval chain through WG9 every so often, and there would have to be
> procedures for dealing with conflicting registrations and so on.  In
> other words, a search of the list would return all known names that
> matched, with probably a one word status: Registered, Pending, Rejected,
> Withdrawn, Unknown, Delisted.

*** Sounds good to me, and since Ada is case insensitive  MyStatsLibrary and
mystatslibrary would be the same and should return a conflict.

>
> If I were doing it I would probably set up a nominal registration fee
> for top level names.  It should be small enough not to pain those who
> are doing the registration to contribute to the community, and
> high-enough so that if a cyber-squatter wants to try it, he can fund the
> whole operation, including the clerical overhead of rejecting most or
> all of his requests. ;-)  Or we could just have a rule about the number
> of top level libraries registered by one person or corporation.

*** I would suggest here that fees depend on the purpose of the submission.
I wouldn't want to charge a fee to a programmer that puts an OpenSource
licence on his submission.  Free Software is Free Software.  But if the aim
of the library or binding etc etc is a commercial one then a fee could be in
order.  and of course should an open source submission's author want to turn
it into a commercial licence then the "fee" would need to apply in this
scenario.

>
> If we work at it, it could be in place and working by the San Diego
> meeting on a provisional basis, then Marin can file a registration
> application for CAL that states the current contents and the rules for
> adding to it.  St�phane can register SAL, ACT can register GNAT, and so
> on.  (If I get a vote on who gets approved, I'm going to look for
> libraries that exist, are well documented, include unit tests, and are
> useful.  So get busy. ;-)

*** And again when's the San Diego meeting?  How much time do we have?
>
> -- 
>                                          Robert I. Eachus

*** I've started work on a possible structure of the "CAL" library (is that
now the official name?) we'll call it that until we know :-).  What we could
do here on the board is perhaps state a list of what sections would be
needed in the documentation to assure that it's clear enough.  I'd suggest
HTML as the file format for those docs so they can be indexed on search
engines so that they are available outside the scope of the library itself.
but that's just a suggestion :-).

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[Stephane Richard]

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

Here is the first draft,

Now this is an initial suggestion, I don't expect this to be the final word,
we probably need to work on it :-).  but hey it's a start.

http://www.adaworld.com/cal/cal_library.txt

Remember that this hierarchy is not representative of search methods, we
could search many more ways than is suggested by the hierarchy, just the
layout (folder/file wise) of the library.  since the names will be in a
database, it would be easy to search anyway we want.  However, the hierarchy
would and should be the "list of categories" in the database for proper
organization of it all. Hence a new entry would need to be "categorized" by
the author or by someone else. so it can be indexed on searches properly.

P.S. I would have attached this but it seems attachments on newsgroups is
"impossible" or highly unrecommended :-).

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[sk]

stephane.richard@verizon.net:
 > ... probably need to work on it :-).  but hey it's a start.
 >
 > http://www.adaworld.com/cal/cal_library.txt
 >
 > Remember that this hierarchy is not representative of search ...

Interesting but what is the difference between this and my proposal,
which nobody showed interest for, in the thread "Newbie: Display
Control" which was renamed to "Ada2005 clear screen etc" started
in march of this year ?

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Standard Library Interest?

[Stephane Richard]

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

"sk" <noname@myob.com> wrote in message
news:mailman.68.1065893639.25614.comp.lang.ada@ada-france.org...
> stephane.richard@verizon.net:
>  > ... probably need to work on it :-).  but hey it's a start.
>  >
>  > http://www.adaworld.com/cal/cal_library.txt
>  >
>  > Remember that this hierarchy is not representative of search ...
>
> Interesting but what is the difference between this and my proposal,
> which nobody showed interest for, in the thread "Newbie: Display
> Control" which was renamed to "Ada2005 clear screen etc" started
> in march of this year ?
>

I dont recall seeing this thread, I use outlook (awaiting flames just about
now hehehe)....so things tend to dissapear if unanswered ... By no means did
I mean to superseed an initial proposal.  I'm sorry, but I did not know
about it.  I'll use Mozilla to retrace your post (unless you can include as
a reply to this message.  See what we can do.  But I didn't mean any
conflict by suggesting this structure :-)

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[Robert I. Eachus]

Stephane Richard wrote:
> Here is the first draft,
> 
> Now this is an initial suggestion, I don't expect this to be the final word,
> we probably need to work on it :-).  but hey it's a start.
> 
> http://www.adaworld.com/cal/cal_library.txt
> 
> Remember that this hierarchy is not representative of search methods, we
> could search many more ways than is suggested by the hierarchy, just the
> layout (folder/file wise) of the library.  since the names will be in a
> database, it would be easy to search anyway we want.  However, the hierarchy
> would and should be the "list of categories" in the database for proper
> organization of it all. Hence a new entry would need to be "categorized" by
> the author or by someone else. so it can be indexed on searches properly.
> 
> P.S. I would have attached this but it seems attachments on newsgroups is
> "impossible" or highly unrecommended :-).

In part, you are heading in a slightly different direction than I am. 
For example, I think it would be a good idea to have an OS tree directly 
within Standard, and Windows, Linux, Unix, under that.  Each of these 
might have grandchildren for specific versions of those OSes.

Similarly, I don't think Graphics and database bindings belong in Ada or 
CAL.  I think they should go in Interfaces.




-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Stephane Richard]

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

"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:3F8846DF.8050303@comcast.net...
>
> In part, you are heading in a slightly different direction than I am.
> For example, I think it would be a good idea to have an OS tree directly
> within Standard, and Windows, Linux, Unix, under that.  Each of these
> might have grandchildren for specific versions of those OSes.
>
> Similarly, I don't think Graphics and database bindings belong in Ada or
> CAL.  I think they should go in Interfaces.

See?  that's exactly what it's for, we have a basis, one to build on,
change, tell me I should be smoking something else, heheheh etc etc...we're
working, we're progressing this way :-)...maybe I'll take that file paste it
in an email, start a new thread so we can all work at it, edit it and make
it what it should be :-).

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[Marin David Condic]

Is that end-user extendable? I've never had a reason to try.

I'd agree that given the name "Interfaces" we'd be wise to include 
anything that smacked of a "binding" into that part. For example, you 
might have a Ada.OS or a Standard.OS that provided some Ada-flavored, 
portable (mostly) facilities for using common OS capabilities. 
(Directories, files, networks, etc.) Then under "Interfaces" you might 
have "Interfaces.Windows" that provided thin bindings to the Win32api. 
The Ada user has a choice: Build his app with the Ada-ish, portable 
features found in Standard.OS and suffer whatever limitations might have 
been sacrificed for the greater good of "portability" *OR* dip directly 
into the non-portable Win32api and get full access to anything the OS 
provides while suffering through the C-ish nature of the interface.

I still think that the question of how to organize the tree(s) is 
something that could be hammered out at a later point. If we got a 
charter from the vendors and ARG to do *something* a SIGAda team might 
be formed up to come up with the "how" issues and perhaps start 
establishing some guidelines. Get acceptance for the concept, then set 
someone up to be the Keeper Of The Eternal Flame and act as the 
editor/publisher. They'd come back to the principals and say "Here's our 
plan..." From there, it just starts to become a mere matter of technical 
details and probably funding.

If we wanted to, we could get all tangled up in details such as "What 
should we use for a configuration management system?" or "What document 
formats should we support?" Eventually, we'd have to answer those 
questions, but right now, we've got a bigger issue of gaining acceptance 
for the general concept. I'd think we want to worry about that first and 
let the rest fall out as "implementation details" once someone sets the 
direction and annoints an editor or team of editors to go worry about it.

MDC


Robert I. Eachus wrote:
> 
> Similarly, I don't think Graphics and database bindings belong in Ada or 
> CAL.  I think they should go in Interfaces.
> 
> 
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Robert I. Eachus]

Marin David Condic wrote:
> Is that end-user extendable? I've never had a reason to try.

Technically with GNAT, all the predefined library packages can be 
recompiled in non-standard mode (i.e. using -gnatg).  Other compilers 
have other rules, and I don't have first hand knowledge of what they do.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:
> Stephane Richard wrote:
>> Here is the first draft,
>> Now this is an initial suggestion, I don't expect this to be the final 
>> word,
>> we probably need to work on it :-).  but hey it's a start.
>>
>> http://www.adaworld.com/cal/cal_library.txt
>>
>> Remember that this hierarchy is not representative of search methods, we
>> could search many more ways than is suggested by the hierarchy, just the
>> layout (folder/file wise) of the library.  since the names will be in a
>> database, it would be easy to search anyway we want.  However, the 
>> hierarchy
>> would and should be the "list of categories" in the database for proper
>> organization of it all. Hence a new entry would need to be 
>> "categorized" by
>> the author or by someone else. so it can be indexed on searches properly.
>>
>> P.S. I would have attached this but it seems attachments on newsgroups is
>> "impossible" or highly unrecommended :-).
> 
> In part, you are heading in a slightly different direction than I am. 
> For example, I think it would be a good idea to have an OS tree directly 
> within Standard, and Windows, Linux, Unix, under that.  Each of these 
> might have grandchildren for specific versions of those OSes.
> 
> Similarly, I don't think Graphics and database bindings belong in Ada or 
> CAL.  I think they should go in Interfaces.

I would prefer to see much that would show up in the Linux/Unix, and some
of Win32, to appear under POSIX (like FLORIST). I would only expect to
see OS unique things under the other OS headings.

The other thing is, it would be nice if some common denominator of
console I/O (other than tty) was available. This is a tall order,
if you insist on including colour(color) and blink attributes, but
if you could subset that to clear screen, cursor position etc., that
would fill a needed gap. The OS specific child libraries, could then
take that further.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Standard Library Interest?

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:
> Stephane Richard wrote:
...
> If I were doing it I would probably set up a nominal registration fee 
> for top level names.  It should be small enough not to pain those who 
> are doing the registration to contribute to the community, and 
> high-enough so that if a cyber-squatter wants to try it, he can fund the 
> whole operation, including the clerical overhead of rejecting most or 
> all of his requests. ;-)  Or we could just have a rule about the number 
> of top level libraries registered by one person or corporation.

The way I would deal with the squatters is that they have to
contribute/produce a product that uses that name within a given
time frame (1-2 years?)  What is produced should optionally be
reviewed, and at the registration committee's discretion, allow
the name to stand or be dropped (anything trivial or junky for
the purpose of squatting can be rejected this way).

Failure to "produce", obviously means that you give up the name.
A conflict resolution process will also likely need some
planning as well. But initially, it could just take the "might
is right" path ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Standard Library Interest?

[Marin David Condic]

What's wrong with saying "You don't have some God-given right to a name. 
You have to ask, beg, plead with me to get one. If I don't like it, I 
say no. If I give it to you, I can pull it back any time I want. Game over."

Whoever ends up Keeper Of The Eternal Flame can limit it to whatever 
they want. They can entertain only serious developers who have something 
concrete to offer. Internet dweebs who hope to cash in by grabbing all 
sorts of names need not even bother applying.

MDC


Warren W. Gay VE3WWG wrote:
> 
> The way I would deal with the squatters is that they have to
> contribute/produce a product that uses that name within a given
> time frame (1-2 years?)  What is produced should optionally be
> reviewed, and at the registration committee's discretion, allow
> the name to stand or be dropped (anything trivial or junky for
> the purpose of squatting can be rejected this way).
> 
> Failure to "produce", obviously means that you give up the name.
> A conflict resolution process will also likely need some
> planning as well. But initially, it could just take the "might
> is right" path ;-)
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> What's wrong with saying "You don't have some God-given right to a name. 
> You have to ask, beg, plead with me to get one. If I don't like it, I 
> say no. If I give it to you, I can pull it back any time I want. Game 
> over."

It works if the dictatorship is a good one ;-)  But good dictatorships
rarely stay good, if they even ever start off as a good one.

> Whoever ends up Keeper Of The Eternal Flame can limit it to whatever 
> they want. They can entertain only serious developers who have something 
> concrete to offer. 

But a value judgement is required here. Someone may come out with
a console I/O package, that favours the design of windows console
sessions. The judge(s) who might be more favourable to Linux, might
then disagree, and want to keep the name reserved for some (in their
minds) more superior idea. A conflict develops.

OTOH, the package writer doesn't want to have the rug yanked out, after
he has released the product, only because the judge(s) later decided
that it sucks and shouldn't be there.

> Internet dweebs who hope to cash in by grabbing all 
> sorts of names need not even bother applying.
> 
> MDC

I hear ya, but in life, there are often two sides of the story that
need to be examined. After a divorce there is his side, her side,
and the truth! ;-)
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Standard Library Interest?

[Stephane Richard]

>
>         Sounds like you want to take Ada OUT OF the standards system
totally.
> (Who would be the "makers" of Ada? Some coalition of compiler writers?).
>
>         How many incompatible features do the various Linux distributions
> contain? Debian packages vs RPMs, etc.
>
>

No, not at all, Ada should remain as standard as it is, my real goal is to
get rid of the 10 year period if wait to get anything new accepted as a
standard, not get rid of the standard itself.  Maybe I wasn't clear enough.
But Ada MUST be standard, it's its strenght.

But 10 years is a really long time to geta revision especially in the
computer world.

Re: Standard Library Interest?

[Marin David Condic]

Be fair. We have not been suggesting that the cycle of ARM/Language 
revision be done at a faster rate. Just that a *library* (which doesn't 
change the syntax or semantics of the language itself) ought to be able 
to get updated at a faster rate. Yes, other language standards take 
about 10 years to update as well and I don't think that needs to be 
"fixed". But if you're going to have a library, you need to be able to 
let it grow to accommodate new developments in the computer world, so 
ten years is too long.

A good example might be if you had an XML branch of the library. XML 
itself is not under such rigorous control as the ARM so it is evolving. 
As it extends and needs new support, would you want to wait ten years to 
get it? An XML DOM would be a wonderful thing to have in a library and 
"Standard" in the sense that all compilers provided the same interface. 
So you'd like a reference implementation that all vendors used. You'd 
like to update it as XML grows and changes. If it were in the ARM, you 
would be SOL.

MDC

Dennis Lee Bieber wrote:
>>
> 
>         Seems common in my experience... FORTRAN IV (F-66), FORTRAN-77, 
> Fortran-90 (11 years, then 13 years). I think there have only been two, 
> maybe three, formal standards for COBOL since the COBOL-74 standard.
> 
>         C was only standardized what, 1990? C++ was standardized when, 98?
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Stephen Leake]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

>         C was only standardized what, 1990? 

1989

>         C++ was standardized when, 98?

1996 

(Ada was the first Internationally Standardized Object Oriented
Language. I just like saying that :).

-- 
-- Stephe

Re: Standard Library Interest?

[Stephane Richard]

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

> (Ada was the first Internationally Standardized Object Oriented
> Language. I just like saying that :).
>
> -- 
> -- Stephe

And I just like hearing it.  ;-)

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[Hyman Rosen]

Dennis Lee Bieber wrote:
 > Is the STL defined as part of the language standard

Yes.

By the way, C++ cognoscenti are addressing similar library issues.
The complaints are the same - we need more libraries because
(insert: Java, C#, Windows, etc.) has them and we're falling behind,
and trying to get them into the standard is too slow.

There's already a central site which is focusing on being the place
where proposed libraries live, <http://www.boost.org/>. It might be
fruitful to read through it to see how their policies work.

Re: Standard Library Interest?

[Stephane Richard]

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

> By the way, C++ cognoscenti are addressing similar library issues.
> The complaints are the same - we need more libraries because
> (insert: Java, C#, Windows, etc.) has them and we're falling behind,
> and trying to get them into the standard is too slow.
>
> There's already a central site which is focusing on being the place
> where proposed libraries live, <http://www.boost.org/>. It might be
> fruitful to read through it to see how their policies work.
>

I just took a look at it, and I'd say you're right, it's worth looking into.
Mix in Ada Style And quality for coding style, create our own hierarchy of
libraries because their idea is pretty good, I for one would use a different
"classification" approach to the library, one that reflects the Ada Style
and quality.  But as far as processes go (reviewing of libraries, different
steps to get a idea into a usabe/reusable stable library state) their
approach seems pretty good.  Perhaps we can borrow a few tips and tricks.

As for how I'd see the "classification" process?  As I mentionned
previously, somewhat of a taxonomy chart of libraries (which could and would
represent object dependancies, agretations, containments within each other)
would be good in my book.  As a basis of course, the means to search the
hierarchy could be from anything to anything as in, keyword searches,
library type search, named searches, anything at all.  and those search
mechanisms could grow as we find ways to search "intelligently" through the
hierarchy or get demands to search by this or that criteria.

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[Stephen Leake]

somebody (I didn't get the original post) writes:

> By the way, C++ cognoscenti are addressing similar library issues.
><snip>
>
> There's already a central site which is focusing on being the place
> where proposed libraries live, <http://www.boost.org/>. It might be
> fruitful to read through it to see how their policies work.

Note that Boost is supported by Boost consulting, which is making
money selling support and development services for the Boost library.
That's a good business model, but it relies on a large customer base.

Maybe part of Ada's problem is that it's so easy to write good code
that nobody needs support for a good library :).

-- 
-- Stephe

Re: Standard Library Interest?

[Georg Bauhaus]

Robert I. Eachus <rieachus@comcast.net> wrote:
: Huh?  Read the RM:   <i>The predefined type Wide_Character is a 
: character type whose values correspond to the 65536 code positions of 
: the ISO 10646 Basic Multilingual Plane (BMP).
: 
: The BMP character set is identical to Unicode. 

How can this be when Unicode has more than 65536 code positions?
(Assuming I wanted to use full Unicode, I guess I will have to rely
on Implementation Permissions to provide me with a corresponding
character type?)


Georg

Re: Standard Library Interest?

[chris]

Georg Bauhaus wrote:

> How can this be when Unicode has more than 65536 code positions?
> (Assuming I wanted to use full Unicode, I guess I will have to rely
> on Implementation Permissions to provide me with a corresponding
> character type?)

I was going to ask that, but assumed BMP uses the same extension 
mechanism as unicode to achieve more than 65536 code points.

Re: Standard Library Interest?

[Robert I. Eachus]

Georg Bauhaus wrote:

> How can this be when Unicode has more than 65536 code positions?
> (Assuming I wanted to use full Unicode, I guess I will have to rely
> on Implementation Permissions to provide me with a corresponding
> character type?)

If you are that familiar with Unicode... Ada Wide_Character corresponds 
to the ISO 10646 BMP, and to Unicode. ISO 10646 defines a 32-bit mapping 
for code points, broken into octets, and further into 16-bit (two octet) 
planes.  It also defines three encoding mechanisms, UTF-8, UTF-16, and 
UTF-32.  Unicode corresponds to UTF-16, where most 16-bit encodings map 
to single code points, and encodings in the surrogates area are used to 
encode code points from other planes.  These encodings consist of a high 
surrogate from the range 16#DC00# to 16#DFFF# followed by a low 
surrogate from the range 16#D800# to 16#DBFF#.  Technically Ada encodes 
the BMP and will not damage any embedded surrogates, but surrogate pairs 
will not be counted as a single code point.

If anyone wants to use "full" Unicode in Ada, the more appropriate 
approach would be to add support for UTF-32 as Wide_Wide_Character.  But 
in practice, there would be no difference between Ada's treatment of 
Wide_Character as the BMP or an encoding using UTF-16, because of the 
way Unicode has defined the surrogate characters.  Most of the 'missing' 
Unicode support has to do with display rules that apply to printers not 
to strings.

If you want to write a subprogram to determine the length of a 
Wide_Character string in characters, you can't do it without adopting 
specific language rules on what is or is not a character.  For  example 
Hangul (a form of Korean) combines up to three code points into a single 
Hangul character, which represents a syllable.  Or Vietnamese, which can 
have several accent marks on a single (Latin) character.

It is certainly possible to have a (written language dependent) set of 
categorization routines that correctly sorts Wide_Character 
representations into appropriate categories for that language. 
(Character, symbol, numeric digit, etc.)  But I would hesitate to even 
try to come up with a language independent mapping.  For example Pi is a 
mathematical symbol in English, but a capital letter in Greek.
-- 
                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Georg Bauhaus]

Robert I. Eachus <rieachus@comcast.net> wrote:
: If you are that familiar with Unicode...

(Ordered a copy of ISO 10646 1) I was thinking, or dreaming as it now turns
out, of I/O streams where Unicode has been used "properly",
i.e. where PI has been chosen to be a MATHEMATICAL PI, but alas, there
is no such PI among the 29 PIs, even among the 15 MATHEMATICAL bold,
italic, small, and capital PIs. (No small caps PI at least ;-)

: But I would hesitate to even 
: try to come up with a language independent mapping.  For example Pi is a 
: mathematical symbol in English, but a capital letter in Greek.

Ah well, I'm beginning to see the difficulties, thanks. The Babel
effect won't be stopped by Unicode ;-)



Georg

Re: Standard Library Interest?

[Robert I. Eachus]

Georg Bauhaus wrote:

> Ah well, I'm beginning to see the difficulties, thanks. The Babel
> effect won't be stopped by Unicode ;-)

What Unicode and ISO 10646 have finally managed to do is associate 
standard names with characters.  As you point out, there are cases where 
there are many identical glyphs with different names, such as LATIN 
CAPITAL LETTER A, GREEK CAPITAL LETTER A, and CYRILLIC CAPITAL LETTER A. 
  But at least now the Babel effect is well documented.  Although there 
was a lot of resistance to the standard initially for political reasons.

As far as I know, the fall of the Soviet Union has ended the problem the 
Russians had with including some Georgian letters, and the various wars 
and so on in former Yugoslavia may have ended concerns about some 
Macedonian characters on the part of the Greeks.  And then there is 
Quebec.  To you and I, the concept of going to war over characters in an 
  alphabet may seem strange, but there were a couple of times when it 
almost came to that.  In fact, the Greeks refused to recognize the 
Republic of Macedonia unless they changed the way the country's name was 
written in English!

I kid you not, the Macadonian and Greek versions of the name were fine, 
but the Greeks wanted to get the Americans, British and so on to use a 
different name for the country.  I think the political compromise was 
for the UN to refer to Macedonia as "the former Yugoslav Republic of 
Macedonia" in English.  I have no idea of what the French, Spanish, 
Russian, Arabic and Chinese versions are like.  Hmmm.  The United 
Nations site gives:
English: Former Yugoslav Republic of Macedonia; FYR of Macedonia
French:  ex-République yougoslave de Macédoine
Spanish: ex República Yugoslava de Macedonia
Russian: бывшая югославская Республика Македония
Arabic:  جمهورية مقدونيا اليوغوسلافية السابقة
Chinese: 前南斯拉夫的马其顿共和国

The European Union site: http://europa.eu.int/eurodicautom/Controller gives:
English:      Former Yugoslav Republic of Macedonia
German:       Ehemalige jugoslawische Republik Mazedonien
French:       Ex-République yougoslave de Macédoine
Italian:      Ex Repubblica jugoslava di Macedonia
all referencing ISO 3166-1:1997

So it seems pretty consistant.
-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Alexandre E. Kopilovitch]

Robert I. Eachus wrote (about Unicode):

> As far as I know, the fall of the Soviet Union has ended the problem the
> Russians had with including some Georgian letters,

Georgian? This seems strange... well, I could expect any twist from Soviet
representatives in international organizations, but I can't guess any reasons
for this particular one. There could be another problem, which had some
political potential - there were several Russian letters that were used before
1918, and were forcibly excluded from the alphabet by early Communist decree.
These letters weren't used in Soviet times (being qualified as things from
"damned Tsarist past"), and any attempt to give them some official status
could invoke resistance.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Standard Library Interest?

[Robert I. Eachus]

Alexandre E. Kopilovitch wrote:

> Georgian? This seems strange... well, I could expect any twist from Soviet
> representatives in international organizations, but I can't guess any reasons
> for this particular one. There could be another problem, which had some
> political potential - there were several Russian letters that were used before
> 1918, and were forcibly excluded from the alphabet by early Communist decree.
> These letters weren't used in Soviet times (being qualified as things from
> "damned Tsarist past"), and any attempt to give them some official status
> could invoke resistance.

Exactly, and Georgian retained one or more of them, was it D and/or G? 
Of course, the (old USSR) position was that Georgian was not a separate 
language from Russian, and the problem was separating GOST from that old 
dogma. I can't remember, and I just spent way too much time looking 
through JTC1/SC2/WG2 and WG3 documents on-line.  I'd probably have to 
find the early votes on DIS 10646, and I don't even know if they are on 
line.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Dmitry A. Kazakov]

On Thu, 09 Oct 2003 05:39:14 GMT, "Robert I. Eachus"
<rieachus@comcast.net> wrote:

>Alexandre E. Kopilovitch wrote:
>
>> Georgian? This seems strange... well, I could expect any twist from Soviet
>> representatives in international organizations, but I can't guess any reasons
>> for this particular one. There could be another problem, which had some
>> political potential - there were several Russian letters that were used before
>> 1918, and were forcibly excluded from the alphabet by early Communist decree.
>> These letters weren't used in Soviet times (being qualified as things from
>> "damned Tsarist past"), and any attempt to give them some official status
>> could invoke resistance.
>
>Exactly, and Georgian retained one or more of them, was it D and/or G? 
>Of course, the (old USSR) position was that Georgian was not a separate 
>language from Russian, and the problem was separating GOST from that old 
>dogma. I can't remember, and I just spent way too much time looking 
>through JTC1/SC2/WG2 and WG3 documents on-line.  I'd probably have to 
>find the early votes on DIS 10646, and I don't even know if they are on 
>line.

Mmm, Georgian alphabet(s) has nothing to do with Cyrillic or any of
its multiple incarnations. Well, there are remote thoughts that maybe
it is also rooted in the Greek alphabet ... But better see:

http://www.omniglot.com/writing/georgian.htm
http://www.omniglot.com/writing/georgian2.htm

Probably you mean Georgian-Russian?

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Standard Library Interest?

[Martin Krischik]

chris wrote:

> Hi,
> 
> Recent discussions with Marin David Condic /suggest/ the development of
> some kind of standard library independant of the ARM, but hopefully
> endorsed by vendors and the ARG, would be a worthwhile endeavour.
> Assuming such a library could be created and was attractive to the
> community, vendors and the ARG what would people want of such a library?

You are not the first one:

http://sourceforge.net/projects/ascl/
http://ascl.sourceforge.net/

However the ascl seem to be stalled but you could take it over and continue.

As for help: I am with you.

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Standard Library Interest?

[Marin David Condic]

And therein lies the problem. Without some leadership, direction and 
*probably* some financial commitment in some form, these all-volunteer 
efforts tend to stall, drift and produce little. Even if it did, without 
some implicit buy-in from the vendors and ARG, its just another library 
amongst many. Go look at all the stuff sitting on AdaPower and 
elsewhere. Its fine work and great that people out it out there. None of 
it has been adopted and declared to be "The Thing", so its got overlap, 
varying styles, varying quality, varying levels of support and 
enhancement, etc. None of it comes along for the ride with any compiler, 
so nobody can point to it and say "I can count on this being in the 
development environment so all Ada programmers will know about it, use 
it, etc."

It needs ARG and vendor support and direction or its mostly wasted effort.

MDC



Martin Krischik wrote:
> 
> You are not the first one:
> 
> http://sourceforge.net/projects/ascl/
> http://ascl.sourceforge.net/
> 
> However the ascl seem to be stalled but you could take it over and continue.
> 
> As for help: I am with you.
> 
> With Regards
> 
> Martin


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[sk]

Marin David Condic <nobody@noplace.com>:

 > ... Go look at all the stuff sitting on AdaPower and
 > elsewhere. ...

... speaking of which, "The C++ To Ada Translation Page"
hosted as "http://www.mcondic.com/C-Plus-Plus_Programming.html"

Any chance you could remedy the situation ?

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Standard Library Interest?

[Marin David Condic]

Not much chance. My original web host went casters up and I had not 
bothered to find another one, move the pages or even renew the domain 
name. Time being of the essence and other projects being more important, 
this one fell on the wayside.

Ultimately, it is the responsibility of those who put links on their 
site to check them periodically and delete the ones that are no longer 
valid. I don't control AdaPower, so I can't update their links. I don't 
know if anyone is making much effort to frequently update AdaPower 
anyway - we're all busy and these sorts of "hobbies" can be too time 
consuming.

I make no apologies for having a defunct web page. If everyone who had 
one were required to apologize for it, we'd here an endless echo of "I'm 
Sorry!!!" coming out of San Jose. ;-)

MDC


sk wrote:
> Marin David Condic <nobody@noplace.com>:
> 
>  > ... Go look at all the stuff sitting on AdaPower and
>  > elsewhere. ...
> 
> ... speaking of which, "The C++ To Ada Translation Page"
> hosted as "http://www.mcondic.com/C-Plus-Plus_Programming.html"
> 
> Any chance you could remedy the situation ?
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Stephane Richard]

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

Is there a URL to get it at right now?  if so which is it? I can update
AdaPower :-)

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com


"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F806193.8010008@noplace.com...
> Not much chance. My original web host went casters up and I had not
> bothered to find another one, move the pages or even renew the domain
> name. Time being of the essence and other projects being more important,
> this one fell on the wayside.
>
> Ultimately, it is the responsibility of those who put links on their
> site to check them periodically and delete the ones that are no longer
> valid. I don't control AdaPower, so I can't update their links. I don't
> know if anyone is making much effort to frequently update AdaPower
> anyway - we're all busy and these sorts of "hobbies" can be too time
> consuming.
>
> I make no apologies for having a defunct web page. If everyone who had
> one were required to apologize for it, we'd here an endless echo of "I'm
> Sorry!!!" coming out of San Jose. ;-)
>
> MDC
>
>
> sk wrote:
> > Marin David Condic <nobody@noplace.com>:
> >
> >  > ... Go look at all the stuff sitting on AdaPower and
> >  > elsewhere. ...
> >
> > ... speaking of which, "The C++ To Ada Translation Page"
> > hosted as "http://www.mcondic.com/C-Plus-Plus_Programming.html"
> >
> > Any chance you could remedy the situation ?
> >
>
>
> -- 
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/
> My project is: http://www.jsf.mil/NSFrames.htm
>
> Send Replies To: m c o n d i c @ a c m . o r g
>
>      "All reformers, however strict their social conscience,
>       live in houses just as big as they can pay for."
>
>           --Logan Pearsall Smith
> ======================================================================
>

Re: Standard Library Interest?

[Marin David Condic]

You could take the link off of AdaPower. I don't have a web page 
anymore, so there's no URL to go point to.

MDC


Stephane Richard wrote:
> Is there a URL to get it at right now?  if so which is it? I can update
> AdaPower :-)
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Jeffrey Carter]

Marin David Condic wrote:
> Not much chance. My original web host went casters up and I had not 
> bothered to find another one, move the pages or even renew the domain 
> name. Time being of the essence and other projects being more important, 
> this one fell on the wayside.

Do you still have the file(s)? They could be hosted on AdaPower or AdaWorld.

-- 
Jeff Carter
"Go and boil your bottoms."
Monty Python & the Holy Grail
01

Re: Standard Library Interest?

[Stephane Richard]

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

"Jeffrey Carter" <spam@spam.com> wrote in message
news:ao_fb.2673$Qy2.436@newsread4.news.pas.earthlink.net...
> Marin David Condic wrote:
> > Not much chance. My original web host went casters up and I had not
> > bothered to find another one, move the pages or even renew the domain
> > name. Time being of the essence and other projects being more important,
> > this one fell on the wayside.
>
> Do you still have the file(s)? They could be hosted on AdaPower or
AdaWorld.
>
> -- 
> Jeff Carter
> "Go and boil your bottoms."
> Monty Python & the Holy Grail
> 01
>
Like Jeff said, that can work too.  I can host it locally on Ada world, not
a problem at all :-).

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com

Re: Standard Library Interest?

[Marin David Condic]

I don't know. It was a few computers ago. I'll poke around and if I find 
it I might communicate with you about it off line.

MDC



Stephane Richard wrote:
> "Jeffrey Carter" <spam@spam.com> wrote in message
> news:ao_fb.2673$Qy2.436@newsread4.news.pas.earthlink.net...
> 
>>Marin David Condic wrote:
>>
>>>Not much chance. My original web host went casters up and I had not
>>>bothered to find another one, move the pages or even renew the domain
>>>name. Time being of the essence and other projects being more important,
>>>this one fell on the wayside.
>>
>>Do you still have the file(s)? They could be hosted on AdaPower or
> 
> AdaWorld.
> 
>>-- 
>>Jeff Carter
>>"Go and boil your bottoms."
>>Monty Python & the Holy Grail
>>01
>>
> 
> Like Jeff said, that can work too.  I can host it locally on Ada world, not
> a problem at all :-).
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Stephane Richard]

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

alrighty, just let me know when and if you find it :-)....let's hope :-)

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com


"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F816B37.8080807@noplace.com...
> I don't know. It was a few computers ago. I'll poke around and if I find
> it I might communicate with you about it off line.
>
> MDC
>
>
>
> Stephane Richard wrote:
> > "Jeffrey Carter" <spam@spam.com> wrote in message
> > news:ao_fb.2673$Qy2.436@newsread4.news.pas.earthlink.net...
> >
> >>Marin David Condic wrote:
> >>
> >>>Not much chance. My original web host went casters up and I had not
> >>>bothered to find another one, move the pages or even renew the domain
> >>>name. Time being of the essence and other projects being more
important,
> >>>this one fell on the wayside.
> >>
> >>Do you still have the file(s)? They could be hosted on AdaPower or
> >
> > AdaWorld.
> >
> >>-- 
> >>Jeff Carter
> >>"Go and boil your bottoms."
> >>Monty Python & the Holy Grail
> >>01
> >>
> >
> > Like Jeff said, that can work too.  I can host it locally on Ada world,
not
> > a problem at all :-).
> >
>
>
> -- 
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/
> My project is: http://www.jsf.mil/NSFrames.htm
>
> Send Replies To: m c o n d i c @ a c m . o r g
>
>      "All reformers, however strict their social conscience,
>       live in houses just as big as they can pay for."
>
>           --Logan Pearsall Smith
> ======================================================================
>

Re: Standard Library Interest?

[Martin Krischik]

Marin David Condic wrote:

> I don't know. It was a few computers ago. I'll poke around and if I find
> it I might communicate with you about it off line.

An yet another good reason to use SourceForge. SourceForge Downloads are
mirrored all around the world and will not disapear.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Standard Library Interest?

[Martin Krischik]

Marin David Condic wrote:

> Not much chance. My original web host went casters up and I had not
> bothered to find another one, move the pages or even renew the domain
> name. Time being of the essence and other projects being more important,
> this one fell on the wayside.

Another good reason to use sourceforge. They are to big to go away without a
replacement.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Standard Library Interest?

[Marin David Condic]

Yeah, but this wasn't really a "project". It was more a web page with 
advice on how one thing translates to another thing in a different language.

The nutiritional value wasn't that high. Sourceforge would have been 
overkill.

MDC


Martin Krischik wrote:
> Marin David Condic wrote:
> 
> 
>>Not much chance. My original web host went casters up and I had not
>>bothered to find another one, move the pages or even renew the domain
>>name. Time being of the essence and other projects being more important,
>>this one fell on the wayside.
> 
> 
> Another good reason to use sourceforge. They are to big to go away without a
> replacement.
> 
> With Regards
> 
> Martin
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Martin Krischik]

Marin David Condic wrote:

> And therein lies the problem. Without some leadership, direction and
> *probably* some financial commitment in some form, these all-volunteer
> efforts tend to stall, drift and produce little.
[cut more elaboration on this]

You are right in some respect. However I belive that if there where enough
volunteers a critical mass would be reached and the project would not stall
any more.

Take Pyhon as an example:

http://sourceforge.net/softwaremap/trove_list.php?form_cat=178

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Standard Library Interest?

[Marin David Condic]

If it were big enough, it might not stall. But how do you get it "Big 
Enough"?

It needs some kind of backing/support/endorsement by the Powers That Be 
in order to get the momentum it needs to be "big enough".

MDC



Martin Krischik wrote:
> 
> You are right in some respect. However I belive that if there where enough
> volunteers a critical mass would be reached and the project would not stall
> any more.
> 
> Take Pyhon as an example:
> 
> http://sourceforge.net/softwaremap/trove_list.php?form_cat=178
> 
> With Regards
> 
> Martin


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Marin David Condic]

The short form from my response in the other thread...

1) Containers (probably on the way within the standard, but possibly we 
might find some things not covered...)

2) Math/Statistics - Vectors, Matrices, Big number math, Symbolic 
algebra, Stats,....

3) Related to Math: Encryption/Decryption, Compression/Decompression of 
streams.

4) Control Laws operations

5) OS Interfacing (including file formats)

6) Internet communication protocols

7) Database interface - or even a database itself.

8) XML Document Object Model (one that uses tagged records, please.)

9) Desktop apps

10) GUI interface

BTW: You can call me just "Marin" - I use my full name because my first 
name can confuse people sometimes.

MDC


chris wrote:
> Hi,
> 
> Recent discussions with Marin David Condic /suggest/ the development of 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Robert I. Eachus]

Marin David Condic wrote:
> The short form from my response in the other thread...

I'm working on statistics packages right now.  I'll post here when they 
are ready for use and comments.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Marin David Condic]

We worked together to build some stats packages back in another 
ill-fated effort to get a library going. It was under SIGAda 
sponsorship, but it eventually disintegrated. Too many players. Too much 
discussion. No clear objective or mandate from anybody that mattered. 
Not enough concrete work done. (Is it any wonder I lack confidence in 
the ability to get this done as a strictly voluntary effort with no 
"official" sponsorship?)

IIRC, our stats stuff was the only "complete" chunk of code to come out 
of that. Are you basing this latest effort on anything that came from there?

MDC

Robert I. Eachus wrote:
> 
> I'm working on statistics packages right now.  I'll post here when they 
> are ready for use and comments.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Robert I. Eachus]

Marin David Condic wrote:

> IIRC, our stats stuff was the only "complete" chunk of code to come out 
> of that. Are you basing this latest effort on anything that came from 
> there?

Actually, I was reorganizing some code I have to compute CDF, PDF, 
Inverse CDF, and Random Variates for a half-dozen or so distributions so 
it is all consistant.  What do you have?

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Marin David Condic]

If you recall, we had some generic packages that did mean, variance, 
std-dev, skew, curtosis, etc., on arrays of numbers. There were a set of 
them to do stats on different numeric types. I don't think I've got the 
original code, but I have a variant of the code that I built in a 
library of my own. (I think I gave you a copy of that library to look at)

It was a while ago - 1997? - and we had been hoping to get some basic 
stats into what was at the time being called the "Ada Standard Component 
Library". We had traded this code back & forth quite a bit. Maybe you 
have a copy of the original effort?

MDC



Robert I. Eachus wrote:
> 
> 
> Actually, I was reorganizing some code I have to compute CDF, PDF, 
> Inverse CDF, and Random Variates for a half-dozen or so distributions so 
> it is all consistant.  What do you have?
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Robert I. Eachus]

Marin David Condic wrote:
> If you recall, we had some generic packages that did mean, variance, 
> std-dev, skew, curtosis, etc., on arrays of numbers. There were a set of 
> them to do stats on different numeric types. I don't think I've got the 
> original code, but I have a variant of the code that I built in a 
> library of my own. (I think I gave you a copy of that library to look at)
> 
> It was a while ago - 1997? - and we had been hoping to get some basic 
> stats into what was at the time being called the "Ada Standard Component 
> Library". We had traded this code back & forth quite a bit. Maybe you 
> have a copy of the original effort?

I'll look.  It may be on a CD I have of stuff from spectre.  Or it may 
be on a tape I have from my PC at work, that would be a little harder to 
  read.  (I have a tape drive on my current PC, but they are not 
compatible.)

-- 
                                              Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Georg Bauhaus]

Marin David Condic <nobody@noplace.com> wrote:
: 
: 2) Math/Statistics - Vectors, Matrices, Big number math, Symbolic 
: algebra, Stats,....

Have you tried the BLAS binding by Duncan Sands?


Georg

Re: Standard Library Interest?

[Marin David Condic]

I don't like bindings.

For most of the things I'd be likely to do in "real work" that involved 
math, I'd need native Ada source that I could embed. For all the rest of 
the things I'd likely do that might involve math, I'd merely *want* Ada 
source I could embed. I refuse to maintain two environments (One to 
compile some math library and the other to compile the Ada that bound to 
it. Where does that end?)

Also, the fact that libraries exist in no way changes my original 
request: That there be a *standard* Ada library shipped with most 
compilers and outside of the ARM so that it can be easily extended. I 
don't want to go grabbing this piece of code from here, that piece of 
code from there, some other piece from somewhere else, cobble it all 
together, hope it compiles and works, deal with inconsistent interfaces, 
a mixed bag of quality, little/no documentation, mixed bag of support, 
etc. I want *ONE* consistent library that is relatively common with all 
Ada compilers. "One Stop Shopping" ought to be the goal along with "It 
works right out of the box" and "They all look the same."

Or I could just go get Java or C++ and utilize whatever I can get from 
there... :-)

MDC


Georg Bauhaus wrote:
> Marin David Condic <nobody@noplace.com> wrote:
> : 
> : 2) Math/Statistics - Vectors, Matrices, Big number math, Symbolic 
> : algebra, Stats,....
> 
> Have you tried the BLAS binding by Duncan Sands?
> 
> 
> Georg


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Georg Bauhaus]

Marin David Condic <nobody@noplace.com> wrote:
:  I refuse to maintain two environments (One to 
: compile some math library and the other to compile the Ada that bound to 
: it. Where does that end?)

In the real world? After all, afaik, most compilers don't run on
bare hardware, so having to maintain an OS, using non-Ada system
libraries, is not uncommon? As is using and files, and a repository,
and compilation options, and cross compilers, and version changes,
and so on... So using one or more additional libraries of the BLAS
kind might add little more than O(n) complexity, when changes
in your Ada setup do not affect your Fortran setup.

: request: That there be a *standard* Ada library.

In a way, the BLAS is certainly a most venerable "standard", with
reference implementation, published theory and source code, and
with implementations tuned to a number of processors.  Luckily,
Ada does have a standard interface to Fortran.  BLAS, typically
written in Fortran, is well tested and well documented. So, to me,
turning it down in favour of a reinvented all Ada solution smells
a bit of NIH :-)


: "One Stop Shopping" ought to be the goal along with "It 
: works right out of the box" and "They all look the same."

A nice dream, indeed :-) but I think it is more effective to strive
for a solution that can be adapted to real world conditions in a
standard way, such as is the case with Interfaces.*.
Is there more than a limited set of software components
that lend themselves well to standard Ada "adapters"?

: Or I could just go get Java or C++ and utilize whatever I can get from 
: there... :-)

Gossip notwithstanding, the situation in Java is not that different:
What libraries are available, and supported, for Java, _the language_?
Containers, I/O, XML, access control, and what else?
How about C++, the language?

-- Georg

Re: Standard Library Interest?

[Marin David Condic]

Georg Bauhaus wrote:
 >
 > In the real world? After all, afaik, most compilers don't run on bare
 > hardware, so having to maintain an OS, using non-Ada system
 > libraries, is not uncommon? As is using and files, and a repository,
 > and compilation options, and cross compilers, and version changes,
 > and so on... So using one or more additional libraries of the BLAS
 > kind might add little more than O(n) complexity, when changes in your
 > Ada setup do not affect your Fortran setup.
 >

That's not how its done. At least not in my real world. :-) Selecting a
compiler, fitting something into our whole release process and getting
code into an embedded processor is an incredibly non-trivial exercise.
Saying "O.K. here is some Fortran - go get a suitable Fortran compiler
and marry it up with your process & get it into the control..." is a
non-starter. (And then we could talk about C libraries, C++ libraries,
Java libraries, etc., etc., etc. The answer is "No.") We could toss into
the mix any sort of licensing problems if you'd like, but basically it
doesn't impact the "Hell No!" answer I'd already get by any significant
amount.

I can use Ada libraries much more easily - especially if its a
compiler-provided package.


 > : request: That there be a *standard* Ada library.
 >
 > In a way, the BLAS is certainly a most venerable "standard", with

But its not an *Ada* standard, is it? And then we start down that whole
path of "Why bother to use Ada when all the *good* stuff is in some
other language???" Why not just use *that* language and discard Ada?
That is an unbelievably difficult argument to overcome.


 >
 > Gossip notwithstanding, the situation in Java is not that different:
 > What libraries are available, and supported, for Java, _the
 > language_? Containers, I/O, XML, access control, and what else? How
 > about C++, the language?
 >
Saying "Its not part of the language but it comes with the compiler..."
is a distinction that falls on deaf ears. Its a difference that makes no 
difference, so it *is* no difference. If I get it with the compiler,
its indistinguishable from the language. Hence, Ada ought to be ready to 
play that game and provide a really huge library of really cool stuff 
that everyone would just assume was part of Ada. Why fight it? Use it!

MDC

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> Georg Bauhaus wrote:
>  >
>  > In the real world? After all, afaik, most compilers don't run on bare
>  > hardware, so having to maintain an OS, using non-Ada system
>  > libraries, is not uncommon? As is using and files, and a repository,
>  > and compilation options, and cross compilers, and version changes,
>  > and so on... So using one or more additional libraries of the BLAS
>  > kind might add little more than O(n) complexity, when changes in your
>  > Ada setup do not affect your Fortran setup.
> 
> That's not how its done. At least not in my real world. :-) Selecting a
> compiler, fitting something into our whole release process and getting
> code into an embedded processor is an incredibly non-trivial exercise.
> Saying "O.K. here is some Fortran - go get a suitable Fortran compiler
> and marry it up with your process & get it into the control..." is a
> non-starter. (And then we could talk about C libraries, C++ libraries,
> Java libraries, etc., etc., etc. The answer is "No.") We could toss into
> the mix any sort of licensing problems if you'd like, but basically it
> doesn't impact the "Hell No!" answer I'd already get by any significant
> amount.
> 
> I can use Ada libraries much more easily - especially if its a
> compiler-provided package.

And one such way to get it there, is to write/mangle packages to
work with GNAT in a "ready to go" fashion (partly to help ourselves,
partly to help ACT, who are helping us).

If we do this successfully, then ACT's competitors will want to
port the GNAT library to work with their version of the compiler.
In effect, this will simply happen as a natural result of an
initial and ongoing effort.

What will be key here(!), is to license the sources in such a way
that they can do this, without involving lawyers. If the lawyers
have to get involved, then you may never see the light of day
from the vendors on this.

Since this is a difficult area, I think you'll need to segment the
naming space such that this is easy to subdivide. For example,
GPL'd code could fall into a GPL.* and/or GPL2.* hierarching, while
public domain stuff could be under a PD.* hierarchy.

Warren.

Re: Standard Library Interest?

[Martin Dowie]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
news:LyBhb.12984$fP6.401050@news20.bellglobal.com...
> If we do this successfully, then ACT's competitors will want to
> port the GNAT library to work with their version of the compiler.
> In effect, this will simply happen as a natural result of an
> initial and ongoing effort.

I've already started a port for ObjectAda @
https://sourceforge.net/projects/gnat4oa/

I really should update it with the stuff on my laptop! :-)

Re: Standard Library Interest?

[Warren W. Gay VE3WWG]

Martin Dowie wrote:

> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
> news:LyBhb.12984$fP6.401050@news20.bellglobal.com...
> 
>>If we do this successfully, then ACT's competitors will want to
>>port the GNAT library to work with their version of the compiler.
>>In effect, this will simply happen as a natural result of an
>>initial and ongoing effort.
> 
> 
> I've already started a port for ObjectAda @
> https://sourceforge.net/projects/gnat4oa/
> 
> I really should update it with the stuff on my laptop! :-)

Very good ;-)
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Standard Library Interest?

[Martin Dowie]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
news:PVejb.7451$PM2.793831@news20.bellglobal.com...
> > I've already started a port for ObjectAda @
> > https://sourceforge.net/projects/gnat4oa/
> >
> > I really should update it with the stuff on my laptop! :-)
>
> Very good ;-)

Thanks - the name is slightly mislead, as I hope the implementation
will be portable to other compilers, e.g. Janus or the one that Nick
Roberts says he's writing ;-)

I don't have access to anything other than 2 flavours of Windows,
so if anyone wants to join up with a VMS or Linux port that would
be great!

Re: Standard Library Interest?

[Warren W. Gay VE3WWG]

Martin Dowie wrote:

> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
> news:PVejb.7451$PM2.793831@news20.bellglobal.com...
>>>I've already started a port for ObjectAda @
>>>https://sourceforge.net/projects/gnat4oa/
>>>
>>>I really should update it with the stuff on my laptop! :-)
>>Very good ;-)
> 
> Thanks - the name is slightly mislead, as I hope the implementation
> will be portable to other compilers, e.g. Janus or the one that Nick
> Roberts says he's writing ;-)
> 
> I don't have access to anything other than 2 flavours of Windows,
> so if anyone wants to join up with a VMS or Linux port that would
> be great!

Even if I had access to a different Ada compiler flavour under
Linux, I currently have more projects than I have time to handle
at the moment.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Standard Library Interest?

[Martin Dowie]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F803278.1020507@noplace.com...
> The short form from my response in the other thread...
>
> 1) Containers (probably on the way within the standard, but possibly we
> might find some things not covered...)

AI-302 http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-10302.TXT


> 2) Math/Statistics - Vectors, Matrices, Big number math, Symbolic
> algebra, Stats,....

AI-294 http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00296.TXT
and http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00346.TXT


> 3) Related to Math: Encryption/Decryption, Compression/Decompression of
> streams.
>
> 4) Control Laws operations

Nothing yet!

> 5) OS Interfacing (including file formats)

AI-248 - http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00248.TXT


> 6) Internet communication protocols
>
> 7) Database interface - or even a database itself.
>
> 8) XML Document Object Model (one that uses tagged records, please.)

See APIWG http://www.acm.org/sigada/wg/apiwg/


> 9) Desktop apps
>
> 10) GUI interface

See <insert favourite GUI API here> - can't see these in any version of Ada
RM ever though

Re: Standard Library Interest?

[Marin David Condic]

I appreciate that there are plans to include stuff in the standard. Are 
you going to provide a means by which it can be extended on a regular 
basis? I can keep coming up with good ideas. I might even be willing to 
help make them real. Is there a way to get them into most 
implementations (or even my *own* implementation? By which I mean I can 
extend the library with my own personal stuff) without waiting 10 years? 
Are they children of the package Ada - and hence I'm not allowed to 
modify or extend them in any way? (Or is that rule changing?) Is it 
going to be a "reference implementation" that is released regularly or 
is it "every vendor for himself?" Will it be in source code so I can 
modify it if I don't like what it does?

There's more to it than simply saying "we're adding some stuff to the 
ARM..." I still think it is the entirely *wrong* answer to cast this 
stuff into the concrete of the ARM - at least on its first pass through. 
Let the ARM pick it up in the next revision if it proves stable. But get 
a process set up to have an extensible library that can react quickly 
outside the ARM.

MDC


Martin Dowie wrote:
> "Marin David Condic" <nobody@noplace.com> wrote in message
> news:3F803278.1020507@noplace.com...
> 
>>The short form from my response in the other thread...
>>
>>1) Containers (probably on the way within the standard, but possibly we
>>might find some things not covered...)
> 
> 
> AI-302 http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-10302.TXT
> 
> 
> 
>>2) Math/Statistics - Vectors, Matrices, Big number math, Symbolic
>>algebra, Stats,....
> 
> 
> AI-294 http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00296.TXT
> and http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00346.TXT
> 
> 
> 
>>3) Related to Math: Encryption/Decryption, Compression/Decompression of
>>streams.
>>
>>4) Control Laws operations
> 
> 
> Nothing yet!
> 
> 
>>5) OS Interfacing (including file formats)
> 
> 
> AI-248 - http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00248.TXT
> 
> 
> 
>>6) Internet communication protocols
>>
>>7) Database interface - or even a database itself.
>>
>>8) XML Document Object Model (one that uses tagged records, please.)
> 
> 
> See APIWG http://www.acm.org/sigada/wg/apiwg/
> 
> 
> 
>>9) Desktop apps
>>
>>10) GUI interface
> 
> 
> See <insert favourite GUI API here> - can't see these in any version of Ada
> RM ever though
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Martin Dowie]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F816F2F.1010407@noplace.com...
> I appreciate that there are plans to include stuff in the standard. Are
> you going to provide a means by which it can be extended on a regular
> basis? I can keep coming up with good ideas. I might even be willing to
> help make them real. Is there a way to get them into most
> implementations (or even my *own* implementation? By which I mean I can
> extend the library with my own personal stuff) without waiting 10 years?

I guess they will only form part of each RM every 10 years or so, but
that doesn't mean the APIWG could provide some sort of "official
status" to an API at any time in between.

The problem with API developments is (apparently) getting them
defined in RM-eze.



> Are they children of the package Ada - and hence I'm not allowed to
> modify or extend them in any way? (Or is that rule changing?) Is it
> going to be a "reference implementation" that is released regularly or
> is it "every vendor for himself?" Will it be in source code so I can
> modify it if I don't like what it does?

I think the rule has always been you can't add children to package
Ada *in normal mode* but you can add grandchildren to existing
packages, seemingly at will! At least in GNAT & ObjectAda it
is easy. I make use of this by adding non-standard but portable (for
me :-) extensions to say Ada.Calendar to add I/O.

Again, for packages that don't require compiler 'magic', it would be
nice for the APIWG to maintain a single reference implementation.

I've got a Win32 ref-imp for AI-248 @ my web site and I'm doing
a vanilla Ada one for AI-296.

But note that the status of these 2 are very different. 248 is about one
step away from being formally adopted to ISO approval but 296 is
still a "work item" - neither may yet get in!


> There's more to it than simply saying "we're adding some stuff to the
> ARM..." I still think it is the entirely *wrong* answer to cast this
> stuff into the concrete of the ARM - at least on its first pass through.
> Let the ARM pick it up in the next revision if it proves stable. But get
> a process set up to have an extensible library that can react quickly
> outside the ARM.

Again, I'd like the APIWG to do this and we should be all signing up
for this asap and being *active*.

Re: Standard Library Interest?

[Marin David Condic]

But therein lies two problems: One is that for something to meet 
"acceptable" criteria for the ARM, it has to have behavior detailed in 
painstaking language that makes it verifiable. (A reference 
implementation does not) The other is that the APIWG contains in its 
name "API". They'd only be spelling out an "Interface" (in painstaking 
detail) and its "Every Man For Himself" - which creates a barrier to 
getting it done.

I still think a "Conventional" library that might migrate parts to the 
ARM eventually would be a good thing. A reference implementation 
provides near instant access for the vendor with little effort to 
support it. If they've got to build a thing from bottom-dead-center and 
test it against a validation suite, it won't get done. At least not to 
the extent it ought to be done.

Some middle ground must exist....

MDC



Martin Dowie wrote:
> 
> I guess they will only form part of each RM every 10 years or so, but
> that doesn't mean the APIWG could provide some sort of "official
> status" to an API at any time in between.
> 
> The problem with API developments is (apparently) getting them
> defined in RM-eze.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[chris]

Martin Dowie wrote:
> "Marin David Condic" <nobody@noplace.com> wrote in message

>>1) Containers (probably on the way within the standard, but possibly we
>>might find some things not covered...)

>>2) Math/Statistics - Vectors, Matrices, Big number math, Symbolic
>>algebra, Stats,....

>>5) OS Interfacing (including file formats)

So is this a list of what is likely to be in the standard then?  IIRC 
there's an implementation *relating to* the OS interfacing component 
somewhere, right?  AdaDirectories or something?


>>7) Database interface - or even a database itself.

And this might make it?



>>6) Internet communication protocols

>>8) XML Document Object Model (one that uses tagged records, please.)

> See APIWG http://www.acm.org/sigada/wg/apiwg/

These don't fit because they're rapidly evolving, though we will get a 
sockets api?

Re: Standard Library Interest?

[sk]

chris <spamoff.danx@ntlworld.com>:

 > IIRC there's an implementation *relating to* the OS
 > interfacing component somewhere, right?  AdaDirectories
 > or something?

More than just Ada.Directories, there are the POSIX
bindings !

I am not sure the current state of the POSIX bindings,
nor have I looked at them, but that is where I would
look if I wanted a complete (or as near as) interface
to the OS.


-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Standard Library Interest?

[chris]

sk wrote:
> chris <spamoff.danx@ntlworld.com>:
> 
>  > IIRC there's an implementation *relating to* the OS
>  > interfacing component somewhere, right?  AdaDirectories
>  > or something?
> 
> More than just Ada.Directories, there are the POSIX
> bindings !

I know about them but don't use them...  Out of interest, what does 
posix give a programmer besides directory control that Ada doesn't 
provide out of the box?

My understanding of posix is that it was defined to provide an api the 
lowest common functionality common to the two big Unices of the day, but 
other than that I haven't explored it in detail.

Re: Standard Library Interest?

[sk]

chris <spamoff.danx@ntlworld.com>:
 > ... snip ...

POSIX - Portable Operating System Interface
(http://www.pasc.org/#POSIX)

--

Sounds good, but like all these "standards" (IEEE,ISO etc)
and organizations, mind-numbingly expensive for casual
use.

http://standards.ieee.org/catalog/olis/licenses/licenses.html

--

Related to Ada ...

http://archive.adaic.com/tools/bindings/bindings95/html/section4.html

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Standard Library Interest?

[Dave Thompson]

On Mon, 06 Oct 2003 16:13:47 -0500, sk <noname@myob.com> wrote:

> chris <spamoff.danx@ntlworld.com>:
>  > ... snip ...
> 
> POSIX - Portable Operating System Interface
> (http://www.pasc.org/#POSIX)
> 
> --
> 
> Sounds good, but like all these "standards" (IEEE,ISO etc)
> and organizations, mind-numbingly expensive for casual
> use.
> 
> http://standards.ieee.org/catalog/olis/licenses/licenses.html
> 
No longer. As of 2002, ISO 9945 is converged with SUS v3, and
available free (with registration) at http://www.unix.org/version3 .
More info and links at http://www.opengroup.org/austin/ .

- David.Thompson1 at worldnet.att.net

Re: Standard Library Interest?

[sk]

Dave Thompson <david.thompson1@worldnet.att.net>:
 > No longer. As of 2002, ISO 9945 is converged with SUS v3, and
 > available free (with registration) at http://www.unix.org/version3 .
 > More info and links at http://www.opengroup.org/austin/ .

Ah-ha ! Thanks.

-- 
-------------------------------------------------
-- Merge vertically for real address
--
--     s n p @ t . o
--      k i e k c c m
-------------------------------------------------

Re: Standard Library Interest?

[Mark Lorenzen]

chris <spamoff.danx@ntlworld.com> writes:

> sk wrote:
>> chris <spamoff.danx@ntlworld.com>:
>>  > IIRC there's an implementation *relating to* the OS
>>  > interfacing component somewhere, right?  AdaDirectories
>>  > or something?
>> More than just Ada.Directories, there are the POSIX
>> bindings !
>
> I know about them but don't use them...  Out of interest, what does
> posix give a programmer besides directory control that Ada doesn't
> provide out of the box?
>

I wonder if I am reading your question correct... There is *a lot*
more to POSIX than what is supported out-of-the-box in Ada!

Think of all the typical "things" you associate with a Unix system:
Processes, signals, sockets, message queues, shared memory, user
accounts, terminals, file locking, memory locking, memory mapping,
file permissions, event handling, process group leader, controlling
terminal, job control, session control etc. The Ada standard does (of
course) not define any means of handling these "things".

> My understanding of posix is that it was defined to provide an api the
> lowest common functionality common to the two big Unices of the day,
> but other than that I haven't explored it in detail.

I would not say the "lowest common functionality". It is a pretty
large part of The Open Group's definition of Unix.

If you want to do some serious development for the Unix platform,
then POSIX is an absolute necessity.

- Mark

Re: Standard Library Interest?

[Robert I. Eachus]

Martin Dowie wrote:

>>2) Math/Statistics - Vectors, Matrices, Big number math, Symbolic
>>algebra, Stats,....
...
> and http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00346.TXT

Look at the somewhat humerous (at least I thought so) discussion we had 
on quintic roots with real coefficients to see just how hard this 
standards stuff is.

The note I posted on BLAS is also worth reading.  A good binding to BLAS 
as part of the standard would mean that users shouldn't have to find a 
Fortran compiler, run ATLAS on their target hardware, and create the 
BLAS libraries in Fortran.  Just install the "right" version of the math 
library for your target hardware and go.  (Or perhaps use library pragmas.)

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Georg Bauhaus]

Robert I. Eachus <rieachus@comcast.net> wrote:
: 
: The note I posted on BLAS is also worth reading.  A good binding to BLAS 
: as part of the standard would mean that users shouldn't have to find a 
: Fortran compiler, run ATLAS on their target hardware, and create the 
: BLAS libraries in Fortran.  Just install the "right" version of the math 
: library for your target hardware and go.  (Or perhaps use library pragmas.)

How about this one:
http://topo.math.u-psud.fr/~sands/Programs/BLAS/index.html

Re: Standard Library Interest?

[Robert I. Eachus]

Georg Bauhaus wrote:
> Robert I. Eachus <rieachus@comcast.net> wrote:
> : 
> : The note I posted on BLAS is also worth reading.  A good binding to BLAS 
> : as part of the standard would mean that users shouldn't have to find a 
> : Fortran compiler, run ATLAS on their target hardware, and create the 
> : BLAS libraries in Fortran.  Just install the "right" version of the math 
> : library for your target hardware and go.  (Or perhaps use library pragmas.)
> 
> How about this one:
> http://topo.math.u-psud.fr/~sands/Programs/BLAS/index.html

It is a start, but only a start.  It is a thin binding to an assumed 
Fortran implementation of the BLAS.  I could get into a long argument 
about whether or not to use "native" Ada arrays. (Since BLAS routines 
often have a transposition parameter, you can map a normal Ada array as 
a transposed Fortran array and vice-versa.  But this might confuse 
users.)  But much more important is to go from "here is a BLAS binding" 
to "Ada compilers provide the BLAS libraries," and users don't have to 
compile the Fortran, or worry about finding (or creating) and binding in 
a BLAS implementation.

-- 
                                      Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Marin David Condic]

Absolutely! Yeah Verrily! Amen!

If Ada doesn't provide it then why use Ada? Saying "Here's a binding..." 
is just saying "Me too!!!" without really providing a one-stop shopping 
experience to the customer or offering anything more than what the other 
guy has. It means "Go get yourself a Fortran compiler as well as an Ada 
compiler..." and the end user starts wondering why bother with Ada when 
it is really Fortran (or C or C++ or Java) that is giving him all the 
*real* functionality he needs. It means you're always one step behind 
the guy who you're binding to - he keeps offering something new and you 
have to lag behind adding the binding after the native-language speakers 
  have already got it.

If Ada wants some kind of math library and "BLAS" is the math library to 
have, then Ada ought to implement BLAS - and maybe even take it in new 
directions providing *more* value to the end user. (I believe the term 
is "Embrace and Extend" ;-) Otherwise the BLAS afficianados don't have 
much reason to select Ada as their language of implementation.

MDC


Robert I. Eachus wrote:
> users.)  But much more important is to go from "here is a BLAS binding" 
> to "Ada compilers provide the BLAS libraries," and users don't have to 
> compile the Fortran, or worry about finding (or creating) and binding in 
> a BLAS implementation.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Robert I. Eachus]

Marin David Condic wrote:
> Absolutely! Yeah Verrily! Amen!

> If Ada wants some kind of math library and "BLAS" is the math library to 
> have, then Ada ought to implement BLAS - and maybe even take it in new 
> directions providing *more* value to the end user. (I believe the term 
> is "Embrace and Extend" ;-) Otherwise the BLAS afficianados don't have 
> much reason to select Ada as their language of implementation.

No, I don't want anyone to rewrite BLAS in Ada.  There should be a 
"thick" binding on top of the BLAS libraries so that the users never 
have to deal with the idiosyncracies of Fortran.  But converting the 
libraries to Adatran wouldn't accomplish anything other than to waste 
money.  As long as the vendors provide a good BLAS implementation 
(probably built by ATLAS) or in the case of GNAT, possibly tell you how 
to build a tuned version for your system as a part of building GNAT, 
then the user need never to know how to invoke the Fortran compiler. 
(And the Ada binding will probably include any necessary linker directives.)

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Preben Randhol]

On 2003-10-05, Marin David Condic <nobody@noplace.com> wrote:
> The short form from my response in the other thread...

The current state is that we have:
(I'm just putting in what I can remember so others can fill in the
blanks and add alternatives)

> 1) Containers (probably on the way within the standard, but possibly we 
> might find some things not covered...)

Charles
SAL

> 2) Math/Statistics - Vectors, Matrices, Big number math, Symbolic 
> algebra, Stats,....
>
> 3) Related to Math: Encryption/Decryption, Compression/Decompression of 
> streams.

Compression/Decomression there is a zlib binding and zip if I remember
correctly. However if they work on streams I don't know. Files at least.

> 4) Control Laws operations

What is this?

> 5) OS Interfacing (including file formats)

and config files.

> 6) Internet communication protocols

AWS
Libra

> 7) Database interface - or even a database itself.

Gnade
APQ

> 8) XML Document Object Model (one that uses tagged records, please.)

AdaXML (yes I know)

> 9) Desktop apps

What do you mean with desktop apps in a standard library? Anyway I'm
going to finish my work on a template for making GUIs (GtkAda) for
applications later this year.

> 10) GUI interface

GtkAda

11) Multimedia - sound and images

However, I think the way to go is not to try to make a standard library
containing all these things at once. I think the most impostant areas to
cover are the Container, Math, OS interfacing and possibly some of the
internet communication protocols.

Another important thing is that the code needs to be available so others
can take over if needed.

Preben

Re: Standard Library Interest?

[Marin David Condic]

This is really important: I absolutely *never* said there weren't 
package out there that can do some/most/all of these things. What I said 
was that they are NOT "STANDARD" and a bunch of other undesirable 
characteristics. If there was a willingness to adopt some of these 
things and declare thenm to be "The Ada Thing", I wouldn't oppose that. 
I just think we're better off making sure we had a consistent, well 
documented, common, standard library.

MDC

Preben Randhol wrote:
> On 2003-10-05, Marin David Condic <nobody@noplace.com> wrote:
> 
>>The short form from my response in the other thread...
> 
> 
> The current state is that we have:
> (I'm just putting in what I can remember so others can fill in the
> blanks and add alternatives)
> 
> 
>>1) Containers (probably on the way within the standard, but possibly we 
>>might find some things not covered...)
> 
> 
> Charles
> SAL
> 
> 
>>2) Math/Statistics - Vectors, Matrices, Big number math, Symbolic 
>>algebra, Stats,....
>>
>>3) Related to Math: Encryption/Decryption, Compression/Decompression of 
>>streams.
> 
> 
> Compression/Decomression there is a zlib binding and zip if I remember
> correctly. However if they work on streams I don't know. Files at least.
> 
> 
>>4) Control Laws operations
> 
> 
> What is this?
> 
> 
>>5) OS Interfacing (including file formats)
> 
> 
> and config files.
> 
> 
>>6) Internet communication protocols
> 
> 
> AWS
> Libra
> 
> 
>>7) Database interface - or even a database itself.
> 
> 
> Gnade
> APQ
> 
> 
>>8) XML Document Object Model (one that uses tagged records, please.)
> 
> 
> AdaXML (yes I know)
> 
> 
>>9) Desktop apps
> 
> 
> What do you mean with desktop apps in a standard library? Anyway I'm
> going to finish my work on a template for making GUIs (GtkAda) for
> applications later this year.
> 
> 
>>10) GUI interface
> 
> 
> GtkAda
> 
> 11) Multimedia - sound and images
> 
> However, I think the way to go is not to try to make a standard library
> containing all these things at once. I think the most impostant areas to
> cover are the Container, Math, OS interfacing and possibly some of the
> internet communication protocols.
> 
> Another important thing is that the code needs to be available so others
> can take over if needed.
> 
> Preben


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Preben Randhol]

On 2003-10-06, Marin David Condic <nobody@noplace.com> wrote:
> This is really important: I absolutely *never* said there weren't 
> package out there that can do some/most/all of these things. What I said 
> was that they are NOT "STANDARD" and a bunch of other undesirable 
> characteristics. If there was a willingness to adopt some of these 
> things and declare thenm to be "The Ada Thing", I wouldn't oppose that. 
> I just think we're better off making sure we had a consistent, well 
> documented, common, standard library.

Sure, but I think that these are at least starting points. I don't see
the reason for rewriting a lot of software just for the exercise if one
can adopt already existing software and mould it into what one wants.

At any rate the GNAT stuff is more or less standard for me.

Preben

Re: Standard Library Interest?

[Marin David Condic]

Great. I agree that existing packages might make a good place to start 
looking at things that should be there. It might even make a great place 
to start with a reference implementation. Two things: I'd like a 
standard, consistent, built-on-common-substrate, orthogonal library and 
grabbing a dozen different things off the Internet probably isn't going 
to do that. I'd also like to see you get some kind of acceptance by the 
folks that matter that they are going to use some stuff currently 
available off the Internet. Chances are they won't buy it.

I'm not against existing software. I just think its hard to pull 
existing stuff together into a consistent library without significant 
rework and history tends to indicate that it won't get accepted. Solve 
those problems and you've got something there.

MDC



Preben Randhol wrote:
> 
> 
> Sure, but I think that these are at least starting points. I don't see
> the reason for rewriting a lot of software just for the exercise if one
> can adopt already existing software and mould it into what one wants.
> 
> At any rate the GNAT stuff is more or less standard for me.
> 
> Preben


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Preben Randhol]

On 2003-10-06, Marin David Condic <nobody@noplace.com> wrote:
> Great. I agree that existing packages might make a good place to start 
> looking at things that should be there. It might even make a great place 
> to start with a reference implementation. Two things: I'd like a 
> standard, consistent, built-on-common-substrate, orthogonal library and 
> grabbing a dozen different things off the Internet probably isn't going 
> to do that. I'd also like to see you get some kind of acceptance by the 
> folks that matter that they are going to use some stuff currently 
> available off the Internet. Chances are they won't buy it.

Well it depends whoes your audience. Buy?

Preben

Re: Standard Library Interest?

[Marin David Condic]

That depends on who it is that declares "This Is The Conventional Ada 
Library". In my mind, that's got to include the endorsement of the ARG 
and the vendors in order for it to have any meaning. Pull a bunch of 
stuff off the Internet, put it on a floppy, send it to the ARG and say 
"This is what I think should be the Conventional Ada Library." My guess 
would be that the answer would end up being "No". There would be lots of 
reasons to say "No" and I understand most of them. It would be my answer 
too if I were in their position.

That's my guess as to what the outcome would be. Why? Simple: If they 
wanted there to be a Conventional Ada Library made up of random bits of 
code sucked down off of the Internet, they could have done that by now. 
The vendors have had the Booch Components and a bunch of other container 
libraries available for years. At any given moment, they could have 
plopped it down on their distribution disks and said "This Is The 
Thing." Since it hasn't happened, I'm betting it won't.

MDC


Preben Randhol wrote:
> 
> 
> Well it depends whoes your audience. Buy?
> 
> Preben


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[tmoran]

>>>2) Math/Statistics - Vectors, Matrices, Big number math, Symbolic
>>>algebra, Stats,....
  Ten years or so ago my compiler vendor (RR Software) sent a library
and (paper) manual "NAG Small Computer Systems Ada Library".  It was
pretty basic, but did other vendors also deliver it?  Who paid for
it and why wasn't it expanded?

>>>5) OS Interfacing (including file formats)
>>>6) Internet communication protocols
>>>10) GUI interface
>> 11) Multimedia - sound and images
  Claw has several of these, and several have been posted to
www.adapower.com, including non-Claw versions of SMTP, FTP, and HTTP.

>This is really important: I absolutely *never* said there weren't
>package out there that can do some/most/all of these things. What I said
>was that they are NOT "STANDARD" and a bunch of other undesirable
>characteristics. If there was a willingness to adopt some of these
  So this is not a programming problem, it's a political/economic problem
of getting someone to advertise (ie, send out with copies of their
compiler), ship, and support a common library.  The question then becomes
"what's in it for them".  I think there may be some confusion in this
thread on the point of which problem you are trying to solve.

Re: Standard Library Interest?

[Marin David Condic]

It always has been and always will be a "Political Problem". We've known 
for aeons how to make a square root routine. Getting one that could be 
accepted as "Standard" was a political problem. Just because its 
"political" doesn't make it any less a "problem", so we need to find the 
"political" will to do it. From there, the technology is relatively simple.

MDC



tmoran@acm.org wrote:
> 
>   So this is not a programming problem, it's a political/economic problem
> of getting someone to advertise (ie, send out with copies of their
> compiler), ship, and support a common library.  The question then becomes
> "what's in it for them".  I think there may be some confusion in this
> thread on the point of which problem you are trying to solve.


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Robert I. Eachus]

Marin David Condic wrote:
> It always has been and always will be a "Political Problem". We've known 
> for aeons how to make a square root routine. Getting one that could be 
> accepted as "Standard" was a political problem. Just because its 
> "political" doesn't make it any less a "problem", so we need to find the 
> "political" will to do it. From there, the technology is relatively simple.

I don't want to harp on this, but WHO has known how to make a square 
root routine for aeons?  In the early sixties it was vital to NASA to do 
  square roots fast and accurately for the Apollo project.  I worked on 
this, and the eventual result was to modify four IBM 7094s to include a 
36-bit to 36-bit integer square-root function.  I won't go into a long 
discussion of WHY a 36-bit to 36-bit square-root with the implicit 
binary point to the right of the most significant digit was what was 
needed.  Just the thought of explaining to ONE more person why that was 
what was needed, and that it was a very simple modification of the IBM 
7094 to add it makes me want to scream.

In the mid-eighties when I was at Stratus, I showed the same thing to 
the hardware engineers responsible for the math co-processor software in 
the Stratus 200 and 600 series.  They agreed it would significantly 
improve the speed of their square root routines, but AFAIK, it was never 
implemented.  (This was when we were about to introduce the 2000 series 
which used Motorola 68881 math co-processors.)  Later, I implemented 
this square-root method in software for Sun SPARCs, since it was so much 
faster than Sun's math routines for most SPARC chips.  (Most UltraSPARC 
chips now seem to do the square-root correctly.)

So yes, I know how to use the Newton-Rhapson method to find square 
roots, and I also know how to implement a square-root in microcode so 
that it is faster than the hardware divide.  But the idea that this was 
well or widely known in 1983 is totally false.  There were CPUs in the 
nineties that still did it wrong.  (Of course, in the nineties Intel 
managed to get divide wrong as well.  Sigh!)  Most implementations of 
sine and cosine were pretty good, but other trig functions and all 
inverses were spotty.  Logs again were spotty both natural and common 
logs, and most implementations of exp were a horror.  Brian Wichmann did 
a lot of work on that, including finding cases where many compilers 
computed X**4 wrong, even when X was integer and the result was 
therefore exact.  (The IBM 360 series and follow-ons were infamous for 
printing the sum of 2.0 and 2.0 as 3.9999999999999...  But that was 
actually a problem in the Fortran print routines, not in the internal 
representation.)

-- 
                                        Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Ole-Hjalmar Kristensen]

OK, I'll bite. What's wrong with Cody-Waite? 

(W.J. Cody and W. Waite, Software manual for the elementary functions, 
Prentice Hall, 1980).

>>>>> "RIE" == Robert I Eachus <rieachus@comcast.net> writes:

    RIE> Marin David Condic wrote:
    >> It always has  been and always will be  a "Political Problem". We've
    >> known for aeons how to make  a square root routine. Getting one that
    >> could  be  accepted as  "Standard"  was  a  political problem.  Just
    >> because its "political" doesn't make  it any less a "problem", so we
    >> need  to  find  the "political"  will  to  do  it. From  there,  the
    >> technology is relatively simple.


    RIE> I don't want to  harp on this, but WHO has known  how to make a square
    RIE> root routine for aeons? In the  early sixties it was vital to NASA to
    RIE> do square roots fast and  accurately for the Apollo project. I worked
    RIE> on  this, and  the eventual  result was  to modify  four IBM  7094s to
    RIE> include a 36-bit  to 36-bit integer square-root function.  I won't go
    RIE> into a long discussion of WHY  a 36-bit to 36-bit square-root with the
    RIE> implicit binary point  to the right of the  most significant digit was
    RIE> what was  needed. Just the thought  of explaining to  ONE more person
    RIE> why  that  was  what  was  needed,  and that  it  was  a  very  simple
    RIE> modification of the IBM 7094 to add it makes me want to scream.

<snip>

    RIE> So yes,  I know how  to use the  Newton-Rhapson method to  find square
    RIE> roots, and I also know how  to implement a square-root in microcode so
    RIE> that it  is faster than the  hardware divide. But the  idea that this
    RIE> was well or widely known in 1983 is totally false.  There were CPUs in
    RIE> the nineties  that still  did it wrong.  (Of course, in  the nineties

<snip>


-- 
Sun Microsystems cannot have these opinions even if they wanted to.

Re: Standard Library Interest?

[Robert I. Eachus]

Ole-Hjalmar Kristensen wrote:
> OK, I'll bite. What's wrong with Cody-Waite? 

Nothing, they were both members of NumWG/NRG that developed the Ada 
numerics standards.

> (W.J. Cody and W. Waite, Software manual for the elementary functions, 
> Prentice Hall, 1980).

Oh, that Cody and Waite.  Same people, but I think you have to realize 
that the Prentice Hall book was at best a working draft for the over 10 
years of work that ended up in the DIS.  And remember the timing.  The 
Cody and Waite book was published about the same time as Mil Std 1815 
(Ada 80) which was the basis for ANSI/Mil-Std 1815A (Ada 83).  Adding 
Cody and Waite to the draft standard, as I said was not done, because 
all the Bills involved Cody, Waite, and Wittaker, (and Bob Mathis) knew 
how much more work was needed.

See if you can find a copy of "Proposed Standard for a Generic Package 
of Elementary Functions for Ada," Ada Letters - A Special Edition from 
SIGAda, Volume XI, Number 7, Fall 1991.  (There are actually four draft 
NRG standards in there, including the complex versions, with complete 
generic implementations.  There are a couple of typos, and I think one 
of the names was changed in the final standard, but the code is all good.)

If you can find it, burn your copy of Cody and Waite.  Otherwise it is 
better than nothing.  (Actually I prefer Abramowitz, M., and Stegun, I. 
A., Eds. Handbook of mathematical functions with formulas, graphs, and 
mathematical tables. Dover Publications Inc., New York, 1972 for 
completeness, and the Ada Letters Special Edition for the reference 
implementations of the functions that are provided.)

Seriously, if I sat down and looked through the original Cody and Waite 
book, I don't think I would find a single function that wasn't 
significantly improved in both performance and accuracy, usually several 
times over the next ten years.

As for the square root in particular, there are two basic algorithms. 
One is to use the N-R approach which doubles accuracy at each step with 
a good starting guess.  But in requires a divide at each iteration, and, 
on modern CPUs, divides are slow. The algorithm you may have learned in 
school (in decimal) works very nicely in binary with only additions, 
subtractions, compares and shifts.  Since it uses two-bits at each step 
in binary, you can often write a machine code version that is faster 
than hardware division.  But don't bother, except for very special uses, 
such as arbitrary precision arithmetic.  The computer you use, unless it 
is ancient, should have this algorithm in microcode as part of the IEEE 
floating point functions.  If I thought it was worth writing the code 
today, I'd show you the tricks that speed up the code.  (Basically you 
want to do compare, adjust, then subtract.)

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Dmitry A. Kazakov]

On Wed, 08 Oct 2003 21:46:52 GMT, "Robert I. Eachus"
<rieachus@comcast.net> wrote:

>Marin David Condic wrote:
>> It always has been and always will be a "Political Problem". We've known 
>> for aeons how to make a square root routine. Getting one that could be 
>> accepted as "Standard" was a political problem. Just because its 
>> "political" doesn't make it any less a "problem", so we need to find the 
>> "political" will to do it. From there, the technology is relatively simple.
>
>I don't want to harp on this, but WHO has known how to make a square 
>root routine for aeons?  In the early sixties it was vital to NASA to do 
>  square roots fast and accurately for the Apollo project.  I worked on 
>this, and the eventual result was to modify four IBM 7094s to include a 
>36-bit to 36-bit integer square-root function.  I won't go into a long 
>discussion of WHY a 36-bit to 36-bit square-root with the implicit 
>binary point to the right of the most significant digit was what was 
>needed.  Just the thought of explaining to ONE more person why that was 
>what was needed, and that it was a very simple modification of the IBM 
>7094 to add it makes me want to scream.
>
>In the mid-eighties when I was at Stratus, I showed the same thing to 
>the hardware engineers responsible for the math co-processor software in 
>the Stratus 200 and 600 series.  They agreed it would significantly 
>improve the speed of their square root routines, but AFAIK, it was never 
>implemented.  (This was when we were about to introduce the 2000 series 
>which used Motorola 68881 math co-processors.)  Later, I implemented 
>this square-root method in software for Sun SPARCs, since it was so much 
>faster than Sun's math routines for most SPARC chips.  (Most UltraSPARC 
>chips now seem to do the square-root correctly.)
>
>So yes, I know how to use the Newton-Rhapson method to find square 
>roots, and I also know how to implement a square-root in microcode so 
>that it is faster than the hardware divide.  But the idea that this was 
>well or widely known in 1983 is totally false.  There were CPUs in the 
>nineties that still did it wrong.  (Of course, in the nineties Intel 
>managed to get divide wrong as well.  Sigh!)  Most implementations of 
>sine and cosine were pretty good, but other trig functions and all 
>inverses were spotty.  Logs again were spotty both natural and common 
>logs, and most implementations of exp were a horror.  Brian Wichmann did 
>a lot of work on that, including finding cases where many compilers 
>computed X**4 wrong, even when X was integer and the result was 
>therefore exact.  (The IBM 360 series and follow-ons were infamous for 
>printing the sum of 2.0 and 2.0 as 3.9999999999999...  But that was 
>actually a problem in the Fortran print routines, not in the internal 
>representation.)

Hear! Hear!

I remember, an excellent book on numerical methods (Forsyte's, I
believe) in early 80s, which started with a square root equation and
showed how difficult in fact to solve such an "elementary" thing
properly. That time there was no numerical library which had a decent
subprogram for that.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Standard Library Interest?

[Marin David Condic]

Now you're talking about having a *Good* square root routine. Your 
"political position" is that before we can define "Sqrt (X)" we have to 
know how to make a *good* one. My "political position" is that Fortran 
had a "Sqrt (X)" that was "good enough" for me to get my work done and 
that while someone is off defining a better way of computing the result, 
my code could still be making reference to an interface that looked like 
"Sqrt (X)" and when the better one comes along, I don't have to change 
my code because they decided to call it "Square_Root (X)" instead.

So you see, that there are *always* "Political Problems" here - finding 
a reasonable compromise between two or more people's desires and 
objectives. You wanted mathematical certainty. I wanted interface 
stability. Someone else probably had other objectives that might or 
might not have been met.

We see the same thing here when discussing a standard library. Some 
folks want it to be in the ARM. Some want it to be informal. Some want 
it to be built by assembling existing code. Others want it to be a 
ground-up effort. There's a million possible ways to go and solving that 
is a political problem.

MDC


Robert I. Eachus wrote:
> 
> 
> I don't want to harp on this, but WHO has known how to make a square 
> root routine for aeons?  In the early sixties it was vital to NASA to do 
>  square roots fast and accurately for the Apollo project.  I worked on 
> this, and the eventual result was to modify four IBM 7094s to include a 
> 36-bit to 36-bit integer square-root function.  I won't go into a long 
> discussion of WHY a 36-bit to 36-bit square-root with the implicit 
> binary point to the right of the most significant digit was what was 
> needed.  Just the thought of explaining to ONE more person why that was 
> what was needed, and that it was a very simple modification of the IBM 
> 7094 to add it makes me want to scream.
> 
> In the mid-eighties when I was at Stratus, I showed the same thing to 
> the hardware engineers responsible for the math co-processor software in 
> the Stratus 200 and 600 series.  They agreed it would significantly 
> improve the speed of their square root routines, but AFAIK, it was never 
> implemented.  (This was when we were about to introduce the 2000 series 
> which used Motorola 68881 math co-processors.)  Later, I implemented 
> this square-root method in software for Sun SPARCs, since it was so much 
> faster than Sun's math routines for most SPARC chips.  (Most UltraSPARC 
> chips now seem to do the square-root correctly.)
> 
> So yes, I know how to use the Newton-Rhapson method to find square 
> roots, and I also know how to implement a square-root in microcode so 
> that it is faster than the hardware divide.  But the idea that this was 
> well or widely known in 1983 is totally false.  There were CPUs in the 
> nineties that still did it wrong.  (Of course, in the nineties Intel 
> managed to get divide wrong as well.  Sigh!)  Most implementations of 
> sine and cosine were pretty good, but other trig functions and all 
> inverses were spotty.  Logs again were spotty both natural and common 
> logs, and most implementations of exp were a horror.  Brian Wichmann did 
> a lot of work on that, including finding cases where many compilers 
> computed X**4 wrong, even when X was integer and the result was 
> therefore exact.  (The IBM 360 series and follow-ons were infamous for 
> printing the sum of 2.0 and 2.0 as 3.9999999999999...  But that was 
> actually a problem in the Fortran print routines, not in the internal 
> representation.)
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Robert I. Eachus]

Marin David Condic wrote:
> Now you're talking about having a *Good* square root routine. Your 
> "political position" is that before we can define "Sqrt (X)" we have to 
> know how to make a *good* one. My "political position" is that Fortran 
> had a "Sqrt (X)" that was "good enough" for me to get my work done and 
> that while someone is off defining a better way of computing the result, 
> my code could still be making reference to an interface that looked like 
> "Sqrt (X)" and when the better one comes along, I don't have to change 
> my code because they decided to call it "Square_Root (X)" instead.

As far as I know, all Ada compiler vendors provided the original Cody 
and Waite math functions as an additional library.  Relatively speaking, 
they were slow but accurate.  The only "problem" I am aware of is that 
DEC, Rational, Verdix, etc. chose different names for the package.

That was the major effect of not including them in the standard, you had 
to change the name in a with clause. (The function names and parameters, 
as far as I can remember were identical.  Hmmm.  I think there were some 
differences/discussions about the parameter names of the two parameter 
form of Arctangent.  Not something that really affected users.)

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Marin David Condic]

Well, as an "end user" in good standing, I'd say it did affect me. I 
wanted portable source code I could take unchanged from one compiler to 
another and I couldn't get there. (Not initially, at least) So there was 
an impact. If I was maintaining code for two different compilers (not at 
all unheard of) I'd have to go through gyrations of configuration 
management to deal with it in some manner.

Its an issue that can safely be put to bed now, but the lesson ought to 
be out there for future similar circumstances. Not everybody's political 
needs are the same, so there need to be compromises.

MDC


Robert I. Eachus wrote:
> 
> That was the major effect of not including them in the standard, you had 
> to change the name in a with clause. (The function names and parameters, 
> as far as I can remember were identical.  Hmmm.  I think there were some 
> differences/discussions about the parameter names of the two parameter 
> form of Arctangent.  Not something that really affected users.)
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Robert I. Eachus]

Marin David Condic wrote:
> Well, as an "end user" in good standing, I'd say it did affect me. I 
> wanted portable source code I could take unchanged from one compiler to 
> another and I couldn't get there. (Not initially, at least) So there was 
> an impact. If I was maintaining code for two different compilers (not at 
> all unheard of) I'd have to go through gyrations of configuration 
> management to deal with it in some manner.

True, but not realistic.  Having been there and done that, there were 
two situations that arose.  One, you had two compilers for the same 
hardware, and it was almost trivial to pick one version of the math 
libraries and treat it as part of your source code.

But the much more frequent case was where I was targeting different 
hardware.  Then choosing the "right" version of a library was 
complicated.  For example, I had three bodies of the math libraries for 
the Amiga: 68000/68010, 68020/68030 with 68881/68882(IEEE), and 
68020/68030 without math chip.  It would have been nice to be able to 
build a single library that did the necessary tests when initialized and 
used the "right" routines automatically, but that didn't work.  The 
floating-point data types and calling sequences were sufficiently 
different that you really had to compile for the floating-point model 
you were using.

It was no different for other languages, you had to choose an 
implementation that your machine supported, and it would run much slower 
than it had to if you choose the wrong version.  (Extremely slowly if 
you generated 68881 calls on a machine that didn't have a math chip.)

> Its an issue that can safely be put to bed now, but the lesson ought to 
> be out there for future similar circumstances. Not everybody's political 
> needs are the same, so there need to be compromises.

Agreed, but don't lose the flip side.  I am not sure if a simple 
database interface will make it into the standard this time around.  In 
Ada 9X it would have been a serious mistake to include one.  This time 
it may be a mistake not to include one, but we could still goof by 
choosing the wrong one.  This is one of the reasons I am participating 
in this discussion.  I would much rather get the key issues for database 
interfaces right for Ada 200X, and allow multiple implementations of the 
actual database interfaces.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[Marin David Condic]

Well, there's an excuse for having a provisional non-standard "standard" 
by way of a Conventional Ada Library. You could create a database 
interface - like possibly ODBC - and see what the reaction is. You could 
add another interface and see if that got better reception. With some 
experience under your belt, you look to the next Ada revision and 
possibly declare a "winner" that gets incorporated into the ARM. The CAL 
support for both still exists (unless there might be some really good 
reason to get rid of one) so users of the loser aren't stranded. 
Besides, they get source, so they could freeze some application to a 
particular version of the CAL and for future applications, use the one 
in the ARM.

I see lots of up-sides to having a non-standard "standard" and not many 
down-sides. It does what the standard cannot do (be flexible and react 
quickly) while not depriving the standard from growing once something 
gets proven out. All it really takes is for the vendors to say "O.K., go 
ahead and build it and we'll distribute it and declare it to be 
'Conventional'..." (O.K. There'd probably have to be some level of 
funding, but maybe not a whole lot. You just can't do something this big 
and not expect to have to spend some cashish in the process.) All the 
rest about incorporation into the ARM, etc, are issues that we have a 
wide number of ways of resolving down the road, assuming that the effort 
met with some success. Lets jump off that bridge when we get to it.

This same approach could have solved the whole square root problem too, 
don't you think? :-)

MDC


Robert I. Eachus wrote:
> 
> Agreed, but don't lose the flip side.  I am not sure if a simple 
> database interface will make it into the standard this time around.  In 
> Ada 9X it would have been a serious mistake to include one.  This time 
> it may be a mistake not to include one, but we could still goof by 
> choosing the wrong one.  This is one of the reasons I am participating 
> in this discussion.  I would much rather get the key issues for database 
> interfaces right for Ada 200X, and allow multiple implementations of the 
> actual database interfaces.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Standard Library Interest?

[Robert I. Eachus]

Marin David Condic wrote:
> Well, there's an excuse for having a provisional non-standard "standard" 
> by way of a Conventional Ada Library. You could create a database 
> interface - like possibly ODBC - and see what the reaction is. You could 
> add another interface and see if that got better reception. With some 
> experience under your belt, you look to the next Ada revision and 
> possibly declare a "winner" that gets incorporated into the ARM. The CAL 
> support for both still exists (unless there might be some really good 
> reason to get rid of one) so users of the loser aren't stranded. 
> Besides, they get source, so they could freeze some application to a 
> particular version of the CAL and for future applications, use the one 
> in the ARM...
 >
> This same approach could have solved the whole square root problem too, 
> don't you think? :-)

That was exactly the approach taken.  I've been trying to remain polite, 
I think pretty successfully, but I finally realize what was that was 
rubbing me the wrong way.  I worked hard, in some cases unfunded, in 
other cases funded in various ways, including directly by the AJPO, on a 
number of extensions to Ada 83.  The some of the material in the ADAR 
components that Dave Emery, Ben Brosgol and I did with AJPO support 
ended up becoming the foundation of the Information Systems annex, and 
the foundation for adding decimal types to the standard.  Some other 
parts of ADAR didn't make it.  Great!  That was exactly the intent.  To 
do the experimentation needed before things got addeded to the standard. 
  I also worked on the CRG to figure out what should be done about 
Unicode and ISO 10646 (in Ada 95) and the SQL RG where even we said 
don't put it in.

With NUMWG and then the NRG, I was more of an interested spectator than 
a member with all the other things going on.  But again the process was 
the same.  There were lots of meetings and discussions, many draft 
standards distributed--incuding reference implementations, several 
approved ISO standards and then those standards were pulled into Ada 95.

I guess in this area I have always been willing to jump in and do the 
work, and then not too concerned about whether that work ends up as part 
of the Ada standard and/or supported by vendors.  There have been a 
couple areas where I do think wrong decisions were made.  But to a great 
extent it is much more important to TRY and see what happens. 
Sometimes, as with SQL and SAMeDL, all you find out is that there still 
isn't a good solution available.

A big part of the problem in SQL to Ada bindings is a cognative 
dissonance.  The approaches that seem natural in Ada clash with SQL 
usage and vice-versa.  That's why I became so excited by the 
Bounded_String_Array abstraction that I posted a few days ago.  I think 
I may be able to use it to write a decent ODBC binding that doesn't 
require a sea of type declarations and generics.

-- 
                                        Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Standard Library Interest?

[(see below)]

On 6/10/03 08:02, in article
slrnbo24ra.34a.randhol+valid_for_reply_from_news@kiuk0152.chembio.ntnu.no,
"Preben Randhol" <randhol+valid_for_reply_from_news@pvv.org> wrote:

> What do you mean with desktop apps in a standard library? Anyway I'm
> going to finish my work on a template for making GUIs (GtkAda) for
> applications later this year.

Preben, can you say a little more about this?
It sounds very interesting.
-- 
Bill

Re: Standard Library Interest?

[Preben Randhol]

On 2003-10-06, (see below) <yaldnifb@blueyonder.co.uk> wrote:
> On 6/10/03 08:02, in article
> slrnbo24ra.34a.randhol+valid_for_reply_from_news@kiuk0152.chembio.ntnu.no,
> "Preben Randhol" <randhol+valid_for_reply_from_news@pvv.org> wrote:
>
>> What do you mean with desktop apps in a standard library? Anyway I'm
>> going to finish my work on a template for making GUIs (GtkAda) for
>> applications later this year.
>
> Preben, can you say a little more about this?
> It sounds very interesting.

In order to make a program with a GUI you have to do a lot of the same
exercise each time. I mean create the menus, statusbar, about dialog,
perhaps help dialog. You have to hook up the callbacks etc... The only
real difference is that you pack a box in the window which contains your
widgets.

So I'll make a template that one can start with in order to ease this
process. I'm making also making some of the commonly used dialogs so it
should be easy to use in the program. At the moment I don't have time,
but in a month I will start up working on this again.

The idea is that you will be able to get started faster on a project and
don't have to waste time on the same design each time.

Preben

Re: Standard Library Interest?

[tmoran]

>In order to make a program with a GUI you have to do a lot of the same
>exercise each time. I mean create the menus, statusbar, about dialog,
>...
>So I'll make a template that one can start with in order to ease this
  Doesn't GtkAda come with a GUI Builder already?

Re: Standard Library Interest?

[Preben Randhol]

On 2003-10-06, tmoran@acm.org <tmoran@acm.org> wrote:
>>In order to make a program with a GUI you have to do a lot of the same
>>exercise each time. I mean create the menus, statusbar, about dialog,
>>...
>>So I'll make a template that one can start with in order to ease this
>   Doesn't GtkAda come with a GUI Builder already?

Sure, but you still have to do a lot of things. I'm not making a new GUI
builder, just something that makes it easier to get started.

Preben

Re: Standard Library Interest?

[Robert C. Leif]

Chris Danx and Marin David Condic  started this thread concerning "the
development of some kind of standard library independent of the ARM".
A mechanism that could be used for this was started at SIGAda 2002 and
is accessible at the www.sigada.org web site. Go to SIGAda Working
Groups and then Ada Application Programming Interfaces (API) Working
Group (APIWG) http://www.sigada.org/wg/apiwg/
Subgroups address areas of special interest areas within APIWG. The
areas identified include:
* Common Gateway Interface (CGI) 
* eXtensible Markup Language (XML) 

Since I head the XML group, I will have a section of the Ada
Application Programming Interfaces Working Group  I suspect many of
the items that you have listed could be construed to fall under XML.
Therefore, if you feel like discussing or proposing APIs relevant to
XML, please attend. If you can not attend and want me to show a short
PowerPoint presentation or anything else that will run on my Windows
laptop, I will try to accommodate you. If the material is beyond XML,
then if you wish to present, it would be appropriate to contact Clyde
Roby, the Chair of the APIWG.

My presentation outline is:

Birds' of a Feather meeting Ada & XML

The prospects for the long-time survival of Ada would be greatly
enhanced by creating bidirectional interfaces with the XML family of
languages and a formal relationship between SIGAda and the World Wide
Web Consortium, W3C.

The following questions will be the subject of this Birds' of a
Feather meeting:
a)	What do we have?
b)	Where is it?
c)	What needs to be created?
d)	Who will create what?
e)	How do we maximize the availability to the Ada and other
communities of Ada interfaces to XML and Ada XML artefacts?
--Problem: There are very significant differences between Copy-Left
and commercial licenses. However, it may be possible to combine the
two.

Reasons for a strong relationship:
f)	The XML family of languages have similar semantics to Ada.
g)	Ada and XML are complimentary; not competitive.
--XML is primarily a presentation and data technology.
h)	XML, particularly XForms, eliminates the need for Java, Javascript
and other languages to create web pages.
i)	XML like Ada is a vendor independent international standard;
however, the maintainer of the XML standards, W3C, would have
benefited and can still benefit from the services of some Ada language
lawyers.
Suggested Deliverables:
j)	XML Schema for Ada
k)	Bindings to XForms, SVG and XSL
--The Xforms and SVG binding could be used to create a GUI for
embedded systems.
 
I might add that a binding for MathML would have the interesting
possibility of permitting Ada compilers to understand standard
mathematical notation.

Bob Leif
Robert C. Leif, Ph.D.
Email rleif@rleif.com
www.newportinstruments.com
   ----------------------------------------------------
   chris <spamoff.danx@ntlworld.com> wrote in message news:<TdJfb.5879$RU4.57294@newsfep4-glfd.server.ntli.net>...
   > Hi,
   > 
   > Recent discussions with Marin David Condic /suggest/ the
development of
   > some kind of standard library independant of the ARM, but
hopefully
   > endorsed by vendors and the ARG, would be a worthwhile endeavour.
   > Assuming such a library could be created and was attractive to
the
   > community, vendors and the ARG what would people want of such a
library?
   > 
   > What would you want to see available that wasn't going to feature
in the
   > next language revision and didn't quite fit with the long
revision times
   > for the standard?  What would you like available that was
portable
   > across platforms for software development?
   > 
   > I wasn't going to suggest anything as a) I don't want to put
words/ideas
   > in peoples' mouths/heads and b) my interests are highly
multimedia
   > orientated but perhaps including some of the following:
   > 
   > XML support
   > Unicode processing library
   > Support for common image formats*
   > Support for common audio formats and audio playback* (free
formats)
   > 
   > *with the ability to extend support for other formats.
   > 
   > XML and Unicode support don't quite fit within the language
standard
   > because they change more frequently, but IMO it'd be nice to have
some
   > standardised support for both of these things.  Note with unicode
I am
   > thinking about things like normalisation, etc.
   > 
   > The idea is to have something that developers can look to on
compilers
   > for general software development, particularly on the desktop. 
If
   > developers need it, it will be there and they don't have to look
around
   > as much for the facilities they need.  So, what facilities do you
need
   > that perhaps could go in such a library?
   > 
   > 
   > Chris

Re: Standard Library Interest?

[Vadim Godunko]

chris <spamoff.danx@ntlworld.com> wrote in message news:<TdJfb.5879$RU4.57294@newsfep4-glfd.server.ntli.net>...
> 
> XML support
> Unicode processing library

See http://www.ada-ru.org/files/ais-0.0.1.tar.gz

It containt string normalization, collation key computation, some
character properties.

--
Vadim Godunko

Re: Standard Library Interest?

[Matthew Heaney]

chris <spamoff.danx@ntlworld.com> writes:

> Recent discussions with Marin David Condic /suggest/ the development
> of some kind of standard library independant of the ARM, but hopefully
> endorsed by vendors and the ARG, would be a worthwhile
> endeavour. Assuming such a library could be created and was attractive
> to the community, vendors and the ARG what would people want of such a
> library?

There is indeed interest in at least a standard container library for
Ada.  The call for APIs is here:

<http://www.adaic.org/news/call4apis.html>

I have submitted a proposal for an API based on the Charles container
library.  My API proposal is here:

<http://home.earthlink.net/~matthewjheaney/charles/ai302.txt>

Charles itself is modeled on the C++ STL.

Re: Standard Library Interest?

[Preben Randhol]

On 2003-10-07, Matthew Heaney <matthewjheaney@earthlink.net> wrote:
>
> There is indeed interest in at least a standard container library for
> Ada.  The call for APIs is here:
>
><http://www.adaic.org/news/call4apis.html>
>
> I have submitted a proposal for an API based on the Charles container
> library.  My API proposal is here:
>
><http://home.earthlink.net/~matthewjheaney/charles/ai302.txt>
>
> Charles itself is modeled on the C++ STL.

Yes, I think it would be great to get a standard container library as one
need this in most situations.

Preben

Re: Standard Library Interest?

[Marin David Condic]

This would be one reason for not adopting a bunch of existing things for 
a Conventional Ada Library. If we got a standard set of containers, 
you'd want all the other utilities to utilize them rather than inventing 
their own containers. Hence, its better to build one from the ground up 
that is well integrated and very regular in its interfaces.

MDC


Preben Randhol wrote:
> 
> Yes, I think it would be great to get a standard container library as one
> need this in most situations.
> 
> Preben


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================