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=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

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]

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 03:22:59 +0200, Yannick Duch=C3=AAne (Hibou57) =

Post by Yannick Duchêne (Hibou57)
There is AdaSockets, http://www.rfc1149.net/devel/adasockets.html

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=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]

[t***@acm.org]

Post by Yannick Duchêne (Hibou57)
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.

[Pascal Obry]

Post by t***@acm.org
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.

[Yannick Duchêne (Hibou57)]

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=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]

[Tero Koskinen]

Hi,

Post by t***@acm.org

Post by Yannick Duchêne (Hibou57)
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 ***@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 ***@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]

Post by Tero Koskinen
Hi,

Post by t***@acm.org
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...

[Yannick Duchêne (Hibou57)]

Le Wed, 25 May 2011 20:43:35 +0200, Tero Koskinen <***@iki.fi>=
a =

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 no=
t =

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=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]

[georg bauhaus]

Post by 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.

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.

[Maciej Sobczak]

Post by georg bauhaus
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

[Thomas Løcke]

Post by Maciej Sobczak
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.

[Ludovic Brenta]

Post by Thomas Løcke

Post by Maciej Sobczak
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.

[Georg Bauhaus]

Post by Thomas Løcke

Post by Maciej Sobczak
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

[Dmitry A. Kazakov]

Post by Georg Bauhaus
Opposing a get-that-duct-tape-solution-out–the-door style for
standardization, I'd imagine starting from questions like the
- 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.

Post by Georg Bauhaus
- 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)

Post by Georg Bauhaus
- 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?

Post by Georg Bauhaus
- 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.

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

What was the question? (:-))

[Georg Bauhaus]

Post by Dmitry A. Kazakov

Post by Georg Bauhaus
Opposing a get-that-duct-tape-solution-out–the-door style for
standardization, I'd imagine starting from questions like the
- 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.)

Post by Dmitry A. Kazakov
Communication between programs
is distribution, the annex E.

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

Post by Dmitry A. Kazakov
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.

Post by Dmitry A. Kazakov

Post by Georg Bauhaus
- 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.

Post by Dmitry A. Kazakov

Post by Georg Bauhaus
- 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?

Post by Dmitry A. Kazakov

Post by Georg Bauhaus
- 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.

Post by Dmitry A. Kazakov
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!?)

Post by Dmitry A. Kazakov

Post by Georg Bauhaus
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.

[Dmitry A. Kazakov]

Post by Georg Bauhaus

Post by Dmitry A. Kazakov
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.

Post by Georg Bauhaus

Post by Dmitry A. Kazakov
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.

Post by Georg Bauhaus
No hardware in sight from this viewpoint.

See above.

Post by Georg Bauhaus

Post by Dmitry A. Kazakov

Post by Georg Bauhaus
- 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.

Post by Georg Bauhaus
Why insist on sockets, then?

Because sockets is the most widely used transport.

Post by Georg Bauhaus

Post by Dmitry A. Kazakov
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.

Post by Georg Bauhaus
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?

Post by Georg Bauhaus
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.

Post by Georg Bauhaus

Post by Dmitry A. Kazakov

Post by Georg Bauhaus
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?

[Georg Bauhaus]

Post by Dmitry A. Kazakov

Post by Georg Bauhaus

Post by Dmitry A. Kazakov
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.

Post by Dmitry A. Kazakov

Post by Georg Bauhaus
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.

Post by Dmitry A. Kazakov

Post by Georg Bauhaus
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?)

Post by Dmitry A. Kazakov

Post by Georg Bauhaus
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.

[Dmitry A. Kazakov]

Post by Georg Bauhaus

Post by Dmitry A. Kazakov

Post by Georg Bauhaus

Post by Dmitry A. Kazakov
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%.

Post by Georg Bauhaus

Post by Dmitry A. Kazakov

Post by Georg Bauhaus
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.

Post by Georg Bauhaus

Post by Dmitry A. Kazakov

Post by Georg Bauhaus
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?

[Adam Beneschan]

Post by Dmitry A. Kazakov

Post by Dmitry A. Kazakov
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

[Dmitry A. Kazakov]

Post by Adam Beneschan

Post by Dmitry A. Kazakov

Post by Dmitry A. Kazakov
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).

Post by Adam Beneschan
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.

Post by Adam Beneschan
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.

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 21:21:43 +0200, Dmitry A. Kazakov =

Post by Dmitry A. Kazakov

Post by Adam Beneschan
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=

=

Post by Dmitry A. Kazakov
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=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]

[Yannick Duchêne (Hibou57)]

Post by Adam Beneschan
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 an=
d =

pipes as it is actually in the Ada standard. This is not an option, this=
=

is a requirement.

Post by Adam Beneschan
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 ha=
ve =

that need. But I agree more abstraction would be welcome, as limiting th=
is =

to sockets, would be as much a damage, as the lack of support for =

communication beyond files.

Post by Adam Beneschan
(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 =E2=80=9Csequence=E2=80=9D property and the =E2=80=9C=
relative time =

conservative=E2=80=9D 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, ther=
e =

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=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]

[Peter C. Chapin]

Post by Yannick Duchêne (Hibou57)
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

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 16:59:52 +0200, Dmitry A. Kazakov =

Post by Dmitry A. Kazakov

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

d?"

Post by Dmitry A. Kazakov
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=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]

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 16:28:32 +0200, Georg Bauhaus =

Post by Georg Bauhaus
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 mainl=
y =

reliable/non-reliable, stream/non-stream. What make the difference betwe=
en =

stream and non-stream, is the reliability=E2=80=A6 TCP/IP is looking lik=
e a PIPE, =

except for its identity, UDP/IP is not.

Post by Georg Bauhaus
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 us=

e

Post by Georg Bauhaus
case of (technically sockets based) data communication.

I do not see what fund your proclamation =E2=80=9CNot datagrams or packa=
ges or =

anything=E2=80=9D. 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).

Post by Georg Bauhaus
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.=

Post by Georg Bauhaus
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 th=
e =

most common of the two.

Post by Georg Bauhaus
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 lev=

el =

Post by Georg Bauhaus
issue

Reliability levels (and identity also).

Post by Georg Bauhaus
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=

=

Post by Georg Bauhaus
what it
might or might not have to do with Ada, or sockets, see below.)

:-)

Post by Georg Bauhaus
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 =E2=80=9Cisolating a few requirements=E2=80=9D, cause as =
replied elsewhere, =

some part of the BSD sockets would probably not be welcome (raw sockets)=
.

Post by Georg Bauhaus
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 la=
ck =

an answer to the other option : why would fund the rejection ?

Post by Georg Bauhaus
No one else has the power.

Pragmatism would suggest the community of active developers (proprietary=
=

or not).

Post by Georg Bauhaus
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 ?

Post by Georg Bauhaus
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=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]

[Georg Bauhaus]

Post by Yannick Duchêne (Hibou57)

Post by Georg Bauhaus
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.

Post by Yannick Duchêne (Hibou57)
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?

Post by Yannick Duchêne (Hibou57)

Post by Georg Bauhaus
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.

Post by Yannick Duchêne (Hibou57)

Post by Georg Bauhaus
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.

Post by Yannick Duchêne (Hibou57)

Post by Georg Bauhaus
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!

Post by Yannick Duchêne (Hibou57)

Post by Georg Bauhaus
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".

[Yannick Duchêne (Hibou57)]

Le Wed, 25 May 2011 02:32:36 +0200, Georg Bauhaus =

Post by Georg Bauhaus

May be an option, I agree. Still that as replied elsewhere, you still=

=

Post by Georg Bauhaus

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 =E2=80=9Cwhat would base/justify the rejection=E2=80=9D


-- =

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]

[Pascal Obry]

Post by Georg Bauhaus
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.

[Georg Bauhaus]

Post by Georg Bauhaus
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.

[Dmitry A. Kazakov]

Post by Georg Bauhaus

Post by Yannick Duchêne (Hibou57)
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.

[Dmitry A. Kazakov]

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.

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 12:00:24 +0200, Georg Bauhaus =

Post by Georg Bauhaus
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 base=
d =

on the BSD specification, was kept close enough. The POSIX specification=
=

seems to only differs in the way to get host by name / address.

Post by Georg Bauhaus
.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).

Post by Georg Bauhaus
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 packag=
es =

for Ada, it's only about sockets, which is either OSI layer 4 or 5 =

(depending on the point of view).

Post by Georg Bauhaus
Define
Commercially_Important_Platforms :=3D {
=E2=88=83 target | POSIX(target) IN { False, True }
}
How large is the subset defined by POSIX(target) =3D 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 sa=
id =

above, there are only little differences between the POSIX and BSD socke=
t =

specification, and then after, sockets does not implies POSIX. POSIX is =
=

one thing, sockets is another.

Post by Georg Bauhaus
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 ?

Post by Georg Bauhaus
Opposing a get-that-duct-tape-solution-out=E2=80=93the-door style for
standardization, I'd imagine starting from questions like the

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.

Post by Georg Bauhaus
- 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.

Post by Georg Bauhaus
- 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 thi=
s =

way).

Post by Georg Bauhaus
- 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 socket=
s =

type : streams and none-stream.

Post by Georg Bauhaus
- Is sockets the right approach? Consider Erlang!

Seems Erlang actually provides sockets.

Post by Georg Bauhaus
- Is sockets the right approach? Consider a CAN!

A can 8-) ?

Post by Georg Bauhaus
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 BS=
D =

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 ar=
e =

a mostly secure things. And Ada has tasking defined in the language, whi=
ch =

can be useful for sockets (think about the "select" operation, while not=
=

formally required, is often used in conjunction with sockets).

Post by Georg Bauhaus
[*] =
http://pike.ida.liu.se/generated/manual/modref/ex/predef_3A_3A/Stdio/P=

ort.html

Post by Georg Bauhaus
[**] 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=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]

[Ludovic Brenta]

Post by Yannick Duchêne (Hibou57)

Post by Georg Bauhaus
Opposing a get-that-duct-tape-solution-out–the-door style for
standardization, I'd imagine starting from questions like the

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?

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 21:54:13 +0200, Ludovic Brenta =

Wrong. http://en.wikibooks.org/wiki/Ada_Programming/Platform/POSIX say=
"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 n=
ot =

the same as adding a vendor specific feature when this pleased this vend=
or =

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 abou=
t =

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=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]

[Ludovic Brenta]

Post by Yannick Duchêne (Hibou57)
Le Tue, 24 May 2011 21:54:13 +0200, Ludovic Brenta

Post by Ludovic Brenta
"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.

Post by Yannick Duchêne (Hibou57)

Post by Ludovic Brenta
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?

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 23:57:48 +0200, Ludovic Brenta =

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=E2=80=A6 Ada still d=
efine file =

types.
Some systems does not have dynamic memory allocation except stack=E2=80=A6=
Ada =

still define the "new" operator and storage pools.
Some systems never deals with character and only bother about numbers=E2=
=80=A6 Ada =

still define character types and character handling (and encoding, as of=
=

Ada 2012).
Some systems have files, while no directory=E2=80=A6 Ada still defines d=
irectory =

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 latte=
r =

and not the former (I suspect some some corporation interest in this =

choice). Here, Ada supports the less widely used, and not the most widel=
y =

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=E2=80=A6 if you really want to know : I use one propriet=
ary 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=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]

[Adam Beneschan]

On May 24, 3:35 pm, Yannick Duchêne (Hibou57)

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

[Ludovic Brenta]

Post by Adam Beneschan
On May 24, 3:35 pm, Yannick Duchêne (Hibou57)

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...

[Yannick Duchêne (Hibou57)]

Le Wed, 25 May 2011 01:40:40 +0200, Ludovic Brenta =

Post by Ludovic Brenta
"Whenever cats meow and sing bizarrely, it's not for dogs."
I too need a translation...

Stop joking french guy ;)

Adam, =E2=80=9Cnot for the dogs=E2=80=9D (literally =C2=AB pas pour les =
chiens =C2=BB), is a french =

expression meaning =E2=80=9Cnot for nothing=E2=80=9D (i.e. =E2=80=9Cther=
e is a purpose=E2=80=9D or =E2=80=9Cthat =

really means something=E2=80=9D). Actually, this cannot be really transl=
ated 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=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]

[Ludovic Brenta]

Post by Yannick Duchêne (Hibou57)
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.

Post by Yannick Duchêne (Hibou57)
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.

[Shark8]

Post by Yannick Duchêne (Hibou57)
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.}

[Yannick Duchêne (Hibou57)]

Le Wed, 25 May 2011 05:07:06 +0200, Shark8 <***@gmail.com> a =
=

Post by Shark8
{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 =E2=80=9CWindows Services for UNIX=E2=80=9D, alias =E2=
=80=9CSubsystem for =

UNIX-based Applications=E2=80=9D.
See http://technet.microsoft.com/fr-fr/library/bb496506(en-us).asp=
x
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 whe=
re =

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=E2=80=A6 so anyone can bet this is not surprising then if U=
NIces =

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=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]

[Georg Bauhaus]

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.

[Ludovic Brenta]

   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

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.

[Manuel Collado]

Post by Ludovic Brenta

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 ;-)

[Peter C. Chapin]

Post by Yannick Duchêne (Hibou57)
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

[Yannick Duchêne (Hibou57)]

=
It also true that autoconf is a travesty... a throwback to a darker ag=

e

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 wha=
t =

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=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]

[Ludovic Brenta]

Post by Peter C. Chapin
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.

[Yannick Duchêne (Hibou57)]

Le Wed, 25 May 2011 18:36:17 +0200, Ludovic Brenta =

[=E2=80=A6 long worthy wordings =E2=80=A6]
Enough said :)

and Good enough. Thanks for the piece of history, that's crystal-clear n=
ow.

-- =

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]

[Maciej Sobczak]

Post by Ludovic Brenta
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

[Ludovic Brenta]

Post by Maciej Sobczak

Post by Ludovic Brenta
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.

[Georg Bauhaus]

Post by Ludovic Brenta

Post by Maciej Sobczak

Post by Ludovic Brenta
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?

[Ludovic Brenta]

Post by Ludovic Brenta

Post by Maciej Sobczak

Post by Ludovic Brenta
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 :)

[Maciej Sobczak]

Post by Ludovic Brenta
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

[Yannick Duchêne (Hibou57)]

Le Thu, 26 May 2011 20:20:33 +0200, Maciej Sobczak =

Post by Maciej Sobczak

Post by Ludovic Brenta
Similarly, make
started as a hack to overcome the deficiencies of C

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 regist=
er =

this as an owned trademark). I heard the same about Make, as what Ludovi=
c =

said. And then, the first time I had to face this ugly Make (and its sil=
ly =

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=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]

[Georg Bauhaus]

Post by Maciej Sobczak

Post by Ludovic Brenta
Similarly, make
started as a hack to overcome the deficiencies of C

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.

[Yannick Duchêne (Hibou57)]

Le Thu, 26 May 2011 22:46:09 +0200, Georg Bauhaus =

Post by Georg Bauhaus
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 compilati=
on =

unit name to file names. This is simpler than what many Makefiles looks =
=

like.

Post by Georg Bauhaus
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=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]

[Georg Bauhaus]

Post by Georg Bauhaus
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.

Post by Georg Bauhaus
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.

[Ludovic Brenta]

Post by Georg Bauhaus
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 :)

Post by Georg Bauhaus
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"?

Post by Georg Bauhaus
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.

[Georg Bauhaus]

Post by Ludovic Brenta

Post by Georg Bauhaus
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.

Post by Ludovic Brenta
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.)
$ 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;
|

Post by Ludovic Brenta

Post by Georg Bauhaus

end of file expected, file can have only one compilation unit

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

Post by Ludovic Brenta
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."

[Vinzent Hoefler]

Post by Maciej Sobczak

Post by Ludovic Brenta
Similarly, make
started as a hack to overcome the deficiencies of C

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.

[Ludovic Brenta]

Post by Vinzent Hoefler

Post by Maciej Sobczak

Post by Ludovic Brenta
Similarly, make
started as a hack to overcome the deficiencies of C

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

[Yannick Duchêne (Hibou57)]

Le Thu, 26 May 2011 20:31:28 +0200, Vinzent Hoefler =

Post by Vinzent Hoefler
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=

. =

Post by Vinzent Hoefler
;)

So Make was=E2=80=A6 Yet Another Compiler-Compiler ? :-D

-- =

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]

[Ludovic Brenta]

Post by Yannick Duchêne (Hibou57)
Le Thu, 26 May 2011 20:31:28 +0200, Vinzent Hoefler

Post by Vinzent Hoefler
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
:)

[a***@att.net]

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.

Post by Vinzent Hoefler

Post by Maciej Sobczak

Post by Ludovic Brenta
Similarly, make
started as a hack to overcome the deficiencies of C

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

[Stephen Leake]

Post by Maciej Sobczak

Post by Ludovic Brenta
Similarly, make
started as a hack to overcome the deficiencies of C

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).

[Adam Beneschan]

Post by Ludovic Brenta

Post by Peter C. Chapin
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

[Ludovic Brenta]

Post by Adam Beneschan

Post by Ludovic Brenta

Post by Yannick Duchêne (Hibou57)

Post by Peter C. Chapin
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 :)

[Georg Bauhaus]

MS Windows has been POSIX complaint since 2000...

Nice. ;-)

[Pascal Obry]

Post by Georg Bauhaus

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.

[Ludovic Brenta]

Post by Shark8

Post by Yannick Duchêne (Hibou57)
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.

Post by Shark8
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.

[Shark8]

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.

[Thomas Løcke]

Post by Ludovic Brenta
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?

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 21:38:03 +0200, Yannick Duch=C3=AAne (Hibou57) =

Post by Georg Bauhaus
- 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. Thi=
s =

in turn can lead to security risk and efficiency troubles to not talk =

about system stability (ouch). Raw socket is useful to implement your ow=
n =

protocol over IP=E2=80=A6 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=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]

[Georg Bauhaus]

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".

Post by Georg Bauhaus
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?

Post by Georg Bauhaus
- 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?

Post by Georg Bauhaus
- 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.

Post by Georg Bauhaus
- 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.

[Yannick Duchêne (Hibou57)]

Le Wed, 25 May 2011 01:09:49 +0200, Georg Bauhaus =

Post by Georg Bauhaus
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=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]

[Dmitry A. Kazakov]

Post by Georg Bauhaus
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).

[Georg Bauhaus]

Post by Georg Bauhaus
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?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 May 2011 01:11:47 +0200, Georg Bauhaus =

Post by Georg Bauhaus
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=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]

[Georg Bauhaus]

Post by Georg Bauhaus
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.

[Yannick Duchêne (Hibou57)]

Le Wed, 25 May 2011 01:57:36 +0200, Georg Bauhaus =

Post by Georg Bauhaus

Post by Yannick Duchêne (Hibou57)
Le Wed, 25 May 2011 01:11:47 +0200, Georg Bauhaus =

Post by Georg Bauhaus
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 sta=

rt =

Post by Georg Bauhaus

Post by Yannick Duchêne (Hibou57)
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=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]

[Dmitry A. Kazakov]

Post by Maciej Sobczak

Post by georg bauhaus
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.

Post by Maciej Sobczak
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.

[Maciej Sobczak]

Post by Dmitry A. Kazakov

Post by Maciej Sobczak
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. ;-)

Post by Dmitry A. Kazakov

Post by Maciej Sobczak
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

[Dmitry A. Kazakov]

Post by Maciej Sobczak

Post by Dmitry A. Kazakov

Post by Maciej Sobczak
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.

[Maciej Sobczak]

Post by Dmitry A. Kazakov

Post by Maciej Sobczak
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.

Post by Dmitry A. Kazakov
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

[Dmitry A. Kazakov]

Post by Maciej Sobczak

Post by Dmitry A. Kazakov

Post by Maciej Sobczak
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.

Post by Maciej Sobczak

Post by Dmitry A. Kazakov
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;

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 09:25:38 +0200, Dmitry A. Kazakov =

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 t=
o =

make things more complex, but to provide different level of reliability,=
=

which make some like streams and some others not. Unlike Unicode encodin=
g =

introduced in Ada 2012, the protocols list is not closed, however, TCP/I=
P =

and UDP/IP are still the widely used. This could be compared to the topi=
c =

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 worr=
y =

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=E2=80=
=A6 unlike =

many others here.

-- =

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]

[Dmitry A. Kazakov]

Post by Yannick Duchêne (Hibou57)
Le Tue, 24 May 2011 09:25:38 +0200, Dmitry A. Kazakov

Post by Dmitry A. Kazakov
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?

Post by Yannick Duchêne (Hibou57)
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.

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 08:24:40 +0200, georg bauhaus =

Post by georg bauhaus
Which modern, post 1990, language supports sockets in the language?

As pointed by others in this thread (with reference and examples) as wel=
l =

as pointed in the opening message, the answer is : near to all well know=
n =

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

Post by georg bauhaus
Which language supports features of modern file storage? (That is, fil=

e

Post by georg bauhaus
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=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]

[J-P. Rosen]

Post by Yannick Duchêne (Hibou57)

Post by georg bauhaus
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...

[Yannick Duchêne (Hibou57)]

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 righ=
t =

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 h=
ow =

much useful it is to softwares=E2=80=A6 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-tim=
e =

(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=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]

[Georg Bauhaus]

Post by georg bauhaus
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.

[Yannick Duchêne (Hibou57)]

Le Wed, 25 May 2011 00:39:58 +0200, Georg Bauhaus =

Post by Georg Bauhaus
- 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).

Post by Georg Bauhaus
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.

Post by Georg Bauhaus
- 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.

Post by Georg Bauhaus
- 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 socket=
s, =

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=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]

[Georg Bauhaus]

Post by Yannick Duchêne (Hibou57)

Post by Georg Bauhaus
- 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.

Post by Yannick Duchêne (Hibou57)

Post by Georg Bauhaus
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.

Post by Yannick Duchêne (Hibou57)

Post by Georg Bauhaus
- 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.

Post by Yannick Duchêne (Hibou57)

Post by Georg Bauhaus
- 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?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 May 2011 01:54:02 +0200, Georg Bauhaus =

Post by Georg Bauhaus
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 somewh=
at =

pure and simpler than IPC, and is just a particular case of IPC, which =

(the latter) is wider.

Post by Georg Bauhaus
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).

Post by Georg Bauhaus
"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 ?).

Post by Georg Bauhaus
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 ;)

Post by Georg Bauhaus

Post by Yannick Duchêne (Hibou57)

Post by Georg Bauhaus
- 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=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]

[Yannick Duchêne (Hibou57)]

Le Wed, 25 May 2011 02:34:16 +0200, Yannick Duch=C3=AAne (Hibou57) =

Post by Yannick Duchêne (Hibou57)

Post by Georg Bauhaus
"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=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]

[AdaMagica]

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

[Yannick Duchêne (Hibou57)]

Le Tue, 24 May 2011 14:38:56 +0200, AdaMagica =

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=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]

[a***@att.net]

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.

Post by 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=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

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]

[Yannick Duchêne (Hibou57)]

Plus, there is no language that contains Sockets as apart of it standa=

rd

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, =E2=80=A6 one more time.


-- =

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]