* Re: Ada Component Registry proposal
[not found] <3F9879C0.9040209@myob.com>
@ 2003-10-24 3:03 ` Alexandre E. Kopilovitch
0 siblings, 0 replies; 57+ messages in thread
From: Alexandre E. Kopilovitch @ 2003-10-24 3:03 UTC (permalink / raw)
To: comp.lang.ada
sk wrote:
> > ... not differ fundamentally from corresponding part
> > of AdaPower (still most successful Ada-oriented website) ...
>
> Perhaps AdaIC would be a better comparison
I doubt it. AdaIC has somehow another purpose, I think... although there is
certainly substantial intersection.
> >http://adaic.com/site/index.html
>
> lot of dead/bad links though.
Not only dead/bad, but also improper ones. I just glanced there... better I
did not do that. In the list of national Ada organizations I discovered
Ada-Russia, to my surprise; I followed the link, and found simply website in
Russian. Yes, it is dedicated for Ada, and contains Ada-related materials and
links, but I found there no traces of any organization. Then I checked list
of associated organizations in Ada-Europe, and as I expected there are no
Ada Russia. So, this name is premature, at best. But this was not the worse:
on that site (pseudo- Ada Russia) I discovered new Ada textbook in Russian,
(not a translation, but presented as original writing) and glanced into it
too... again, better I did not do it. Well, as I feared (by past experience)
all symptoms are in place, beginning from the book title, which demonstrates
playing with words - this title may be read as slang form of "Ada programming"
or normal language form of "Hell programming". Then follows the substance of
the book with all usual terminological negligence; the highest achievement is,
perhaps, translation of the term "elaboration"... but I may be mistaken here -
I looked into the text about 5 minutes only, so there may be even greater
invention. Well, I understand - good intentions, as usual.
Alexander Kopilovitch aek@vib.usr.pu.ru
Saint-Petersburg
Russia
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
@ 2003-10-23 16:16 Robert C. Leif
2003-10-24 11:48 ` Georg Bauhaus
0 siblings, 1 reply; 57+ messages in thread
From: Robert C. Leif @ 2003-10-23 16:16 UTC (permalink / raw)
To: comp.lang.ada, rieachus
Why are you using a DTD, which is the antithesis of Ada? A schema which
is the semantic equivalent (translation) of a collection of Ada types would
be far more appropriate.
Bob Leif
Robert C. Leif, Ph.D.
Email rleif@rleif.com
------------------------------------------------
Robert I. Eachus Wrote:
Don't worry about it. I said that I thought that the first version of
the XML document was not something I would be comfortable posting, but I
would send copies to anyone who wanted to review it. Stephane Richard
was willing to do so. Unless there are significant changes, or more
people who want to take a shot at the current XML state, I will probably
post version 0.2 to comp.lang.ada tomorrow. Another potential delay is
that I am probably going to write an XML to HTML converter this weekend,
so you can look at the HTML to make comments.
No intent to exclude anyone, but XML is still not all that common a
language, and I felt the intersection of those who knew XML well enough
to comment, and were also interested in the registry project would be
pretty small. Hmmm. Actually, why not? Here is the current XML
DOCTYPE, and the start of the registry declaration. If you want a
snapshot of the whole thing, send e-mail. But, please, only if you are
willing to read it and comment.:
<?xml version="1.0" encoding="UTF-8" standalone=yes ?>
<!DOCTYPE Ada_Component_Registry [
<!-- Version 0.2 Doctype Copyright 2003 by Robert I. Eachus, copying
allowed, all other rights reserved for now. -->
<!ELEMENT Registry (Author*, Project+, Entry+) >
<!ATTLIST Registry
Name CDATA #REQUIRED
Version CDATA #REQUIRED
Website CDATA #IMPLIED
Copyright CDATA #REQUIRED
>
<!ELEMENT Project (Author*, Requires*, Supports*, Description?)
<!ATTLIST Project
Name CDATA #REQUIRED
Version CDATA #IMPLIED
Website CDATA #IMPLIED
Bug_Reports CDATA #REQUIRED
Copyright CDATA #REQUIRED
>
<!ELEMENT Entry (Author+, Description?, Requires*, Supports*,
Contents?)
<!ATTLIST Entry
Name CDATA #REQUIRED
Project CDATA #REQUIRED
Version CDATA #IMPLIED
Source CDATA #IMPLIED
Copyright CDATA #IMPLIED
>
<!ELEMENT Author>
<!ATTLIST Author
Name CDATA #REQUIRED
Email CDATA #IMPLIED
Telephone CDATA #IMPLIED
Company CDATA #IMPLIED
Address CDATA #IMPLIED
>
<!ELEMENT Compiler >
<!ATTLIST Compiler
Name CDATA #REQUIRED
Version CDATA #IMPLIED
>
<!ELEMENT Contents (#PCDATA )>
<!ELEMENT Database>
<!ATTLIST Database
Name CDATA #REQUIRED
Version CDATA #IMPLIED
>
<!ELEMENT Date (((Month, Day?)?, Year)|#PCDATA)>
<!ELEMENT Description (#PCDATA )>
<!ELEMENT Full_Name (#PCDATA )>
<!ELEMENT Language
<!ATTLIST Language
Version (Ada80 | Ada83 | Ada95 | Ada2000 | Ada0X) "Ada95"
<!ELEMENT OS>
<!ATTLIST OS
Name CDATA #REQUIRED
Version CDATA #IMPLIED
>
<!ELEMENT Project_Name (#PCDATA ) >
<!ELEMENT Requires (Project_Name|Compiler|OS|Hardware)+ >
<!ELEMENT Supports (Language_Version|Compiler|OS|Hardware)+ >
<!ELEMENT Root_Name (#PCDATA )>
<!ELEMENT URL (#PCDATA ) >
<!ELEMENT Version (#PCDATA)>
<!ATTLIST Version Date CDATA >
<!ELEMENT Website (#PCDATA) >
]>
<Registry Name="Ada Component Registry"
Version="0.2"
Copyright="Copyright 2003 by Robert I. Eachus, copying
allowed, all other rights reserved for now."
>
--
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
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-23 16:16 Robert C. Leif
@ 2003-10-24 11:48 ` Georg Bauhaus
0 siblings, 0 replies; 57+ messages in thread
From: Georg Bauhaus @ 2003-10-24 11:48 UTC (permalink / raw)
Robert C. Leif <rleif@rleif.com> wrote:
:
: Why are you using a DTD, which is the antithesis of Ada? A schema which
: is the semantic equivalent (translation) of a collection of Ada types would
: be far more appropriate.
I think before considering whether the C/Unix oriented Schema type
library is a restriction or an improvement, it is, first of all,
necessary to consider which Elements should be in the registry,
then their relations, and then whether an XML-DTD schema, or a
RELAX NG schema, or a Schema schema is more useful.
Georg
^ permalink raw reply [flat|nested] 57+ messages in thread
* Ada Component Registry proposal
@ 2003-10-19 17:16 Robert I. Eachus
0 siblings, 0 replies; 57+ messages in thread
From: Robert I. Eachus @ 2003-10-19 17:16 UTC (permalink / raw)
I put together an XML DOCTYPE for a Ada Component Registry, and tried
it out on GNADE. If a couple of people who understand XML would like to
look at it and criticize, I'll send you a copy. But right now I consider
it too preliminary to let loose in the wild. I'll probably have a much
better worked out version by the end of next week. (Oops! Mental note to
self, the registry itself needs a version number. ;-)
I picked GNADE as a test case though, expecting it to be a decent stress
test. Boy was it! For me as well as the XML grammer. I'd like to
comment on a few things that I found and what they mean for a formal
registry, or for the Common Ada Library.
One of the things that the registry does is makes the zip or tar or
whatever file that you can download more accessable. Much more
accessable. Amazingly more accessable. GNADE as delivered has over a
dozen directories and if you actually compile it, creates a few more.
(And just to confuse you puts some stuff into existing directories
outside the GNADE structure.) With the registry, you can look and see
that most of the source files are children of GNU.DB, and that package
declaration can be found in ../gnade-src-1.4.3a/support. The problem
though can be found in that word most. There is also a separate OCI
root for an Oracle binding, and over a dozen packages and programs at
the library level that can conflict with other bindings. These include
such wonderful names as Parser, Scanner, SQL, ODBC, and Tools.
Am I saying that GNADE is horribly organized? No. Just that GNADE is a
excellent example of why a registry is needed. If there were a standard
place for a database interface packages--I would prefer
Interfaces.Xxxxx, but that is a detail--then GNADE could provide some of
those packages and mix and match with implementations of such packages
from elsewhere. And GNU.DB.Support would disappear as GNADE moved to
using more standard implementations of tables and lists. Finally, the
scanner and parser that GNADE provides to support embedded SQL could be
reused by other projects that have nothing to do with databases.
But all of this has to be understood in terms of encouragement and
process. GNADE is not going to adopt major changes just because I say
they should. But the existance of a useable registry and "standard"
Common Ada Library would encourage the GNADE authors to evolve their
code in directions that will make it easier to reuse.
--
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
^ permalink raw reply [flat|nested] 57+ messages in thread
* Ada Component Registry proposal
@ 2003-10-19 16:41 Robert I. Eachus
2003-10-19 16:44 ` Stephane Richard
` (4 more replies)
0 siblings, 5 replies; 57+ messages in thread
From: Robert I. Eachus @ 2003-10-19 16:41 UTC (permalink / raw)
I put together an XML DOCTYPE for a Ada Component Registry, and tried it
out on GNADE. If anyone who understands XML would like to look at it and
criticize, I'll send you a copy. But right now I consider it too
preliminary to let loose in the wild. I'll probably have a much better
worked out version by the end of next week. (Oops! Mental note to self,
the registry itself needs a version number. ;-)
I picked GNADE as a test case though, expecting it to be a decent stress
test. Boy was it! For me as well as the XML grammer. I'd like to
comment on a few things that I found and what they mean for a formal
registry, or for the Common Ada Library.
One of the things that the registry does is makes the Zip or tar or
whatever file that you can download more accessable. Much more
accessable. Amazingly more accessable. GNADE as delivered has over a
dozen directories and if you actually compile it, creates a few more.
(And just to confuse you puts some stuff into existing directories
outside the GNADE structure.) With the registry, you can look and see
that most of the source files are children of GNU.DB, and that package
declaration can be found in
--
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
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-19 16:41 Robert I. Eachus
@ 2003-10-19 16:44 ` Stephane Richard
2003-10-21 20:45 ` sk
` (3 subsequent siblings)
4 siblings, 0 replies; 57+ messages in thread
From: Stephane Richard @ 2003-10-19 16:44 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1896 bytes --]
do send a copy my way :-). if you please Robert.
--
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com
"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:3F92BEAA.9030004@comcast.net...
> I put together an XML DOCTYPE for a Ada Component Registry, and tried it
> out on GNADE. If anyone who understands XML would like to look at it and
> criticize, I'll send you a copy. But right now I consider it too
> preliminary to let loose in the wild. I'll probably have a much better
> worked out version by the end of next week. (Oops! Mental note to self,
> the registry itself needs a version number. ;-)
>
> I picked GNADE as a test case though, expecting it to be a decent stress
> test. Boy was it! For me as well as the XML grammer. I'd like to
> comment on a few things that I found and what they mean for a formal
> registry, or for the Common Ada Library.
>
> One of the things that the registry does is makes the Zip or tar or
> whatever file that you can download more accessable. Much more
> accessable. Amazingly more accessable. GNADE as delivered has over a
> dozen directories and if you actually compile it, creates a few more.
> (And just to confuse you puts some stuff into existing directories
> outside the GNADE structure.) With the registry, you can look and see
> that most of the source files are children of GNU.DB, and that package
> declaration can be found in
>
>
> --
> 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
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-19 16:41 Robert I. Eachus
2003-10-19 16:44 ` Stephane Richard
@ 2003-10-21 20:45 ` sk
2003-10-22 0:28 ` Robert I. Eachus
2003-10-22 2:26 ` sk
` (2 subsequent siblings)
4 siblings, 1 reply; 57+ messages in thread
From: sk @ 2003-10-21 20:45 UTC (permalink / raw)
To: comp.lang.ada
"Robert I. Eachus" <rieachus@comcast.net>:
> ... If anyone who understands XML would like to look at ...
Sorry, do not have GNADE nor knowledge of XML. However, I think
that fundamentally you are aiming to establish a naming hierarchy
correct ?
I would prefer to second Warren W. Gay's proposal in the "Standard
Library Interest" thread which suggests, I believe, taking an inventory
of what is already available and integrate it into some acceptable
form.
I am not criticizing your proposal since I have not seen it, but
I feel that inventory and integrate *might* produce more results
and interest in terms of not having to start all over again.
--
-------------------------------------------------
-- Merge vertically for real address
--
-- s n p @ t . o
-- k i e k c c m
-------------------------------------------------
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-21 20:45 ` sk
@ 2003-10-22 0:28 ` Robert I. Eachus
0 siblings, 0 replies; 57+ messages in thread
From: Robert I. Eachus @ 2003-10-22 0:28 UTC (permalink / raw)
sk wrote:
> I am not criticizing your proposal since I have not seen it, but
> I feel that inventory and integrate *might* produce more results
> and interest in terms of not having to start all over again.
No disagreement. But doing that inventory is WORK. A lot of it. If I
am going to be doing that work, or even a small part of it, I need
feedback. A survey that doesn't include the right information, or is
not in the right form, is useless.
So at this point my plan is:
1) Design a Registry.
2) Build tools to create it, maintain it and reference it.
3) Populate the Registry.
4) Repeat as needed.
It might be nice to have "official" standard status for the Registry.
But if it exists and the Registry and supporting tools are widely used,
it won't matter if it is a de jure or de facto standard.
Having said that I have gotten so far as:
The Registry should be an XML document.
There should be publicly accessable free software that can be used to
reference the public registry and private or subset registries. Of
course, this software should be written in Ada, and be listed in the
Registry. ;-)
For this to work, the registry is going to require lots of feedback. As
I said, for now I just want to send the very preliminary draft to people
willing to read it as XML. Soon I should have the XML solid enough to
write a quick XML to HTML converter, and I can post the draft registry
in html form also. After that will come a database form with query
tools. But notice that the "reference" form of the registry will be an
XML document, even if the normal use of it is to update a local database.
To misuse a great quote from Larry Niven and Jerry Pournelle's Oath of
Fealty: "Think of it as evolution in action." The whole idea is to
create a process that makes reuse of Ada easier. Evolution of the
contents of the registry, the registry, and the registry toolset all
need to be part of that process.
--
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
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-19 16:41 Robert I. Eachus
2003-10-19 16:44 ` Stephane Richard
2003-10-21 20:45 ` sk
@ 2003-10-22 2:26 ` sk
2003-10-22 3:38 ` Robert I. Eachus
2003-10-22 4:26 ` sk
2003-10-23 5:41 ` sk
4 siblings, 1 reply; 57+ messages in thread
From: sk @ 2003-10-22 2:26 UTC (permalink / raw)
To: comp.lang.ada
I would like to propose "Ada95" as the root of the library
hierarchy.
Many Ada projects have a common name such as (my own stuff)
EduOS-Ada, or GtkAda or <normal-name>+<"Ada"> which always
suggests that "Ada" is "special" with all the negative conotations.
I believe (note the singular pronoun *I*, a sample set of 1 :-)
that some people, including myself, are put off by this seemingly
egotistical naming convention that the Ada community seems to follow.
So GtkAda -> Ada95.Gtk etc.
... AdaSockets -> Ada95.Sockets
etc.
This naming convention could also be used to happily distinguish
between code strictly for '83, '95 and '0y
Ada83.Gtk, Ada83.SDL, Ada83.Sockets etc.
Ada95.Gtk, Ada95.SDL, Ada95.Sockets etc.
Ada0y.Gtk, Ada0y.SDL, Ada0y.Sockets etc.
with of course the possibilities of renaming etc.
package Ada95.Sockets renames Ada83.Sockets;
package Ada0y.Sockets renames Ada83.Sockets;
as an example.
I am not trying in any way to usurp RI Eachus' effort, I am
just trying to keep the ball rolling whilst he is formalizing.
There seems to be a lot of momentum at the moment for defining
and creating a common/standard library and I want to keep it going.
With the idea of keeping the momentum going, I am willing to
volunteer a start at doing some of the inventory work to meet
RI Eachus' proposal and as per any discussion that this message
invokes..
--
-------------------------------------------------
-- Merge vertically for real address
--
-- s n p @ t . o
-- k i e k c c m
-------------------------------------------------
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-22 2:26 ` sk
@ 2003-10-22 3:38 ` Robert I. Eachus
2003-10-22 10:35 ` Stephane Richard
2003-10-22 13:11 ` Marin David Condic
0 siblings, 2 replies; 57+ messages in thread
From: Robert I. Eachus @ 2003-10-22 3:38 UTC (permalink / raw)
sk wrote:
> I would like to propose "Ada95" as the root of the library
> hierarchy.
I think we should be aiming for the future, not the past.
> This naming convention could also be used to happily distinguish
> between code strictly for '83, '95 and '0y
>
> Ada83.Gtk, Ada83.SDL, Ada83.Sockets etc.
> Ada95.Gtk, Ada95.SDL, Ada95.Sockets etc.
> Ada0y.Gtk, Ada0y.SDL, Ada0y.Sockets etc.
What about Ada80.Sockets, Ada87.Sockets, and Ada2000.Sockets?
The differences between some of these versions, and others not mentioned
is slight. (For example, there were three differences between MIL-STD
1815A, and ANSI/MIL-STD 1815A, and the second was the page number for
2-2. ;-) But the current standard really is Ada 2000, although its
formal name is more cumbersome. It is possible to get a copy of TC1 and
see what changed between Ada 95 and Ada 2000, but I prefer to just use
the standard as posted at: http://www.ada-auth.org/~acats/arm.html
To quote from that page: "When ISO published the Technical Corrigendum,
it did not also publish a document that merges the Technical Corrigendum
changes into the text of the International Standard. However, ISO rules
require that the project editor for the Technical Corrigendum be able to
produce such a document on demand. The document available here is what
the project editor would provide to ISO in response to such a request.
It should be understood that the publication of any ISO document
involves changes in "boilerplate" as well as a review by professional
editors that may introduce editorial changes."
I'm not trying to be a stickler for accuracy here, just pointing out
that the Ada standard is evolving. I'd hate to have the CAL come out
labelled as Ada95 (or Ada2000) just in time for the Ada 0X standard.
> I am not trying in any way to usurp RI Eachus' effort, I am
> just trying to keep the ball rolling whilst he is formalizing.
>
> There seems to be a lot of momentum at the moment for defining
> and creating a common/standard library and I want to keep it going.
>
> With the idea of keeping the momentum going, I am willing to
> volunteer a start at doing some of the inventory work to meet
> RI Eachus' proposal and as per any discussion that this message
> invokes..
I'll be calling soon. ;-) But right now I could use a couple more
people who know XML to do some reviewing.
--
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
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-22 3:38 ` Robert I. Eachus
@ 2003-10-22 10:35 ` Stephane Richard
2003-10-22 16:58 ` Robert I. Eachus
2003-10-22 13:11 ` Marin David Condic
1 sibling, 1 reply; 57+ messages in thread
From: Stephane Richard @ 2003-10-22 10:35 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3211 bytes --]
Well I'm reviewing it right now :-). Have you taken a decision on where
you'd be putting the copyright as we discussed in emails?
--
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com
"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:3F95FB78.4090305@comcast.net...
> sk wrote:
> > I would like to propose "Ada95" as the root of the library
> > hierarchy.
>
> I think we should be aiming for the future, not the past.
>
> > This naming convention could also be used to happily distinguish
> > between code strictly for '83, '95 and '0y
> >
> > Ada83.Gtk, Ada83.SDL, Ada83.Sockets etc.
> > Ada95.Gtk, Ada95.SDL, Ada95.Sockets etc.
> > Ada0y.Gtk, Ada0y.SDL, Ada0y.Sockets etc.
>
> What about Ada80.Sockets, Ada87.Sockets, and Ada2000.Sockets?
>
> The differences between some of these versions, and others not mentioned
> is slight. (For example, there were three differences between MIL-STD
> 1815A, and ANSI/MIL-STD 1815A, and the second was the page number for
> 2-2. ;-) But the current standard really is Ada 2000, although its
> formal name is more cumbersome. It is possible to get a copy of TC1 and
> see what changed between Ada 95 and Ada 2000, but I prefer to just use
> the standard as posted at: http://www.ada-auth.org/~acats/arm.html
>
> To quote from that page: "When ISO published the Technical Corrigendum,
> it did not also publish a document that merges the Technical Corrigendum
> changes into the text of the International Standard. However, ISO rules
> require that the project editor for the Technical Corrigendum be able to
> produce such a document on demand. The document available here is what
> the project editor would provide to ISO in response to such a request.
> It should be understood that the publication of any ISO document
> involves changes in "boilerplate" as well as a review by professional
> editors that may introduce editorial changes."
>
> I'm not trying to be a stickler for accuracy here, just pointing out
> that the Ada standard is evolving. I'd hate to have the CAL come out
> labelled as Ada95 (or Ada2000) just in time for the Ada 0X standard.
>
> > I am not trying in any way to usurp RI Eachus' effort, I am
> > just trying to keep the ball rolling whilst he is formalizing.
> >
> > There seems to be a lot of momentum at the moment for defining
> > and creating a common/standard library and I want to keep it going.
> >
> > With the idea of keeping the momentum going, I am willing to
> > volunteer a start at doing some of the inventory work to meet
> > RI Eachus' proposal and as per any discussion that this message
> > invokes..
>
> I'll be calling soon. ;-) But right now I could use a couple more
> people who know XML to do some reviewing.
>
> --
> 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
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-22 10:35 ` Stephane Richard
@ 2003-10-22 16:58 ` Robert I. Eachus
2003-10-22 17:06 ` Stephane Richard
2003-10-22 23:14 ` Georg Bauhaus
0 siblings, 2 replies; 57+ messages in thread
From: Robert I. Eachus @ 2003-10-22 16:58 UTC (permalink / raw)
Stephane Richard wrote:
> Well I'm reviewing it right now :-). Have you taken a decision on where
> you'd be putting the copyright as we discussed in emails?
I think the right answer is in both the project description and the
individual name entries. Probably make it an optional section in both
places. Hmmm. Maybe better is that it is required for the project,
even if all it says is "Varies, see components."
I'm also thinking deeply about what you said vis-a-vis uncgi. Maybe the
best thing to do is just write a cgi-bin program in Ada, and if
necessary, convert some of the uncgi routines to Ada to avoid any
inherent buffer overflow problems. That would allow me to make the
actual query screen pure HTML that runs the cgi-bin program to do
selections. Of course, for now all I plan is an XML to HTML converter
that will allow the entire registry to be viewed as pure HTML.
--
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
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-22 16:58 ` Robert I. Eachus
@ 2003-10-22 17:06 ` Stephane Richard
2003-10-22 23:14 ` Georg Bauhaus
1 sibling, 0 replies; 57+ messages in thread
From: Stephane Richard @ 2003-10-22 17:06 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1597 bytes --]
that makes sense to me and that can be done :-).
--
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com
"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:3F96B6F9.3040302@comcast.net...
> Stephane Richard wrote:
> > Well I'm reviewing it right now :-). Have you taken a decision on where
> > you'd be putting the copyright as we discussed in emails?
>
> I think the right answer is in both the project description and the
> individual name entries. Probably make it an optional section in both
> places. Hmmm. Maybe better is that it is required for the project,
> even if all it says is "Varies, see components."
>
> I'm also thinking deeply about what you said vis-a-vis uncgi. Maybe the
> best thing to do is just write a cgi-bin program in Ada, and if
> necessary, convert some of the uncgi routines to Ada to avoid any
> inherent buffer overflow problems. That would allow me to make the
> actual query screen pure HTML that runs the cgi-bin program to do
> selections. Of course, for now all I plan is an XML to HTML converter
> that will allow the entire registry to be viewed as pure HTML.
>
> --
> 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
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-22 16:58 ` Robert I. Eachus
2003-10-22 17:06 ` Stephane Richard
@ 2003-10-22 23:14 ` Georg Bauhaus
1 sibling, 0 replies; 57+ messages in thread
From: Georg Bauhaus @ 2003-10-22 23:14 UTC (permalink / raw)
Robert I. Eachus <rieachus@comcast.net> wrote:
: Of course, for now all I plan is an XML to HTML converter
: that will allow the entire registry to be viewed as pure HTML.
Uhm, I think there are some choices, I hope I'm not just
stating the obvious:
a/ use an XSLT.
a1/ use that directly in the browser, via a
<?xml-stylesheet ...?> processing instruction
a2/ run it once, result is "static" HTML.
b/ use CSS 2 with XML, current browsers can display XML content with
the help of CSSs
(however, CSS 2 does not allow one to make element selections etc)
c/ combine them
Are you thinking of a2, using some DTD for the registry documents?
I've set up a dummy text using DocBook (not because I think it
is well suited, but because everything is readily available,
including XSL transformations.) Its structure and content
do not reflect the registry except making stupid references to the
context, for the sake of an example. It shows that (a1) does
not yet work too well; (a1) does work to some extent if you have the XSLT
in local files, at least with Mozilla.
With no fancy style; the "data content" is in test.xml,
http://home.arcor.de/bauhaus/tmp.Ada/test.html (a2)
http://home.arcor.de/bauhaus/tmp.Ada/test.pdf (a2', PDF, same procedure)
http://home.arcor.de/bauhaus/tmp.Ada/test.xml (original XML file)
http://home.arcor.de/bauhaus/tmp.Ada/test-local.xml
(local XSLT, type="text/xsl", not type="application/xslt+xml")
Done using DocBook XSL stylesheets 1.62.4, a copy of the HTML part
is referenced in the processing instruction in test.xml.
Georg
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-22 3:38 ` Robert I. Eachus
2003-10-22 10:35 ` Stephane Richard
@ 2003-10-22 13:11 ` Marin David Condic
2003-10-22 13:51 ` sk
1 sibling, 1 reply; 57+ messages in thread
From: Marin David Condic @ 2003-10-22 13:11 UTC (permalink / raw)
I'd bet you wouldn't want to make everyone change their code if a new
version of the library were to come out. Not unless you'd freeze "Adaxx"
and add only new stuff to "Adayy" - and I think that would end up an
unholy mess.
MDC
Robert I. Eachus wrote:
>
> What about Ada80.Sockets, Ada87.Sockets, and Ada2000.Sockets?
>
--
======================================================================
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
======================================================================
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-22 13:11 ` Marin David Condic
@ 2003-10-22 13:51 ` sk
0 siblings, 0 replies; 57+ messages in thread
From: sk @ 2003-10-22 13:51 UTC (permalink / raw)
To: comp.lang.ada
MDC :
> Not unless you'd freeze "Adaxx" and add only new stuff to
> "Adayy" - and I ...
Again I am not going to argue for "Adaxx" and as I have said,
I have no vested interest one way or another and the idea was
not intended as a version control.
From RI Eachus' discussion concerning the standards, and the
statement "But the current standard really is Ada 2000,", it
would suggest that the current "Ada.*", "Interfaces.*" etc are
not frozen either and there is absolutely nothing to prevent
vendors from silently implementing an AI update.
I am *almost* tempted to do "diffs" on all of the GNAT supplied
"Ada.*", "Interfaces.*" for 3,13p and 3.15p, both of which are
for Ada'95, to see if there are specification changes to meet AI
requirements.
... and again, this issue would occurr no matter what the "root"
package was called.
--
-------------------------------------------------
-- Merge vertically for real address
--
-- s n p @ t . o
-- k i e k c c m
-------------------------------------------------
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-19 16:41 Robert I. Eachus
` (2 preceding siblings ...)
2003-10-22 2:26 ` sk
@ 2003-10-22 4:26 ` sk
2003-10-22 11:14 ` Jeff C,
2003-10-23 5:41 ` sk
4 siblings, 1 reply; 57+ messages in thread
From: sk @ 2003-10-22 4:26 UTC (permalink / raw)
To: comp.lang.ada
"Robert I. Eachus" <rieachus@comcast.net>:
> What about Ada80.Sockets, Ada87.Sockets, and Ada2000.Sockets?
>
> The differences between some of these versions, and others not
> mentioned is slight. (For example, there were three differences
> between MIL-STD ...
Interesting, I must look at my LRM (after I find it) to see whether I
followed MIL-STD or ANSI/MIL-STD Ada'83 :-) This also might explain a
recent problem of ARM quoting where myself and another where quoting
from the same textual section/paragraph but were using different chapter
numbers. However, I don't see this as particularly limiting.
Another reason I would prefer a short and complete name, such as Ada95
is that "CAL", "SAL", "XAL", "EACHUS" etc. don't suggest what they are
and they are acronyms or peoples personal labels rather than being
descriptive etc.
> I'm not trying to be a stickler for accuracy here, just pointing out
> that the Ada standard is evolving. I'd hate to have the CAL come out
> labelled as Ada95 (or Ada2000) just in time for the Ada 0X standard.
Yes, but the inventory would be for *now* which is for Ada95 and prior,
when sub-packages become suitable for Ada0x, then they move to the Ada0x
tree. Not picking, just do not see the difficulty.
I am not fighting for my own idea, just trying to steer away from acronyms,
personal labels, or corporate hierarchy names (GNAT.Directory_Operations,
nothing against GNAT, but do not know how it will port to a platform not
supported by GNAT).
--
-------------------------------------------------
-- Merge vertically for real address
--
-- s n p @ t . o
-- k i e k c c m
-------------------------------------------------
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-22 4:26 ` sk
@ 2003-10-22 11:14 ` Jeff C,
2003-10-22 11:34 ` Stephane Richard
2003-10-22 12:12 ` sk
0 siblings, 2 replies; 57+ messages in thread
From: Jeff C, @ 2003-10-22 11:14 UTC (permalink / raw)
"sk" <noname@myob.com> wrote in message
news:mailman.162.1066796252.25614.comp.lang.ada@ada-france.org...
> "Robert I. Eachus" <rieachus@comcast.net>:
> > What about Ada80.Sockets, Ada87.Sockets, and Ada2000.Sockets?
> >
> > The differences between some of these versions, and others not
> > mentioned is slight. (For example, there were three differences
> > between MIL-STD ...
>
> Interesting, I must look at my LRM (after I find it) to see whether I
> followed MIL-STD or ANSI/MIL-STD Ada'83 :-) This also might explain a
> recent problem of ARM quoting where myself and another where quoting
> from the same textual section/paragraph but were using different chapter
> numbers. However, I don't see this as particularly limiting.
>
> Another reason I would prefer a short and complete name, such as Ada95
> is that "CAL", "SAL", "XAL", "EACHUS" etc. don't suggest what they are
> and they are acronyms or peoples personal labels rather than being
> descriptive etc.
>
> > I'm not trying to be a stickler for accuracy here, just pointing out
> > that the Ada standard is evolving. I'd hate to have the CAL come out
> > labelled as Ada95 (or Ada2000) just in time for the Ada 0X standard.
>
> Yes, but the inventory would be for *now* which is for Ada95 and prior,
> when sub-packages become suitable for Ada0x, then they move to the Ada0x
> tree. Not picking, just do not see the difficulty.
I think this is not the right path. When Ada 2020 comes out and we want to
add a new
subprogram to Ada05.Directory_Operations does that mean we now have an
Ada20.Directory_Operations
that looks the same but with the new procedure or do we add to it. No matter
what the answer is I don't think I
like it.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-22 11:14 ` Jeff C,
@ 2003-10-22 11:34 ` Stephane Richard
2003-10-22 12:23 ` sk
2003-10-22 12:12 ` sk
1 sibling, 1 reply; 57+ messages in thread
From: Stephane Richard @ 2003-10-22 11:34 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 865 bytes --]
"Jeff C," <nolongersafeto@userealemailsniff.com> wrote in message
news:uEtlb.204590$%h1.203097@sccrnsc02...
>
> I think this is not the right path. When Ada 2020 comes out and we want to
> add a new
> subprogram to Ada05.Directory_Operations does that mean we now have an
> Ada20.Directory_Operations
> that looks the same but with the new procedure or do we add to it. No
matter
> what the answer is I don't think I
> like it.
>
*** I agree, although I dont think it's that bad an idea, but Jeff is right,
the library shouldn't reflect what was used to develop it because it will
follow through Ada's evolution. An independant name like CAL or any other
for that matter would isolate the library from the language thus making the
motion from what version of Ada to the next seamless :-).
--
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-22 11:34 ` Stephane Richard
@ 2003-10-22 12:23 ` sk
2003-10-22 17:09 ` Robert I. Eachus
0 siblings, 1 reply; 57+ messages in thread
From: sk @ 2003-10-22 12:23 UTC (permalink / raw)
To: comp.lang.ada
stephane.richard@verizon.net:
> the library shouldn't reflect what was used to develop it
> because it will what was used to develop it because it will
> follow through Ada's evolution
I disagree, not with your naming disagreement since I have
absolutely no vested interest one way or another, but I disagree
with the idea that it shouldn't "reflect what was used to develop it".
If you have libraries hanging around for Ada83, you need to be
very aware that Ada83 techniques were used to develop it. Admittedly,
if you are compiling from source, this would rapidly become apparent
but there is a need to know which version of Ada the code was
intended to work with.
The naming scheme would give an immediate signal that there are
potentially very dangerous 'Address clauses and UC's going on in
the body which are totally uneccessary with Ada95.
--
-------------------------------------------------
-- Merge vertically for real address
--
-- s n p @ t . o
-- k i e k c c m
-------------------------------------------------
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-22 12:23 ` sk
@ 2003-10-22 17:09 ` Robert I. Eachus
2003-10-22 19:13 ` sk
0 siblings, 1 reply; 57+ messages in thread
From: Robert I. Eachus @ 2003-10-22 17:09 UTC (permalink / raw)
sk wrote:
> The naming scheme would give an immediate signal that there are
> potentially very dangerous 'Address clauses and UC's going on in
> the body which are totally uneccessary with Ada95.
Right now the XML grammer has a requires clause that can specify
libraries, hardware, operating systems, and compilers. Adding a
language version requirement as such is trivial.
But again, and this is why I am still at the thinking stage, right now
if you "require" two different hardware platforms or operating systems,
there is an implicit "or", while two software libraries have an implicit
"and". It may be worth making those explicit, or it might be better to
have a supports clause. That way supports Ada 95 and Ada 83 implies it
has been tested on both, while requires Ada 95 implies it doesn't work
under Ada 83. And of course, requires for a particular compiler would
be much more restrictive in meaning that supports that compiler. What
do you think?
--
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
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-22 17:09 ` Robert I. Eachus
@ 2003-10-22 19:13 ` sk
2003-10-23 2:17 ` Robert I. Eachus
0 siblings, 1 reply; 57+ messages in thread
From: sk @ 2003-10-22 19:13 UTC (permalink / raw)
To: comp.lang.ada
"Robert I. Eachus" <rieachus@comcast.net>:
> Right now the XML ...
> ... <snip> ...
> under Ada 83. And ...
Firstly, I am not too sure about how realistic the scenario of
having both Ada83 and Ada95 libraries co-residing in the same
development environment is. It was just an example of things that
need to be thought of.
My very limited exposure to cross-compiling on Linux suggests
that 2 completely separate libraries are maintained even if the
vast majority of the code is the same.
What do I think ? I don't think I understand all the implications
of what you are saying since I don't understand XML or have GNADE
installed :-)
However, since I am foaming at the brain for something, here are my
thoughts from march this year
NOTE: I am not a big fan of expanding the "Ada.*" or "Interfaces.*"
hierarchies. The "Ada.Strings.*" packages seem "alien" to me as
part of the ARM hierarchy and really should be (*my* opinion) in
the conceptual new package hierarchy. Limit the ARM hierarchy as
I quote Larry Killigan suggesting in one of the following messages.
-- 2003-05-03 Re: Ada2005 clear scressn etc. ----------------------
> Hi,
>
> <randhol+news@pvv.org> :
> > As a external library. I don't see the need for it. I mean next
> > will be that we should have some sort of GUI standard in the
> > Ada standard.
>
> In case anybody is starting a voting process on this, I am in the
> <randhol+news@pvv.org> group of hoping that specific platform needs
> are NOT incorporated into any new language standards.
>
> Let the market decide on useful *external* libraries, but do not
> burden the language itself with items possibly subject to fashion
> or politics.
>
> Eg, Sockets : Windows has an API for sockets, the rest of the world
> has another. I would not like for Ada, a few years from now, tied
> to the obsolete socket API when the politics gets sorted out and
> one API is accepted by all. Also especially since the abstract concept
> of "sockets" might have changed altogther and be called "connection" or
> "channel" or something.
-- 2003-06-03 Re: Ada2005 clear scressn etc. ----------------------
> Hi,
>
> Stephen.A.Leake@nasa.gov :
> > ... ANSI standard ...
>
> I was more panicing over the thought that the language
> be bound to some possibly transient fashion and hadn't
> stopped to consider some never dying, ubiquitous things
> like the ANSI terminal standard.
>
> However, I tend towards the <Kilgallen@SpamCop.net> comment
>
> > Because the Ada standard should be for things that require
> > support from the compiler vendor.
>
> and subsequent comments on the response cycle for a set of
> libraries.
>
> With that thought, how about an official but very flexible
> and distinctly separate package hierarchy ?
>
> (.. and I am sure it has been discussed before or there are
> comments as part of the Ada200y process, sorry for lack of
> opportunity to fully investigate. Also please note that I
> am not familiar with any of the ongoing Ada library projects
> or the "C++" standard library so, again, sorry if this is
> a rehash of other discussions or duplication of ideas so
> RTFM me, with URL, if appropriate).
>
> Standard
> Ada.xxx
> Interfaces.xxx
> System.xxx
>
> Libraries.xxx
>
> "Libraries" just a graft point, nothing significant about
> the name. "Libraries" would, by agreement, have some invarient
> subtrees. Perhaps two levels of abstract/conceptual packages
> before specific solutions are grafted into the tree ?
>
> Libraries.Vendor (invarient, children as needed)
> .Gnat.
> .Os_Lib;
> ...
> .RRSoftware
> .Claw
> ...
>
> Libraries.Host (invariant, children as needed)
> .Linux
> .Windows
> .Win32Ada
>
> Libraries.Host_Interfaces.
> .Console.
> .ANSI_Terminal
> <Perhaps the M.Feldman terminal package >
> .VT100_Terminal
> ...
> .Graphical
> .Win32Ada renames Libraries.Host.Windows.Win32Ada
> .GtkAda
> ...
> .File_System
> ...
> .Network
> .Transport
> .Sockets
> ...
> .Protocols
> .Smtp
> .Http
> ...
> .etc
>
> Libraries.Objects_And_Methods
> .Containers
> . <The current Container library project perhaps>
>
> .Strings
> <Just "Ada.Strings.*" as an example of the purpose
> for "Libraries.Objects_And_Methods">
>
> Libraries.Standardized_Interfaces
> .Posix
> .RFCs
>
> etc
>
> There are a lot of crossovers, but Ada has the "renames"
> mechanism which could associate "Libraries.Vendor.Gnat.Directory_Operations"
> for example,
> with "Libraries.Host_Interfaces.File_System.Directories"
>
> This needs a lot more thought and work (rearrangment, better
> nameing, interdependencies, circularity, management burden etc),
> however, it could provide a more cohesive framework into which
> APIs would fit without burdening the core language or its "Ada.*"
> package hierarchy.
-----------------------------------------------------------------------
--
-------------------------------------------------
-- Merge vertically for real address
--
-- s n p @ t . o
-- k i e k c c m
-------------------------------------------------
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-22 19:13 ` sk
@ 2003-10-23 2:17 ` Robert I. Eachus
2003-10-23 5:20 ` sk
0 siblings, 1 reply; 57+ messages in thread
From: Robert I. Eachus @ 2003-10-23 2:17 UTC (permalink / raw)
sk wrote:
> However, since I am foaming at the brain for something, here are my
> thoughts from march this year
...
> > Libraries.xxx
> >
> > "Libraries" just a graft point, nothing significant about
> > the name. "Libraries" would, by agreement, have some invarient
> > subtrees. Perhaps two levels of abstract/conceptual packages
> > before specific solutions are grafted into the tree ?
> >
As good as any other...
> > Libraries.Vendor (invarient, children as needed)
> > .Gnat.
> > .Os_Lib;
> > ...
> > .RRSoftware
> > .Claw
> > ...
> >
> > Libraries.Host (invariant, children as needed)
> > .Linux
> > .Windows
> > .Win32Ada...
More a style comment than anything else, I think this hierarchy is not
bushy enough to be natural for Ada. For example, above I would prefer:
Libraries.Gnat.
Libraries.Claw
Libraries.Linux
Libraries.Windows
As the second level entries. We are all big boys and girls who know how
to use grep, or the equivalent if we need to do a search. It might be
worth having OS as a second level, but only if it didn't push things
toward a renames. How about:
Libs.OS.Linux
Libs.OS.Windows...
Of course, resolving this is important. But as far as the registry
project goes, I need to register what exists now.
--
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
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-23 2:17 ` Robert I. Eachus
@ 2003-10-23 5:20 ` sk
2003-10-23 14:39 ` Robert I. Eachus
0 siblings, 1 reply; 57+ messages in thread
From: sk @ 2003-10-23 5:20 UTC (permalink / raw)
To: comp.lang.ada
rieachus@comcast.net:
> ... I would prefer:
>
> Libraries.Gnat.
> Libraries.Claw
> Libraries.Linux
> Libraries.Windows
Personally, I would prefer conceptual, "OS", "Network", "Vendor" at
the second level but I also see that this can become very messy. I
did like the idea of the tree that was the R1000 environment but at
the same time, it became a pain trying to remember where everything
was.
> Libs. ...
Everyone knows that "Libs" means "Libraries" but the shortened form
bugs me like acronyms do, anal retentive I know, but why not spell
every thing out ?
> ... I need to register what exists now.
Ah, I was under the impression from the other thread that you were
proposing a formal approach before collecting data. Admittedly, I
have been having more fun trying to bait Russ, but it seems as if the
other thread has become a discussion between MDCondic and WGGay over
how to put a library together, either highly competitive or highly
cooperative.
Regardless, I posted my thoughts to see how others felt and I am
not too concerned (not zealous) about any of my issues as long as
the process has a certain level of open discussion.
> ... I need to register what exists now.
... and from a previous post ...
> I think we should be aiming for the future, not the past.
Not XOR but there seems to be a certain OR about the two statements :-)
--
-------------------------------------------------
-- Merge vertically for real address
--
-- s n p @ t . o
-- k i e k c c m
-------------------------------------------------
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-23 5:20 ` sk
@ 2003-10-23 14:39 ` Robert I. Eachus
0 siblings, 0 replies; 57+ messages in thread
From: Robert I. Eachus @ 2003-10-23 14:39 UTC (permalink / raw)
sk wrote:
> > ... I need to register what exists now.
>
> ... and from a previous post ...
>
> > I think we should be aiming for the future, not the past.
>
> Not XOR but there seems to be a certain OR about the two statements :-)
Exactly. Marins want to find a better way to determine what user
requirements for a standard library are. I think that the registry will
eventually turn into a resource that indicates what actually exists now
(or at some point in the future) and what of that is used. Then others
will be able to take this set and evolve it toward a consistant library.
I certainly have no objection to a "standard" library that comes in
pieces supplied by different authors and groups and where one of the
things that the standard library provides is "fixed points" where all of
the components have been synchronized so that there is no version skew.
Users can then take one or more later versions of particular
components, but will have to be aware of the potential version skew
problems.
--
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
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-22 11:14 ` Jeff C,
2003-10-22 11:34 ` Stephane Richard
@ 2003-10-22 12:12 ` sk
1 sibling, 0 replies; 57+ messages in thread
From: sk @ 2003-10-22 12:12 UTC (permalink / raw)
To: comp.lang.ada
nolongersafeto@userealemailsniff.com:
> I think this is not the right path. When Ada 2020 comes out and
> we want to add a new subprogram to Ada05.Directory_Operations
> does that mean we now have an Ada20.Directory_Operations that looks
> the same but with the new procedure or do we add to it. No matter
> what the answer is I don't think I like it.
The Ada83, Ada95, Ada0x scheme was intended to imply a "works-with"
relationship rather than a versioning relationship.
For example, there is a good chance that an Ada83.Directory_Operations
would resort to the subprogram'address methods for binding whereas
the Ada95.Directory_Operations would take advantage of the Interfaces.*
hierarchy and also possibly the subprogram'access capability of Ada'95.
I think the issue you describe tends to be a versioning issue rather
than a library-hierarchy issue and would occurr whether the root name
for the library was "root", "Ada95" or "CAL".
--
-------------------------------------------------
-- Merge vertically for real address
--
-- s n p @ t . o
-- k i e k c c m
-------------------------------------------------
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-19 16:41 Robert I. Eachus
` (3 preceding siblings ...)
2003-10-22 4:26 ` sk
@ 2003-10-23 5:41 ` sk
2003-10-23 15:01 ` Robert I. Eachus
4 siblings, 1 reply; 57+ messages in thread
From: sk @ 2003-10-23 5:41 UTC (permalink / raw)
To: comp.lang.ada
me:
> certain level of open discussion.
I need to highlight *open* and I must confess some discomfort
over the implications of another message of this thread
rieachus@comcast.net:
> Stephane Richard wrote:
> > ... copyright as we discussed in emails?
>
> I think ...
--
-------------------------------------------------
-- Merge vertically for real address
--
-- s n p @ t . o
-- k i e k c c m
-------------------------------------------------
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-23 5:41 ` sk
@ 2003-10-23 15:01 ` Robert I. Eachus
2003-10-23 19:03 ` Alexandre E. Kopilovitch
` (3 more replies)
0 siblings, 4 replies; 57+ messages in thread
From: Robert I. Eachus @ 2003-10-23 15:01 UTC (permalink / raw)
sk wrote:
> me:
> > certain level of open discussion.
>
> I need to highlight *open* and I must confess some discomfort
> over the implications of another message of this thread
>
> rieachus@comcast.net:
> > Stephane Richard wrote:
> > > ... copyright as we discussed in emails?
> >
> > I think ...
Don't worry about it. I said that I thought that the first version of
the XML document was not something I would be comfortable posting, but I
would send copies to anyone who wanted to review it. Stephane Richard
was willing to do so. Unless there are significant changes, or more
people who want to take a shot at the current XML state, I will probably
post version 0.2 to comp.lang.ada tomorrow. Another potential delay is
that I am probably going to write an XML to HTML converter this weekend,
so you can look at the HTML to make comments.
No intent to exclude anyone, but XML is still not all that common a
language, and I felt the intersection of those who knew XML well enough
to comment, and were also interested in the registry project would be
pretty small. Hmmm. Actually, why not? Here is the current XML
DOCTYPE, and the start of the registry declaration. If you want a
snapshot of the whole thing, send e-mail. But, please, only if you are
willing to read it and comment.:
<?xml version="1.0" encoding="UTF-8" standalone=yes ?>
<!DOCTYPE Ada_Component_Registry [
<!-- Version 0.2 Doctype Copyright 2003 by Robert I. Eachus, copying
allowed, all other rights reserved for now. -->
<!ELEMENT Registry (Author*, Project+, Entry+) >
<!ATTLIST Registry
Name CDATA #REQUIRED
Version CDATA #REQUIRED
Website CDATA #IMPLIED
Copyright CDATA #REQUIRED
>
<!ELEMENT Project (Author*, Requires*, Supports*, Description?)
<!ATTLIST Project
Name CDATA #REQUIRED
Version CDATA #IMPLIED
Website CDATA #IMPLIED
Bug_Reports CDATA #REQUIRED
Copyright CDATA #REQUIRED
>
<!ELEMENT Entry (Author+, Description?, Requires*, Supports*,
Contents?)
<!ATTLIST Entry
Name CDATA #REQUIRED
Project CDATA #REQUIRED
Version CDATA #IMPLIED
Source CDATA #IMPLIED
Copyright CDATA #IMPLIED
>
<!ELEMENT Author>
<!ATTLIST Author
Name CDATA #REQUIRED
Email CDATA #IMPLIED
Telephone CDATA #IMPLIED
Company CDATA #IMPLIED
Address CDATA #IMPLIED
>
<!ELEMENT Compiler >
<!ATTLIST Compiler
Name CDATA #REQUIRED
Version CDATA #IMPLIED
>
<!ELEMENT Contents (#PCDATA )>
<!ELEMENT Database>
<!ATTLIST Database
Name CDATA #REQUIRED
Version CDATA #IMPLIED
>
<!ELEMENT Date (((Month, Day?)?, Year)|#PCDATA)>
<!ELEMENT Description (#PCDATA )>
<!ELEMENT Full_Name (#PCDATA )>
<!ELEMENT Language
<!ATTLIST Language
Version (Ada80 | Ada83 | Ada95 | Ada2000 | Ada0X) "Ada95"
<!ELEMENT OS>
<!ATTLIST OS
Name CDATA #REQUIRED
Version CDATA #IMPLIED
>
<!ELEMENT Project_Name (#PCDATA ) >
<!ELEMENT Requires (Project_Name|Compiler|OS|Hardware)+ >
<!ELEMENT Supports (Language_Version|Compiler|OS|Hardware)+ >
<!ELEMENT Root_Name (#PCDATA )>
<!ELEMENT URL (#PCDATA ) >
<!ELEMENT Version (#PCDATA)>
<!ATTLIST Version Date CDATA >
<!ELEMENT Website (#PCDATA) >
]>
<Registry Name="Ada Component Registry"
Version="0.2"
Copyright="Copyright 2003 by Robert I. Eachus, copying
allowed, all other rights reserved for now."
>
--
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
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-23 15:01 ` Robert I. Eachus
@ 2003-10-23 19:03 ` Alexandre E. Kopilovitch
2003-10-23 23:58 ` sk
` (2 subsequent siblings)
3 siblings, 0 replies; 57+ messages in thread
From: Alexandre E. Kopilovitch @ 2003-10-23 19:03 UTC (permalink / raw)
To: comp.lang.ada
Robert I. Eachus wrote:
> No intent to exclude anyone, but XML is still not all that common a
> language, and I felt the intersection of those who knew XML well enough
> to comment, and were also interested in the registry project would be
> pretty small.
Yes, this is most probably true - both things are doubtful: XML does not seem
good notation, it is probably worse that many programming languages in this
respect... perhaps there should be translators *into* XML; as for the registry
project, it is still unclear why it will be more useful than, say, AdaPower,
and whether it has chances to survive.
> Hmmm. Actually, why not? Here is the current XML
> DOCTYPE, and the start of the registry declaration.
>From what is presented so far, I conclude that the registry will contain only
one major kind of entities - Projects. I think that this is wrong way to go,
because such a registry will not differ fundamentally from corresponding part
of AdaPower (still most successful Ada-oriented website), and will suffer from
the same principal problems (yes, it may be equipped with various technical,
legal and procedural elements, but all that will not save the thing).
I think that any really useful and alive registry of this kind should contain
also 2 other major kinds of entities: 1) reviews and 2) design patterns.
Alexander Kopilovitch aek@vib.usr.pu.ru
Saint-Petersburg
Russia
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-23 15:01 ` Robert I. Eachus
2003-10-23 19:03 ` Alexandre E. Kopilovitch
@ 2003-10-23 23:58 ` sk
2003-10-24 1:02 ` Robert I. Eachus
[not found] ` <mSBO2c_KxF@vib.usr.pu.ru>
2003-10-24 13:39 ` sk
3 siblings, 1 reply; 57+ messages in thread
From: sk @ 2003-10-23 23:58 UTC (permalink / raw)
To: comp.lang.ada
"Robert I. Eachus" <rieachus@comcast.net>:
> Here is the current XML DOCTYPE, and the ...
Is your proposal just for a registry of packages and not
to actually put together a library in terms of packages ?
I must admit that if this is the case, I have probably
volunteered for something I thought was something else :-)
Another thought, what would the "registry" provide more than
an equivalent web page of links to other peoples packages ?
--
-------------------------------------------------
-- Merge vertically for real address
--
-- s n p @ t . o
-- k i e k c c m
-------------------------------------------------
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-23 23:58 ` sk
@ 2003-10-24 1:02 ` Robert I. Eachus
2003-10-24 1:18 ` Stephane Richard
` (2 more replies)
0 siblings, 3 replies; 57+ messages in thread
From: Robert I. Eachus @ 2003-10-24 1:02 UTC (permalink / raw)
sk wrote:
> Is your proposal just for a registry of packages and not
> to actually put together a library in terms of packages ?
Correct. It should end up being an inventory of what exists and is
available, as well as, a guide to who is using which names. But that is
information useful to someone putting together a consistant library, not
a library in and of itself.
> I must admit that if this is the case, I have probably
> volunteered for something I thought was something else :-)
>
> Another thought, what would the "registry" provide more than
> an equivalent web page of links to other peoples packages ?
Yes. If nothing else the existance of the registry should make it much
easier for people to find out what is "out there" and available for use.
So it will promote reuse just by existing.
But only if combined with a project to pull together a joint library
will it fullfill its intended purpose. I chose this as a first step I
can make happen.
--
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
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-24 1:02 ` Robert I. Eachus
@ 2003-10-24 1:18 ` Stephane Richard
2003-10-24 13:23 ` sk
2003-10-24 17:50 ` Alexandre E. Kopilovitch
2 siblings, 0 replies; 57+ messages in thread
From: Stephane Richard @ 2003-10-24 1:18 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]
"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:3F9879DA.6070205@comcast.net...
>
> Yes. If nothing else the existance of the registry should make it much
> easier for people to find out what is "out there" and available for use.
> So it will promote reuse just by existing.
>
> But only if combined with a project to pull together a joint library
> will it fullfill its intended purpose. I chose this as a first step I
> can make happen.
>
> --
> Robert I. Eachus
I see that as a good first step. For all of us whether we just want to know
what's out there or want to create our own in fields not yet touched by what
is out there, we need to know somehow. Once we have that list of existing
stuff out there, we can fill in the gaps. Talk to the authors of what's out
there see what we can do about incorporating their efforts within the
library, etc etc..
--
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-24 1:02 ` Robert I. Eachus
2003-10-24 1:18 ` Stephane Richard
@ 2003-10-24 13:23 ` sk
2003-10-24 13:30 ` Stephane Richard
2003-10-24 17:50 ` Alexandre E. Kopilovitch
2 siblings, 1 reply; 57+ messages in thread
From: sk @ 2003-10-24 13:23 UTC (permalink / raw)
To: comp.lang.ada
"Robert I. Eachus" <rieachus@comcast.net>:
> Correct. ...
Fair enough. Makes any of my proposed naming schemes
irrelevent though :-)
So it would seem that your DB categories would be
something along the lines of "Vendors", "Tools", "Papers",
"Libraries" etc ? Or would you be limiting to code
based ("Libraries", "Tools") items ?
> ... "out there" and available for use
I like the idea of being able to centrally find what is
"out there". Traveling from AdaIC yesterday reminded me of
links and introduced me to others. However, there are
too many dead/bad/out-of-date links (not just AdaIC,
AdaPower too) which quickly discourages one from further
exploration and hints (possibly falsly) at a lack of website
interest or maintenence.
I know I should wait for your HTML publication before asking,
but have you allowed for a mechanism, within the Registry,
which will ensure that a potential user does not quickly
get annoyed by dead-[links,entries] and give up using it ?
--
-------------------------------------------------
-- Merge vertically for real address
--
-- s n p @ t . o
-- k i e k c c m
-------------------------------------------------
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-24 13:23 ` sk
@ 2003-10-24 13:30 ` Stephane Richard
2003-10-24 15:11 ` sk
2003-10-24 17:31 ` tmoran
0 siblings, 2 replies; 57+ messages in thread
From: Stephane Richard @ 2003-10-24 13:30 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2179 bytes --]
"sk" <noname@myob.com> wrote in message >
> I know I should wait for your HTML publication before asking,
> but have you allowed for a mechanism, within the Registry,
> which will ensure that a potential user does not quickly
> get annoyed by dead-[links,entries] and give up using it ?
>
> --
> -------------------------------------------------
> -- Merge vertically for real address
> --
> -- s n p @ t . o
> -- k i e k c c m
> -------------------------------------------------
>
I think I can answer that one well to a certain point :-).
You see, ultimately we could do a bot of our own crawling the web as per the
list of URLs tha appear in the XML file and write a log (successful or non
successful) in trying to get to the library's webpage. The library authors
would need to assure to update such things as URL Changes to their libraries
or to noticy somehow (via email perhaps) or simply by udpating the XML file
that the library is out of commission or could be taken over by someone
else.
Likewise we could also, instead of linking to, hosting the libraries
themselves so that it doesn't become the responsibility of the author but of
the library maintenance team to assure proper linkage to available source
code. Of course this last suggestion is pending the author's approval to
have his library hosted (or mirror) on the library website.(in lieu of or in
addition to the current place where the library is hosted). Just for the
sake that should the author's current location go down or the library is
abandonned (for any reason) then perhaps another programmer can continue
it's development right on the website). Of course, as mentionned, this
would work provided the library authors agree to having us host the code (or
mirror ir) locally here.
Having each library element hosted locally would give us full control over
the availability of the library which does have it's advantage :-). not to
mention an instant backup for the authors in case their other hosting places
go down whether for maintenance or permanently we'd still have their
library(ies) there for them.
--
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-24 13:30 ` Stephane Richard
@ 2003-10-24 15:11 ` sk
2003-10-24 17:12 ` Robert I. Eachus
2003-10-24 17:31 ` tmoran
1 sibling, 1 reply; 57+ messages in thread
From: sk @ 2003-10-24 15:11 UTC (permalink / raw)
To: comp.lang.ada
Stephane Richard <stephane.richard@verizon.net>:
> ... bot of our own crawling the web ...
A manual crawl from AdaIC's site map from "Cetus OO-Ada",
for example, quickly leads to a seeming infinite links
to links etc.
Based on the above, and
> ... provided the library authors agree to having us host
> the code ...
[at AdaWorld, presumably] this is *massive*.
Gaining the cooperation of all concerned might be a problem
especially over the hosting issue.
How big a problem I do not know, but it could render the
Registry useless if valuable resources do not wish to
participate. Or even worse, participate with everything but
the hosting and then disappear.
> ... library maintenance team ...
Is it a library or a Registry ?
This is an important distinction for me which can probably
only be answered by waiting for RIEachus' full proposal :-)
--
-------------------------------------------------
-- Merge vertically for real address
--
-- s n p @ t . o
-- k i e k c c m
-------------------------------------------------
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-24 15:11 ` sk
@ 2003-10-24 17:12 ` Robert I. Eachus
2003-10-25 0:03 ` sk
0 siblings, 1 reply; 57+ messages in thread
From: Robert I. Eachus @ 2003-10-24 17:12 UTC (permalink / raw)
sk wrote:
> This is an important distinction for me which can probably
> only be answered by waiting for RIEachus' full proposal :-)
The problem is one of terminology. I am developing A registry, and a
set registry maintenance software and tools that should result in many
people taking THE registry, and adding their proprietary software
libraries to it. No reason they shouldn't, and if they do it by having
a local registry they merge with each new release of THE registry, the
whole process should be fairly painless. If at some point they decide
to publish some of their local tools, great.
In the context of what I will call the Common Ada Library (CAL)
proposal, the registry software can be used to maintain a subset which
is the CAL. It would almost certainly have much stricter rules for
inclusion than my version of the registry. Again, if people want to
comply with the "extra" rules needed for CAL and sumbit their software
there, great. So the goal is that software components will migrate:
Local library/registry --> Global registry --> CAL.
That is part of what I mean when I talk about evolution.
--
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
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-24 17:12 ` Robert I. Eachus
@ 2003-10-25 0:03 ` sk
2003-10-25 17:43 ` Robert I. Eachus
0 siblings, 1 reply; 57+ messages in thread
From: sk @ 2003-10-25 0:03 UTC (permalink / raw)
To: comp.lang.ada
"Robert I. Eachus" <rieachus@comcast.net>
> ... should result in many people taking THE registry ...
Randy Brukardt recently noted that AdaIC has ability to
find libraries ("Re: setjmp/longjmp?" thread) and then
"The only problem with it is that a lot of people never
have nominated their sites for inclusion. (In which case,
of course, they're not indexed at all.)"
My question is why would you expect the participation
with the Registry to be any different than the experience
with AdaIC or other websites ?
> ... set registry maintenance software and tools ...
I am not going to waste any more of your time on implementation
details until you have published your proposal so that there
is actually something to comment about.
--
-------------------------------------------------
-- Merge vertically for real address
--
-- s n p @ t . o
-- k i e k c c m
-------------------------------------------------
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-25 0:03 ` sk
@ 2003-10-25 17:43 ` Robert I. Eachus
2003-10-25 18:53 ` Marius Amado Alves
2003-10-26 2:28 ` sk
0 siblings, 2 replies; 57+ messages in thread
From: Robert I. Eachus @ 2003-10-25 17:43 UTC (permalink / raw)
sk wrote:
> My question is why would you expect the participation
> with the Registry to be any different than the experience
> with AdaIC or other websites ?
Different purpose if you will. Registering a website or whatever on
AdaIC just adds one more place that people can look and maybe find your
reusable library. With the registry, the main benefit for everyone is a
standard format for describing reusable software. Even if you don't
share your software with anyone, or outside your own company, using the
standard repository format to describe and link to it should make it
easier for people to use--even you. (And if it doesn't do that, it will
fail.)
And what I have already found from experiments is that the level of
effort to do a good job of entering an existing library is significant,
but the rewards are worth it. For example, did you know that there is a
binding to Oracle's OCI as part of GNADE? I didn't until I downloaded
the Zip file and walked the directory heirarchy looking to see what was
there.
--
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
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-25 17:43 ` Robert I. Eachus
@ 2003-10-25 18:53 ` Marius Amado Alves
2003-10-25 21:11 ` Marin David Condic
2003-10-26 2:28 ` sk
1 sibling, 1 reply; 57+ messages in thread
From: Marius Amado Alves @ 2003-10-25 18:53 UTC (permalink / raw)
To: Robert I. Eachus; +Cc: comp.lang.ada
On Sat, 2003-10-25 at 17:43, Robert I. Eachus wrote:
> sk wrote:
>
> > My question is why would you expect the participation
> > with the Registry to be any different than the experience
> > with AdaIC or other websites ?
>
> Different purpose if you will. Registering a website or whatever on
> AdaIC just adds one more place that people can look and maybe find your
> reusable library. With the registry, the main benefit for everyone is a
> standard format for describing reusable software.
That sounds no less than solving the essential difficulty of
component-oriented software engineering--GO FOR IT!
But I agree with others on this list that a volunteer basis only will
not get us there. Some hard commitment i.e. money is necessary. And some
kind of executive/business plan is necessary to gather this kind of
support. Note I'm not against the current technical work on the
Registry. This and other technical elements are necessary for *any*
plan. I also feel the lack of a work plan.
A marketeer's challenge: a shorter term for "solving the essential
difficulty of component-oriented software engineering." Tip:
"component-oriented programming" = "mega-programming".
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-25 18:53 ` Marius Amado Alves
@ 2003-10-25 21:11 ` Marin David Condic
2003-10-25 21:23 ` Robert I. Eachus
0 siblings, 1 reply; 57+ messages in thread
From: Marin David Condic @ 2003-10-25 21:11 UTC (permalink / raw)
I don't think that a committment of money is necessary at exactly this
point in time - although if the vendors or the government or someone
wants to jump up and fund the whole thing, I wouldn't stop them. ;-)
What would be a good first step from the standpoint of the vendors would
be simply to indicate some interest in the project and a willingness to
participate in some way to guide it along, with the implication that a
successful start would be adopted and distributed with their compilers.
(No committments - just a willingness to distribute it *if* it meets
expectations.)
Money is a matter that needs to be considered if they expect the library
to get any bigger than a few container packages. If all they want is
container packages, there's plenty of "Volunteer-Speculation-Efforts"
out there from which to pick already.
MDC
Marius Amado Alves wrote:
>
> But I agree with others on this list that a volunteer basis only will
> not get us there. Some hard commitment i.e. money is necessary. And some
> kind of executive/business plan is necessary to gather this kind of
> support. Note I'm not against the current technical work on the
> Registry. This and other technical elements are necessary for *any*
> plan. I also feel the lack of a work plan.
>
--
======================================================================
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
"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
======================================================================
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-25 21:11 ` Marin David Condic
@ 2003-10-25 21:23 ` Robert I. Eachus
2003-10-25 21:28 ` Marin David Condic
0 siblings, 1 reply; 57+ messages in thread
From: Robert I. Eachus @ 2003-10-25 21:23 UTC (permalink / raw)
Marin David Condic wrote:
> I don't think that a committment of money is necessary at exactly this
> point in time - although if the vendors or the government or someone
> wants to jump up and fund the whole thing, I wouldn't stop them. ;-)
Same here. Someone jumping up and supporting the registry part might
seem like a wonderful thought, but I think I need to push things along
further before adding money to the equation would help, not hurt.
Another way of saying it is that as long as everything is on a volunteer
basis, there is no time spent arguing about/deciding how or where the
money should be spent.
--
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
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-25 21:23 ` Robert I. Eachus
@ 2003-10-25 21:28 ` Marin David Condic
2003-10-26 0:24 ` Stephane Richard
0 siblings, 1 reply; 57+ messages in thread
From: Marin David Condic @ 2003-10-25 21:28 UTC (permalink / raw)
Yeah, but it would be nice to see that all/some/one of the vendors had
some mild interest in the project - or is it all a pipe dream?
MDC
Robert I. Eachus wrote:
>
> Another way of saying it is that as long as everything is on a volunteer
> basis, there is no time spent arguing about/deciding how or where the
> money should be spent.
>
--
======================================================================
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
"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
======================================================================
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-25 21:28 ` Marin David Condic
@ 2003-10-26 0:24 ` Stephane Richard
2003-10-26 13:36 ` Marin David Condic
0 siblings, 1 reply; 57+ messages in thread
From: Stephane Richard @ 2003-10-26 0:24 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1960 bytes --]
Well I talked to ACT quickly, I'm still waiting for a phone call which it
looks like I'll have to remind them of it seems :-). But nonetheless, they
did recognize the effort, they do follow c.l.a. pretty good, now to wait for
em to say something. but I need to talk to that dude first. Guess at the
time it was too early to pronounce themselves but they didn't categorically
reject it either (so far). Maybe all they are waiting for is something to
look at (hence what Robert is doing) so they can see how it is planned to
work, give them a basis of an idea of what it might look like and as Robert
said how easily usable it is as far as concepts goes.
I'll get in touch with them again monday probably.
--
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com
"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F9AEB09.9020102@noplace.com...
> Yeah, but it would be nice to see that all/some/one of the vendors had
> some mild interest in the project - or is it all a pipe dream?
>
> MDC
>
> Robert I. Eachus wrote:
> >
> > Another way of saying it is that as long as everything is on a volunteer
> > basis, there is no time spent arguing about/deciding how or where the
> > money should be spent.
> >
>
>
> --
> ======================================================================
> 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
>
> "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
> ======================================================================
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-26 0:24 ` Stephane Richard
@ 2003-10-26 13:36 ` Marin David Condic
2003-10-26 16:02 ` Martin Dowie
2003-10-26 16:34 ` Stephane Richard
0 siblings, 2 replies; 57+ messages in thread
From: Marin David Condic @ 2003-10-26 13:36 UTC (permalink / raw)
Well, that's something. ACT is probably the most active in enhancing
their Ada product - I don't know what the other vendors are up to or if
they anticipate making any significant enhancements to their compiler at
all. If ACT were driving it and it was available for other vendors to
adopt, that might be a suitable way to go.
It might be a good idea to get a read on the relative interest of other
vendors and some fix on how actively they are developing their compiler.
That's where the ARG could be useful - if a vendor has a representative
on the ARG, they are probably interested in Ada's future, have some
willingness to extend their Ada product and could be asked to comment on
the interest in a library. If they don't have a representative on the
ARG, then its a good bet they aren't terribly interested in any future
enhancements to their Ada compiler - if they don't care enough about
major syntactic/semantic changes to Ada, then they almost certainly
won't care about a relatively lesser thing like a library.
One other thing the ARG would be good for - comment on what is already
planned or likely to be planned for the next issue of Ada. I had heard
talk of a file system interface package and probably some additional
things, but I don't know that there is a current plan to have any sort
of containers. They might conceivably comment on two other issues: 1) If
Ada were to get a CAL, what should the first area(s) of priority be?
(Containers? Math? Network? OS?...) 2) Are there any criteria they would
find important in ultimately accepting or rejecting a CAL as being "part
of Ada"? (Style issues? Domain issues? Platform issues? - Basically what
sorts of things might get the CAL shot down and rejected.)
Since we have an ARG member (or two, or three...) listening in - maybe
there's some comment? Say something to me off line if you'd prefer to
discuss it out of the public eye. (See my return address in the .SIG)
MDC
Stephane Richard wrote:
> Well I talked to ACT quickly, I'm still waiting for a phone call which it
> looks like I'll have to remind them of it seems :-). But nonetheless, they
> did recognize the effort, they do follow c.l.a. pretty good, now to wait for
> em to say something. but I need to talk to that dude first. Guess at the
> time it was too early to pronounce themselves but they didn't categorically
> reject it either (so far). Maybe all they are waiting for is something to
> look at (hence what Robert is doing) so they can see how it is planned to
> work, give them a basis of an idea of what it might look like and as Robert
> said how easily usable it is as far as concepts goes.
>
> I'll get in touch with them again monday probably.
>
--
======================================================================
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
"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
======================================================================
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-26 13:36 ` Marin David Condic
@ 2003-10-26 16:02 ` Martin Dowie
2003-10-26 16:45 ` sk
2003-10-26 21:54 ` Marin David Condic
2003-10-26 16:34 ` Stephane Richard
1 sibling, 2 replies; 57+ messages in thread
From: Martin Dowie @ 2003-10-26 16:02 UTC (permalink / raw)
"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F9BCDE0.1070704@noplace.com...
> One other thing the ARG would be good for - comment on what is already
> planned or likely to be planned for the next issue of Ada. I had heard
> talk of a file system interface package and probably some additional
> things, but I don't know that there is a current plan to have any sort
> of containers.
No, check out AI-302 (both proposals :-)
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-26 16:02 ` Martin Dowie
@ 2003-10-26 16:45 ` sk
2003-10-26 21:54 ` Marin David Condic
1 sibling, 0 replies; 57+ messages in thread
From: sk @ 2003-10-26 16:45 UTC (permalink / raw)
To: comp.lang.ada
Martin Dowie <martin.dowie@btopenworld.com>:
> No, check out AI-302 (both proposals :-)
After *scanning* these AI's can I ask if there
is any thought to keeping additional libraries
*out* of the ARM and in a separate hierarchy.
I ask, because the thrust of the naming schemes
I proposed earlier in the thread were to try to
keep away from the "Ada.*", "Interfaces.*" etc
unless necessary. The additional libraries are
just something that I think is not part of the
core language definition.
If there are any thoughts in this direction, how
seriously are they being considered ?
--
-------------------------------------------------
-- Merge vertically for real address
--
-- s n p @ t . o
-- k i e k c c m
-------------------------------------------------
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-26 16:02 ` Martin Dowie
2003-10-26 16:45 ` sk
@ 2003-10-26 21:54 ` Marin David Condic
1 sibling, 0 replies; 57+ messages in thread
From: Marin David Condic @ 2003-10-26 21:54 UTC (permalink / raw)
"No" - what? Not clear. "No, there isn't a file system interface"? "No,
there isn't a container library"? There was talk of having some ability
to access directories and files via some standard Ada package, so I know
that was discussed. Not planned?
If the ARG is not planning to add a container library, would they like
to see one as the first priority? Any problem with the ones that already
exist? (Id est, let's not go build yet another container library and do
the same things that made existing ones unattractive...)
MDC
Martin Dowie wrote:
> "Marin David Condic" <nobody@noplace.com> wrote in message
> news:3F9BCDE0.1070704@noplace.com...
>
>>One other thing the ARG would be good for - comment on what is already
>>planned or likely to be planned for the next issue of Ada. I had heard
>>talk of a file system interface package and probably some additional
>>things, but I don't know that there is a current plan to have any sort
>>of containers.
>
>
> No, check out AI-302 (both proposals :-)
>
>
>
>
--
======================================================================
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
======================================================================
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-26 13:36 ` Marin David Condic
2003-10-26 16:02 ` Martin Dowie
@ 2003-10-26 16:34 ` Stephane Richard
1 sibling, 0 replies; 57+ messages in thread
From: Stephane Richard @ 2003-10-26 16:34 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3963 bytes --]
Yeah, it's a step in the right direction :-). I just emailed him again to
arrange another phone call if he can. I also stated questions and issues
(as in what we'd like from vendors in general). so he can answer them if he
can't call me...so we'll see tomorrow or tuesday :-).
--
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com
"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F9BCDE0.1070704@noplace.com...
> Well, that's something. ACT is probably the most active in enhancing
> their Ada product - I don't know what the other vendors are up to or if
> they anticipate making any significant enhancements to their compiler at
> all. If ACT were driving it and it was available for other vendors to
> adopt, that might be a suitable way to go.
>
> It might be a good idea to get a read on the relative interest of other
> vendors and some fix on how actively they are developing their compiler.
> That's where the ARG could be useful - if a vendor has a representative
> on the ARG, they are probably interested in Ada's future, have some
> willingness to extend their Ada product and could be asked to comment on
> the interest in a library. If they don't have a representative on the
> ARG, then its a good bet they aren't terribly interested in any future
> enhancements to their Ada compiler - if they don't care enough about
> major syntactic/semantic changes to Ada, then they almost certainly
> won't care about a relatively lesser thing like a library.
>
> One other thing the ARG would be good for - comment on what is already
> planned or likely to be planned for the next issue of Ada. I had heard
> talk of a file system interface package and probably some additional
> things, but I don't know that there is a current plan to have any sort
> of containers. They might conceivably comment on two other issues: 1) If
> Ada were to get a CAL, what should the first area(s) of priority be?
> (Containers? Math? Network? OS?...) 2) Are there any criteria they would
> find important in ultimately accepting or rejecting a CAL as being "part
> of Ada"? (Style issues? Domain issues? Platform issues? - Basically what
> sorts of things might get the CAL shot down and rejected.)
>
> Since we have an ARG member (or two, or three...) listening in - maybe
> there's some comment? Say something to me off line if you'd prefer to
> discuss it out of the public eye. (See my return address in the .SIG)
>
> MDC
>
> Stephane Richard wrote:
> > Well I talked to ACT quickly, I'm still waiting for a phone call which
it
> > looks like I'll have to remind them of it seems :-). But nonetheless,
they
> > did recognize the effort, they do follow c.l.a. pretty good, now to wait
for
> > em to say something. but I need to talk to that dude first. Guess at
the
> > time it was too early to pronounce themselves but they didn't
categorically
> > reject it either (so far). Maybe all they are waiting for is something
to
> > look at (hence what Robert is doing) so they can see how it is planned
to
> > work, give them a basis of an idea of what it might look like and as
Robert
> > said how easily usable it is as far as concepts goes.
> >
> > I'll get in touch with them again monday probably.
> >
>
>
> --
> ======================================================================
> 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
>
> "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
> ======================================================================
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-25 17:43 ` Robert I. Eachus
2003-10-25 18:53 ` Marius Amado Alves
@ 2003-10-26 2:28 ` sk
2003-10-26 18:11 ` Robert I. Eachus
2003-10-26 18:34 ` chris
1 sibling, 2 replies; 57+ messages in thread
From: sk @ 2003-10-26 2:28 UTC (permalink / raw)
To: comp.lang.ada
"Robert I. Eachus" <rieachus@comcast.net>:
> Different purpose if you will. ...
Still not convinced that *participation* will be significantly
different from "link-farms" (meant in positive sense), but
for the moment I will yield that issue.
me:
> I am not going to waste any more of your time on
> implementation details
Sorry, breaking my intentions. In case you havn't included a
"field" for dependencies, you probably need to. For example,
the OpenGL binding depends on AdaBindX.
--
-------------------------------------------------
-- Merge vertically for real address
--
-- s n p @ t . o
-- k i e k c c m
-------------------------------------------------
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-26 2:28 ` sk
@ 2003-10-26 18:11 ` Robert I. Eachus
2003-10-26 18:34 ` chris
1 sibling, 0 replies; 57+ messages in thread
From: Robert I. Eachus @ 2003-10-26 18:11 UTC (permalink / raw)
sk wrote:
> Sorry, breaking my intentions. In case you havn't included a
> "field" for dependencies, you probably need to. For example,
> the OpenGL binding depends on AdaBindX.
Right now I have a Requires entry that can include other projects,
compilers, Ada versions, hardware or operating systems. It will
probably get expanded a bit to allow for bindings to non-Ada code to say
what they bind to. (Or that may end up as a different type of entry.
"Binds to" perhaps?)
There is also a category Supports which is similar but different in
intent. If software has been ported to several compilers or several
operating systems, this allows documentation of what versions are known
to be supported.
--
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
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-26 2:28 ` sk
2003-10-26 18:11 ` Robert I. Eachus
@ 2003-10-26 18:34 ` chris
1 sibling, 0 replies; 57+ messages in thread
From: chris @ 2003-10-26 18:34 UTC (permalink / raw)
sk wrote:
> Sorry, breaking my intentions. In case you havn't included a
> "field" for dependencies, you probably need to. For example,
> the OpenGL binding depends on AdaBindX.
Don't think it does anymore... not sure though.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-24 13:30 ` Stephane Richard
2003-10-24 15:11 ` sk
@ 2003-10-24 17:31 ` tmoran
1 sibling, 0 replies; 57+ messages in thread
From: tmoran @ 2003-10-24 17:31 UTC (permalink / raw)
>You see, ultimately we could do a bot of our own crawling the web as per the
>list of URLs tha appear in the XML file and write a log (successful or non
>successful) in trying to get to the library's webpage. The library authors
www.adapower.com/os/finder.html
has an early version of a crawler for finding dead links. The current
version also handles robots.txt, cookies, and more. It's available.
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-24 1:02 ` Robert I. Eachus
2003-10-24 1:18 ` Stephane Richard
2003-10-24 13:23 ` sk
@ 2003-10-24 17:50 ` Alexandre E. Kopilovitch
2003-10-25 17:48 ` Robert I. Eachus
2 siblings, 1 reply; 57+ messages in thread
From: Alexandre E. Kopilovitch @ 2003-10-24 17:50 UTC (permalink / raw)
To: comp.lang.ada
Robert I. Eachus wrote:
> > Is your proposal just for a registry of packages and not
> > to actually put together a library in terms of packages ?
>
> Correct. It should end up being an inventory of what exists and is
> available, as well as, a guide to who is using which names. But that is
> information useful to someone putting together a consistant library, not
> a library in and of itself.
>
> > I must admit that if this is the case, I have probably
> > volunteered for something I thought was something else :-)
> >
> > Another thought, what would the "registry" provide more than
> > an equivalent web page of links to other peoples packages ?
>
> Yes. If nothing else the existance of the registry should make it much
> easier for people to find out what is "out there" and available for use.
> So it will promote reuse just by existing.
>
> But only if combined with a project to pull together a joint library
> will it fullfill its intended purpose. I chose this as a first step I
> can make happen.
As far as I can see now, there are 2 very different purposes for the Registry.
They have in common a major notion of "referencing", but in other respects
they are different and even possibly potentially conflicting.
First of them is pure Software Engineering purpose: to have a firmly established
way for unambiguous referencing a known component. This is something similar
to Java "packages" in its purpose (but not in design), yes?
The second purpose is providing a kind of searchable public database where one
can find candidates for reuse. This database should differ from other public
resources of this kind in that that it should be better suited for systematic
and organized software development.
Then, if I understand correctly, the first purpose is considered as primary
one; and at this initial stage it takes all attention, while the second purpose
is expected to care for itself for some time. Well, this seems quite reasonable.
Alexander Kopilovitch aek@vib.usr.pu.ru
Saint-Petersburg
Russia
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-24 17:50 ` Alexandre E. Kopilovitch
@ 2003-10-25 17:48 ` Robert I. Eachus
0 siblings, 0 replies; 57+ messages in thread
From: Robert I. Eachus @ 2003-10-25 17:48 UTC (permalink / raw)
Alexandre E. Kopilovitch wrote:
> As far as I can see now, there are 2 very different purposes for the Registry.
> They have in common a major notion of "referencing", but in other respects
> they are different and even possibly potentially conflicting.
>
> First of them is pure Software Engineering purpose: to have a firmly established
> way for unambiguous referencing a known component. This is something similar
> to Java "packages" in its purpose (but not in design), yes?
>
> The second purpose is providing a kind of searchable public database where one
> can find candidates for reuse. This database should differ from other public
> resources of this kind in that that it should be better suited for systematic
> and organized software development.
Correct, but both these purposes/uses are equally important.
> Then, if I understand correctly, the first purpose is considered as primary
> one; and at this initial stage it takes all attention, while the second purpose
> is expected to care for itself for some time. Well, this seems quite reasonable.
Actually, I think I will end up devoting more of my time this week to
the second purpose. This is in part because it needs to be more of a
centralized activity. Once the maintenance tools are available, anyone
will be able to submit entries, updates, or corrections.
--
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
^ permalink raw reply [flat|nested] 57+ messages in thread
[parent not found: <mSBO2c_KxF@vib.usr.pu.ru>]
* Re: Ada Component Registry proposal
2003-10-23 15:01 ` Robert I. Eachus
` (2 preceding siblings ...)
[not found] ` <mSBO2c_KxF@vib.usr.pu.ru>
@ 2003-10-24 13:39 ` sk
2003-10-24 17:18 ` Robert I. Eachus
3 siblings, 1 reply; 57+ messages in thread
From: sk @ 2003-10-24 13:39 UTC (permalink / raw)
To: comp.lang.ada
"Robert I. Eachus" <rieachus@comcast.net>
> Don't worry about it. ...
That it is the lead in to so many jokes ("Trust me...",)
that they aren't funny anymore:-)
--
-------------------------------------------------
-- Merge vertically for real address
--
-- s n p @ t . o
-- k i e k c c m
-------------------------------------------------
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Ada Component Registry proposal
2003-10-24 13:39 ` sk
@ 2003-10-24 17:18 ` Robert I. Eachus
0 siblings, 0 replies; 57+ messages in thread
From: Robert I. Eachus @ 2003-10-24 17:18 UTC (permalink / raw)
sk wrote:
> That it is the lead in to so many jokes ("Trust me...",) that they
> aren't funny anymore:-)
But in this case, it is true. The only reason I didn't post the current
state of the registry here was that I felt it would be unnecessary
clutter. I will probably have it up on my web site sometime in the next
few weeks, and probably on some other Ada websites as well. Keeping the
whole process open is necessary if it is to succeed, and I expect that
for most software, the authors will be the ones to create and maintain
the registry entries. The only potential problem is that if the
software for adding material to a site is posted and used "too soon,"
authors may give up if there are too many changes and the software
changes too often. That is what I am trying to avoid.
--
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
^ permalink raw reply [flat|nested] 57+ messages in thread
end of thread, other threads:[~2003-10-26 21:54 UTC | newest]
Thread overview: 57+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <3F9879C0.9040209@myob.com>
2003-10-24 3:03 ` Ada Component Registry proposal Alexandre E. Kopilovitch
2003-10-23 16:16 Robert C. Leif
2003-10-24 11:48 ` Georg Bauhaus
-- strict thread matches above, loose matches on Subject: below --
2003-10-19 17:16 Robert I. Eachus
2003-10-19 16:41 Robert I. Eachus
2003-10-19 16:44 ` Stephane Richard
2003-10-21 20:45 ` sk
2003-10-22 0:28 ` Robert I. Eachus
2003-10-22 2:26 ` sk
2003-10-22 3:38 ` Robert I. Eachus
2003-10-22 10:35 ` Stephane Richard
2003-10-22 16:58 ` Robert I. Eachus
2003-10-22 17:06 ` Stephane Richard
2003-10-22 23:14 ` Georg Bauhaus
2003-10-22 13:11 ` Marin David Condic
2003-10-22 13:51 ` sk
2003-10-22 4:26 ` sk
2003-10-22 11:14 ` Jeff C,
2003-10-22 11:34 ` Stephane Richard
2003-10-22 12:23 ` sk
2003-10-22 17:09 ` Robert I. Eachus
2003-10-22 19:13 ` sk
2003-10-23 2:17 ` Robert I. Eachus
2003-10-23 5:20 ` sk
2003-10-23 14:39 ` Robert I. Eachus
2003-10-22 12:12 ` sk
2003-10-23 5:41 ` sk
2003-10-23 15:01 ` Robert I. Eachus
2003-10-23 19:03 ` Alexandre E. Kopilovitch
2003-10-23 23:58 ` sk
2003-10-24 1:02 ` Robert I. Eachus
2003-10-24 1:18 ` Stephane Richard
2003-10-24 13:23 ` sk
2003-10-24 13:30 ` Stephane Richard
2003-10-24 15:11 ` sk
2003-10-24 17:12 ` Robert I. Eachus
2003-10-25 0:03 ` sk
2003-10-25 17:43 ` Robert I. Eachus
2003-10-25 18:53 ` Marius Amado Alves
2003-10-25 21:11 ` Marin David Condic
2003-10-25 21:23 ` Robert I. Eachus
2003-10-25 21:28 ` Marin David Condic
2003-10-26 0:24 ` Stephane Richard
2003-10-26 13:36 ` Marin David Condic
2003-10-26 16:02 ` Martin Dowie
2003-10-26 16:45 ` sk
2003-10-26 21:54 ` Marin David Condic
2003-10-26 16:34 ` Stephane Richard
2003-10-26 2:28 ` sk
2003-10-26 18:11 ` Robert I. Eachus
2003-10-26 18:34 ` chris
2003-10-24 17:31 ` tmoran
2003-10-24 17:50 ` Alexandre E. Kopilovitch
2003-10-25 17:48 ` Robert I. Eachus
[not found] ` <mSBO2c_KxF@vib.usr.pu.ru>
2003-10-24 1:00 ` sk
2003-10-24 13:39 ` sk
2003-10-24 17:18 ` Robert I. Eachus
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox