Why no socket package in the standard ?

Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Hello one again,

According to http://www.ibm.com/developerworks/linux/library/l-sockpit/
> First introduced into the 4.2 BSD UNIX® operating system,
> the Sockets API is now a standard feature of any operating system.In  
> fact, it's hard to find a modern language that doesn'tsupport the  
> Sockets API.

This may help Ada (and be useful too) to add sockets in standard packages.

There is AdaSockets, http://www.rfc1149.net/devel/adasockets.html
which has cool licensing terms:
> This library lets you use BSD sockets from Ada (TCP, UDP and multicast).
> It is released under the GNAT Modified General Public License, which  
> means
> that you can freely AdaSockets in a proprietary application without  
> having
> it contaminate your code.

Nice, but still not part of the standard, and I cannot see a reason why,  
such a fundamental thing, at least as fundamental as file access and  
standard I/O streams are, is not part of the standard packages. May be a  
candidate for an optional annex at least ? Already discussed or not ?

Sorry for any inconvenience if I ever missed something there (this  
question seems so much basic I can't avoid feeling I've missed something).


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 03:22:59 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> There is AdaSockets, http://www.rfc1149.net/devel/adasockets.html
> which has cool licensing terms:

Except (I just looked at the source) I personally don't enjoy bindings  
which end to introduce C like namings [*] in Ada. Things like PF_INET,  
IPPROTO_IP or SOL_SOCKET looks really strange for an Ada source; use of  
this kind of abbreviation is typically discouraged, with good reasons. A  
standard package would also be an occasion to give it a more Ada-ishe  
design and presentation.


[*] Not because that is C namings, but because of what these namings are.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[tmoran]

> Except (I just looked at the source) I personally don't enjoy bindings
> which end to introduce C like namings [*] in Ada. Things like PF_INET,
> IPPROTO_IP or SOL_SOCKET looks really strange for an Ada source;

A thicker binding is NC sockets ("Not Claw", derived from Claw.Sockets).
It's nc.zip at www.adaworld.com, look there under
Ada Projects/Ada Internet Projects/Internet Protocols
It's for Windows but IIRC the WSAStartup and WSACleanup should be
the only Windows specific things.

Re: Why no socket package in the standard ?

[georg bauhaus]

Yannick Duchêne (Hibou57 ) <yannick_duchene@yahoo.fr> wrote:
> Hello one again,
> 
> According to
> http://www.ibm.com/developerworks/linux/library/l-sockpit/
> > First introduced into the 4.2 BSD UNIX® operating system,
> > the Sockets API is now a standard feature of any operating system.In
> >  
> > fact, it's hard to find a modern language that doesn'tsupport the  
> > Sockets API.
> 
> This may help Ada (and be useful too) to add sockets in standard
> packages.

Two questions:

Which modern, post 1990, language supports sockets in the language?

Which language supports features of modern file storage? (That is, file
attributes, files as documents (standardized ca. 1984),... )
Note that these capabilities are available with file archives, too.

Re: Why no socket package in the standard ?

[Maciej Sobczak]

On 24 Maj, 08:24, georg bauhaus <rmhost.bauh...@maps.arcor.de> wrote:

> Which modern, post 1990, language supports sockets in the language?

In the language? Probably none, as this does not belong to the
language. It might, however, be part of the standard library.

Java, C# (.NET), Python, etc. are easy examples of more or less recent
languages that support sockets in their standard libraries.

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

Re: Why no socket package in the standard ?

[Thomas Løcke]

On 05/24/2011 09:07 AM, Maciej Sobczak wrote:
> Java, C# (.NET), Python, etc. are easy examples of more or less recent
> languages that support sockets in their standard libraries.


And, for what it is worth, PHP.

-- 
Thomas L�cke

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

Re: Why no socket package in the standard ?

[Dmitry A. Kazakov]

On Tue, 24 May 2011 00:07:55 -0700 (PDT), Maciej Sobczak wrote:

> On 24 Maj, 08:24, georg bauhaus <rmhost.bauh...@maps.arcor.de> wrote:
> 
>> Which modern, post 1990, language supports sockets in the language?
> 
> In the language? Probably none, as this does not belong to the
> language.

That is an interesting question. Actually sockets could belong to the
language. Consider for example the select statement containing alternatives
of a socket's select.

> It might, however, be part of the standard library.

There are many difficulties on that path. When people are demanding sockets
they forget that beyond TCP/IP and UDP there is a lot of other stuff
communicated over sockets, e.g. multi-cast protocols, raw sockets and so
on. These are barely standardized.

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

Re: Why no socket package in the standard ?

[Ludovic Brenta]

Thomas Løcke wrote on comp.lang.ada:
> On 05/24/2011 09:07 AM, Maciej Sobczak wrote:
>> Java, C# (.NET), Python, etc. are easy examples of more or less recent
>> languages that support sockets in their standard libraries.
>
> And, for what it is worth, PHP.

I didn't know these languages even had a standard.  OK, C# has one but
I couldn't find anything about sockets in Partition IV of ECMA 335; it
does mention a "Network Library" but I couldn't find its definition.

Anyway, FWIW, GNAT has GNAT.Sockets out of the box.

--
Ludovic Brenta.

Re: Why no socket package in the standard ?

[Georg Bauhaus]

On 24.05.11 09:19, Thomas Løcke wrote:
> On 05/24/2011 09:07 AM, Maciej Sobczak wrote:
>> Java, C# (.NET), Python, etc. are easy examples of more or less recent
>> languages that support sockets in their standard libraries.
> 
> 
> And, for what it is worth, PHP.


and Pike [*],
(and CSNOBOL-4 [**]),
and anything supported by SWIG,
and Haskell [***]
and ...

1. The reason simply is that each and every of them has started
by offering some glue code for the BSD/POSIX socket functions.
.NET languages will likely just use a .NET class.

But there have been and will be difficulties when porting
the languages' alleged "standard" libraries to non-POSIX
(or non-.NET) operating systems.  Perhaps the difficulties
are even conceptual ones whenever POSIX sockets don't really
meet the networking requirements.

Define

  Commercially_Important_Platforms := {
    ∃ target | POSIX(target) IN { False, True }
  }

How large is the subset defined by POSIX(target) = False?
Is POSIX/Sockets the best Ada solution when this is the case?


2. In the light of Ada's history regarding standardization,
there is, I believe, networking knowledge that warrants more
than canonization of a practical workaround---which might fail
if requirements are actually different.

Opposing a get-that-duct-tape-solution-out–the-door style for
standardization, I'd imagine starting from questions like the
following and then weigh POSIX sockets as the possible answer:

- What should programs be able to do when communicating data
  along some network connection?

- Should there be a layered approach?  How much detail?

- Where in the language will this integrate nicely?
  (E.g. package structure? What types if any?  Or anything
  that has already been mentioned.)

- Is sockets the right approach?  Consider Erlang!

- Is sockets the right approach?  Consider a CAN!

I doubt that the best answer to these questions can
be summed up by saying, "Mirror Posix sockets!".



___
[*] http://pike.ida.liu.se/generated/manual/modref/ex/predef_3A_3A/Stdio/Port.html

[**] http://www.snobol4.org/csnobol4/curr/doc/snobol4.html

[***] "Haskell's networking functions almost always correspond
directly to familiar C function calls."
http://book.realworldhaskell.org/read/sockets-and-syslog.html

Re: Why no socket package in the standard ?

[AdaMagica]

On 24 Mai, 03:22, Yannick Duchêne (Hibou57) <yannick_duch...@yahoo.fr>
wrote:
> There is AdaSockets,http://www.rfc1149.net/devel/adasockets.html
> Nice, but still not part of the standard, and I cannot see a reason why,  

See Ada 2005 Rationale http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-9-3-8.html

Re: Why no socket package in the standard ?

[Dmitry A. Kazakov]

On Tue, 24 May 2011 12:00:24 +0200, Georg Bauhaus wrote:

> Opposing a get-that-duct-tape-solution-out嚙碾the-door style for
> standardization, I'd imagine starting from questions like the
> following and then weigh POSIX sockets as the possible answer:
> 
> - What should programs be able to do when communicating data
>   along some network connection?

Well, this has nothing to do with sockets. Communication between programs
is distribution, the annex E. Sockets are a about communication to the
hardware, even if the other side is actually a program.
 
> - Should there be a layered approach?  How much detail?

This is the above question again. If distribution meant, there is the
program (application) level only. Then the question is not about the
levels, but about the architecture of such communication (object vs event
vs procedural vs data views etc)

> - Where in the language will this integrate nicely?
>   (E.g. package structure? What types if any?  Or anything
>   that has already been mentioned.)
> 
> - Is sockets the right approach?  Consider Erlang!

An approach to what?

> - Is sockets the right approach?  Consider a CAN!

CAN is not stream- or packet-oriented, not even Ethernet. Even
Ethernet-based protocols, such as EtherCAT are have nothing to do with
sockets. So are the protocols which actually use TCP/IP or UDP as a
transport, e.g. ModBus, XCP etc. And for all of then (even for CAN, if
talking about CAN Open) data exchange (the only thing sockets offer) is the
least problem.

Blurring transport and application level issues does not help. You seem to
imply that there could be an application level solution. A much more
moderate goal to standardize sockets is very difficult.

> I doubt that the best answer to these questions can
> be summed up by saying, "Mirror Posix sockets!".

What was the question? (:-))

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

Re: Why no socket package in the standard ?

[Georg Bauhaus]

On 24.05.11 14:53, Dmitry A. Kazakov wrote:
> On Tue, 24 May 2011 12:00:24 +0200, Georg Bauhaus wrote:
> 
>> Opposing a get-that-duct-tape-solution-out嚙碾the-door style for
>> standardization, I'd imagine starting from questions like the
>> following and then weigh POSIX sockets as the possible answer:
>>
>> - What should programs be able to do when communicating data
>>   along some network connection?
> 
> Well, this has nothing to do with sockets.

It hasn't.  (My point.)

> Communication between programs
> is distribution, the annex E.

Yes.  If the endpoints of communication are Ada partitions.
Otherwise ...?

> Sockets are a about communication to the
> hardware, even if the other side is actually a program.

From a programmer perspective, sockets may well be about
how to send a String value to some "Port" on some
"machine" identifiable via DNS.

No hardware in sight from this viewpoint.

Whereas network communication may well be different, as you have
outlined.

>> - Should there be a layered approach?  How much detail?
> 
> This is the above question again. If distribution meant, there is the
> program (application) level only. Then the question is not about the
> levels, but about the architecture of such communication (object vs event
> vs procedural vs data views etc)

Yes.


>> - Is sockets the right approach?  Consider Erlang!
> 
> An approach to what?

A more general approach to sending data around.  That's what socket
programs do very frequently, I think, at least when they stream text,
for example. From the programmer's point of view, they use text based
protocols. Not datagrams or packages or anything.  This defines one use
case of (technically sockets based) data communication.

Why insist on sockets, then?

>> - Is sockets the right approach?  Consider a CAN!
> 
> CAN is not stream- or packet-oriented, not even Ethernet. Even
> Ethernet-based protocols, such as EtherCAT are have nothing to do with
> sockets.

Which is why I had hoped to remind that Ada programs, even when
operating a network, might not profit at all from a standard sockets
package, if they do not use sockets, but do control networked communication.

> Blurring transport and application level issues does not help.

Yes.  But at least we might try to learn, for the purpose of standardization,
what a typical transport level issue is versus what an application level issue
is---not so much about how solutions are built around sockets whenever
these happen to be available.  Standards work seems a good opportunity
to isolate, in abstract terms, what a transport level issue is.   (And what it
might or might not have to do with Ada, or sockets, see below.)

If these issues are central to Ada programming, and future-proof,
there might be funding for isolating a few requirements.  Then start
from these requirements.

Or, if sockets are as important as, say, timers, or windows---if they
are important, then enlighten industry (or govt.) that they have the power
to ask for compiler-independent packages. These would not even
need ISO standardization, just compiler independence, to be used
by industry.

No one else has the power.

Consider libraries like public roads or not-so-public infrastructure
that everyone needs.

Remembering industry's built-in rewards system for anti-co-operation,
its power to influence the software makers towards generally useful
packages is unlikely to be employed, though.  (Packages that could
be used with a different compiler! By a different company!?)


>> I doubt that the best answer to these questions can
>> be summed up by saying, "Mirror Posix sockets!".
> 
> What was the question? (:-))

The original question was, "Why no socket package in the standard?".

Let me rephrase it: "Why no ISO/IEC 14519:2001 package in the standard?"

I believe there was a preliminary answer to the latter question
that might show the first in a new light.

Re: Why no socket package in the standard ?

[Dmitry A. Kazakov]

On Tue, 24 May 2011 16:28:32 +0200, Georg Bauhaus wrote:

> On 24.05.11 14:53, Dmitry A. Kazakov wrote:
>> 
>> Communication between programs
>> is distribution, the annex E.
> 
> Yes.  If the endpoints of communication are Ada partitions.
> Otherwise ...?

Non-Ada programs = non-programs. No offence to other languages meant, it is
just so that we cannot communicate them at this height of abstraction
level.
 
>> Sockets are a about communication to the
>> hardware, even if the other side is actually a program.
> 
> From a programmer perspective, sockets may well be about
> how to send a String value to some "Port" on some
> "machine" identifiable via DNS.

That is not Ada's programmer perspective. A value has the type. This type
is an Ada type, otherwise we are back to the hardware level of bits and
bytes.

> No hardware in sight from this viewpoint.

See above.

>>> - Is sockets the right approach?  Consider Erlang!
>> 
>> An approach to what?
> 
> A more general approach to sending data around.

Data are meaningless (We had this discussion before). Meaningful is
distribution and that is the annex E.

> Why insist on sockets, then?

Because sockets is the most widely used transport.

>> Blurring transport and application level issues does not help.
> 
> Yes.  But at least we might try to learn, for the purpose of standardization,
> what a typical transport level issue is versus what an application level issue
> is---not so much about how solutions are built around sockets whenever
> these happen to be available.  Standards work seems a good opportunity
> to isolate, in abstract terms, what a transport level issue is.

I don't see how standards from the areas, where mentioned by you CAN is
applied, could help.

> If these issues are central to Ada programming, and future-proof,
> there might be funding for isolating a few requirements.  Then start
> from these requirements.

From CAN Open, ASAP, ASAM etc? Are you kidding?
 
> Or, if sockets are as important as, say, timers, or windows---if they
> are important, then enlighten industry (or govt.) that they have the power
> to ask for compiler-independent packages.

Sockets are more or less realistic to support at the standard's level,
though very difficult.

>>> I doubt that the best answer to these questions can
>>> be summed up by saying, "Mirror Posix sockets!".
>> 
>> What was the question? (:-))
> 
> The original question was, "Why no socket package in the standard?".
> 
> Let me rephrase it: "Why no ISO/IEC 14519:2001 package in the standard?"

I cannot say. I do not care much about POSIX, maybe, others do not either.
Why is it relevant to sockets?

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

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 14:38:56 +0200, AdaMagica  
<christ-usch.grein@t-online.de> a écrit:
> See Ada 2005 Rationale  
> http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-9-3-8.html
Thanks AdaMagica :)

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Adam Beneschan]

On May 24, 7:59 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Tue, 24 May 2011 16:28:32 +0200, Georg Bauhaus wrote:
> > On 24.05.11 14:53, Dmitry A. Kazakov wrote:
>
> >> Communication between programs
> >> is distribution, the annex E.
>
> > Yes.  If the endpoints of communication are Ada partitions.
> > Otherwise ...?
>
> Non-Ada programs = non-programs. No offence to other languages meant, it is
> just so that we cannot communicate them at this height of abstraction
> level.

What do you mean by "this height"?  What height?  From what I can
tell, figuring out the correct level of abstraction is still part of
the problem, a part that needs a lot of thought.

Being able to communicate with programs written in other languages
*is* a need, and I think that any package that would become part of
the Ada standard would have to meet that need.  And I think it could
be done with some level of abstraction, i.e. with more than just a
thin binding to the Unix socket library, and in a way that allows for
different communications mechanisms than just sockets.  (I have some
experience with this.  I wrote a message-communication package that
had two different bodies, one that implemented the messages with VMS
mailboxes, and another that used sockets to communicate with a Solaris
host.  This was due to requirements imposed by the customer, and it
was set up to communicate specifically with a program written by the
customer.  But the package specification was the same in both cases
and was general enough that I was able to reuse it for other
purposes.  So I'm convinced this is doable, but difficult to do in a
way that will meet the needs of as many users as possible.)

                                  -- Adam

Re: Why no socket package in the standard ?

[Georg Bauhaus]

On 24.05.11 16:59, Dmitry A. Kazakov wrote:
> On Tue, 24 May 2011 16:28:32 +0200, Georg Bauhaus wrote:
> 
>> On 24.05.11 14:53, Dmitry A. Kazakov wrote:
>>>
>>> Communication between programs
>>> is distribution, the annex E.
>>
>> Yes.  If the endpoints of communication are Ada partitions.
>> Otherwise ...?
> 
> Non-Ada programs = non-programs. No offence to other languages meant, it is
> just so that we cannot communicate them at this height of abstraction
> level.

But we do have an ORB style of distribution; and since ORBs
can be language neutral, Non-Ada programs might be programs,
again.

>> From a programmer perspective, sockets may well be about
>> how to send a String value to some "Port" on some
>> "machine" identifiable via DNS.
> 
> That is not Ada's programmer perspective.

OK.




>> If these issues are central to Ada programming, and future-proof,
>> there might be funding for isolating a few requirements.  Then start
>> from these requirements.
> 
> From CAN Open, ASAP, ASAM etc? Are you kidding?

No, I mean transport as a concept, considering pay load,
buffers, timeouts, latency; interaction with possible RTSs;
things that matter to programming the level in question.
E.g., is there anything special regarding interrupt handling
when it comes to receiving data?  (Likely not, I think?)



>> The original question was, "Why no socket package in the standard?".
>>
>> Let me rephrase it: "Why no ISO/IEC 14519:2001 package in the standard?"
> 
> I cannot say. I do not care much about POSIX, maybe, others do not either.
> Why is it relevant to sockets?


http://www.cs.scranton.edu/~beidler/Ada/posix/posix-sockets-internet.html

Or so I thought, at least.

Re: Why no socket package in the standard ?

[Pascal Obry]

Le 24/05/2011 08:11, tmoran@acm.org a écrit :
> A thicker binding is NC sockets ("Not Claw", derived from Claw.Sockets).
> It's nc.zip at www.adaworld.com, look there under
> Ada Projects/Ada Internet Projects/Internet Protocols
> It's for Windows but IIRC the WSAStartup and WSACleanup should be
> the only Windows specific things.

I've not looked at the source but I bet there is others. For example 
closesocket (which is close on POSIX AFAIK). Plus all the constants 
related to the socket layer which are different on Windows.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Why no socket package in the standard ?

[anon]

Ada was designed to be "Portable" and "System Independent and Secure" 
which means that most system library packages such as Sockets are not 
apart of the main Ada language. 

To the Ada programmer, Ada removes the concerns of how it communicates 
with other components, like from server task communication to and from a 
client task. No, programmer needs to know if the system is using 
system-wide stacks or queues or if the communication is via a parallel, 
serial or network port. This may explain why "Annex E. Distributed Systems" 
is thin in it scope. The main problem is that since Ada 95 the design has 
been more toward "oops" programming than modifying the run-time system to 
keep up with new technology.

Plus, there is no language that contains Sockets as apart of it standard 
library.  C, C++, Java, Fortran, etc. have no references to Sockets in 
their standard language.  Sockets is an add on system library package to 
all languages and that includes Ada.  For Ada, the main problem here is 
that most Ada programmers spend their time writing application and not 
"Add On" libraries for Ada. They just bind what they need instead of 
building the complete library package for future projects.


In <op.vvyoslycule2fv@douda-yannick>, =?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= writes:
>Hello one again,
>
>According to http://www.ibm.com/developerworks/linux/library/l-sockpit/
>> First introduced into the 4.2 BSD UNIX=C2=AE operating system,
>> the Sockets API is now a standard feature of any operating system.In  =
>
>> fact, it's hard to find a modern language that doesn'tsupport the  =
>
>> Sockets API.
>
>This may help Ada (and be useful too) to add sockets in standard package=
>s.
>
>There is AdaSockets, http://www.rfc1149.net/devel/adasockets.html
>which has cool licensing terms:
>> This library lets you use BSD sockets from Ada (TCP, UDP and multicast=
>).
>> It is released under the GNAT Modified General Public License, which  =
>
>> means
>> that you can freely AdaSockets in a proprietary application without  =
>
>> having
>> it contaminate your code.
>
>Nice, but still not part of the standard, and I cannot see a reason why,=
>  =
>
>such a fundamental thing, at least as fundamental as file access and  =
>
>standard I/O streams are, is not part of the standard packages. May be a=
>  =
>
>candidate for an optional annex at least ? Already discussed or not ?
>
>Sorry for any inconvenience if I ever missed something there (this  =
>
>question seems so much basic I can't avoid feeling I've missed something=
>).
>
>
>-- =
>
>Si les chats miaulent et font autant de vocalises bizarres, c=E2=80=99es=
>t pas pour  =
>
>les chiens.
>=E2=80=9C c++; /* this makes c bigger but returns the old value */ =E2=80=
>=9D [Anonymous]

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 20:29:56 +0200, <anon@att.net> a écrit:
> Plus, there is no language that contains Sockets as apart of it standard
> library.  C, C++, Java, Fortran, etc. have no references to Sockets in
> their standard language.
Yes, but all of these comes with near-standard sockets library  
(near-standard, because there is one and single you can always rely on,  
even WSA sockets are close enough to BSD sockets).

Moreover, nothings disallow Ada to be ahead, … one more time.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 08:11:43 +0200, <tmoran@acm.org> a écrit:
> A thicker binding is NC sockets ("Not Claw", derived from Claw.Sockets).
> It's nc.zip at www.adaworld.com, look there under
> Ada Projects/Ada Internet Projects/Internet Protocols
> It's for Windows but IIRC the WSAStartup and WSACleanup should be
> the only Windows specific things.
If that is representative of Claw source layout, I can say I like it  
(consistent comments every where in specs files)
Thanks to you for this pointer, as that is the first time I could see an  
example of Claw source (I do not own a Janus-Ada compiler).

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 08:24:40 +0200, georg bauhaus  
<rmhost.bauhaus@maps.arcor.de> a écrit:
> Two questions:
>
> Which modern, post 1990, language supports sockets in the language?
As pointed by others in this thread (with reference and examples) as well  
as pointed in the opening message, the answer is : near to all well known  
languages.

Although optional, even a so much few famous language as SML, makes  
reference to it in its standard library:
http://www.standardml.org/Basis/overview.html#section:8

> Which language supports features of modern file storage? (That is, file
> attributes, files as documents (standardized ca. 1984),... )
> Note that these capabilities are available with file archives, too.
These are not as much standard as sockets are. As an example, file  
attributes handling are always annotated with platform provision in the  
Python standard library. Even such a basic things to me, as file's  
creation time, is not universally available (does not exist in standard  
Linux distribution at least). This is not comparable to widespread of  
sockets.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Dmitry A. Kazakov]

On Tue, 24 May 2011 09:07:42 -0700 (PDT), Adam Beneschan wrote:

> On May 24, 7:59�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Tue, 24 May 2011 16:28:32 +0200, Georg Bauhaus wrote:
>>> On 24.05.11 14:53, Dmitry A. Kazakov wrote:
>>
>>>> Communication between programs
>>>> is distribution, the annex E.
>>
>>> Yes. �If the endpoints of communication are Ada partitions.
>>> Otherwise ...?
>>
>> Non-Ada programs = non-programs. No offence to other languages meant, it is
>> just so that we cannot communicate them at this height of abstraction
>> level.
> 
> What do you mean by "this height"?  What height?  From what I can
> tell, figuring out the correct level of abstraction is still part of
> the problem, a part that needs a lot of thought.

Whatever level it might be, it cannot be lower than the language level (Ada
is a higher level typed language).

> Being able to communicate with programs written in other languages
> *is* a need, and I think that any package that would become part of
> the Ada standard would have to meet that need.

You cannot do that in a standard way because many of not most other
language do not have means for that. This is why lower level protocols are
used, e.g. sockets.

> And I think it could
> be done with some level of abstraction, i.e. with more than just a
> thin binding to the Unix socket library, and in a way that allows for
> different communications mechanisms than just sockets.  (I have some
> experience with this.  I wrote a message-communication package that
> had two different bodies, one that implemented the messages with VMS
> mailboxes, and another that used sockets to communicate with a Solaris
> host.  This was due to requirements imposed by the customer, and it
> was set up to communicate specifically with a program written by the
> customer.  But the package specification was the same in both cases
> and was general enough that I was able to reuse it for other
> purposes.  So I'm convinced this is doable, but difficult to do in a
> way that will meet the needs of as many users as possible.)

If there were some messaging standard that could be done. Still that would
not make it communication with programs, because messages are not much
higher level than streams.

The RPCs are higher.

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

Re: Why no socket package in the standard ?

[J-P. Rosen]

Le 24/05/2011 21:17, Yannick Duchêne (Hibou57) a écrit :
>> Which modern, post 1990, language supports sockets in the language?
> As pointed by others in this thread (with reference and examples) as
> well as pointed in the opening message, the answer is : near to all well
> known languages.
> 

Hmm... all languages I've seen mentionne so far have no official standard.

As long as the language is designed by a single person/company/body,
providing bindings as the author pleases is easy. When it comes to
standardization, you have to account for various operating systems and
lots of "details" that make it a lot more difficult.

Matthew Heaney (I hope I got it spelled right) had a very nice
containers library. Ask him about what happened when turning it into a
standard...

Re: Why no socket package in the standard ?

[Dmitry A. Kazakov]

On Tue, 24 May 2011 18:10:49 +0200, Georg Bauhaus wrote:

> On 24.05.11 16:59, Dmitry A. Kazakov wrote:
>> On Tue, 24 May 2011 16:28:32 +0200, Georg Bauhaus wrote:
>> 
>>> On 24.05.11 14:53, Dmitry A. Kazakov wrote:
>>>>
>>>> Communication between programs
>>>> is distribution, the annex E.
>>>
>>> Yes.  If the endpoints of communication are Ada partitions.
>>> Otherwise ...?
>> 
>> Non-Ada programs = non-programs. No offence to other languages meant, it is
>> just so that we cannot communicate them at this height of abstraction
>> level.
> 
> But we do have an ORB style of distribution; and since ORBs
> can be language neutral, Non-Ada programs might be programs,
> again.

Yes. That would be a very different level, and usage under 1%.

>>> If these issues are central to Ada programming, and future-proof,
>>> there might be funding for isolating a few requirements.  Then start
>>> from these requirements.
>> 
>> From CAN Open, ASAP, ASAM etc? Are you kidding?
> 
> No, I mean transport as a concept, considering pay load,
> buffers, timeouts, latency; interaction with possible RTSs;
> things that matter to programming the level in question.
> E.g., is there anything special regarding interrupt handling
> when it comes to receiving data?  (Likely not, I think?)

Those look non-functional (QoS etc). What about starting with the
functional part. That looks pretty weak.
 
>>> The original question was, "Why no socket package in the standard?".
>>>
>>> Let me rephrase it: "Why no ISO/IEC 14519:2001 package in the standard?"
>> 
>> I cannot say. I do not care much about POSIX, maybe, others do not either.
>> Why is it relevant to sockets?
> 
> http://www.cs.scranton.edu/~beidler/Ada/posix/posix-sockets-internet.html
> 
> Or so I thought, at least.

I see, you meant POSIX sockets.

BTW, IPPROTO_RAW does not work under Windows (I didn't test VxWorks). Does
it mean that Ada standard should require RTL to provide an NDIS to hack
that?

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

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 12:00:24 +0200, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:
> 1. The reason simply is that each and every of them has started
> by offering some glue code for the BSD/POSIX socket functions.
BSD is the standard C API for sockets, even the POSIX one, intially based  
on the BSD specification, was kept close enough. The POSIX specification  
seems to only differs in the way to get host by name / address.

> .NET languages will likely just use a .NET class.
Which is probably a tick binding to the socket API (if I'm wrong with  
this, tell me).

> But there have been and will be difficulties when porting
> the languages' alleged "standard" libraries to non-POSIX
> (or non-.NET) operating systems.  Perhaps the difficulties
> are even conceptual ones whenever POSIX sockets don't really
> meet the networking requirements.
What networking requirement ? This thread is not about OSI layers packages  
for Ada, it's only about sockets, which is either OSI layer 4 or 5  
(depending on the point of view).

> Define
>
>   Commercially_Important_Platforms := {
>     ∃ target | POSIX(target) IN { False, True }
>   }
>
> How large is the subset defined by POSIX(target) = False?
> Is POSIX/Sockets the best Ada solution when this is the case?
Be pragmatic : the standard socket API is the BSD socket API, then as said  
above, there are only little differences between the POSIX and BSD socket  
specification, and then after, sockets does not implies POSIX. POSIX is  
one thing, sockets is another.


> 2. In the light of Ada's history regarding standardization,
> there is, I believe, networking knowledge that warrants more
> than canonization of a practical workaround---which might fail
> if requirements are actually different.
What workaround ?

> Opposing a get-that-duct-tape-solution-out–the-door style for
> standardization, I'd imagine starting from questions like the
> following and then weigh POSIX sockets as the possible answer:
Why not, POSIX would be OK, indeed, as it provides the same. But there  
should be good reason to introduce POSIX here. This would be OK if there  
was support for POSIX in the Ada standard, and this is actually not.

> - What should programs be able to do when communicating data
>   along some network connection?
Answered by the socket specification : there are raw, datagram, stream,  
blocking and none-blocking sockets, with IPv4 or IPv6 addresses.

> - Should there be a layered approach?  How much detail?
Sockets already belong to its layer, but Ada is not concerned about it.  
This is not about creating a network package hierarchy, this is about a  
socket package only (may be a hierarchy, if it appears to be cleaner this  
way).

> - Where in the language will this integrate nicely?
>   (E.g. package structure? What types if any?  Or anything
>   that has already been mentioned.)
Streams in some part, but not always, has some usage of sockets does not  
have stream behavior (like UDP). This would probably requires two sockets  
type : streams and none-stream.

> - Is sockets the right approach?  Consider Erlang!
Seems Erlang actually provides sockets.

> - Is sockets the right approach?  Consider a CAN!
A can 8-) ?

> I doubt that the best answer to these questions can
> be summed up by saying, "Mirror Posix sockets!".
Why ? Thousands of applications are working nice with either POSIX or BSD  
sockets, and this was not cause of any big troubles I could hear about,  
unlike stack or buffer overflow, lack of typing and the like. Sockets are  
a mostly secure things. And Ada has tasking defined in the language, which  
can be useful for sockets (think about the "select" operation, while not  
formally required, is often used in conjunction with sockets).


> [*]  
> http://pike.ida.liu.se/generated/manual/modref/ex/predef_3A_3A/Stdio/Port.html
>
> [**] http://www.snobol4.org/csnobol4/curr/doc/snobol4.html
>
> [***] "Haskell's networking functions almost always correspond
> directly to familiar C function calls."
> http://book.realworldhaskell.org/read/sockets-and-syslog.html
OK, will get some time to read these.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 21:30:39 +0200, J-P. Rosen <rosen@adalog.fr> a écrit:
> Hmm... all languages I've seen mentionne so far have no official  
> standard.
>
> As long as the language is designed by a single person/company/body,
> providing bindings as the author pleases is easy. When it comes to
> standardization, you have to account for various operating systems and
> lots of "details" that make it a lot more difficult.
If these languages was mentioned here, this was not to suggest the Ada  
standard should be managed the same way these languages are. You're right  
to point these languages are not standardized (and that's really a  
problem). But the topic is not concerned about it : if the fact "socket  
are part of many and many libraries" was introduced, this was to point how  
much useful it is to softwares… especially with the increase of remote  
communication needs, servers and things looking like servers,  
client-server design, etc. This is, I feel, as much demanded as real-time  
(and safety) features.

> Matthew Heaney (I hope I got it spelled right) had a very nice
> containers library. Ask him about what happened when turning it into a
> standard...
Thanks for the notice

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Ludovic Brenta]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:
>> Opposing a get-that-duct-tape-solution-out–the-door style for
>> standardization, I'd imagine starting from questions like the
>> following and then weigh POSIX sockets as the possible answer:
> Why not, POSIX would be OK, indeed, as it provides the same. But there
> should be good reason to introduce POSIX here. This would be OK if
> there  was support for POSIX in the Ada standard, and this is actually
> not.

Wrong. http://en.wikibooks.org/wiki/Ada_Programming/Platform/POSIX says:

"POSIX.5 is an IEEE (IEEE Standard 1003.5b-1996) and ISO (ISO/IEC
14519:2001) standard defining an Ada interface to the POSIX system
calls."

Florist is a Free Software implementation of POSIX.5.  The only nit you
might pick is that POSIX.5 is not included by reference in the Ada
Reference Manual.  Personally I don't really care.  If I need to and if
my target system is POSIX compliant (which it always is in practice), I
can write a standard Ada program using the standard sockets interface
which is part of the standard POSIX.5.

Oh, and I think I did mention GNAT.Sockets.  So what are people
complaining about, again?

-- 
Ludovic Brenta.

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 21:54:13 +0200, Ludovic Brenta  
<ludovic@ludovic-brenta.org> a écrit:
> Wrong. http://en.wikibooks.org/wiki/Ada_Programming/Platform/POSIX says:
>
> "POSIX.5 is an IEEE (IEEE Standard 1003.5b-1996) and ISO (ISO/IEC
> 14519:2001) standard defining an Ada interface to the POSIX system
> calls."
Yes. I did not say there is not standard POSIX Ada, I instead said POSIX  
Ada is not part of the Ada standard.

> Oh, and I think I did mention GNAT.Sockets.  So what are people
> complaining about, again?
GNAT specific, that's a big enough point (I will have to check it : I'm  
also afraid this may make use of some GNAT internals). As Jean-Pierre  
underlined in a message in this same thread, maintaining a standard is not  
the same as adding a vendor specific feature when this pleased this vendor  
or single person. GNAT.Sockets, is vendor specific. I don't want the use  
of Sockets in Ada source, to be an advertising for GNAT, I would prefer it  
to be an advertising for Ada as a language (while the reason is not about  
advertising, but about a pressing requirement in the real world), be it  
GNAT (which I still enjoy, of course), Aonix, Janus, and others. If you  
use GNAT specific stuff, this is not Ada anymore, this GNAT (there is no  
legitimate way to reduce Ada to GNAT, whatever how much good GNAT is).


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Maciej Sobczak]

On 24 Maj, 09:25, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > In the language? Probably none, as this does not belong to the
> > language.
>
> That is an interesting question. Actually sockets could belong to the
> language. Consider for example the select statement containing alternatives
> of a socket's select.

Still, they (sockets) don't have to be part of the language to be
select-ready. It is enough to make them protected objects with
appropriate entries.
The problem is, neither Ada nor the operating system make it easy to
do this kind of integration in a sufficiently efficient way.

Which brings some interesting point for the future language evolution:
make it possible to write "select hooks" - that is, protected
procedures that are called automatically when any task attempts to
call some entry in any way, including its use in the select statement.
Something like:

protected Example is
   entry Lets_Go when Ready is ...

   -- this procedure is called when Lets_Go is used
   -- it is executed *before* evaluation of the barrier in Lets_Go
   procedure Lets_Go_Hook is
   begin
      -- ...
      -- perhaps set Ready or whatever
   end Lets_Go_Hook;

private
   Ready : Boolean;
end Example;

With this language feature I can imagine a relatively efficient
implementation of a socket library where socket objects are selectable
in the Ada sense.

Nitpick: implement Ada 2005 before that. Please. ;-)

> > It might, however, be part of the standard library.
>
> There are many difficulties on that path. When people are demanding sockets
> they forget that beyond TCP/IP and UDP there is a lot of other stuff
> communicated over sockets, e.g. multi-cast protocols, raw sockets and so
> on. These are barely standardized.

So what? Standardize the stuff that is obvious to standardize and
don't throw the baby out with the water. Just don't give people more
reasons for not learning Ada.

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

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 21:38:03 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
>> - What should programs be able to do when communicating data
>>   along some network connection?
> Answered by the socket specification : there are raw, datagram, stream,  
> blocking and none-blocking sockets, with IPv4 or IPv6 addresses.
>
Now, was thinking raw socket should be stripped away : these are rather  
limited on Windows according to a Winsock FAQs [*], and there are good  
reasons for that; this is because a raw socket overrides OS drivers. This  
in turn can lead to security risk and efficiency troubles to not talk  
about system stability (ouch). Raw socket is useful to implement your own  
protocol over IP… which make it of a limited audience; there is no way to  
expect Ada to support such a low level topic (would be like introducing  
direct device access along with file access).

[*] I did not check for UNIcies.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Ludovic Brenta]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:
> Le Tue, 24 May 2011 21:54:13 +0200, Ludovic Brenta
> <ludovic@ludovic-brenta.org> a écrit:
>> Wrong. http://en.wikibooks.org/wiki/Ada_Programming/Platform/POSIX says:
>>
>> "POSIX.5 is an IEEE (IEEE Standard 1003.5b-1996) and ISO (ISO/IEC
>> 14519:2001) standard defining an Ada interface to the POSIX system
>> calls."
> Yes. I did not say there is not standard POSIX Ada, I instead said
> POSIX Ada is not part of the Ada standard.

That's because making POSIX part of Ada would restrict Ada to working
only on POSIX targets.

>> Oh, and I think I did mention GNAT.Sockets.  So what are people
>> complaining about, again?
> GNAT specific, that's a big enough point [...]

OK.

So, what you're complaining about is that sockets are not part of Ada.
Thay are not.  Furthermore, they cannot be part of Ada or any other
general-purpose language definition because (a) general-purpose
languages must work on targets that do not have sockets and (b)
mandating that the language provide sockets on targets that don't have
them is a bad idea.  Therefore, sockets must be in an optional,
target-specific library; preferably one with a standard interface.
That's what POSIX.5 is.  Ada with POSIX.5 is in this respect in a better
position than all other languages mentioned in this thread, i.e. it has
good, official standards for both the language and the socket interface.

And if you're so keen on standards, why are you still using a
non-standard, proprietary operating system?

-- 
Ludovic Brenta.

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 09:25:38 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> There are many difficulties on that path. When people are demanding  
> sockets
> they forget that beyond TCP/IP and UDP there is a lot of other stuff
> communicated over sockets
This can be abstracted down. The purpose of different protocols is not to  
make things more complex, but to provide different level of reliability,  
which make some like streams and some others not. Unlike Unicode encoding  
introduced in Ada 2012, the protocols list is not closed, however, TCP/IP  
and UDP/IP are still the widely used. This could be compared to the topic  
old character code pages : there was many, but Ada still supported the  
most widely used one beyond pure ANSI : ISO 8859-1. There may be no worry  
to support TCP/IP and UDP/IP above any others, the same way.

A question : what is the state of the use of IP based protocols in the  
embedded-boards area ? I use to see references to TCP and UDP usages in  
some embedded stuffs, but I am not mastering anything in that area… unlike  
many others here.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 23:57:48 +0200, Ludovic Brenta  
<ludovic@ludovic-brenta.org> a écrit:
> So, what you're complaining about is that sockets are not part of Ada.
> Thay are not.  Furthermore, they cannot be part of Ada or any other
> general-purpose language definition because (a) general-purpose
> languages must work on targets that do not have sockets and (b)
> mandating that the language provide sockets on targets that don't have
> them is a bad idea.
Some systems does not even have anything like files… Ada still define file  
types.
Some systems does not have dynamic memory allocation except stack… Ada  
still define the "new" operator and storage pools.
Some systems never deals with character and only bother about numbers… Ada  
still define character types and character handling (and encoding, as of  
Ada 2012).
Some systems have files, while no directory… Ada still defines directory  
traversal facilities.
(some people may extend this list)

These all shows your objection is not relevant : pragmatism is, however.

Above that, really more application are already concerned about remote  
data transfer than with remote procedure call, but Ada defines the latter  
and not the former (I suspect some some corporation interest in this  
choice). Here, Ada supports the less widely used, and not the most widely  
used. Except if you want it to be restricted to some niches, that's not  
good.

> And if you're so keen on standards, why are you still using a
> non-standard, proprietary operating system?
How does this relate to Ada standard please ? 8-| Whether or not I am  
using a proprietary or none-proprietary OS, a proprietary or  
none-proprietary browser, this is not relevant here, and I expect you  
agree I am free to choose. By the way, there is not event something like a  
standard OS (there may be proprietaries or not, but none is standard).


<confident>Well… if you really want to know : I use one proprietary and  
one non-proprietary OS and a proprietary browser which is not the one  
provided by the provider of the proprietary OS ;-) And I wish in the  
future, to add a proprietary OS to what is available to me (Mac  
OSX).</confident>

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Georg Bauhaus]

On 5/24/11 9:17 PM, Yannick Duchêne (Hibou57) wrote:
> Le Tue, 24 May 2011 08:24:40 +0200, georg bauhaus <rmhost.bauhaus@maps.arcor.de> a écrit:
>> Two questions:
>>
>> Which modern, post 1990, language supports sockets in the language?
> As pointed by others in this thread (with reference and examples) as well as pointed in the opening message, the answer is : near to all well known languages.

It says "hard to find a modern language that doesn't support
the Sockets API".  Ada does support the sockets API, of course,
just like the others do. Pretty much the same way in all
bindings.

Let's see the well known "modern" languages of post 1990.

Java, C#.

Well, maybe the P* scripting languages, though these
have roots/version inthe late 1980s.

Will sockets APIs help with JVM or .NET? On the contrary:

Ada -> JVM gives you the best sockets for the platform
directly, *not* by having it added to the Ada standard,
but by simply offering the JVM/.NET classes.
Which aren't BSD style.

> Although optional, even a so much few famous language as SML,

ML. A language that got started in the 1970s.
SML, being written in SML and C, got a binding to BSD internet
sockets. A fairly thin interface if you look close.


I mentioned extended attributes and no standardization at all
because in this case

1) standardization work need not refer to any implementation;
    it can stay purely abstract.
2) virtually all standard file systems support EAs
3) virtually all archive formats support EAs
4) many programs make assumptions about EAs of files
    (such as the type of a file's contents) but lack
    Ada style explicitness.

That' another standard that should live outside language
definitions.

While fewer modern OSs have support BSD sockets (remember,
TCP/IP was an add-on to OS/2 and Windows, and to larger
IBM computers, I believe), I thought that

- if Ada was to standardize a binding, then that's new.
   Something standard that is not about an abstraction,  but
   rather about including some historic incident like BSD
   sockets, in the language description.

- it seems completely sufficient to agree, outside the standard,
   on an API that can be used with any Ada compiler.  No
   standardization  is needed at all.

- Wait. We *do* have Ada Posix binding with an ISO number; since
   Posix sockets do the trick, there is no need to add them to Ada.

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 May 2011 00:39:58 +0200, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:
> - if Ada was to standardize a binding, then that's new.
>    Something standard that is not about an abstraction,
That's about abstraction, otherwise socket could be defined atop of Ada  
streams (defining pipes over Ada streams, would be OK as an example, but  
defining sockets above Ada streams, would not).

>    but
>    rather about including some historic incident like BSD
>    sockets, in the language description.
Where do you think Unicode (now partially supported by Ada) is rooted ?  
Answer : one of the topmost code page at sometime.

> - it seems completely sufficient to agree, outside the standard,
>    on an API that can be used with any Ada compiler.  No
>    standardization  is needed at all.
OK. Let say it is not required, so "not" may be an option. But to answer  
the topic, you should now give an answer to why this should not. If  
"don't" is an option, "do" is still an option too.

> - Wait. We *do* have Ada Posix binding with an ISO number; since
>    Posix sockets do the trick, there is no need to add them to Ada.
Bringing all of POSIX just to get sockets, is too heavy. And sockets can  
live without POSIX (in some extent, even POSIX could live without sockets,  
which is not a major part of this standard, as far as I understand it).


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Georg Bauhaus]

On 5/24/11 9:38 PM, Yannick Duchêne (Hibou57) wrote:

> The POSIX specification seems to only differs in the way to get host by name / address.

POSIX differs by being a standard.



> What networking requirement ?

In ISO Ada standardization, requirements seem the
reasonable criteria by which to proceed.


> This thread is not about OSI layers packages for Ada, it's only about sockets,

Then use the sockets from the Ada-POSIX binding and say a few
strong words when your Ada vendor wishes to talk you into its
compiler specific language packages.


> Be pragmatic

Hell, no, I'm really fed up with cleaning up after pseudo
pragmatism.  When it comes to standardization, the topos
"pragmatic" has a very different meaning, an Ada meaning,
not one of advertising an existing binding for language blessing.
One aspect is that is must be practically possible to implement
a feature.

I don't expect SMB/CIFS in Ada either, even though it is
just as ubiquitous, and even when using it means being
"pragmatic".



>> 2. In the light of Ada's history regarding standardization,
>> there is, I believe, networking knowledge that warrants more
>> than canonization of a practical workaround---which might fail
>> if requirements are actually different.

> What workaround ?

When the requirements include "networking", then why would a
language make the requirements more specific than need be
by providing a standard package restricted to BSD Socket
techniques?



>> - What should programs be able to do when communicating data
>> along some network connection?
> Answered by the socket specification : there are raw, datagram, stream, blocking and none-blocking sockets, with IPv4 or IPv6 addresses.

IP?



>> - Is sockets the right approach? Consider Erlang!
> Seems Erlang actually provides sockets.

More prominently, and crucially, Erlang has channels
built into the language, even into the syntax.
That's the things by which you compare, design,
and standardize languages, IMHO.


>> - Is sockets the right approach? Consider a CAN!
> A can 8-) ?

A CAN is real, it is wide spread, it is not that new, and
has money associated with it.  I'm not familiar with one,
but I am aware of its existence, and certainly that is
a network to be considered if networking stuff is to be
added to Ada proper.

Re: Why no socket package in the standard ?

[Georg Bauhaus]

On 5/24/11 9:38 PM, Yannick Duchêne (Hibou57) wrote:

>> I doubt that the best answer to these questions can
>> be summed up by saying, "Mirror Posix sockets!".
> Why ?

Because design of networked applications in general,
following a language standard, cannot be addressed
by the QoI of some Unix library only.
In particular when this is about language standardization.

Millions of programs run fairly well and call C library functions.
That's not a compelling reason to add more from the C library
to the Ada standard, is it?

Threads, POSIX style threads, are ubiquitous as well.
Should they get an Annex, too?

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 16:28:32 +0200, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:
> From a programmer perspective, sockets may well be about
> how to send a String value to some "Port" on some
> "machine" identifiable via DNS.
Not only, the concern is also about the protocol behavior, that is mainly  
reliable/non-reliable, stream/non-stream. What make the difference between  
stream and non-stream, is the reliability… TCP/IP is looking like a PIPE,  
except for its identity, UDP/IP is not.

> A more general approach to sending data around.  That's what socket
> programs do very frequently, I think, at least when they stream text,
> for example. From the programmer's point of view, they use text based
> protocols. Not datagrams or packages or anything.  This defines one use
> case of (technically sockets based) data communication.
I do not see what fund your proclamation “Not datagrams or packages or  
anything”. UDP is really used when it does not matter a lot when some data  
is lost on reception or emission (used for example, for some kind of  
continuous real-time stream).

> Why insist on sockets, then?
Good question. May be talking about IPC would be wiser then. After all,  
IPC could be seen as a primitive for RPC, which Ada already talks about.

> Which is why I had hoped to remind that Ada programs, even when
> operating a network, might not profit at all from a standard sockets
> package, if they do not use sockets, but do control networked  
> communication.
Be pragmatic. Nothing is totally 0 or totally 1. The kind of application  
you are pointing, are the most rare, the one targeted by sockets, are the  
most common of the two.

> Yes.  But at least we might try to learn, for the purpose of  
> standardization,
> what a typical transport level issue is versus what an application level  
> issue
Reliability levels (and identity also).

> is---not so much about how solutions are built around sockets whenever
> these happen to be available.  Standards work seems a good opportunity
> to isolate, in abstract terms, what a transport level issue is.   (And  
> what it
> might or might not have to do with Ada, or sockets, see below.)
:-)

> If these issues are central to Ada programming, and future-proof,
> there might be funding for isolating a few requirements.  Then start
> from these requirements.
I welcome this “isolating a few requirements”, cause as replied elsewhere,  
some part of the BSD sockets would probably not be welcome (raw sockets).

> Or, if sockets are as important as, say, timers, or windows---if they
> are important, then enlighten industry (or govt.) that they have the  
> power
> to ask for compiler-independent packages. These would not even
> need ISO standardization, just compiler independence, to be used
> by industry.
May be an option, I agree. Still that as replied elsewhere, you still lack  
an answer to the other option : why would fund the rejection ?

> No one else has the power.
Pragmatism would suggest the community of active developers (proprietary  
or not).

> Remembering industry's built-in rewards system for anti-co-operation,
> its power to influence the software makers towards generally useful
> packages is unlikely to be employed, though.  (Packages that could
> be used with a different compiler! By a different company!?)
There is no way to be afraid of such things with sockets. Or do you see  
some ?

> The original question was, "Why no socket package in the standard?".
>
> Let me rephrase it: "Why no ISO/IEC 14519:2001 package in the standard?"
There is no way to rephrase it this way. POSIX is not comparable to  
sockets.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 May 2011 01:09:49 +0200, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:
> More prominently, and crucially, Erlang has channels
> built into the language
Yes, channels is a good abstraction.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 May 2011 01:11:47 +0200, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:
> Threads, POSIX style threads, are ubiquitous as well.
> Should they get an Annex, too?
Ada has task, POSIX threads may be just a flavor or a material to start  
with to implement Ada task as specified by Ada.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Adam Beneschan]

On May 24, 3:35 pm, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:

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

All right, I have to ask for a translation.  I don't speak French and
can only figure out some of the words here.  We have a beagle that
makes some pretty bizarre sounds sometimes, but this probably isn't
about that.  :)

                       -- thanks, Adam

Re: Why no socket package in the standard ?

[Ludovic Brenta]

Yannick Duchêne writes on comp.lang.ada:
> These all shows your objection is not relevant : pragmatism is,
> however.

Your insistence that BSD sockets ought to be part of the Ada language
definition is anything *but* pragmatic, especially when there already
exists a standard for sockets, called POSIX.5, an implementation of
which is readily available at no cost.  Oh BTW: no, you do not need all
of POSIX if you "just" want to use sockets.  If you were pragmatic,
you'd be busy writing your sockets application right now, using Florist.

> By the way, there is not event something like a standard OS (there may
> be proprietaries or not, but none is standard).

POSIX is a standard.  A POSIX-compliant OS is a standard OS.  An OS that
refuses to comply with POSIX, or any other standard, is non-standard.

Even MVS aka z/OS is standard in that sense.

-- 
Ludovic Brenta.

Re: Why no socket package in the standard ?

[Ludovic Brenta]

Adam Beneschan writes:
> On May 24, 3:35 pm, Yannick Duchêne (Hibou57)
> <yannick_duch...@yahoo.fr> wrote:
>
>> Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
>> les chiens.
>
> All right, I have to ask for a translation.  I don't speak French and
> can only figure out some of the words here.  We have a beagle that
> makes some pretty bizarre sounds sometimes, but this probably isn't
> about that.  :)

"Whenever cats meow and sing bizarrely, it's not for dogs."

I too need a translation...

-- 
Ludovic Brenta.

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 May 2011 01:40:40 +0200, Ludovic Brenta  
<ludovic@ludovic-brenta.org> a écrit:
> "Whenever cats meow and sing bizarrely, it's not for dogs."
>
> I too need a translation...
Stop joking french guy ;)

Adam, “not for the dogs” (literally « pas pour les chiens »), is a french  
expression meaning “not for nothing” (i.e. “there is a purpose” or “that  
really means something”). Actually, this cannot be really translated into  
English (or any other language else than french), as this plays with  
french words polysemy. P.S. I still enjoy dogs, along with beagles, as I  
feel of any other forms of life ;)

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Georg Bauhaus]

On 5/25/11 12:54 AM, Yannick Duchêne (Hibou57) wrote:
> Le Wed, 25 May 2011 00:39:58 +0200, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> a écrit:
>> - if Ada was to standardize a binding, then that's new.
>> Something standard that is not about an abstraction,
> That's about abstraction,

An abstraction like "network data communication" which
would be similar to Sequential File. Whichever way the
latter happens to be available in the external environment,
you can open the file, read or write items, close it,
etc.


>> but
>> rather about including some historic incident like BSD
>> sockets, in the language description.
> Where do you think Unicode (now partially supported by Ada) is rooted ?

http://www.unicode.org/history/earlyyears.html

Specifically, you can see how requirements were weighed
and how the process didn't just revolve around just one
precendent.  They also noticed how they had been wrong
assuming things. (In the following quote, I have replaced
some Unicode specifics with letters to better show the
general pattern in the process):

"But all of a sudden, we could see the light go on in both
of our faces: we had assumed that the standard ABC was a XYZ
standard. We were so, so wrong. You needed WYZX to represent
even the most common N. Worse yet, some P could be both G
and H. We weren't in Kansas anymore!"

I'm guessing that the same is going to happen if the  Ada
standard were to quickly adopt BSD Sockets.

>> - it seems completely sufficient to agree, outside the standard,
>> on an API that can be used with any Ada compiler. No
>> standardization is needed at all.
> OK. Let say it is not required, so "not" may be an option.

Because a language standard is about things more general
than a specific networking library.



>> - Wait. We *do* have Ada Posix binding with an ISO number; since
>> Posix sockets do the trick, there is no need to add them to Ada.
> Bringing all of POSIX just to get sockets, is too heavy.

The POSIX binding is ISO standardized. In a POSIX environment,
such as Unix, Ada compilers would naturally be running on
POSIX anyway.  So it's already there.  If not, then adding the
binding will not mean that by using POSIX sockets you will
also be dragging in POSIX threads, IMHO?.  A language that
allows a Max_Tasks => 0 restriction but threads when a
programmer wishes to with a POSIX package?

Re: Why no socket package in the standard ?

[Georg Bauhaus]

On 5/25/11 1:28 AM, Yannick Duchêne (Hibou57) wrote:
> Le Wed, 25 May 2011 01:11:47 +0200, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> a écrit:
>> Threads, POSIX style threads, are ubiquitous as well.
>> Should they get an Annex, too?
> Ada has task, POSIX threads may be just a flavor or a material to start with to implement Ada task as specified by Ada.

Exactly.  And the same may be true of BSD Sockets.

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 18:07:42 +0200, Adam Beneschan <adam@irvine.com> a  
écrit:
> What do you mean by "this height"?  What height?  From what I can
> tell, figuring out the correct level of abstraction is still part of
> the problem, a part that needs a lot of thought.
Indeed, communication with the outside world, is a master concern for a  
program. I do not see a reason why this should be restricted to files and  
pipes as it is actually in the Ada standard. This is not an option, this  
is a requirement.

> Being able to communicate with programs written in other languages
> *is* a need, and I think that any package that would become part of
> the Ada standard would have to meet that need.  And I think it could
> be done with some level of abstraction, i.e. with more than just a
> thin binding to the Unix socket library, and in a way that allows for
> different communications mechanisms than just sockets.
As I replied to Georg, I agree too with the need of more abstraction  
(that's a good idea). I came to start with sockets, because this is  
actually the first and straightforward thing you think about when you have  
that need. But I agree more abstraction would be welcome, as limiting this  
to sockets, would be as much a damage, as the lack of support for  
communication beyond files.

>  (I have some
> experience with this.  I wrote a message-communication package that
> had two different bodies, one that implemented the messages with VMS
> mailboxes, and another that used sockets to communicate with a Solaris
> host.  This was due to requirements imposed by the customer, and it
> was set up to communicate specifically with a program written by the
> customer.  But the package specification was the same in both cases
> and was general enough that I was able to reuse it for other
> purposes.  So I'm convinced this is doable, but difficult to do in a
> way that will meet the needs of as many users as possible.)
>
>                                   -- Adam
Well, what would you think about these abstract properties (I will talk  
about channels, to use a term introduced bu Georg after Erlang concepts) :

* A channel may be data conservative or non-conservative

      - Conservative: all data sent between peers will be received
      - Non-Conservative: some data sent between peers may be lost.
      - Socket analogy: TCP vs UDP

* A channel may be relative time conservative or non-conservative

      - Conservative: any data chunk sent after a previous one, will
        arrive after that previous one.
      - Non-Conservative: data chunk sent after a previous one, may
        be received at the same time as the previous after it was
        delayed as well after the previous.
      - Socket analogy: the Nagle algorithm is disabled vs enabled.

* A channel may act as a sequence or as a kind of set

     - As a sequence: data arrives in the same order as sent.
     - As a set: data arrives in any order, order does not matter.
     - Socket analogy: TCP vs UDP (not a perfect analogy for
       UDP).

* A channel with the “sequence” property and the “relative time  
conservative” property, may be either have real-time requirement or not  
have real time requirement.

* A channel may have a global or a local identity (global or local, is a  
property of the identity).

* A channel identity may have aliases (which would not be required, there  
could be only one), and during one session, only one of its identifier  
would be the canonical one (luckily, otherwise this would be mess-prone).  
Honestly, this aspect seems a bit tricky to me.

I still have questions about blocking/non-blocking, although task would  
probably be involved here (any way, Ada already allows I/O to be  
potentially blocking).

What about this first draft of a draft ? :)

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Georg Bauhaus]

On 5/25/11 1:20 AM, Yannick Duchêne (Hibou57) wrote:

>> Which is why I had hoped to remind that Ada programs, even when
>> operating a network, might not profit at all from a standard sockets
>> package, if they do not use sockets, but do control networked communication.
> Be pragmatic. Nothing is totally 0 or totally 1.

Bits are, in general, totally 0 or totally 1.

> The kind of application you are pointing, are the most rare,

Really?  I understand that < 32 bits µcontrollers are the most
widespread computer systems.  Is it true that they use UDP,
say, to send and receive signals along the wire, if any?


>> Or, if sockets are as important as, say, timers, or windows---if they
>> are important, then enlighten industry (or govt.) that they have the power
>> to ask for compiler-independent packages. These would not even
>> need ISO standardization, just compiler independence, to be used
>> by industry.
> May be an option, I agree. Still that as replied elsewhere, you still lack an answer to the other option : why would fund the rejection ?

Why fund rejection?  No money needed there.
  
>> No one else has the power.
> Pragmatism would suggest the community of active developers (proprietary or not).

The community of active developers tends to be part of,
and to be paid by, the industry (and govt.).  Not every
developer has the time, the resources, and the freedom to
write the stuff that everyone needs.  Things seem to go
well as regards POSIX, likely including free software development.


>> Remembering industry's built-in rewards system for anti-co-operation,
>> its power to influence the software makers towards generally useful
>> packages is unlikely to be employed, though. (Packages that could
>> be used with a different compiler! By a different company!?)
> There is no way to be afraid of such things with sockets. Or do you see some ?

I wouldn't be surprised!


>> The original question was, "Why no socket package in the standard?".
>>
>> Let me rephrase it: "Why no ISO/IEC 14519:2001 package in the standard?"
> There is no way to rephrase it this way. POSIX is not comparable to sockets.

Why?  POSIX defines Socket, Socket Address, Connection, Datagram,
etc.  It has a section "Networking Services" that starts with "Sockets Overview".

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 May 2011 01:54:02 +0200, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:
> An abstraction like "network data communication" which
> would be similar to Sequential File. Whichever way the
> latter happens to be available in the external environment,
> you can open the file, read or write items, close it,
> etc.
IPC have unavoidable properties, which are as real as physics is, and  
which cannot be expressed in terms of file access. File access is somewhat  
pure and simpler than IPC, and is just a particular case of IPC, which  
(the latter) is wider.

> http://www.unicode.org/history/earlyyears.html
>
> Specifically, you can see how requirements were weighed
> and how the process didn't just revolve around just one
> precendent.
Will read this later (I interested in Unicode since very long). Any way,  
Unicode code points still match ISO 8859-1 (which does not require  
mapping).

> "But all of a sudden, we could see the light go on in both
> of our faces: we had assumed that the standard ABC was a XYZ
> standard. We were so, so wrong. You needed WYZX to represent
> even the most common N. Worse yet, some P could be both G
> and H. We weren't in Kansas anymore!"
Oops, will have to read this again and again before I am sure I've  
understood (where does this quote originates ? a novel ?).

> I'm guessing that the same is going to happen if the  Ada
> standard were to quickly adopt BSD Sockets.
Stooooop.

I agreed for a better abstraction multiple since your last replies ;)

>>> - it seems completely sufficient to agree, outside the standard,
>>> on an API that can be used with any Ada compiler. No
>>> standardization is needed at all.
>> OK. Let say it is not required, so "not" may be an option.
>
> Because a language standard is about things more general
> than a specific networking library.
You said this after you though I wanted BSD sockets, strictly. But that is  
not, I want, not BSD sockets, but the functionalities BSD sockets  
provides. And these are not available through the file nor the stream  
interface of actual Ada.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 May 2011 01:57:36 +0200, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:

> On 5/25/11 1:28 AM, Yannick Duchêne (Hibou57) wrote:
>> Le Wed, 25 May 2011 01:11:47 +0200, Georg Bauhaus  
>> <rm.dash-bauhaus@futureapps.de> a écrit:
>>> Threads, POSIX style threads, are ubiquitous as well.
>>> Should they get an Annex, too?
>> Ada has task, POSIX threads may be just a flavor or a material to start  
>> with to implement Ada task as specified by Ada.
>
> Exactly.  And the same may be true of BSD Sockets.
Nice to meet you here Georg :)


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 May 2011 02:32:36 +0200, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:
>> May be an option, I agree. Still that as replied elsewhere, you still  
>> lack an answer to the other option : why would fund the rejection ?
>
> Why fund rejection?  No money needed there.
Sorry, was mislead by a similar french word which has another meaning. I  
meant “what would base/justify the rejection”


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 21:21:43 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>> Being able to communicate with programs written in other languages
>> *is* a need, and I think that any package that would become part of
>> the Ada standard would have to meet that need.
>
> You cannot do that in a standard way because many of not most other
> language do not have means for that. This is why lower level protocols  
> are used, e.g. sockets.
Right. Ada has provisions to do it a cleaner (and less  
one-arbitrary-technology-tied) way.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 16:59:52 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>> Let me rephrase it: "Why no ISO/IEC 14519:2001 package in the standard?"
>
> I cannot say. I do not care much about POSIX
Me too. To care about POSIX and to care about IPC (remote included) are  
two disjoint matters (you may care to both, just one, or none, these are  
not correlated).


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 May 2011 02:34:16 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
>> "But all of a sudden, we could see the light go on in both
>> of our faces: we had assumed that the standard ABC was a XYZ
>> standard. We were so, so wrong. You needed WYZX to represent
>> even the most common N. Worse yet, some P could be both G
>> and H. We weren't in Kansas anymore!"
> Oops, will have to read this again and again before I am sure I've  
> understood (where does this quote originates ? a novel ?).

OK, you did a rewritten excerpt of
http://www.unicode.org/history/earlyyears.html
Now I understand (at least I feel)

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Shark8]

On May 24, 2:54 pm, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> Oh, and I think I did mention GNAT.Sockets.  So what are people
> complaining about, again?
>
> --
> Ludovic Brenta.

As near as I can tell "Ada doesn't have BSD's POSIX SOCKETS!!"...
but I might be reading into the text what's not there.

Re: Why no socket package in the standard ?

[Shark8]

On May 24, 6:35 pm, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> Yannick Duchêne writes on comp.lang.ada:
>
>
> > By the way, there is not event something like a standard OS (there may
> > be proprietaries or not, but none is standard).
>
> POSIX is a standard.  A POSIX-compliant OS is a standard OS.  An OS that
> refuses to comply with POSIX, or any other standard, is non-standard.
>
> Even MVS aka z/OS is standard in that sense.
>
> --
> Ludovic Brenta.

And, it is useful/instructive to realize that just because something
is a
[part of a] standard does NOT mean that standard requires/says
anything useful.

This was something I learned from a mathematics professor (though
about
'definitions' rather than 'standards') and is important enough that it
should be remembered from time-to-time.

{IIRC as far as POSIX is concerned, MS Windows has been POSIX
complaint
 since 2000... and this says NOTHING about how portable binaries (or
their
sources) are between Windows and unix/linux computers.}

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 May 2011 05:07:06 +0200, Shark8 <onewingedshark@gmail.com> a  
écrit:
> {IIRC as far as POSIX is concerned, MS Windows has been POSIX
> complaint
>  since 2000... and this says NOTHING about how portable binaries (or
> their
> sources) are between Windows and unix/linux computers.}

Also funny to note two things.

   1) There exist a “Windows Services for UNIX”, alias “Subsystem for  
UNIX-based Applications”.
      See http://technet.microsoft.com/fr-fr/library/bb496506(en-us).aspx
   2) Linux is not fully POSIX compliant
      See  
https://www.opengroup.org/platform/single_unix_specification/uploads/40/13450/POSIX_and_Linux_Application_Compatibility_Final_-_v1.0.pdf
      (and it appears no one would want to pay the average $15000 fee  
required to pass compliance test which would be required anyway)

That was just to tease a bit the author of the claim :-P POSIX does not  
make an OS better or worse than another, as POSIX is meaningful only where  
POSIX is a requirement, and that is restricted to some application areas  
(as an example, most desktop users don't care at all). This provides no  
other added value than that.

Then I don't believe POSIX is a standard the same way Ada is a standard.  
Ada started as a standard from requirements, while POSIX started as a  
standard from existing features : its purpose was to be a standard for  
UNIX systems… so anyone can bet this is not surprising then if UNIces  
seems more POSIX compliant than others. Or may be UNIX is the only one  
legitimate OS base ? (I believe someones believe this, indeed). POSIX is  
not more a standard than PHP or Python are.

I am not even sure a POSIX platform make designing a compliant Ada  
compiler easier (at least as an example, the Linux thread model is not  
that cool, not to talk about file locking, which is often required with  
concurrent task).

Apologizes to others for that crooked post.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Georg Bauhaus]

On 5/25/11 6:01 AM, Yannick Duchêne (Hibou57) wrote:

>  POSIX does not make an OS better or worse than another,
>   as POSIX is meaningful only where POSIX is a requirement,
>   and that is restricted to some application areas (as an
>   example, most desktop users don't care at all).
>  This provides no other added value than that.

When programs are written for POSIX, chances are that you can
compile them.  This is a consequence of POSIX being a widely
supported standard.

POSIX is a much better starting point than that huge non-standard
obstacle that gets in the way of portability: Unix-C+autoconf.

Re: Why no socket package in the standard ?

[Georg Bauhaus]

On 5/25/11 5:07 AM, Shark8 wrote:

> MS Windows has been POSIX complaint since 2000...

Nice. ;-)

Re: Why no socket package in the standard ?

[Ludovic Brenta]

Yannick Duchêne wrote on comp.lang.ada:
>    1) There exist a “Windows Services for UNIX”, alias “Subsystem for  
> UNIX-based Applications”.
>       See http://technet.microsoft.com/fr-fr/library/bb496506(en-us).aspx

Which confirms that Windows is not POSIX-compliant out of the box but
requires an add-on.

>    2) Linux is not fully POSIX compliant
>       See  https://www.opengroup.org/platform/single_unix_specification/uploads/...
>       (and it appears no one would want to pay the average $15000 fee  
> required to pass compliance test which would be required anyway)

It is funny that after reading the first paragraph of that document
you should claim that:

> POSIX is not more a standard than PHP or Python are.

Come on.  POSIX started as an IEEE standard and has been an ISO
standard (specifically ISO/IEC 9945) since 1996.  How much more
standard do you want it to be?

--
Ludovic Brenta.

Re: Why no socket package in the standard ?

[Ludovic Brenta]

Shark8 wrote on comp.lang.ada:
> On May 24, 6:35 pm, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>> Yannick Duchêne writes on comp.lang.ada:
>>> By the way, there is not event something like a standard OS (there may
>>> be proprietaries or not, but none is standard).
>>
>> POSIX is a standard.  A POSIX-compliant OS is a standard OS.  An OS that
>> refuses to comply with POSIX, or any other standard, is non-standard.
>>
>> Even MVS aka z/OS is standard in that sense.
>
> And, it is useful/instructive to realize that just because something
> is a [part of a] standard does NOT mean that standard requires/says
> anything useful.

The reason why I mentioned POSIX is because the OP declared BSD
sockets to be "the standard" and wanted this included in the Ada
language definition.  POSIX is "the standard" as far as sockets are
concerned and POSIX.5 is "the standard Ada socket interface".  But you
are right; just because someone wants sockets in Ada does not mean
that sockets are necessarily the best solution, or even useful at all,
for the problem at hand.

> This was something I learned from a mathematics professor (though
> about 'definitions' rather than 'standards') and is important enough
> that it should be remembered from time-to-time.
>
> {IIRC as far as POSIX is concerned, MS Windows has been POSIX
> complaint since 2000... and this says NOTHING about how portable
> binaries (or their sources) are between Windows and unix/linux
> computers.}

Actually it does; POSIX is all about source compatibility.  Of course,
if you want source compatibility, your application must comply with
the standard, i.e. not use any non-standard features (i.e. you can use
sockets but no GUI for example).  This brings us back to the question
of the usefulness of a particular standard for a particular problem.

--
Ludovic Brenta.

Re: Why no socket package in the standard ?

[Dmitry A. Kazakov]

On Wed, 25 May 2011 01:20:53 +0200, Yannick Duchêne (Hibou57) wrote:

> What make the difference between  
> stream and non-stream, is the reliability…

No, packets can be reliable as well. Stream enforces an sequential order on
the data items.

BTW, many, if not most industrial protocols, which use TCP/IP, add a packet
layer on top of it. This makes packets reliable.

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

Re: Why no socket package in the standard ?

[Pascal Obry]

Le 25/05/2011 02:32, Georg Bauhaus a écrit :
> Bits are, in general, totally 0 or totally 1.

Hum... Don't you remember the weak-bit from Copywrite tool that was able 
to write in a floppy disk a bit that could be 0 or 1. This was used as a 
software copy control at this time. Copywrite was able to mimic that to 
bypass the protection.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Why no socket package in the standard ?

[Dmitry A. Kazakov]

On Wed, 25 May 2011 02:32:36 +0200, Georg Bauhaus wrote:

> On 5/25/11 1:20 AM, Yannick Duch�ne (Hibou57) wrote:
> 
>> The kind of application you are pointing, are the most rare,
> 
> Really?  I understand that < 32 bits �controllers are the most
> widespread computer systems.  Is it true that they use UDP,
> say, to send and receive signals along the wire, if any?

It is difficult to say. Modern protocols are such a huge complex mess, that
TCP/IP stack were a minor concern here. In my experience UDP is pretty rare
in process automation. For example XCP runs on top of UDP. TCP/IP is more
widely used, but like UDP almost always with something on top of it, e.g.
DLMS, ModBus etc.

Anyway, I would like to stress that it is not data exchange which makes
troubles. Before you get on data, you must configure the slaves. This stuff
is in relation 90 to 10 (or more) to data exchange. So, if Ada standardized
the exchange, that would be unusable anyway.

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

Re: Why no socket package in the standard ?

[Georg Bauhaus]

On 5/25/11 9:55 AM, Pascal Obry wrote:
> Le 25/05/2011 02:32, Georg Bauhaus a écrit :
>> Bits are, in general, totally 0 or totally 1.
>
> Hum... Don't you remember the weak-bit from Copywrite tool that was able to write in a floppy disk a bit that could be 0 or 1. This was used as a software copy control at this time. Copywrite was able to mimic that to bypass the protection.

These are tits, then, not bits.

Re: Why no socket package in the standard ?

[Dmitry A. Kazakov]

On Wed, 25 May 2011 01:09:49 +0200, Georg Bauhaus wrote:

> A CAN is real, it is wide spread, it is not that new, and
> has money associated with it.

Yes, but

1. CAN is dying, to be superseded by EtherCAT, XCP etc.

2. CAN requires special adaptors (vendors are IXXAT, Vector, NI), which
have no standardized interface. You need to standardize that interface
first, i.e. do the job sockets did for Ethernet adapters.

3. Raw CAN is only 20% or so. Most vendors use CAN Open on its top. CAN
Open is an utter mess.

4. Raw CAN is useless at the application level, because it has only 8 bytes
of data (if you don't mess with IDs, which would give another 11 bits).

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

Re: Why no socket package in the standard ?

[Thomas Løcke]

On 05/24/2011 09:54 PM, Ludovic Brenta wrote:
> Florist is a Free Software implementation of POSIX.5.  The only nit you
> might pick is that POSIX.5 is not included by reference in the Ada
> Reference Manual.  Personally I don't really care.  If I need to and if
> my target system is POSIX compliant (which it always is in practice), I
> can write a standard Ada program using the standard sockets interface
> which is part of the standard POSIX.5.
>
> Oh, and I think I did mention GNAT.Sockets.  So what are people
> complaining about, again?



The Florist package from libre.adacore.com appears to have dumped POSIX
sockets. At least I can't find them anywhere.

Is there another Florist package available out there in the wild?

Or am I just missing something completely obvious?

-- 
Thomas Løcke

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

Re: Why no socket package in the standard ?

[Dmitry A. Kazakov]

On Tue, 24 May 2011 14:22:42 -0700 (PDT), Maciej Sobczak wrote:

> On 24 Maj, 09:25, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> In the language? Probably none, as this does not belong to the
>>> language.
>>
>> That is an interesting question. Actually sockets could belong to the
>> language. Consider for example the select statement containing alternatives
>> of a socket's select.
> 
> Still, they (sockets) don't have to be part of the language to be
> select-ready. It is enough to make them protected objects with
> appropriate entries.

1. We need to be able to cancel connect/accept/send/receive from an AST or
timed entry call.

2. We should never do any I/O related stuff on the context of a protected
action.

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

Re: Why no socket package in the standard ?

[Dmitry A. Kazakov]

On Wed, 25 May 2011 00:04:19 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Tue, 24 May 2011 09:25:38 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
>> There are many difficulties on that path. When people are demanding sockets
>> they forget that beyond TCP/IP and UDP there is a lot of other stuff
>> communicated over sockets
> This can be abstracted down.

Hmm, how would you abstract, say, PGM?

> A question : what is the state of the use of IP based protocols in the  
> embedded-boards area?

VxWorks provides a full implementation of TCP/IP stack and UDP. We are
using both (through GNAT sockets).

I have no idea about bare-boards. I guess it depends on the board.

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

Re: Why no socket package in the standard ?

[Peter C. Chapin]

On Wed, 25 May 2011 06:01:06 +0200, Yannick Duchêne (Hibou57) wrote:

> Then I don't believe POSIX is a standard the same way Ada is a standard.
> Ada started as a standard from requirements, while POSIX started as a
> standard from existing features : its purpose was to be a standard for
> UNIX systems… so anyone can bet this is not surprising then if UNIces
> seems more POSIX compliant than others. Or may be UNIX is the only one
> legitimate OS base ? (I believe someones believe this, indeed). POSIX is
> not more a standard than PHP or Python are.

I think that's an inaccurate characterization of POSIX.

POSIX is, in fact, a standard. It was originally created by the IEEE. 
See, for example:

     http://pubs.opengroup.org/onlinepubs/009695399/

From the abstract:

"This standard defines a standard operating system interface and 
environment, including a command interpreter (or "shell"), and common 
utility programs to support applications portability at the source code 
level. This standard is the single common revision to IEEE Std 
1003.1-1996, IEEE Std 1003.2-1992, and the Base Specifications of The 
Open Group Single UNIX Specification, Version 2. This standard is 
intended to be used by both applications developers and system 
implementors. It comprises four major components (each in an associated 
volume)"

It is true that POSIX was designed to standardize the existing practice 
in the Unix community. This is typical of the way standards are usually 
created; it is the history of the Ada standard is unusual.

It also true that autoconf is a travesty... a throwback to a darker age 
when the POSIX standard did not exist (or at least was not widely 
implemented).

Peter

Re: Why no socket package in the standard ?

[Manuel Collado]

El 25/05/2011 9:42, Ludovic Brenta escribi�:
> Yannick Duch�ne wrote on comp.lang.ada:
>>     1) There exist a �Windows Services for UNIX�, alias �Subsystem for
>> UNIX-based Applications�.
>>        See http://technet.microsoft.com/fr-fr/library/bb496506(en-us).aspx
>
> Which confirms that Windows is not POSIX-compliant out of the box but
> requires an add-on.

IMHO, the most POSIX compliant Windows add-on is Cygwin. Much more than 
Microsoft's �Windows Services for UNIX�.

And it includes GPL Ada, if that matters ;-)

-- 
Manuel Collado - http://lml.ls.fi.upm.es/~mcollado

Re: Why no socket package in the standard ?

[Pascal Obry]

Le 25/05/2011 09:40, Georg Bauhaus a �crit :
> On 5/25/11 5:07 AM, Shark8 wrote:
>
>> MS Windows has been POSIX complaint since 2000...
>
> Nice. ;-)

Well Windows 2000 had a POSIX subsystem (that probably almost nobody has 
ever used) completely separate to the Win32 one. This was done to be 
able to enter some european market IIRC, no?

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Why no socket package in the standard ?

[Peter C. Chapin]

On Wed, 25 May 2011 02:21:26 +0200, Yannick Duchêne (Hibou57) wrote:

> Indeed, communication with the outside world, is a master concern for a
> program. I do not see a reason why this should be restricted to files
> and pipes as it is actually in the Ada standard. This is not an option,
> this is a requirement.

You asked originally why there is no support for sockets in the Ada 
standard itself (as opposed to an auxiliary operating system standard). I 
think the length of this thread is your answer: it's a contentious issue. 
There are just so many ways to deal with network communication that it's 
very unclear how one would standardize it at the language or standard 
library level.

Files are a bit different since most systems support files in a similar 
way... at least when it comes to the basics. Even with files, however, 
issues arise.

Peter

Re: Why no socket package in the standard ?

[Maciej Sobczak]

On 25 Maj, 11:14, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > Still, they (sockets) don't have to be part of the language to be
> > select-ready. It is enough to make them protected objects with
> > appropriate entries.
>
> 1. We need to be able to cancel connect/accept/send/receive from an AST or
> timed entry call.

No problem, use non-blocking I/O as an underlying implementation.

> 2. We should never do any I/O related stuff on the context of a protected
> action.

No problem - the protected object need not represent the socket
directly, it might as well be a proxy only representing its current
state, in which case no I/O happens in the protected context.

Both solutions above have been used in YAMI4:

http://www.inspirel.com/yami4/

where in the high-level Ada interface outgoing messages are
represented as protected objects exactly with the purpose of making
them selectable.
It is true, however, that YAMI4 operates at a much higher level of
abstraction (messages vs. sockets) and this type of library design
might not be adequate with something as low-level as sockets. On the
other hand, asynchronous communication services (instead of naive use
of basic socket API) could potentially solve this problem.

Looks like an interesting project idea...

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

Re: Why no socket package in the standard ?

[Dmitry A. Kazakov]

On Wed, 25 May 2011 04:54:20 -0700 (PDT), Maciej Sobczak wrote:

> On 25 Maj, 11:14, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> Still, they (sockets) don't have to be part of the language to be
>>> select-ready. It is enough to make them protected objects with
>>> appropriate entries.
>>
>> 1. We need to be able to cancel connect/accept/send/receive from an AST or
>> timed entry call.
> 
> No problem, use non-blocking I/O as an underlying implementation.

The problem is not the implementation, but the interface. If sockets to be
a part of the language they should use language means for handling
synchronization issues.

>> 2. We should never do any I/O related stuff on the context of a protected
>> action.
> 
> No problem - the protected object need not represent the socket
> directly, it might as well be a proxy only representing its current
> state, in which case no I/O happens in the protected context.

I meant handling the states, doing I/O from a protected action would be
just illegal. But it is also inadmissible to handle read/write completion
from there. Yes you could release some waiting tasks and pass the I/O
buffer to one of them, this is how sockets are dealt with now. Such a
clumsy design does not deserve standardization, IMO.

I think that "task" is a more suitable abstraction for socket.

    task type Connect_Socket is
        entry Connect (...);
        entry Receive (...);
        entry Send (...)
    end Socket;

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

Re: Why no socket package in the standard ?

[Tero Koskinen]

Hi,

On Tue, 24 May 2011 06:11:43 +0000 (UTC) tmoran@acm.org wrote:

> > Except (I just looked at the source) I personally don't enjoy bindings
> > which end to introduce C like namings [*] in Ada. Things like PF_INET,
> > IPPROTO_IP or SOL_SOCKET looks really strange for an Ada source;
> 
> A thicker binding is NC sockets ("Not Claw", derived from Claw.Sockets).
> It's nc.zip at www.adaworld.com, look there under
> Ada Projects/Ada Internet Projects/Internet Protocols
> It's for Windows but IIRC the WSAStartup and WSACleanup should be
> the only Windows specific things.

Here is a diff which allows the package to compile on OpenBSD/amd64.
(It includes also some filename upper/lower case corrections, so
 the diff is pretty big.)

The example programs still segfault. I guess the datastructure
definitions are incorrect.

diff -r f734a2862510 -r 2cca25a3f5f4 GETJPG.ADB
--- a/GETJPG.ADB	Tue Dec 21 19:45:44 2010 +0200
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,75 +0,0 @@
--- Sample program using NC.Sockets
--- It goes to the San Jose State weathercam and downloads to pic.jpg
--- a picture of the current skyline in San Jose, California
--- Copyright 2003 tmoran@acm.org anyone may use for any purpose
-with Ada.Streams,
-     Ada.Streams.Stream_IO,
-     Ada.Text_IO,
-     Nc.Sockets;
-procedure Getjpg is
-  use type Ada.Streams.Stream_Element_Offset;
-
-  Buffer  : Ada.Streams.Stream_Element_Array(1 .. 5000);
-  Last    : Ada.Streams.Stream_Element_Offset;
-  F       : Ada.Streams.Stream_IO.File_Type;
-  Socket  : Nc.Sockets.Socket_Type;
-  Length  : Ada.Streams.Stream_Element_Offset := 0;
-  type States is (Start, Seen_CR1, Seen_LF1, Seen_CR2, In_Data);
-  subtype Header is States range Start .. Seen_Cr2;
-  State   : States := Start;
-
-  procedure Write is
-    use Ada.Streams;
-    C : Character;
-    Watch_For : constant array(Header) of Character
-      := (Start => Ascii.CR, Seen_CR1 => Ascii.LF, Seen_LF1 => Ascii.CR,
-          Seen_CR2 => Ascii.LF);
-  begin
-    if State = In_Data then
-      Stream_IO.Write(F, Buffer(1 .. Last));
-      Length := Length + Last;
-      return;
-    end if;
-    for I in 1 .. Last loop
-      C := Character'Val(Stream_Element'Pos(Buffer(I)));
-      Ada.Text_IO.Put(C);
-      if C = Watch_For(State) then
-        State := States'succ(State);
-        if State = In_Data then
-          Stream_Io.Create(F, Stream_Io.Out_File, "pic.jpg");
-          if I < Last then
-            Stream_Io.Write(F, Buffer(I + 1 .. Last));
-            Length := Last - I;
-          end if;
-          exit;
-        end if;
-      else
-        State := Start;
-      end if;
-    end loop;
-  end Write;
-
-  procedure Stop is
-  begin
-    Ada.Text_IO.Put_Line(Ada.Streams.Stream_Element_Offset'Image(Length)
-                         & " file pic.jpg written");
-    if Ada.Streams.Stream_IO.Is_Open(F) then
-      Ada.Streams.Stream_IO.Close(F);
-    end if;
-  end Stop;
-
-begin
-  Nc.Sockets.Open(Socket, "metsun1.met.sjsu.edu", 80, Timeout => 20.0);
-  Nc.Sockets.Put_Line(Socket, "GET /cam_directory/latest.jpg HTTP/1.0");
-  Nc.Sockets.Put_Line(Socket, "");
-  loop
-    Nc.Sockets.Input(Socket, Timeout => 10.0, Item => Buffer, Last => Last);
-    exit when Last < Buffer'First;
-    Write;
-  end loop;
-  Nc.Sockets.Close(Socket);
-  Stop;
-exception
-  when Nc.Not_Found_Error =>
-    Stop;
-end Getjpg;
diff -r f734a2862510 -r 2cca25a3f5f4 NC.ADS
--- a/NC.ADS	Tue Dec 21 19:45:44 2010 +0200
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,19 +0,0 @@
-with Interfaces.C;
-package NC is
-  type Short is new Interfaces.C.Short;
-  type Int is new Interfaces.C.Int;
-  subtype Natural_Int is Int range 0 .. Int'last;
-  type UInt is new Interfaces.C.Unsigned;
-  type DWord is new Interfaces.C.Unsigned_Long;
-
-  type Byte is range 0 .. 255;
-  for Byte'size use 8;
-  type Word is mod 2**16;
-  for Word'size use 16;
-
-  Windows_Error,
-  Not_Valid_Error,
-  Already_Valid_Error,
-  Not_Found_Error : Exception;
-  type Lpcstr is access all Interfaces.C.Char;
-end NC;
diff -r f734a2862510 -r 2cca25a3f5f4 getjpg.adb
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/getjpg.adb	Wed Dec 22 18:05:52 2010 +0200
@@ -0,0 +1,75 @@
+-- Sample program using NC.Sockets
+-- It goes to the San Jose State weathercam and downloads to pic.jpg
+-- a picture of the current skyline in San Jose, California
+-- Copyright 2003 tmoran@acm.org anyone may use for any purpose
+with Ada.Streams,
+     Ada.Streams.Stream_IO,
+     Ada.Text_IO,
+     Nc.Sockets;
+procedure Getjpg is
+  use type Ada.Streams.Stream_Element_Offset;
+
+  Buffer  : Ada.Streams.Stream_Element_Array(1 .. 5000);
+  Last    : Ada.Streams.Stream_Element_Offset;
+  F       : Ada.Streams.Stream_IO.File_Type;
+  Socket  : Nc.Sockets.Socket_Type;
+  Length  : Ada.Streams.Stream_Element_Offset := 0;
+  type States is (Start, Seen_CR1, Seen_LF1, Seen_CR2, In_Data);
+  subtype Header is States range Start .. Seen_Cr2;
+  State   : States := Start;
+
+  procedure Write is
+    use Ada.Streams;
+    C : Character;
+    Watch_For : constant array(Header) of Character
+      := (Start => Ascii.CR, Seen_CR1 => Ascii.LF, Seen_LF1 => Ascii.CR,
+          Seen_CR2 => Ascii.LF);
+  begin
+    if State = In_Data then
+      Stream_IO.Write(F, Buffer(1 .. Last));
+      Length := Length + Last;
+      return;
+    end if;
+    for I in 1 .. Last loop
+      C := Character'Val(Stream_Element'Pos(Buffer(I)));
+      Ada.Text_IO.Put(C);
+      if C = Watch_For(State) then
+        State := States'succ(State);
+        if State = In_Data then
+          Stream_Io.Create(F, Stream_Io.Out_File, "pic.jpg");
+          if I < Last then
+            Stream_Io.Write(F, Buffer(I + 1 .. Last));
+            Length := Last - I;
+          end if;
+          exit;
+        end if;
+      else
+        State := Start;
+      end if;
+    end loop;
+  end Write;
+
+  procedure Stop is
+  begin
+    Ada.Text_IO.Put_Line(Ada.Streams.Stream_Element_Offset'Image(Length)
+                         & " file pic.jpg written");
+    if Ada.Streams.Stream_IO.Is_Open(F) then
+      Ada.Streams.Stream_IO.Close(F);
+    end if;
+  end Stop;
+
+begin
+  Nc.Sockets.Open(Socket, "metsun1.met.sjsu.edu", 80, Timeout => 20.0);
+  Nc.Sockets.Put_Line(Socket, "GET /cam_directory/latest.jpg HTTP/1.0");
+  Nc.Sockets.Put_Line(Socket, "");
+  loop
+    Nc.Sockets.Input(Socket, Timeout => 10.0, Item => Buffer, Last => Last);
+    exit when Last < Buffer'First;
+    Write;
+  end loop;
+  Nc.Sockets.Close(Socket);
+  Stop;
+exception
+  when Nc.Not_Found_Error =>
+    Stop;
+end Getjpg;
diff -r f734a2862510 -r 2cca25a3f5f4 nc-sockets-alt_gethostbyname.adb
--- a/nc-sockets-alt_gethostbyname.adb	Tue Dec 21 19:45:44 2010 +0200
+++ b/nc-sockets-alt_gethostbyname.adb	Wed Dec 22 18:05:52 2010 +0200
@@ -10,7 +10,7 @@
     end loop;
     Result.P_Hostent := NC.Sockets.B_Helper.gethostbyname(Result.C_Name(0)'unchecked_access);
     if Result.P_Hostent = null then
-      Result.Error := NC.Sockets.B_Helper.WSAGetLastError;
+      Result.Error := 0;
     end if;
     Result.Output_Ready:=True;
     while not Result.Fini loop
diff -r f734a2862510 -r 2cca25a3f5f4 nc-sockets.adb
--- a/nc-sockets.adb	Tue Dec 21 19:45:44 2010 +0200
+++ b/nc-sockets.adb	Wed Dec 22 18:05:52 2010 +0200
@@ -32,6 +32,10 @@
   use Claw.Sockets.Low_Level;
 
   System_Control : System_Controls;
+  function WSAGetLastError return Error_Codes is
+  begin
+     return 0;
+  end WSAGetLastError;
 
   procedure Get_Error_Code(Info       : in out Host_Info_Type;
                            Error_Code :    out Error_Codes) is
@@ -212,8 +216,10 @@
 
       C_Name_Length : Size_T := Claw.sockets.Alt_Gethostbyname.C_Name_Type'length;
 
-      function Get_Last_Error return Claw.DWord;
-      pragma Import (StdCall, Get_Last_Error, "GetLastError");
+      function Get_Last_Error return Claw.DWord is
+      begin
+         return 0;
+      end Get_Last_Error;
 
     begin
 
@@ -489,19 +495,13 @@
       if Is_Running then
         Error := 0;
       else
-        Error := WSAStartup(16#0101#, wsadata'access);
-        if Error = 0 then
-          Is_Running := True;
-        end if;
+        Is_Running := True;
       end if;
     end Make_Running;
 
     procedure Make_Stopped is
     begin
       if not Is_Running then return;end if;
-      if WSACleanup = Socket_Error then
-        raise Claw.windows_error;  -- to be caught by Shut_Down
-      end if;
       Is_Running := False;
     end Make_Stopped;
   end Winsock_Systems;
diff -r f734a2862510 -r 2cca25a3f5f4 nc-sockets.ads
--- a/nc-sockets.ads	Tue Dec 21 19:45:44 2010 +0200
+++ b/nc-sockets.ads	Wed Dec 22 18:05:52 2010 +0200
@@ -8,7 +8,7 @@
 
 package NC.Sockets is
   package Claw renames NC;
-  pragma Link_With("libwsock32.a");
+  -- pragma Link_With("libwsock32.a");
     --
     -- Edit History:
     --
@@ -746,13 +746,13 @@
       Host_Address_List_Ptr : Host_Address_List_Ptr_Type; -- h_addr_list
   end record;
   for Hostents use record
-      Host_Name_Ptr at 0 range 0 .. 31;
-      Host_Alias_Ptr_List at 4 range 0 .. 31;
-      Host_Address_Kind at 8 range 0 .. 15;
-      Host_Address_Length at 10 range 0 .. 15;
-      Host_Address_List_Ptr at 12 range 0 .. 31;
+      Host_Name_Ptr at 0 range 0 .. 63;
+      Host_Alias_Ptr_List at 8 range 0 .. 63;
+      Host_Address_Kind at 16 range 0 .. 15;
+      Host_Address_Length at 18 range 0 .. 15;
+      Host_Address_List_Ptr at 20 range 0 .. 63;
   end record;
-  for Hostents'size use 16*8;
+  for Hostents'size use 224;
 
   type Hostent_Ptr_Type is access all HOSTENTs;
 
@@ -782,9 +782,9 @@
     Last_Error_Code : Error_Codes := 0;
   end record;
   for W_Host_Info_Type use record
-    Hostent at 0 range 0 .. 16*8-1;
-    Data_Area at 16 range 0 .. (MAXGETHOSTSTRUCT-16)*8-1;
-    Last_Error_Code at MAXGETHOSTSTRUCT range 0 .. 31;
+    Hostent at 0 range 0 .. 224-1;
+    Data_Area at 32 range 0 .. (MAXGETHOSTSTRUCT-16)*8-1;
+    Last_Error_Code at (MAXGETHOSTSTRUCT+32) range 0 .. 31;
   end record;
 
   procedure Copy_Host_Info(Source : in W_Host_Info_Type;
@@ -800,16 +800,15 @@
   package Low_Level is
     use type Claw.Int;
 
-    function WSAGetLastError return Error_Codes;
-    pragma Import(Stdcall, WSAGetLastError, "WSAGetLastError");
+    -- function WSAGetLastError return Error_Codes;
 
     function gethostbyname(name: NC.lpcstr) return Hostent_Ptr_Type;
-    pragma Import(Stdcall, gethostbyname, "gethostbyname");
+    pragma Import(C, gethostbyname, "gethostbyname");
 
     function gethostbyaddr(addr: access Network_Address_Type;
                            len : Claw.Int := Network_Address_Type'size/8;
                            kind : Claw.Int := PF_Inet) return Hostent_Ptr_Type;
-    pragma Import(Stdcall, gethostbyaddr, "gethostbyaddr");
+    pragma Import(C, gethostbyaddr, "gethostbyaddr");
 
     WSADescription_Len : constant := 256;
     WSASys_Status_Len  : constant := 128;
@@ -829,21 +828,13 @@
         szSystemStatus at 261 range 0 .. 129*8-1;
         iMaxSockets    at 390 range 0 .. 15;
         iMaxUdpDg      at 392 range 0 .. 15;
-        lpVendorInfo   at 394 range 0 .. 31;
+        lpVendorInfo   at 394 range 0 .. 63;
     end record;
-    for WSADatas'size use 398*8;
-
-    function WSAStartup (wVersionRequired : NC.word;
-                         lpWSAData      : access WSADatas)
-             return Error_Codes;
-    pragma Import(Stdcall, WSAStartup, "WSAStartup");
-
-    function WSACleanup return Claw.Int;
-    pragma Import(Stdcall, WSACleanup, "WSACleanup");
+    for WSADatas'size use 3216;
 
     function gethostname(Name : NC.lpcstr;
                          Length : Claw.Int) return Claw.Int;
-    pragma Import(Stdcall, gethostname, "gethostname");
+    pragma Import(C, gethostname, "gethostname");
 
     type Address_Family_Type is new Claw.short;
     AF_INET : constant Address_Family_Type := 2;
@@ -851,7 +842,7 @@
     type Network_Port_Type is new NC.word; -- network byte order
 
     function htons(hostshort: Port_Type) return Network_Port_Type;
-    pragma Import(Stdcall, htons, "htons");
+    pragma Import(C, htons, "htons");
 
     type SOCKADDR_INs is record
       Family  : Address_Family_Type := AF_INET;
@@ -863,32 +854,32 @@
     for SOCKADDR_INs use record
       Family  at 0 range 0 .. 15;
       Port    at 2 range 0 .. 15;
-      Address at 4 range 0 .. 31;
-      Extra   at 8 range 0 .. 8*8-1;
+      Address at 4 range 0 .. 63;
+      Extra   at 12 range 0 .. 8*8-1;
     end record;
-    for SOCKADDR_INs'size use 16*8;
+    for SOCKADDR_INs'size use 160;
 
     function Connect(S      : Socket_Handles;
                      Name   : access SOCKADDR_INs;
                      Length : Claw.Int := SOCKADDR_INs'size/8)
              return Claw.Int;
-    pragma Import(Stdcall, Connect, "connect");
+    pragma Import(C, Connect, "connect");
 
     function Bind(S       : Socket_Handles;
                   Address : access SOCKADDR_INs;
                   Length  : Claw.Int := SOCKADDR_INs'size/8)
              return Claw.Int;
-    pragma Import(Stdcall, Bind, "bind");
+    pragma Import(C, Bind, "bind");
 
     function Listen(S   : Socket_Handles;
                     Q_Length : Claw.Int) return Claw.Int;
-    pragma Import(Stdcall, Listen, "listen");
+    pragma Import(C, Listen, "listen");
 
     function Accept_function(S       : Socket_Handles;
                              Address : access SOCKADDR_INs;
                              Length  : access Claw.Int)
                return Socket_Handles;
-    pragma Import(Stdcall, Accept_function, "accept");
+    pragma Import(C, Accept_function, "accept");
 
     type Protocol_Type is new Claw.Int;
     Ipproto_TCP : constant Protocol_Type := 6;
@@ -898,7 +889,7 @@
                              Kind    : Sock_Type;
                              Protocol: Protocol_Type)
                return Socket_Handles;
-    pragma Import(Stdcall, Socket_function, "socket");
+    pragma Import(C, Socket_function, "socket");
 
     FD_SETSIZE : constant := 64;
 
@@ -932,10 +923,10 @@
                              Exceptions_FD_Set : access FD_SET_Type;
                              Timeout           : access Timeval_Type)
              return Claw.Int;
-    pragma Import(Stdcall, Select_function, "select");
+    pragma Import(C, Select_function, "select");
 
     function closesocket(s: Socket_Handles) return Claw.Int;
-    pragma Import(Stdcall, closesocket, "closesocket");
+    pragma Import(C, closesocket, "close");
 
     function recv(
                 s    : Socket_Handles;
@@ -943,7 +934,7 @@
                 Len  : Claw.Int;
                 Flags: Claw.Int)
                return Claw.Int;
-    pragma Import(Stdcall, recv, "recv");
+    pragma Import(C, recv, "recv");
 
     function recvfrom(
                 s    : Socket_Handles;
@@ -953,7 +944,7 @@
                 Name   : access SOCKADDR_INs;
                 Length : access Claw.Int)
                return Claw.Int;
-    pragma Import(Stdcall, recvfrom, "recvfrom");
+    pragma Import(C, recvfrom, "recvfrom");
 
     function send(
                 s    : Socket_Handles;
@@ -961,7 +952,7 @@
                 Len  : Claw.Int;
                 Flags: Claw.Int)
                return Claw.Int;
-    pragma Import(Stdcall, send, "send");
+    pragma Import(C, send, "send");
 
     function sendto(
                 s    : Socket_Handles;
@@ -971,7 +962,7 @@
                 Name   : access SOCKADDR_INs;
                 Length : Claw.Int := SOCKADDR_INs'size/8)
                return Claw.Int;
-    pragma Import(Stdcall, sendto, "sendto");
+    pragma Import(C, sendto, "sendto");
 
     type Event_Type is new Claw.uint;
     FD_READ_Event    : constant Event_Type := 1;
@@ -984,12 +975,12 @@
     function getpeername(s : Socket_Handles;
                          Address: access SOCKADDR_INs;
                          Length  : access Claw.Int) return Claw.Int;
-    pragma Import(Stdcall, getpeername, "getpeername");
+    pragma Import(C, getpeername, "getpeername");
 
     function getsockname(s : Socket_Handles;
                          Address: access SOCKADDR_INs;
                          Length  : access Claw.Int) return Claw.Int;
-    pragma Import(Stdcall, getsockname, "getsockname");
+    pragma Import(C, getsockname, "getsockname");
 
     type ioctl_cmd_type is new Claw.DWord;
 
@@ -998,7 +989,7 @@
     function ioctlsocket(s   : Socket_Handles;
                          cmd : ioctl_cmd_type;
                          arg : access Claw.DWord) return Claw.Int;
-    pragma Import(Stdcall, ioctlsocket, "ioctlsocket");
+    pragma Import(C, ioctlsocket, "ioctl");
 
   end Low_Level;
 
diff -r f734a2862510 -r 2cca25a3f5f4 nc.ads
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/nc.ads	Wed Dec 22 18:05:52 2010 +0200
@@ -0,0 +1,19 @@
+with Interfaces.C;
+package NC is
+  type Short is new Interfaces.C.Short;
+  type Int is new Interfaces.C.Int;
+  subtype Natural_Int is Int range 0 .. Int'last;
+  type UInt is new Interfaces.C.Unsigned;
+  type DWord is new Interfaces.C.Unsigned_Long;
+
+  type Byte is range 0 .. 255;
+  for Byte'size use 8;
+  type Word is mod 2**16;
+  for Word'size use 16;
+
+  Windows_Error,
+  Not_Valid_Error,
+  Already_Valid_Error,
+  Not_Found_Error : Exception;
+  type Lpcstr is access all Interfaces.C.Char;
+end NC;


-- 
Tero Koskinen - http://iki.fi/tero.koskinen/

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 May 2011 12:44:20 +0200, Peter C. Chapin <PChapin@vtc.vsc.edu>  
a écrit:
> It also true that autoconf is a travesty... a throwback to a darker age
> when the POSIX standard did not exist (or at least was not widely
> implemented).
I do not know that much about Autoconf, so I can't really understand what  
that mean and implies (someone else here also say a bit the same as you  
too).

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Ludovic Brenta]

Yannick Duchêne wrote on comp.lang.ada:
> Peter C. Chapin a écrit:
>> It also true that autoconf is a travesty... a throwback to a darker age
>> when the POSIX standard did not exist (or at least was not widely
>> implemented).
>
> I do not know that much about Autoconf, so I can't really understand what  
> that mean and implies (someone else here also say a bit the same as you  
> too).

Make was invented to overcome the deficiencies of C, notably the lack
of modular programming and dependency management.

Automake was invented to overcome the deficiencies of make, notably
the poor maintainability of Makefiles.

Configure was invented to overcome the deficiencies of early UNIX
systems, notably the lack of conformance to POSIX, and their impact of
the maintenance of Automake files.

Autoconf was invented to overcome the deficiencies of Configure,
notably the sheer size and horror of the configure scripts, which
routinely consist of hundreds of thousands of lines of illegible POSIX
shell code.

The novice programmer adds corrective code.
The master programmer removes defective code.

Enough said :)

--
Ludovic Brenta.

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 May 2011 18:36:17 +0200, Ludovic Brenta  
<ludovic@ludovic-brenta.org> a écrit:
> [… long worthy wordings …]
> Enough said :)
and Good enough. Thanks for the piece of history, that's crystal-clear now.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Tero Koskinen]

On Wed, 25 May 2011 18:12:52 +0300 Tero Koskinen wrote:

> Hi,
> 
> On Tue, 24 May 2011 06:11:43 +0000 (UTC) tmoran@acm.org wrote:
> > A thicker binding is NC sockets ("Not Claw", derived from Claw.Sockets).
> > It's nc.zip at www.adaworld.com, look there under
> > Ada Projects/Ada Internet Projects/Internet Protocols
> > It's for Windows but IIRC the WSAStartup and WSACleanup should be
> > the only Windows specific things.
> 
> Here is a diff which allows the package to compile on OpenBSD/amd64.

It seems that you need to tailor NC.sockets for every operating system
separately. I created a Mercurial repository 
https://bitbucket.org/tkoskine/not-claw-sockets-linux-x86
which contains Linux/x86 version of NC.sockets.

At the moment getjpg example compiles and connection is opened,
but for some reason there is no data read (or send). I guess
I need to open wireshark and debug a little more...

-- 
Tero Koskinen - http://iki.fi/tero.koskinen/

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 May 2011 20:43:35 +0200, Tero Koskinen <tero.koskinen@iki.fi> a  
écrit:
> It seems that you need to tailor NC.sockets for every operating system
Just like it is with every binding to low level stuff, indeed.

> At the moment getjpg example compiles and connection is opened,
> but for some reason there is no data read (or send). I guess
> I need to open wireshark and debug a little more...
You can avoid going so much further: "metsun1.met.sjsu.edu" is simply not  
valid any more ;) (this redirect to the root domain, the sub-domain has  
gone)


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Maciej Sobczak]

On 25 Maj, 18:36, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:

> Make was invented to overcome the deficiencies of C, notably the lack
> of modular programming and dependency management.

Umm, no.
Make is a general-purpose project management system that can be used
to manage any file-system related build activity. Compiling C programs
is one of the most trivial and boring things that make can be used
for.

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

Re: Why no socket package in the standard ?

[Ludovic Brenta]

Maciej Sobczak wrote on comp.lang.ada:
> On 25 Maj, 18:36, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>
>> Make was invented to overcome the deficiencies of C, notably the lack
>> of modular programming and dependency management.
>
> Umm, no.
> Make is a general-purpose project management system that can be used
> to manage any file-system related build activity. Compiling C programs
> is one of the most trivial and boring things that make can be used
> for.

I know (I've used make myself for such purposes) but that does not
change anything to what I wrote.

C was designed as a systems programming language, by and for kernel
hackers, and was used as a general-purpose language.  Similarly, make
started as a hack to overcome the deficiencies of C and was then
extended for other, more general uses.

--
Ludovic Brenta.

Re: Why no socket package in the standard ?

[Georg Bauhaus]

On 26.05.11 14:42, Ludovic Brenta wrote:
> Maciej Sobczak wrote on comp.lang.ada:
>> On 25 Maj, 18:36, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>>
>>> Make was invented to overcome the deficiencies of C, notably the lack
>>> of modular programming and dependency management.
>>
>> Umm, no.
>> Make is a general-purpose project management system that can be used
>> to manage any file-system related build activity. Compiling C programs
>> is one of the most trivial and boring things that make can be used
>> for.
> 
> I know (I've used make myself for such purposes) but that does not
> change anything to what I wrote.
> 
> C was designed as a systems programming language, by and for kernel
> hackers, and was used as a general-purpose language.  Similarly, make
> started as a hack to overcome the deficiencies of C and was then
> extended for other, more general uses.

How does the make program helps with adding modules to C
and its file scope?

Re: Why no socket package in the standard ?

[Adam Beneschan]

On May 25, 9:36 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> Yannick Duchêne wrote on comp.lang.ada:
>
> > Peter C. Chapin a écrit:
> >> It also true that autoconf is a travesty... a throwback to a darker age
> >> when the POSIX standard did not exist (or at least was not widely
> >> implemented).
>
> > I do not know that much about Autoconf, so I can't really understand what  
> > that mean and implies (someone else here also say a bit the same as you  
> > too).
>
> Make was invented to overcome the deficiencies of C, notably the lack
> of modular programming and dependency management.
>
> Automake was invented to overcome the deficiencies of make, notably
> the poor maintainability of Makefiles.
>
> Configure was invented to overcome the deficiencies of early UNIX
> systems, notably the lack of conformance to POSIX, and their impact of
> the maintenance of Automake files.
>
> Autoconf was invented to overcome the deficiencies of Configure,
> notably the sheer size and horror of the configure scripts, which
> routinely consist of hundreds of thousands of lines of illegible POSIX
> shell code.

I was going to ask what was the invention to overcome the deficiencies
of autoconf, but I think I figured it out ... rm -rf, right?

                            -- Adam

Re: Why no socket package in the standard ?

[Ludovic Brenta]

Georg Bauhaus writes on comp.lang.ada:
> On 26.05.11 14:42, Ludovic Brenta wrote:
>> Maciej Sobczak wrote on comp.lang.ada:
>>> On 25 Maj, 18:36, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>>>
>>>> Make was invented to overcome the deficiencies of C, notably the lack
>>>> of modular programming and dependency management.
>>>
>>> Umm, no.
>>> Make is a general-purpose project management system that can be used
>>> to manage any file-system related build activity. Compiling C programs
>>> is one of the most trivial and boring things that make can be used
>>> for.
>> 
>> I know (I've used make myself for such purposes) but that does not
>> change anything to what I wrote.
>> 
>> C was designed as a systems programming language, by and for kernel
>> hackers, and was used as a general-purpose language.  Similarly, make
>> started as a hack to overcome the deficiencies of C and was then
>> extended for other, more general uses.
>
> How does the make program helps with adding modules to C and its file
> scope?

It helps a little bit by deciding which source files are out of date WRT
their header files and corresponding object files, then deciding in
which order to call the compiler and linker.  This however requires a
lot of labor to teach Make about the dependencies, and is of course a
partial solution only.  Just as C was a partial solution to the problem
of programming as a human activity :)

-- 
Ludovic Brenta.

Re: Why no socket package in the standard ?

[Ludovic Brenta]

Adam Beneschan writes on comp.lang.ada:
> On May 25, 9:36 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>> Yannick Duchêne wrote on comp.lang.ada:
>>
>>> Peter C. Chapin a écrit:
>>>> It also true that autoconf is a travesty... a throwback to a darker
>>>> age when the POSIX standard did not exist (or at least was not
>>>> widely implemented).
>>
>>> I do not know that much about Autoconf, so I can't really understand
>>> what that mean and implies (someone else here also say a bit the
>>> same as you too).
>>
>> Make was invented to overcome the deficiencies of C, notably the lack
>> of modular programming and dependency management.
>>
>> Automake was invented to overcome the deficiencies of make, notably
>> the poor maintainability of Makefiles.
>>
>> Configure was invented to overcome the deficiencies of early UNIX
>> systems, notably the lack of conformance to POSIX, and their impact
>> of the maintenance of Automake files.
>>
>> Autoconf was invented to overcome the deficiencies of Configure,
>> notably the sheer size and horror of the configure scripts, which
>> routinely consist of hundreds of thousands of lines of illegible
>> POSIX shell code.
>
> I was going to ask what was the invention to overcome the deficiencies
> of autoconf, but I think I figured it out ... rm -rf, right?

Opinions differ but I'd tend to side with you :)

-- 
Ludovic Brenta.

Re: Why no socket package in the standard ?

[Maciej Sobczak]

On 26 Maj, 14:42, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:

> Similarly, make
> started as a hack to overcome the deficiencies of C

Sorry, but here:

http://en.wikipedia.org/wiki/Make_%28software%29

there is nothing about it. Any references to C in this article are
qualified with "for example", which is in line with what I've said.

Could you please share the source of your information? I'm genuinely
interested.

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

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Thu, 26 May 2011 20:20:33 +0200, Maciej Sobczak  
<see.my.homepage@gmail.com> a écrit:

> On 26 Maj, 14:42, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>
>> Similarly, make
>> started as a hack to overcome the deficiencies of C
>
> Sorry, but here:
>
> http://en.wikipedia.org/wiki/Make_%28software%29
>
> there is nothing about it. Any references to C in this article are
> qualified with "for example", which is in line with what I've said.

Wikipedia is not the owner of the truth (although it may dream to register  
this as an owned trademark). I heard the same about Make, as what Ludovic  
said. And then, the first time I had to face this ugly Make (and its silly  
file format), was for C/C++. Typically, when you have to deal with a  
Makefile, this is about C sources (and if its big enough, you also have  
multiple sources of nightmare).

That's a fact that C compilers, cannot handle dependencies without the  
help of an external tool (add this to the preprocessor).

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Vinzent Hoefler]

Maciej Sobczak wrote:

> On 26 Maj, 14:42, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>
>> Similarly, make
>> started as a hack to overcome the deficiencies of C
>
> Sorry, but here:
>
> http://en.wikipedia.org/wiki/Make_%28software%29
>
> there is nothing about it. Any references to C in this article are
> qualified with "for example", which is in line with what I've said.
>
> Could you please share the source of your information? I'm genuinely
> interested.

<http://en.wikipedia.org/wiki/Stuart_Feldman>

1977, Bell Labs, UNIX, first FORTRAN 77 compiler.

I'd suspect, this compiler wasn't written in FORTRAN itself, so the
logical conclusion would be that the compiler was witten in C (like
almost anything for UNIX, especially at that time) and thus 'make'
was written to simplify the task of compiling those compiler's sources. ;)


Vinzent.

-- 
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
   --  Waldi Ravens

Re: Why no socket package in the standard ?

[Ludovic Brenta]

Vinzent Hoefler writes on comp.lang.ada:
> Maciej Sobczak wrote:
>
>> On 26 Maj, 14:42, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>>
>>> Similarly, make
>>> started as a hack to overcome the deficiencies of C
>>
>> Sorry, but here:
>>
>> http://en.wikipedia.org/wiki/Make_%28software%29
>>
>> there is nothing about it. Any references to C in this article are
>> qualified with "for example", which is in line with what I've said.
>>
>> Could you please share the source of your information? I'm genuinely
>> interested.
>
> <http://en.wikipedia.org/wiki/Stuart_Feldman>
>
> 1977, Bell Labs, UNIX, first FORTRAN 77 compiler.
>
> I'd suspect, this compiler wasn't written in FORTRAN itself, so the
> logical conclusion would be that the compiler was witten in C (like
> almost anything for UNIX, especially at that time) and thus 'make' was
> written to simplify the task of compiling those compiler's sources. ;)

And that leads to http://www.faqs.org/docs/artu/ch15s04.html:

| Make originated with a visit from Steve Johnson (author of yacc,
| etc.), storming into my office, cursing the Fates that had caused him
| to waste a morning debugging a correct program (bug had been fixed,
| file hadn't been compiled, cc *.o was therefore unaffected). As I had
| spent a part of the previous evening coping with the same disaster on
| a project I was working on, the idea of a tool to solve it came up. It
| began with an elaborate idea of a dependency analyzer, boiled down to
| something much simpler, and turned into Make that weekend. Use of
| tools that were still wet was part of the culture. Makefiles were text
| files, not magically encoded binaries, because that was the Unix
| ethos: printable, debuggable, understandable stuff. -- Stuart Feldman

-- 
Ludovic Brenta.

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Thu, 26 May 2011 20:31:28 +0200, Vinzent Hoefler  
<0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> a écrit:
> I'd suspect, this compiler wasn't written in FORTRAN itself, so the
> logical conclusion would be that the compiler was witten in C (like
> almost anything for UNIX, especially at that time) and thus 'make'
> was written to simplify the task of compiling those compiler's sources.  
> ;)

So Make was… Yet Another Compiler-Compiler ? :-D

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Ludovic Brenta]

Yannick Duchêne wrote on comp.lang.ada:
> Le Thu, 26 May 2011 20:31:28 +0200, Vinzent Hoefler
> <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> a écrit:
>> I'd suspect, this compiler wasn't written in FORTRAN itself, so the
>> logical conclusion would be that the compiler was witten in C (like
>> almost anything for UNIX, especially at that time) and thus 'make'
>> was written to simplify the task of compiling those compiler's
>> sources. ;)
>
> So Make was… Yet Another Compiler-Compiler ? :-D

No, Make was made over one weekend to Make Yet Another Compiler-Compiler
:)

-- 
Ludovic Brenta.

Re: Why no socket package in the standard ?

[Georg Bauhaus]

On 5/26/11 8:29 PM, Yannick Duchêne (Hibou57) wrote:
> Le Thu, 26 May 2011 20:20:33 +0200, Maciej Sobczak <see.my.homepage@gmail.com> a écrit:
>
>> On 26 Maj, 14:42, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>>
>>> Similarly, make
>>> started as a hack to overcome the deficiencies of C
>>
>> Sorry, but here:
>>
>> http://en.wikipedia.org/wiki/Make_%28software%29
>>
>> there is nothing about it. Any references to C in this article are
>> qualified with "for example", which is in line with what I've said.
>
> Wikipedia is not the owner of the truth (although it may dream to register this as an owned trademark). I heard the same about Make, as what Ludovic said. And then, the first time I had to face this ugly Make (and its silly file format), was for C/C++. Typically, when you have to deal with a Makefile, this is about C sources (and if its big enough, you also have multiple sources of nightmare).
>
> That's a fact that C compilers, cannot handle dependencies without the help of an external tool (add this to the preprocessor).
>

Make (or similar) is still good for building Ada programs, in particular,
portable Ada programs (between compilers), and its associated
documentation and the tests.

Ada compilers typically include their own driver programs that
have it their own non-portable ways, and Ada library related programs.
These will detect Ada sources only after they know about how and
where to find them.

In the case of GNAT, this used to boil down to combining
gnatchop, gnatmake, and possibly a special file that would list
mappings from files to compilation units, or file name patterns that
would allow identifying compilation units in the file system.
Or setting variables such as ADA_INCLUDE_PATH.
For example, gnatmake is not enough if your program is this:

procedure Hello;
-- offer greetings to the world

with Ada.Text_IO;
procedure Hello is
begin
    Ada.Text_IO.Put_Line("Hello, World!");
end Hello;

I think gprbuild or at least a GNAT specific project file is needed.


In the case of ObjectAda or other frontends built around AdaMagic
a program called adareg or similar will permit adding files and
paths to the Ada libary;  files can consist of more than one
compilation unit, no chopping is needed (even though a 1:1
correspondence has been recommended).  Additional programs include
adamake or adabuild or adacomp.

I understand that IBM Rational Apex is using a sophisticated
Ada library management software.

Make (or similar) on top of this is fairly simple to use and gives
you another level of simple configuration. E.g., set environment
variables that a GNAT project file will read; use VPATH if you
have GNU make and easily switch configurations.

Re: Why no socket package in the standard ?

[Yannick Duchêne (Hibou57)]

Le Thu, 26 May 2011 22:46:09 +0200, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:
> In the case of ObjectAda or other frontends built around AdaMagic
> a program called adareg or similar will permit adding files and
> paths to the Ada libary;  files can consist of more than one
> compilation unit, no chopping is needed (even though a 1:1
> correspondence has been recommended).
Yes, I know the standard does not requires a single compilation unit per  
file, while GNAT can't handle this. This may be a big enough difference  
between Ada compilers. Except that, all are able to handle dependencies,  
and all you need is typically a search path and a mapping from compilation  
unit name to file names. This is simpler than what many Makefiles looks  
like.


> compilation unit, no chopping is needed (even though a 1:1
> correspondence has been recommended).
Recommended by whom ?

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]

Re: Why no socket package in the standard ?

[Georg Bauhaus]

On 5/26/11 11:02 PM, Yannick Duchêne (Hibou57) wrote:
> Le Thu, 26 May 2011 22:46:09 +0200, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> a écrit:
>> In the case of ObjectAda or other frontends built around AdaMagic
>> a program called adareg or similar will permit adding files and
>> paths to the Ada libary; files can consist of more than one
>> compilation unit, no chopping is needed (even though a 1:1
>> correspondence has been recommended).
> Yes, I know the standard does not requires a single compilation unit per file, while GNAT can't handle this. This may be a big enough difference between Ada compilers. Except that, all are able to handle dependencies, and all you need is typically a search path and a mapping from compilation unit name to file names. This is simpler than what many Makefiles looks like.
>
>
>> compilation unit, no chopping is needed (even though a 1:1
>> correspondence has been recommended).
> Recommended by whom ?
>
I think by one of the makers of the front end, considering
advantages that 1:1 may have when computing compilation
requirements after changes.

Re: Why no socket package in the standard ?

[Ludovic Brenta]

Georg Bauhaus writes on comp.lang.ada:
> Make (or similar) is still good for building Ada programs, in
> particular, portable Ada programs (between compilers), and its
> associated documentation and the tests.

Make is a wrapper around shell scripts (the rules in Makefiles are shell
scripts).  You can use a Makefile as a wrapper around the compiler
driver but you might as well avoid Make and use shell scripts directly
because you do not need Make to figure dependencies or order of
compilation out.  In fact, Make's built-in rules and dependency engine
might get in the way.

Makefiles tend not to be portable between operating systems anyway;
that's what Automake and Configure are for :)

> For example, gnatmake is not enough if your program is this:
>
> procedure Hello;
> -- offer greetings to the world
>
> with Ada.Text_IO;
> procedure Hello is
> begin
>    Ada.Text_IO.Put_Line("Hello, World!");
> end Hello;
>
> I think gprbuild or at least a GNAT specific project file is needed.

Huh?

$ gnatmake hello
gcc-4.4 -c hello.adb
gnatbind -x hello.ali
gnatlink hello.ali
$ ./hello
Hello, World!

What is missing that makes gnatmake "not enough"?

> In the case of ObjectAda or other frontends built around AdaMagic a
> program called adareg or similar will permit adding files and paths to
> the Ada libary; files can consist of more than one compilation unit,
> no chopping is needed (even though a 1:1 correspondence has been
> recommended).  Additional programs include adamake or adabuild or
> adacomp.
>
> I understand that IBM Rational Apex is using a sophisticated Ada
> library management software.
>
> Make (or similar) on top of this is fairly simple to use and gives you
> another level of simple configuration. E.g., set environment variables
> that a GNAT project file will read; use VPATH if you have GNU make and
> easily switch configurations.

No, Makefiles wrappers around compiler drivers + Ada library management
would be complicated and difficult to maintain.  You'd be better off
with even simpler shell scripts or, why not, gprmake.

-- 
Ludovic Brenta.

Re: Why no socket package in the standard ?

[anon]

        In the mid 1970s, AT&T and Bell Labs sold their OS by saying 
you provide a C compiler you can get a secure OS written in 100% C.

So, the Fortran && compiler was written in C.

In <op.vv3pqqq5lzeukk@jellix.jlfencey.com>, "Vinzent Hoefler" <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> writes:
>Maciej Sobczak wrote:
>
>> On 26 Maj, 14:42, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>>
>>> Similarly, make
>>> started as a hack to overcome the deficiencies of C
>>
>> Sorry, but here:
>>
>> http://en.wikipedia.org/wiki/Make_%28software%29
>>
>> there is nothing about it. Any references to C in this article are
>> qualified with "for example", which is in line with what I've said.
>>
>> Could you please share the source of your information? I'm genuinely
>> interested.
>
><http://en.wikipedia.org/wiki/Stuart_Feldman>
>
>1977, Bell Labs, UNIX, first FORTRAN 77 compiler.
>
>I'd suspect, this compiler wasn't written in FORTRAN itself, so the
>logical conclusion would be that the compiler was witten in C (like
>almost anything for UNIX, especially at that time) and thus 'make'
>was written to simplify the task of compiling those compiler's sources. ;)
>
>
>Vinzent.
>
>-- 
>A C program is like a fast dance on a newly waxed dance floor by people carrying
>razors.
>   --  Waldi Ravens

Re: Why no socket package in the standard ?

[Georg Bauhaus]

On 5/26/11 11:59 PM, Ludovic Brenta wrote:
> Georg Bauhaus writes on comp.lang.ada:
>> Make (or similar) is still good for building Ada programs, in
>> particular, portable Ada programs (between compilers), and its
>> associated documentation and the tests.
>
> Make is a wrapper around shell scripts (the rules in Makefiles are shell
> scripts).

A rule system is more than a wrapper just like an Ada compiler's
Find_Dependencies routine is more than a recursive ls(1)
(assuming the compiler does use just file based search).

Plus, some make programs don't assume a sh(1) or anything
available withUnix.


> you do not need Make to figure dependencies or order of
> compilation out.

A project is not fully built when just the Ada part is built.
How would I have the customer run XSL transformation for doc
generation using, as you suggest, sh(1) on Windows(TM)?

Will GPRClean remove intermediate files in non-Ada parts
like make would?  (I don't know about this; the GPR docs
are extensive, and seem to concentrate on building Ada programs.)


>> For example, gnatmake is not enough if your program is this:

$ cat Hello.ada
procedure Hello;
-- offer greetings to the world

with Ada.Text_IO;
procedure Hello is
begin
     Ada.Text_IO.Put_Line("Hello, World!");
end Hello;
$

Gnatmake cannot translate the Ada program above.  It has more
than one separately compilable unit:

$ gnatmake -gnatf -gnatv Hello.ada
gcc -c -gnatf -gnatv -x ada hello.ada

GNAT GPL 2010 (20100603)
Copyright 1992-2010, Free Software Foundation, Inc.

Compiling: hello.ada (source file time stamp: 2011-05-27 07:07:02)

      4. with Ada.Text_IO;
         |
         >>> end of file expected, file can have only one compilation unit

  8 lines: 1 error
gnatmake: "hello.ada" compilation error




>  why not, gprmake.

The PATH issues in GPR* have again been mentioned.  Yes, they can
be solved, and they are documented. Just like: Yes, one can write
range checks in C, and the secret C standard + compiler documentation
+ machine documentation will say how.

Besides,

$ grep -i gprmake /opt/GNAT2010/share/doc/gnat/txt/*
$

I have yet to find the section detailing the "added" part
from the following promising sentence, quoted from gnat_ugn (GPL 2010):

   "Tools like `gnatmake' only know about Ada, while other tools like
    `gprbuild' know about many more languages such as C, C++,
    Fortran, assembly and others can be added dynamically."

Re: Why no socket package in the standard ?

[Stephen Leake]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> On 26 Maj, 14:42, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>
>> Similarly, make
>> started as a hack to overcome the deficiencies of C
>
> Sorry, but here:
>
> http://en.wikipedia.org/wiki/Make_%28software%29
>
> there is nothing about it. Any references to C in this article are
> qualified with "for example", which is in line with what I've said.

The "Origin" section (which is what we are talking about) is very short,
and implies (as Ludovic said) that 'make' was originally written to help
compile C code (since that was the primary language on Unix at the
time).

-- 
-- Stephe

Re: Why no socket package in the standard ?

[Stephen Leake]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> Adam Beneschan writes on comp.lang.ada:
>> On May 25, 9:36 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>>> Yannick Duchêne wrote on comp.lang.ada:
>>>
>>>> Peter C. Chapin a écrit:
>>>>> It also true that autoconf is a travesty... a throwback to a darker
>>>>> age when the POSIX standard did not exist (or at least was not
>>>>> widely implemented).
>>>
>>>> I do not know that much about Autoconf, so I can't really understand
>>>> what that mean and implies (someone else here also say a bit the
>>>> same as you too).
>>>
>>> Make was invented to overcome the deficiencies of C, notably the lack
>>> of modular programming and dependency management.
>>>
>>> Automake was invented to overcome the deficiencies of make, notably
>>> the poor maintainability of Makefiles.
>>>
>>> Configure was invented to overcome the deficiencies of early UNIX
>>> systems, notably the lack of conformance to POSIX, and their impact
>>> of the maintenance of Automake files.
>>>
>>> Autoconf was invented to overcome the deficiencies of Configure,
>>> notably the sheer size and horror of the configure scripts, which
>>> routinely consist of hundreds of thousands of lines of illegible
>>> POSIX shell code.
>>
>> I was going to ask what was the invention to overcome the deficiencies
>> of autoconf, but I think I figured it out ... rm -rf, right?
>
> Opinions differ but I'd tend to side with you :)

No! Ada and gprbuild :) we finally got it right :)

-- 
-- Stephe

Re: Why no socket package in the standard ?

[Dmitry A. Kazakov]

On Fri, 27 May 2011 07:46:43 -0400, Stephen Leake wrote:

> Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
> 
>> Adam Beneschan writes on comp.lang.ada:
>>> On May 25, 9:36�am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
>>>> Yannick Duch�ne wrote on comp.lang.ada:
>>>>
>>>>> Peter C. Chapin a �crit:
>>>>>> It also true that autoconf is a travesty... a throwback to a darker
>>>>>> age when the POSIX standard did not exist (or at least was not
>>>>>> widely implemented).
>>>>
>>>>> I do not know that much about Autoconf, so I can't really understand
>>>>> what that mean and implies (someone else here also say a bit the
>>>>> same as you too).
>>>>
>>>> Make was invented to overcome the deficiencies of C, notably the lack
>>>> of modular programming and dependency management.
>>>>
>>>> Automake was invented to overcome the deficiencies of make, notably
>>>> the poor maintainability of Makefiles.
>>>>
>>>> Configure was invented to overcome the deficiencies of early UNIX
>>>> systems, notably the lack of conformance to POSIX, and their impact
>>>> of the maintenance of Automake files.
>>>>
>>>> Autoconf was invented to overcome the deficiencies of Configure,
>>>> notably the sheer size and horror of the configure scripts, which
>>>> routinely consist of hundreds of thousands of lines of illegible
>>>> POSIX shell code.
>>>
>>> I was going to ask what was the invention to overcome the deficiencies
>>> of autoconf, but I think I figured it out ... rm -rf, right?
>>
>> Opinions differ but I'd tend to side with you :)
> 
> No! Ada and gprbuild :) we finally got it right :)

No, it was only one step forward. There are still mseinstall, rpmbuild,
dpkg mess around there.

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

Make, Automake, Configure, Autocong, GPRbuild etc (was: Why no socket package in the standard ?)

[Ludovic Brenta]

Dmitry A. Kazakov wrote on comp.lang.ada:
> On Fri, 27 May 2011 07:46:43 -0400, Stephen Leake wrote:
>> Ludovic Brenta writes:
>>> Adam Beneschan writes on comp.lang.ada:
>>>> Ludovic Brenta wrote:
>>>>> Yannick Duchêne wrote on comp.lang.ada:
>>>>>> Peter C. Chapin a écrit:
>>>>>>> It also true that autoconf is a travesty... a throwback to a
>>>>>>> darker age when the POSIX standard did not exist (or at least
>>>>>>> was not widely implemented).
>>>>>>
>>>>>> I do not know that much about Autoconf, so I can't really
>>>>>> understand what that mean and implies (someone else here
>>>>>> also say a bit the same as you too).
>>>>>
>>>>> Make was invented to overcome the deficiencies of C, notably
>>>>> the lack of modular programming and dependency management.
>>>>>
>>>>> Automake was invented to overcome the deficiencies of make,
>>>>> notably the poor maintainability of Makefiles.
>>>>>
>>>>> Configure was invented to overcome the deficiencies of early
>>>>> UNIX systems, notably the lack of conformance to POSIX, and
>>>>> their impact on the maintenance of Automake files.
>>>>>
>>>>> Autoconf was invented to overcome the deficiencies of
>>>>> Configure, notably the sheer size and horror of the configure
>>>>> scripts, which routinely consist of hundreds of thousands of
>>>>> lines of illegible POSIX shell code.
>>>>
>>>> I was going to ask what was the invention to overcome the
>>>> deficiencies of autoconf, but I think I figured it out ...
>>>> rm -rf, right?
>>>>
>>> Opinions differ but I'd tend to side with you :)
>>
>> No! Ada and gprbuild :) we finally got it right :)
>
> No, it was only one step forward. There are still mseinstall,
> rpmbuild, dpkg mess around there.

I think it is appropriate to separate the building of the binary
software from the packaging for a particular target platform.  For
starters, the author of the software does not necessarily have access
to all target operating systems.  The package maintainer requires
intimate knowledge of the target operating system, its package
management system, its policies, the names of existing packages, etc.
These are different concerns best addressed by different build
systems.  The things you mentioned (mseinstall, rpmbuild, dpkg)
naturally sit on top of the build system provided as part of the
software source distribution.  I don't think they should be merged.

That said, simplicity in both the build system and the packaging is of
course a Good Thing.  In Debian I've taken that approach to extremes
at times, bypassing the fragile Autoconf-based build system of some
software and replacing it with a single GPR project file and a couple
of rules in the packaging Makefile.

--
Ludovic Brenta.

Re: Make, Automake, Configure, Autocong, GPRbuild etc

[Dmitry A. Kazakov]

On Fri, 27 May 2011 05:49:26 -0700 (PDT), Ludovic Brenta wrote:

> Dmitry A. Kazakov wrote on comp.lang.ada:
>> On Fri, 27 May 2011 07:46:43 -0400, Stephen Leake wrote:
>>> Ludovic Brenta writes:
>>>> Adam Beneschan writes on comp.lang.ada:
>>>>> Ludovic Brenta wrote:
>>>>>> Yannick Duch�ne wrote on comp.lang.ada:
>>>>>>> Peter C. Chapin a �crit:
>>>>>>>> It also true that autoconf is a travesty... a throwback to a
>>>>>>>> darker age when the POSIX standard did not exist (or at least
>>>>>>>> was not widely implemented).
>>>>>>>
>>>>>>> I do not know that much about Autoconf, so I can't really
>>>>>>> understand what that mean and implies (someone else here
>>>>>>> also say a bit the same as you too).
>>>>>>
>>>>>> Make was invented to overcome the deficiencies of C, notably
>>>>>> the lack of modular programming and dependency management.
>>>>>>
>>>>>> Automake was invented to overcome the deficiencies of make,
>>>>>> notably the poor maintainability of Makefiles.
>>>>>>
>>>>>> Configure was invented to overcome the deficiencies of early
>>>>>> UNIX systems, notably the lack of conformance to POSIX, and
>>>>>> their impact on the maintenance of Automake files.
>>>>>>
>>>>>> Autoconf was invented to overcome the deficiencies of
>>>>>> Configure, notably the sheer size and horror of the configure
>>>>>> scripts, which routinely consist of hundreds of thousands of
>>>>>> lines of illegible POSIX shell code.
>>>>>
>>>>> I was going to ask what was the invention to overcome the
>>>>> deficiencies of autoconf, but I think I figured it out ...
>>>>> rm -rf, right?
>>>>>
>>>> Opinions differ but I'd tend to side with you :)
>>>
>>> No! Ada and gprbuild :) we finally got it right :)
>>
>> No, it was only one step forward. There are still mseinstall,
>> rpmbuild, dpkg mess around there.
> 
> I think it is appropriate to separate the building of the binary
> software from the packaging for a particular target platform.  For
> starters, the author of the software does not necessarily have access
> to all target operating systems.  The package maintainer requires
> intimate knowledge of the target operating system, its package
> management system, its policies, the names of existing packages, etc.

Exactly why the things I mentioned are garbage. Why such an intimate
knowledge is needed for packaging and is no more needed for building
binaries? Why intimacy of system directories is more intimate than privacy
of machine instructions, object and binary formats?

> These are different concerns best addressed by different build
> systems.  The things you mentioned (mseinstall, rpmbuild, dpkg)
> naturally sit on top of the build system provided as part of the
> software source distribution.  I don't think they should be merged.

Not merged, abstracted away, packaging is a trivial concept comparing to
compilation, optimization and linkage.

UNIX tools are so complicated, because it is a long standing tradition to
have it as broken as possible. If C, make, autoconf & Co. are that bad, why
dpkg should be any better?

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

Re: Why no socket package in the standard ?

[Simon Wright]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> You'd be better off with even simpler shell scripts or, why not,
> gprmake.

Pretty sure gprmake is obsolete now. I'm not happy that gprbuild isn't
part of GCC or in a public repo, but there you go.

Re: Why no socket package in the standard ?

[Ludovic Brenta]

Simon Wright writes on comp.lang.ada:
> Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
>
>> You'd be better off with even simpler shell scripts or, why not,
>> gprmake.
>
> Pretty sure gprmake is obsolete now. I'm not happy that gprbuild isn't
> part of GCC or in a public repo, but there you go.

Yes, sorry, I meant gprbuild not gprmake.  I share your feelings about
the availability of the sources.

-- 
Ludovic Brenta.

Re: Make, Automake, Configure, Autocong, GPRbuild etc

[Ludovic Brenta]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> These are different concerns [building vs. packaging] best addressed
>> by different build systems.  The things you mentioned (mseinstall,
>> rpmbuild, dpkg) naturally sit on top of the build system provided as
>> part of the software source distribution.  I don't think they should
>> be merged.
>
> Not merged, abstracted away, packaging is a trivial concept comparing to
> compilation, optimization and linkage.

OK, then I agree with you.

> UNIX tools are so complicated, because it is a long standing tradition
> to have it as broken as possible. If C, make, autoconf & Co. are that
> bad, why dpkg should be any better?

I never said dpkg et al were any better; only that they address
different problems than the build machinery used during development of
the software.

-- 
Ludovic Brenta.

Re: Why no socket package in the standard ?

[Randy Brukardt]

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

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message 
news:op.vvyoslycule2fv@douda-yannick...
>Hello one again,
>
>According to http://www.ibm.com/developerworks/linux/library/l-sockpit/
>> First introduced into the 4.2 BSD UNIX� operating system,
>> the Sockets API is now a standard feature of any operating system.In 
>> fact, it's hard to find a modern language that doesn'tsupport the 
>> Sockets API.
>
>This may help Ada (and be useful too) to add sockets in standard packages.

We had a project for this in Ada 2005, but no one stepped forward to do the 
extensive work needed. After the effort  to create the wording for 
Ada.Directories, I wasn't about to volunteer to create any more packages...

Defining a package spec is easy enough (many have done that), but describing 
what it does in a target-independent way is a much bigger job. Note that 
there is no ISO standard (so far as I'm aware) that describes BSD Sockets, 
so we'd have to recreate at least some description of those in the Ada 
Standard.

Languages without formal standards (or formal standards for their libraries) 
don't have this problem -- the libraries do whatever they do, and often that 
is good enough. And that's fine for Ada too, so long as you don't expect the 
Standard to include such things...

[Note that Ada also doesn't include a standard GUI, a standard program run 
("exec"), or many other things that are widely used. We tried to do "exec" 
and couldn't come up with a consistent definition of what it does -- and 
then gave up.]
                                       Randy.

Re: Why no socket package in the standard ?

[Florian Weimer]

* Randy Brukardt:

> Defining a package spec is easy enough (many have done that), but describing 
> what it does in a target-independent way is a much bigger job. Note that 
> there is no ISO standard (so far as I'm aware) that describes BSD Sockets, 
> so we'd have to recreate at least some description of those in the Ada 
> Standard.

I believe they are part of ISO/IEC 9945:2002.

However, it turns out that there already is an ISO standard for an Ada
interface to BSD sockets (which happens to include a file system
interface, too): ISO/IEC 14519:2001.  Efforts to standardize operating
system interfaces should rather concentrate on liberating that
document to increase adoption, addressing open issues, if necessary;
and not be wasted on duplicating it.  I think this offers a cautionary
tale why proprietary standards can be really, really bad.

Re: Why no socket package in the standard ?

[anon]

If the ARG was doing it job then RM 1.2 Normative References would list 
a number of extra IEC/ISO standards. But it seams that the only standards
are for the character set and a couple of references standards for external 
languages like C and Fortran. 

I think most would say where's the IEEE Math standards 754-2008 before 
adopting a BSD standard, IEEE 754 standard, have existed since 1985 
before Ada 95, so why it is not include in Ada 2005 and beyond.

So, when you get into "Standards",  Ada needs a great deal of work.


In <87k4d4z6b6.fsf@mid.deneb.enyo.de>, Florian Weimer <fw@deneb.enyo.de> writes:
>* Randy Brukardt:
>
>> Defining a package spec is easy enough (many have done that), but describing 
>> what it does in a target-independent way is a much bigger job. Note that 
>> there is no ISO standard (so far as I'm aware) that describes BSD Sockets, 
>> so we'd have to recreate at least some description of those in the Ada 
>> Standard.
>
>I believe they are part of ISO/IEC 9945:2002.
>
>However, it turns out that there already is an ISO standard for an Ada
>interface to BSD sockets (which happens to include a file system
>interface, too): ISO/IEC 14519:2001.  Efforts to standardize operating
>system interfaces should rather concentrate on liberating that
>document to increase adoption, addressing open issues, if necessary;
>and not be wasted on duplicating it.  I think this offers a cautionary
>tale why proprietary standards can be really, really bad.

Re: Why no socket package in the standard ?

[Florian Weimer]

> I think most would say where's the IEEE Math standards 754-2008 before 
> adopting a BSD standard, IEEE 754 standard, have existed since 1985 
> before Ada 95, so why it is not include in Ada 2005 and beyond.

Does Ada really use the IEEE 754 floating point model?  I don't think
so---the RM allows optimizations which are generally frowned upon for
reasons I do not entirely understand (such as increasing the accuracy
of operations by reassociation).

Re: Why no socket package in the standard ?

[J-P. Rosen]

Le 02/06/2011 22:38, anon@att.net a �crit :
> I think most would say where's the IEEE Math standards 754-2008 before 
> adopting a BSD standard, IEEE 754 standard, have existed since 1985 
> before Ada 95, so why it is not include in Ada 2005 and beyond.
> 
Because there are many machines that do not conform to IEEE, and it is
widely recognized that forcing IEEE arithmetic was a major flaw in Java.

Ada did not make the same error.

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

Re: Why no socket package in the standard ?

[Randy Brukardt]

"Florian Weimer" <fw@deneb.enyo.de> wrote in message 
news:87k4d4z6b6.fsf@mid.deneb.enyo.de...
>* Randy Brukardt:
>
>> Defining a package spec is easy enough (many have done that), but 
>> describing
>> what it does in a target-independent way is a much bigger job. Note that
>> there is no ISO standard (so far as I'm aware) that describes BSD 
>> Sockets,
>> so we'd have to recreate at least some description of those in the Ada
>> Standard.
>
> I believe they are part of ISO/IEC 9945:2002.

You're right; I had forgotten that POSIX had an ISO standard. (I don't think 
we can reference the IEEE standards.)

But one wonders about the wisdom of requiring a particular OS interface for 
Ada -- Ada is supposed to be target-independent. Perhaps it would be OK to 
reference a small piece of it.

> However, it turns out that there already is an ISO standard for an Ada
> interface to BSD sockets (which happens to include a file system
> interface, too): ISO/IEC 14519:2001.  Efforts to standardize operating
> system interfaces should rather concentrate on liberating that
> document to increase adoption, addressing open issues, if necessary;
> and not be wasted on duplicating it.  I think this offers a cautionary
> tale why proprietary standards can be really, really bad.

The POSIX standard is too low-level, IMHO, to be a very useful inclusion in 
the Ada standard. We have higher-level concepts in Ada for file management 
and tasking, for example (and Ada 2012 has a small amount of locale support 
as well), and that would seem to be appropriate for sockets as well. POSIX 
has it's place, of course, but it seems fine for it to be a separate 
standard -- most users have no reason to be writing at such a low level.

                           Randy.

Re: Why no socket package in the standard ?

[anon]

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


Why should the problem with Java and IEEE-754 cause any problem with Ada?

Ada is designed with System Independent. No other Language, System or 
Virtual Machine should influent the design of Ada. And this includes the 
CPU and/or FPU.  Note: Library package "Interfaces" and it sub-packages 
are be used to interface between language and system but these packages 
should not alter Ada or influent its design.

An example is:

  type Big_Integer is range - 2 ** 255 - 1  ..  2 ** 255 - 1 ;
  -- or
  type Big_Float is digits 64 ;

which only a few special systems can handle those types but Ada should so 
long as the functions are defined for this type. Either by the compiler 
or external math library during linking.

Now, having a generic Ada math package or design would insure at least 
for math that Ada is System Independent. And using a standard like IEEE
754 would insure application accuracy while maintaining that System 
Independent.

Note: The math functions may be defined as low-level functions but 
      they are used as medium to high priority function. 
      ISO/IEC/IEEE 60559:2011 (standard IEEE-754) has been approved.

So, for Ada 2012 it could be added.


In <is8unu$7np$1@dont-email.me>, "J-P. Rosen" <rosen@adalog.fr> writes:
>Le 02/06/2011 22:38, anon@att.net a �crit :
>> I think most would say where's the IEEE Math standards 754-2008 before 
>> adopting a BSD standard, IEEE 754 standard, have existed since 1985 
>> before Ada 95, so why it is not include in Ada 2005 and beyond.
>> 
>Because there are many machines that do not conform to IEEE, and it is
>widely recognized that forcing IEEE arithmetic was a major flaw in Java.
>
>Ada did not make the same error.
>
>-- 
>---------------------------------------------------------
>           J-P. Rosen (rosen@adalog.fr)
>Adalog a d�m�nag� / Adalog has moved:
>2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
>Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: Why no socket package in the standard ?

[J-P. Rosen]

Le 04/06/2011 23:35, anon@att.net a �crit :
> Now, having a generic Ada math package or design would insure at least 
> for math that Ada is System Independent. And using a standard like IEEE
> 754 would insure application accuracy while maintaining that System 
> Independent.
> 
The trouble is that numerical intensive applications often need
efficient implementations.

If you require IEEE arithmetic, and you are on a machine whose hardware
does not support IEEE-754 (note: supports and not implements, since
IEEE-754 is a software standard), you have a choice of 1) implement the
whole standard in software and say bye-bye to efficiency, or 2) ignore
the standard and use the native floating-point, which is a failure of
the standardization.

The Ada model allows portable guaranteed bounds to inaccurracy, without
requiring any particular arithmetic model, and is therefore efficiently
implementable on any hardware. That was part of the requirements.
-- 
---------------------------------------------------------
          J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: Why no socket package in the standard ?

[Florian Weimer]

* Randy Brukardt:

> But one wonders about the wisdom of requiring a particular OS
> interface for Ada -- Ada is supposed to be target-independent.
> Perhaps it would be OK to reference a small piece of it.

For all its faults, there is no alternative to BSD sockets.  All
systems supporting TCP and UDP use those concepts, even if they are
very far away from the original UNIX concepts in other aspects.  Even
the XTI interface was retrofitted to match the BSD sockets concepts,
even though the TLI interfaces suggested a closer correspondence to
the TCP state in the network.

Re: Why no socket package in the standard ?

[Dmitry A. Kazakov]

On Sun, 05 Jun 2011 13:06:59 +0200, Florian Weimer wrote:

> * Randy Brukardt:
> 
>> But one wonders about the wisdom of requiring a particular OS
>> interface for Ada -- Ada is supposed to be target-independent.
>> Perhaps it would be OK to reference a small piece of it.
> 
> For all its faults, there is no alternative to BSD sockets.

So what? Ada's interface to TCP/IP stack and other network stacks need not
to be thin. On the contrary it should be as abstract as possible in order
to remain independent on any OS-specific mess.

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

Re: Why no socket package in the standard ?

[Florian Weimer]

* Dmitry A. Kazakov:

> On Sun, 05 Jun 2011 13:06:59 +0200, Florian Weimer wrote:
>
>> * Randy Brukardt:
>> 
>>> But one wonders about the wisdom of requiring a particular OS
>>> interface for Ada -- Ada is supposed to be target-independent.
>>> Perhaps it would be OK to reference a small piece of it.
>> 
>> For all its faults, there is no alternative to BSD sockets.
>
> So what? Ada's interface to TCP/IP stack and other network stacks need not
> to be thin. On the contrary it should be as abstract as possible in order
> to remain independent on any OS-specific mess.

Sorry, I have no idea what you're talking about.  What would an API
look like that is more abstract than BSD sockets?  Would it
parametrize aspects such as congestion control and packet
fragmentation?

Re: Why no socket package in the standard ?

[Dmitry A. Kazakov]

On Sun, 05 Jun 2011 16:51:36 +0200, Florian Weimer wrote:

> * Dmitry A. Kazakov:
> 
>> On Sun, 05 Jun 2011 13:06:59 +0200, Florian Weimer wrote:
>>
>>> * Randy Brukardt:
>>> 
>>>> But one wonders about the wisdom of requiring a particular OS
>>>> interface for Ada -- Ada is supposed to be target-independent.
>>>> Perhaps it would be OK to reference a small piece of it.
>>> 
>>> For all its faults, there is no alternative to BSD sockets.
>>
>> So what? Ada's interface to TCP/IP stack and other network stacks need not
>> to be thin. On the contrary it should be as abstract as possible in order
>> to remain independent on any OS-specific mess.
> 
> Sorry, I have no idea what you're talking about.  What would an API
> look like that is more abstract than BSD sockets?

You would have a root controlled type with derived instances in particular
for TCP/IP (one for listening another for connection):

   Root_Network_Communication_Type (abstract)
     |
   Connection_Oriented_Type (abstract)
     |
   TCP_IP_Socket_Type (abstract)
     |
   TCP_IP_Client_Type (concrete)

> Would it
> parametrize aspects such as congestion control and packet
> fragmentation?

Options will be set using primitive operations rather than that awful stuff
characteristic for C bindings, just

    Set_No_Delay (Connection : in out TCP_IP_Socket_Type);
    Reset_No_Delay (Connection : in out TCP_IP_Socket_Type);

Similarly, idiotic BSD sockets' structures for dealing with names and
addresses will be replaced with properly designed Ada types.

Where is a problem?

A more interesting issue would be integrating asynchronous I/O into Ada
tasking, e.g. socket select. I think the implementation should provide a
task type with corresponding entries, e.g.

   task type Network_IO is
       entry Received (
          Connection : out not null access TCP_IP_Socket_Type'Class;
          Buffer : in out Octet_Array;
          Last : out Positive);
       entry Connected ...
       entry Sent ...
       entry Closed ...
       entry Assign_Sockets ...

(Will Ada 2012 support "out access"?)

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

Re: Why no socket package in the standard ?

[anon]

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

Actually, for any "numerical intensive applications" or High-Performance 
computing need to be "Parallel" to be efficient. Any other way of coding 
is totally, a waste of time. Ada 95 should of had threads, and by 2005 a 
parallel design should of been in place.

In paralleling an algorithm there are two main designs, The first is to 
add a paralleling optimizer component to the Ada compiler. This component 
optimizes an algorithm by rewriting parts in parallel form. But most of 
these optimizers requires standardization of the arithmetic processes 
such as using 754.

The second method is to allow the Ada programmer to construct a parallel 
routines. In the second case Ada is not parallel or even threaded. Using 
"Distributed Parallel" design might gives some help depending upon the 
lag time between systems. Too long a lag time kill the efficient also.

Using IEEE-754 standards on an Intel processor for example which does 
not fully support the 754 standards can easily done. By providing a 
conversion or interfacing packages to deal with those non-implement designs 
and as for efficiency its a trade off of being fast or being accurate. With 
efficiency using less accuracy finding someone with GPS, being off a couple 
of meters might not hurt, but using a laser in the operating room accuracy 
counts more than efficiency.

And using standards is more "portable" than depending on the computer 
systems or the OS.



In <isffbc$2jj$1@dont-email.me>, "J-P. Rosen" <rosen@adalog.fr> writes:
>Le 04/06/2011 23:35, anon@att.net a �crit :
>> Now, having a generic Ada math package or design would insure at least 
>> for math that Ada is System Independent. And using a standard like IEEE
>> 754 would insure application accuracy while maintaining that System 
>> Independent.
>> 
>The trouble is that numerical intensive applications often need
>efficient implementations.
>
>If you require IEEE arithmetic, and you are on a machine whose hardware
>does not support IEEE-754 (note: supports and not implements, since
>IEEE-754 is a software standard), you have a choice of 1) implement the
>whole standard in software and say bye-bye to efficiency, or 2) ignore
>the standard and use the native floating-point, which is a failure of
>the standardization.
>
>The Ada model allows portable guaranteed bounds to inaccurracy, without
>requiring any particular arithmetic model, and is therefore efficiently
>implementable on any hardware. That was part of the requirements.
>-- 
>---------------------------------------------------------
>          J-P. Rosen (rosen@adalog.fr)
>Adalog a d�m�nag� / Adalog has moved:
>2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
>Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: Why no socket package in the standard ?

[Randy Brukardt]

"Florian Weimer" <fw@deneb.enyo.de> wrote in message 
news:87pqms8h6v.fsf@mid.deneb.enyo.de...
>* Dmitry A. Kazakov:
>
>> On Sun, 05 Jun 2011 13:06:59 +0200, Florian Weimer wrote:
...
>>> For all its faults, there is no alternative to BSD sockets.
>>
>> So what? Ada's interface to TCP/IP stack and other network stacks need 
>> not
>> to be thin. On the contrary it should be as abstract as possible in order
>> to remain independent on any OS-specific mess.
>
> Sorry, I have no idea what you're talking about.  What would an API
> look like that is more abstract than BSD sockets?  Would it
> parametrize aspects such as congestion control and packet
> fragmentation?

BSD sockets is full of bizarre operational requirements which make it quite 
a bit more complex than necessary. One way to abstract it (lightly) is shown 
by Tom Moran's NC.Sockets (originally part of Claw). It probably would be 
better to abstract it even further (Tom wasn't trying to write a portable 
abstraction of sockets, it only worked out to be most of that).

                                       Randy.