* Why no socket package in the standard ? @ 2011-05-24 1:22 Yannick Duchêne (Hibou57) 2011-05-24 1:39 ` Yannick Duchêne (Hibou57) ` (4 more replies) 0 siblings, 5 replies; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-24 1:22 UTC (permalink / raw) Hello one again, According to http://www.ibm.com/developerworks/linux/library/l-sockpit/ > First introduced into the 4.2 BSD UNIX® operating system, > the Sockets API is now a standard feature of any operating system.In > fact, it's hard to find a modern language that doesn'tsupport the > Sockets API. This may help Ada (and be useful too) to add sockets in standard packages. There is AdaSockets, http://www.rfc1149.net/devel/adasockets.html which has cool licensing terms: > This library lets you use BSD sockets from Ada (TCP, UDP and multicast). > It is released under the GNAT Modified General Public License, which > means > that you can freely AdaSockets in a proprietary application without > having > it contaminate your code. Nice, but still not part of the standard, and I cannot see a reason why, such a fundamental thing, at least as fundamental as file access and standard I/O streams are, is not part of the standard packages. May be a candidate for an optional annex at least ? Already discussed or not ? Sorry for any inconvenience if I ever missed something there (this question seems so much basic I can't avoid feeling I've missed something). -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 1:22 Why no socket package in the standard ? Yannick Duchêne (Hibou57) @ 2011-05-24 1:39 ` Yannick Duchêne (Hibou57) 2011-05-24 6:11 ` tmoran 2011-05-24 6:24 ` georg bauhaus ` (3 subsequent siblings) 4 siblings, 1 reply; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-24 1:39 UTC (permalink / raw) Le Tue, 24 May 2011 03:22:59 +0200, Yannick Duchêne (Hibou57) <yannick_duchene@yahoo.fr> a écrit: > There is AdaSockets, http://www.rfc1149.net/devel/adasockets.html > which has cool licensing terms: Except (I just looked at the source) I personally don't enjoy bindings which end to introduce C like namings [*] in Ada. Things like PF_INET, IPPROTO_IP or SOL_SOCKET looks really strange for an Ada source; use of this kind of abbreviation is typically discouraged, with good reasons. A standard package would also be an occasion to give it a more Ada-ishe design and presentation. [*] Not because that is C namings, but because of what these namings are. -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 1:39 ` Yannick Duchêne (Hibou57) @ 2011-05-24 6:11 ` tmoran 2011-05-24 17:23 ` Pascal Obry ` (2 more replies) 0 siblings, 3 replies; 121+ messages in thread From: tmoran @ 2011-05-24 6:11 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 6:11 ` tmoran @ 2011-05-24 17:23 ` Pascal Obry 2011-05-24 19:10 ` Yannick Duchêne (Hibou57) 2011-05-25 15:12 ` Tero Koskinen 2 siblings, 0 replies; 121+ messages in thread From: Pascal Obry @ 2011-05-24 17:23 UTC (permalink / raw) To: tmoran Le 24/05/2011 08:11, tmoran@acm.org a écrit : > A thicker binding is NC sockets ("Not Claw", derived from Claw.Sockets). > It's nc.zip at www.adaworld.com, look there under > Ada Projects/Ada Internet Projects/Internet Protocols > It's for Windows but IIRC the WSAStartup and WSACleanup should be > the only Windows specific things. I've not looked at the source but I bet there is others. For example closesocket (which is close on POSIX AFAIK). Plus all the constants related to the socket layer which are different on Windows. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net - http://v2p.fr.eu.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver keys.gnupg.net --recv-key F949BD3B ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 6:11 ` tmoran 2011-05-24 17:23 ` Pascal Obry @ 2011-05-24 19:10 ` Yannick Duchêne (Hibou57) 2011-05-25 15:12 ` Tero Koskinen 2 siblings, 0 replies; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-24 19:10 UTC (permalink / raw) Le Tue, 24 May 2011 08:11:43 +0200, <tmoran@acm.org> a écrit: > A thicker binding is NC sockets ("Not Claw", derived from Claw.Sockets). > It's nc.zip at www.adaworld.com, look there under > Ada Projects/Ada Internet Projects/Internet Protocols > It's for Windows but IIRC the WSAStartup and WSACleanup should be > the only Windows specific things. If that is representative of Claw source layout, I can say I like it (consistent comments every where in specs files) Thanks to you for this pointer, as that is the first time I could see an example of Claw source (I do not own a Janus-Ada compiler). -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 6:11 ` tmoran 2011-05-24 17:23 ` Pascal Obry 2011-05-24 19:10 ` Yannick Duchêne (Hibou57) @ 2011-05-25 15:12 ` Tero Koskinen 2011-05-25 18:43 ` Tero Koskinen 2 siblings, 1 reply; 121+ messages in thread From: Tero Koskinen @ 2011-05-25 15:12 UTC (permalink / raw) Hi, On Tue, 24 May 2011 06:11:43 +0000 (UTC) tmoran@acm.org wrote: > > Except (I just looked at the source) I personally don't enjoy bindings > > which end to introduce C like namings [*] in Ada. Things like PF_INET, > > IPPROTO_IP or SOL_SOCKET looks really strange for an Ada source; > > A thicker binding is NC sockets ("Not Claw", derived from Claw.Sockets). > It's nc.zip at www.adaworld.com, look there under > Ada Projects/Ada Internet Projects/Internet Protocols > It's for Windows but IIRC the WSAStartup and WSACleanup should be > the only Windows specific things. Here is a diff which allows the package to compile on OpenBSD/amd64. (It includes also some filename upper/lower case corrections, so the diff is pretty big.) The example programs still segfault. I guess the datastructure definitions are incorrect. diff -r f734a2862510 -r 2cca25a3f5f4 GETJPG.ADB --- a/GETJPG.ADB Tue Dec 21 19:45:44 2010 +0200 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,75 +0,0 @@ --- Sample program using NC.Sockets --- It goes to the San Jose State weathercam and downloads to pic.jpg --- a picture of the current skyline in San Jose, California --- Copyright 2003 tmoran@acm.org anyone may use for any purpose -with Ada.Streams, - Ada.Streams.Stream_IO, - Ada.Text_IO, - Nc.Sockets; -procedure Getjpg is - use type Ada.Streams.Stream_Element_Offset; - - Buffer : Ada.Streams.Stream_Element_Array(1 .. 5000); - Last : Ada.Streams.Stream_Element_Offset; - F : Ada.Streams.Stream_IO.File_Type; - Socket : Nc.Sockets.Socket_Type; - Length : Ada.Streams.Stream_Element_Offset := 0; - type States is (Start, Seen_CR1, Seen_LF1, Seen_CR2, In_Data); - subtype Header is States range Start .. Seen_Cr2; - State : States := Start; - - procedure Write is - use Ada.Streams; - C : Character; - Watch_For : constant array(Header) of Character - := (Start => Ascii.CR, Seen_CR1 => Ascii.LF, Seen_LF1 => Ascii.CR, - Seen_CR2 => Ascii.LF); - begin - if State = In_Data then - Stream_IO.Write(F, Buffer(1 .. Last)); - Length := Length + Last; - return; - end if; - for I in 1 .. Last loop - C := Character'Val(Stream_Element'Pos(Buffer(I))); - Ada.Text_IO.Put(C); - if C = Watch_For(State) then - State := States'succ(State); - if State = In_Data then - Stream_Io.Create(F, Stream_Io.Out_File, "pic.jpg"); - if I < Last then - Stream_Io.Write(F, Buffer(I + 1 .. Last)); - Length := Last - I; - end if; - exit; - end if; - else - State := Start; - end if; - end loop; - end Write; - - procedure Stop is - begin - Ada.Text_IO.Put_Line(Ada.Streams.Stream_Element_Offset'Image(Length) - & " file pic.jpg written"); - if Ada.Streams.Stream_IO.Is_Open(F) then - Ada.Streams.Stream_IO.Close(F); - end if; - end Stop; - -begin - Nc.Sockets.Open(Socket, "metsun1.met.sjsu.edu", 80, Timeout => 20.0); - Nc.Sockets.Put_Line(Socket, "GET /cam_directory/latest.jpg HTTP/1.0"); - Nc.Sockets.Put_Line(Socket, ""); - loop - Nc.Sockets.Input(Socket, Timeout => 10.0, Item => Buffer, Last => Last); - exit when Last < Buffer'First; - Write; - end loop; - Nc.Sockets.Close(Socket); - Stop; -exception - when Nc.Not_Found_Error => - Stop; -end Getjpg; diff -r f734a2862510 -r 2cca25a3f5f4 NC.ADS --- a/NC.ADS Tue Dec 21 19:45:44 2010 +0200 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,19 +0,0 @@ -with Interfaces.C; -package NC is - type Short is new Interfaces.C.Short; - type Int is new Interfaces.C.Int; - subtype Natural_Int is Int range 0 .. Int'last; - type UInt is new Interfaces.C.Unsigned; - type DWord is new Interfaces.C.Unsigned_Long; - - type Byte is range 0 .. 255; - for Byte'size use 8; - type Word is mod 2**16; - for Word'size use 16; - - Windows_Error, - Not_Valid_Error, - Already_Valid_Error, - Not_Found_Error : Exception; - type Lpcstr is access all Interfaces.C.Char; -end NC; diff -r f734a2862510 -r 2cca25a3f5f4 getjpg.adb --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/getjpg.adb Wed Dec 22 18:05:52 2010 +0200 @@ -0,0 +1,75 @@ +-- Sample program using NC.Sockets +-- It goes to the San Jose State weathercam and downloads to pic.jpg +-- a picture of the current skyline in San Jose, California +-- Copyright 2003 tmoran@acm.org anyone may use for any purpose +with Ada.Streams, + Ada.Streams.Stream_IO, + Ada.Text_IO, + Nc.Sockets; +procedure Getjpg is + use type Ada.Streams.Stream_Element_Offset; + + Buffer : Ada.Streams.Stream_Element_Array(1 .. 5000); + Last : Ada.Streams.Stream_Element_Offset; + F : Ada.Streams.Stream_IO.File_Type; + Socket : Nc.Sockets.Socket_Type; + Length : Ada.Streams.Stream_Element_Offset := 0; + type States is (Start, Seen_CR1, Seen_LF1, Seen_CR2, In_Data); + subtype Header is States range Start .. Seen_Cr2; + State : States := Start; + + procedure Write is + use Ada.Streams; + C : Character; + Watch_For : constant array(Header) of Character + := (Start => Ascii.CR, Seen_CR1 => Ascii.LF, Seen_LF1 => Ascii.CR, + Seen_CR2 => Ascii.LF); + begin + if State = In_Data then + Stream_IO.Write(F, Buffer(1 .. Last)); + Length := Length + Last; + return; + end if; + for I in 1 .. Last loop + C := Character'Val(Stream_Element'Pos(Buffer(I))); + Ada.Text_IO.Put(C); + if C = Watch_For(State) then + State := States'succ(State); + if State = In_Data then + Stream_Io.Create(F, Stream_Io.Out_File, "pic.jpg"); + if I < Last then + Stream_Io.Write(F, Buffer(I + 1 .. Last)); + Length := Last - I; + end if; + exit; + end if; + else + State := Start; + end if; + end loop; + end Write; + + procedure Stop is + begin + Ada.Text_IO.Put_Line(Ada.Streams.Stream_Element_Offset'Image(Length) + & " file pic.jpg written"); + if Ada.Streams.Stream_IO.Is_Open(F) then + Ada.Streams.Stream_IO.Close(F); + end if; + end Stop; + +begin + Nc.Sockets.Open(Socket, "metsun1.met.sjsu.edu", 80, Timeout => 20.0); + Nc.Sockets.Put_Line(Socket, "GET /cam_directory/latest.jpg HTTP/1.0"); + Nc.Sockets.Put_Line(Socket, ""); + loop + Nc.Sockets.Input(Socket, Timeout => 10.0, Item => Buffer, Last => Last); + exit when Last < Buffer'First; + Write; + end loop; + Nc.Sockets.Close(Socket); + Stop; +exception + when Nc.Not_Found_Error => + Stop; +end Getjpg; diff -r f734a2862510 -r 2cca25a3f5f4 nc-sockets-alt_gethostbyname.adb --- a/nc-sockets-alt_gethostbyname.adb Tue Dec 21 19:45:44 2010 +0200 +++ b/nc-sockets-alt_gethostbyname.adb Wed Dec 22 18:05:52 2010 +0200 @@ -10,7 +10,7 @@ end loop; Result.P_Hostent := NC.Sockets.B_Helper.gethostbyname(Result.C_Name(0)'unchecked_access); if Result.P_Hostent = null then - Result.Error := NC.Sockets.B_Helper.WSAGetLastError; + Result.Error := 0; end if; Result.Output_Ready:=True; while not Result.Fini loop diff -r f734a2862510 -r 2cca25a3f5f4 nc-sockets.adb --- a/nc-sockets.adb Tue Dec 21 19:45:44 2010 +0200 +++ b/nc-sockets.adb Wed Dec 22 18:05:52 2010 +0200 @@ -32,6 +32,10 @@ use Claw.Sockets.Low_Level; System_Control : System_Controls; + function WSAGetLastError return Error_Codes is + begin + return 0; + end WSAGetLastError; procedure Get_Error_Code(Info : in out Host_Info_Type; Error_Code : out Error_Codes) is @@ -212,8 +216,10 @@ C_Name_Length : Size_T := Claw.sockets.Alt_Gethostbyname.C_Name_Type'length; - function Get_Last_Error return Claw.DWord; - pragma Import (StdCall, Get_Last_Error, "GetLastError"); + function Get_Last_Error return Claw.DWord is + begin + return 0; + end Get_Last_Error; begin @@ -489,19 +495,13 @@ if Is_Running then Error := 0; else - Error := WSAStartup(16#0101#, wsadata'access); - if Error = 0 then - Is_Running := True; - end if; + Is_Running := True; end if; end Make_Running; procedure Make_Stopped is begin if not Is_Running then return;end if; - if WSACleanup = Socket_Error then - raise Claw.windows_error; -- to be caught by Shut_Down - end if; Is_Running := False; end Make_Stopped; end Winsock_Systems; diff -r f734a2862510 -r 2cca25a3f5f4 nc-sockets.ads --- a/nc-sockets.ads Tue Dec 21 19:45:44 2010 +0200 +++ b/nc-sockets.ads Wed Dec 22 18:05:52 2010 +0200 @@ -8,7 +8,7 @@ package NC.Sockets is package Claw renames NC; - pragma Link_With("libwsock32.a"); + -- pragma Link_With("libwsock32.a"); -- -- Edit History: -- @@ -746,13 +746,13 @@ Host_Address_List_Ptr : Host_Address_List_Ptr_Type; -- h_addr_list end record; for Hostents use record - Host_Name_Ptr at 0 range 0 .. 31; - Host_Alias_Ptr_List at 4 range 0 .. 31; - Host_Address_Kind at 8 range 0 .. 15; - Host_Address_Length at 10 range 0 .. 15; - Host_Address_List_Ptr at 12 range 0 .. 31; + Host_Name_Ptr at 0 range 0 .. 63; + Host_Alias_Ptr_List at 8 range 0 .. 63; + Host_Address_Kind at 16 range 0 .. 15; + Host_Address_Length at 18 range 0 .. 15; + Host_Address_List_Ptr at 20 range 0 .. 63; end record; - for Hostents'size use 16*8; + for Hostents'size use 224; type Hostent_Ptr_Type is access all HOSTENTs; @@ -782,9 +782,9 @@ Last_Error_Code : Error_Codes := 0; end record; for W_Host_Info_Type use record - Hostent at 0 range 0 .. 16*8-1; - Data_Area at 16 range 0 .. (MAXGETHOSTSTRUCT-16)*8-1; - Last_Error_Code at MAXGETHOSTSTRUCT range 0 .. 31; + Hostent at 0 range 0 .. 224-1; + Data_Area at 32 range 0 .. (MAXGETHOSTSTRUCT-16)*8-1; + Last_Error_Code at (MAXGETHOSTSTRUCT+32) range 0 .. 31; end record; procedure Copy_Host_Info(Source : in W_Host_Info_Type; @@ -800,16 +800,15 @@ package Low_Level is use type Claw.Int; - function WSAGetLastError return Error_Codes; - pragma Import(Stdcall, WSAGetLastError, "WSAGetLastError"); + -- function WSAGetLastError return Error_Codes; function gethostbyname(name: NC.lpcstr) return Hostent_Ptr_Type; - pragma Import(Stdcall, gethostbyname, "gethostbyname"); + pragma Import(C, gethostbyname, "gethostbyname"); function gethostbyaddr(addr: access Network_Address_Type; len : Claw.Int := Network_Address_Type'size/8; kind : Claw.Int := PF_Inet) return Hostent_Ptr_Type; - pragma Import(Stdcall, gethostbyaddr, "gethostbyaddr"); + pragma Import(C, gethostbyaddr, "gethostbyaddr"); WSADescription_Len : constant := 256; WSASys_Status_Len : constant := 128; @@ -829,21 +828,13 @@ szSystemStatus at 261 range 0 .. 129*8-1; iMaxSockets at 390 range 0 .. 15; iMaxUdpDg at 392 range 0 .. 15; - lpVendorInfo at 394 range 0 .. 31; + lpVendorInfo at 394 range 0 .. 63; end record; - for WSADatas'size use 398*8; - - function WSAStartup (wVersionRequired : NC.word; - lpWSAData : access WSADatas) - return Error_Codes; - pragma Import(Stdcall, WSAStartup, "WSAStartup"); - - function WSACleanup return Claw.Int; - pragma Import(Stdcall, WSACleanup, "WSACleanup"); + for WSADatas'size use 3216; function gethostname(Name : NC.lpcstr; Length : Claw.Int) return Claw.Int; - pragma Import(Stdcall, gethostname, "gethostname"); + pragma Import(C, gethostname, "gethostname"); type Address_Family_Type is new Claw.short; AF_INET : constant Address_Family_Type := 2; @@ -851,7 +842,7 @@ type Network_Port_Type is new NC.word; -- network byte order function htons(hostshort: Port_Type) return Network_Port_Type; - pragma Import(Stdcall, htons, "htons"); + pragma Import(C, htons, "htons"); type SOCKADDR_INs is record Family : Address_Family_Type := AF_INET; @@ -863,32 +854,32 @@ for SOCKADDR_INs use record Family at 0 range 0 .. 15; Port at 2 range 0 .. 15; - Address at 4 range 0 .. 31; - Extra at 8 range 0 .. 8*8-1; + Address at 4 range 0 .. 63; + Extra at 12 range 0 .. 8*8-1; end record; - for SOCKADDR_INs'size use 16*8; + for SOCKADDR_INs'size use 160; function Connect(S : Socket_Handles; Name : access SOCKADDR_INs; Length : Claw.Int := SOCKADDR_INs'size/8) return Claw.Int; - pragma Import(Stdcall, Connect, "connect"); + pragma Import(C, Connect, "connect"); function Bind(S : Socket_Handles; Address : access SOCKADDR_INs; Length : Claw.Int := SOCKADDR_INs'size/8) return Claw.Int; - pragma Import(Stdcall, Bind, "bind"); + pragma Import(C, Bind, "bind"); function Listen(S : Socket_Handles; Q_Length : Claw.Int) return Claw.Int; - pragma Import(Stdcall, Listen, "listen"); + pragma Import(C, Listen, "listen"); function Accept_function(S : Socket_Handles; Address : access SOCKADDR_INs; Length : access Claw.Int) return Socket_Handles; - pragma Import(Stdcall, Accept_function, "accept"); + pragma Import(C, Accept_function, "accept"); type Protocol_Type is new Claw.Int; Ipproto_TCP : constant Protocol_Type := 6; @@ -898,7 +889,7 @@ Kind : Sock_Type; Protocol: Protocol_Type) return Socket_Handles; - pragma Import(Stdcall, Socket_function, "socket"); + pragma Import(C, Socket_function, "socket"); FD_SETSIZE : constant := 64; @@ -932,10 +923,10 @@ Exceptions_FD_Set : access FD_SET_Type; Timeout : access Timeval_Type) return Claw.Int; - pragma Import(Stdcall, Select_function, "select"); + pragma Import(C, Select_function, "select"); function closesocket(s: Socket_Handles) return Claw.Int; - pragma Import(Stdcall, closesocket, "closesocket"); + pragma Import(C, closesocket, "close"); function recv( s : Socket_Handles; @@ -943,7 +934,7 @@ Len : Claw.Int; Flags: Claw.Int) return Claw.Int; - pragma Import(Stdcall, recv, "recv"); + pragma Import(C, recv, "recv"); function recvfrom( s : Socket_Handles; @@ -953,7 +944,7 @@ Name : access SOCKADDR_INs; Length : access Claw.Int) return Claw.Int; - pragma Import(Stdcall, recvfrom, "recvfrom"); + pragma Import(C, recvfrom, "recvfrom"); function send( s : Socket_Handles; @@ -961,7 +952,7 @@ Len : Claw.Int; Flags: Claw.Int) return Claw.Int; - pragma Import(Stdcall, send, "send"); + pragma Import(C, send, "send"); function sendto( s : Socket_Handles; @@ -971,7 +962,7 @@ Name : access SOCKADDR_INs; Length : Claw.Int := SOCKADDR_INs'size/8) return Claw.Int; - pragma Import(Stdcall, sendto, "sendto"); + pragma Import(C, sendto, "sendto"); type Event_Type is new Claw.uint; FD_READ_Event : constant Event_Type := 1; @@ -984,12 +975,12 @@ function getpeername(s : Socket_Handles; Address: access SOCKADDR_INs; Length : access Claw.Int) return Claw.Int; - pragma Import(Stdcall, getpeername, "getpeername"); + pragma Import(C, getpeername, "getpeername"); function getsockname(s : Socket_Handles; Address: access SOCKADDR_INs; Length : access Claw.Int) return Claw.Int; - pragma Import(Stdcall, getsockname, "getsockname"); + pragma Import(C, getsockname, "getsockname"); type ioctl_cmd_type is new Claw.DWord; @@ -998,7 +989,7 @@ function ioctlsocket(s : Socket_Handles; cmd : ioctl_cmd_type; arg : access Claw.DWord) return Claw.Int; - pragma Import(Stdcall, ioctlsocket, "ioctlsocket"); + pragma Import(C, ioctlsocket, "ioctl"); end Low_Level; diff -r f734a2862510 -r 2cca25a3f5f4 nc.ads --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/nc.ads Wed Dec 22 18:05:52 2010 +0200 @@ -0,0 +1,19 @@ +with Interfaces.C; +package NC is + type Short is new Interfaces.C.Short; + type Int is new Interfaces.C.Int; + subtype Natural_Int is Int range 0 .. Int'last; + type UInt is new Interfaces.C.Unsigned; + type DWord is new Interfaces.C.Unsigned_Long; + + type Byte is range 0 .. 255; + for Byte'size use 8; + type Word is mod 2**16; + for Word'size use 16; + + Windows_Error, + Not_Valid_Error, + Already_Valid_Error, + Not_Found_Error : Exception; + type Lpcstr is access all Interfaces.C.Char; +end NC; -- Tero Koskinen - http://iki.fi/tero.koskinen/ ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-25 15:12 ` Tero Koskinen @ 2011-05-25 18:43 ` Tero Koskinen 2011-05-25 19:08 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 121+ messages in thread From: Tero Koskinen @ 2011-05-25 18:43 UTC (permalink / raw) On Wed, 25 May 2011 18:12:52 +0300 Tero Koskinen wrote: > Hi, > > On Tue, 24 May 2011 06:11:43 +0000 (UTC) tmoran@acm.org wrote: > > A thicker binding is NC sockets ("Not Claw", derived from Claw.Sockets). > > It's nc.zip at www.adaworld.com, look there under > > Ada Projects/Ada Internet Projects/Internet Protocols > > It's for Windows but IIRC the WSAStartup and WSACleanup should be > > the only Windows specific things. > > Here is a diff which allows the package to compile on OpenBSD/amd64. It seems that you need to tailor NC.sockets for every operating system separately. I created a Mercurial repository https://bitbucket.org/tkoskine/not-claw-sockets-linux-x86 which contains Linux/x86 version of NC.sockets. At the moment getjpg example compiles and connection is opened, but for some reason there is no data read (or send). I guess I need to open wireshark and debug a little more... -- Tero Koskinen - http://iki.fi/tero.koskinen/ ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-25 18:43 ` Tero Koskinen @ 2011-05-25 19:08 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-25 19:08 UTC (permalink / raw) Le Wed, 25 May 2011 20:43:35 +0200, Tero Koskinen <tero.koskinen@iki.fi> a écrit: > It seems that you need to tailor NC.sockets for every operating system Just like it is with every binding to low level stuff, indeed. > At the moment getjpg example compiles and connection is opened, > but for some reason there is no data read (or send). I guess > I need to open wireshark and debug a little more... You can avoid going so much further: "metsun1.met.sjsu.edu" is simply not valid any more ;) (this redirect to the root domain, the sub-domain has gone) -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 1:22 Why no socket package in the standard ? Yannick Duchêne (Hibou57) 2011-05-24 1:39 ` Yannick Duchêne (Hibou57) @ 2011-05-24 6:24 ` georg bauhaus 2011-05-24 7:07 ` Maciej Sobczak 2011-05-24 19:17 ` Yannick Duchêne (Hibou57) 2011-05-24 12:38 ` AdaMagica ` (2 subsequent siblings) 4 siblings, 2 replies; 121+ messages in thread From: georg bauhaus @ 2011-05-24 6:24 UTC (permalink / raw) Yannick Duchêne (Hibou57 ) <yannick_duchene@yahoo.fr> wrote: > Hello one again, > > According to > http://www.ibm.com/developerworks/linux/library/l-sockpit/ > > First introduced into the 4.2 BSD UNIX® operating system, > > the Sockets API is now a standard feature of any operating system.In > > > > fact, it's hard to find a modern language that doesn'tsupport the > > Sockets API. > > This may help Ada (and be useful too) to add sockets in standard > packages. Two questions: Which modern, post 1990, language supports sockets in the language? Which language supports features of modern file storage? (That is, file attributes, files as documents (standardized ca. 1984),... ) Note that these capabilities are available with file archives, too. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 6:24 ` georg bauhaus @ 2011-05-24 7:07 ` Maciej Sobczak 2011-05-24 7:19 ` Thomas Løcke 2011-05-24 7:25 ` Dmitry A. Kazakov 2011-05-24 19:17 ` Yannick Duchêne (Hibou57) 1 sibling, 2 replies; 121+ messages in thread From: Maciej Sobczak @ 2011-05-24 7:07 UTC (permalink / raw) On 24 Maj, 08:24, georg bauhaus <rmhost.bauh...@maps.arcor.de> wrote: > Which modern, post 1990, language supports sockets in the language? In the language? Probably none, as this does not belong to the language. It might, however, be part of the standard library. Java, C# (.NET), Python, etc. are easy examples of more or less recent languages that support sockets in their standard libraries. -- Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 7:07 ` Maciej Sobczak @ 2011-05-24 7:19 ` Thomas Løcke 2011-05-24 7:35 ` Ludovic Brenta 2011-05-24 10:00 ` Georg Bauhaus 2011-05-24 7:25 ` Dmitry A. Kazakov 1 sibling, 2 replies; 121+ messages in thread From: Thomas Løcke @ 2011-05-24 7:19 UTC (permalink / raw) On 05/24/2011 09:07 AM, Maciej Sobczak wrote: > Java, C# (.NET), Python, etc. are easy examples of more or less recent > languages that support sockets in their standard libraries. And, for what it is worth, PHP. -- Thomas L�cke Email: tl at ada-dk.org Web: http//:ada-dk.org http://identi.ca/thomaslocke ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 7:19 ` Thomas Løcke @ 2011-05-24 7:35 ` Ludovic Brenta 2011-05-24 10:00 ` Georg Bauhaus 1 sibling, 0 replies; 121+ messages in thread From: Ludovic Brenta @ 2011-05-24 7:35 UTC (permalink / raw) Thomas Løcke wrote on comp.lang.ada: > On 05/24/2011 09:07 AM, Maciej Sobczak wrote: >> Java, C# (.NET), Python, etc. are easy examples of more or less recent >> languages that support sockets in their standard libraries. > > And, for what it is worth, PHP. I didn't know these languages even had a standard. OK, C# has one but I couldn't find anything about sockets in Partition IV of ECMA 335; it does mention a "Network Library" but I couldn't find its definition. Anyway, FWIW, GNAT has GNAT.Sockets out of the box. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 7:19 ` Thomas Løcke 2011-05-24 7:35 ` Ludovic Brenta @ 2011-05-24 10:00 ` Georg Bauhaus 2011-05-24 12:53 ` Dmitry A. Kazakov 2011-05-24 19:38 ` Yannick Duchêne (Hibou57) 1 sibling, 2 replies; 121+ messages in thread From: Georg Bauhaus @ 2011-05-24 10:00 UTC (permalink / raw) On 24.05.11 09:19, Thomas Løcke wrote: > On 05/24/2011 09:07 AM, Maciej Sobczak wrote: >> Java, C# (.NET), Python, etc. are easy examples of more or less recent >> languages that support sockets in their standard libraries. > > > And, for what it is worth, PHP. and Pike [*], (and CSNOBOL-4 [**]), and anything supported by SWIG, and Haskell [***] and ... 1. The reason simply is that each and every of them has started by offering some glue code for the BSD/POSIX socket functions. .NET languages will likely just use a .NET class. But there have been and will be difficulties when porting the languages' alleged "standard" libraries to non-POSIX (or non-.NET) operating systems. Perhaps the difficulties are even conceptual ones whenever POSIX sockets don't really meet the networking requirements. Define Commercially_Important_Platforms := { ∃ target | POSIX(target) IN { False, True } } How large is the subset defined by POSIX(target) = False? Is POSIX/Sockets the best Ada solution when this is the case? 2. In the light of Ada's history regarding standardization, there is, I believe, networking knowledge that warrants more than canonization of a practical workaround---which might fail if requirements are actually different. Opposing a get-that-duct-tape-solution-out–the-door style for standardization, I'd imagine starting from questions like the following and then weigh POSIX sockets as the possible answer: - What should programs be able to do when communicating data along some network connection? - Should there be a layered approach? How much detail? - Where in the language will this integrate nicely? (E.g. package structure? What types if any? Or anything that has already been mentioned.) - Is sockets the right approach? Consider Erlang! - Is sockets the right approach? Consider a CAN! I doubt that the best answer to these questions can be summed up by saying, "Mirror Posix sockets!". ___ [*] http://pike.ida.liu.se/generated/manual/modref/ex/predef_3A_3A/Stdio/Port.html [**] http://www.snobol4.org/csnobol4/curr/doc/snobol4.html [***] "Haskell's networking functions almost always correspond directly to familiar C function calls." http://book.realworldhaskell.org/read/sockets-and-syslog.html ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 10:00 ` Georg Bauhaus @ 2011-05-24 12:53 ` Dmitry A. Kazakov 2011-05-24 14:28 ` Georg Bauhaus 2011-05-24 19:38 ` Yannick Duchêne (Hibou57) 1 sibling, 1 reply; 121+ messages in thread From: Dmitry A. Kazakov @ 2011-05-24 12:53 UTC (permalink / raw) On Tue, 24 May 2011 12:00:24 +0200, Georg Bauhaus wrote: > Opposing a get-that-duct-tape-solution-out嚙碾the-door style for > standardization, I'd imagine starting from questions like the > following and then weigh POSIX sockets as the possible answer: > > - What should programs be able to do when communicating data > along some network connection? Well, this has nothing to do with sockets. Communication between programs is distribution, the annex E. Sockets are a about communication to the hardware, even if the other side is actually a program. > - Should there be a layered approach? How much detail? This is the above question again. If distribution meant, there is the program (application) level only. Then the question is not about the levels, but about the architecture of such communication (object vs event vs procedural vs data views etc) > - Where in the language will this integrate nicely? > (E.g. package structure? What types if any? Or anything > that has already been mentioned.) > > - Is sockets the right approach? Consider Erlang! An approach to what? > - Is sockets the right approach? Consider a CAN! CAN is not stream- or packet-oriented, not even Ethernet. Even Ethernet-based protocols, such as EtherCAT are have nothing to do with sockets. So are the protocols which actually use TCP/IP or UDP as a transport, e.g. ModBus, XCP etc. And for all of then (even for CAN, if talking about CAN Open) data exchange (the only thing sockets offer) is the least problem. Blurring transport and application level issues does not help. You seem to imply that there could be an application level solution. A much more moderate goal to standardize sockets is very difficult. > I doubt that the best answer to these questions can > be summed up by saying, "Mirror Posix sockets!". What was the question? (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 12:53 ` Dmitry A. Kazakov @ 2011-05-24 14:28 ` Georg Bauhaus 2011-05-24 14:59 ` Dmitry A. Kazakov 2011-05-24 23:20 ` Yannick Duchêne (Hibou57) 0 siblings, 2 replies; 121+ messages in thread From: Georg Bauhaus @ 2011-05-24 14:28 UTC (permalink / raw) On 24.05.11 14:53, Dmitry A. Kazakov wrote: > On Tue, 24 May 2011 12:00:24 +0200, Georg Bauhaus wrote: > >> Opposing a get-that-duct-tape-solution-out嚙碾the-door style for >> standardization, I'd imagine starting from questions like the >> following and then weigh POSIX sockets as the possible answer: >> >> - What should programs be able to do when communicating data >> along some network connection? > > Well, this has nothing to do with sockets. It hasn't. (My point.) > Communication between programs > is distribution, the annex E. Yes. If the endpoints of communication are Ada partitions. Otherwise ...? > Sockets are a about communication to the > hardware, even if the other side is actually a program. From a programmer perspective, sockets may well be about how to send a String value to some "Port" on some "machine" identifiable via DNS. No hardware in sight from this viewpoint. Whereas network communication may well be different, as you have outlined. >> - Should there be a layered approach? How much detail? > > This is the above question again. If distribution meant, there is the > program (application) level only. Then the question is not about the > levels, but about the architecture of such communication (object vs event > vs procedural vs data views etc) Yes. >> - Is sockets the right approach? Consider Erlang! > > An approach to what? A more general approach to sending data around. That's what socket programs do very frequently, I think, at least when they stream text, for example. From the programmer's point of view, they use text based protocols. Not datagrams or packages or anything. This defines one use case of (technically sockets based) data communication. Why insist on sockets, then? >> - Is sockets the right approach? Consider a CAN! > > CAN is not stream- or packet-oriented, not even Ethernet. Even > Ethernet-based protocols, such as EtherCAT are have nothing to do with > sockets. Which is why I had hoped to remind that Ada programs, even when operating a network, might not profit at all from a standard sockets package, if they do not use sockets, but do control networked communication. > Blurring transport and application level issues does not help. Yes. But at least we might try to learn, for the purpose of standardization, what a typical transport level issue is versus what an application level issue is---not so much about how solutions are built around sockets whenever these happen to be available. Standards work seems a good opportunity to isolate, in abstract terms, what a transport level issue is. (And what it might or might not have to do with Ada, or sockets, see below.) If these issues are central to Ada programming, and future-proof, there might be funding for isolating a few requirements. Then start from these requirements. Or, if sockets are as important as, say, timers, or windows---if they are important, then enlighten industry (or govt.) that they have the power to ask for compiler-independent packages. These would not even need ISO standardization, just compiler independence, to be used by industry. No one else has the power. Consider libraries like public roads or not-so-public infrastructure that everyone needs. Remembering industry's built-in rewards system for anti-co-operation, its power to influence the software makers towards generally useful packages is unlikely to be employed, though. (Packages that could be used with a different compiler! By a different company!?) >> I doubt that the best answer to these questions can >> be summed up by saying, "Mirror Posix sockets!". > > What was the question? (:-)) The original question was, "Why no socket package in the standard?". Let me rephrase it: "Why no ISO/IEC 14519:2001 package in the standard?" I believe there was a preliminary answer to the latter question that might show the first in a new light. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 14:28 ` Georg Bauhaus @ 2011-05-24 14:59 ` Dmitry A. Kazakov 2011-05-24 16:07 ` Adam Beneschan ` (2 more replies) 2011-05-24 23:20 ` Yannick Duchêne (Hibou57) 1 sibling, 3 replies; 121+ messages in thread From: Dmitry A. Kazakov @ 2011-05-24 14:59 UTC (permalink / raw) On Tue, 24 May 2011 16:28:32 +0200, Georg Bauhaus wrote: > On 24.05.11 14:53, Dmitry A. Kazakov wrote: >> >> Communication between programs >> is distribution, the annex E. > > Yes. If the endpoints of communication are Ada partitions. > Otherwise ...? Non-Ada programs = non-programs. No offence to other languages meant, it is just so that we cannot communicate them at this height of abstraction level. >> Sockets are a about communication to the >> hardware, even if the other side is actually a program. > > From a programmer perspective, sockets may well be about > how to send a String value to some "Port" on some > "machine" identifiable via DNS. That is not Ada's programmer perspective. A value has the type. This type is an Ada type, otherwise we are back to the hardware level of bits and bytes. > No hardware in sight from this viewpoint. See above. >>> - Is sockets the right approach? Consider Erlang! >> >> An approach to what? > > A more general approach to sending data around. Data are meaningless (We had this discussion before). Meaningful is distribution and that is the annex E. > Why insist on sockets, then? Because sockets is the most widely used transport. >> Blurring transport and application level issues does not help. > > Yes. But at least we might try to learn, for the purpose of standardization, > what a typical transport level issue is versus what an application level issue > is---not so much about how solutions are built around sockets whenever > these happen to be available. Standards work seems a good opportunity > to isolate, in abstract terms, what a transport level issue is. I don't see how standards from the areas, where mentioned by you CAN is applied, could help. > If these issues are central to Ada programming, and future-proof, > there might be funding for isolating a few requirements. Then start > from these requirements. From CAN Open, ASAP, ASAM etc? Are you kidding? > Or, if sockets are as important as, say, timers, or windows---if they > are important, then enlighten industry (or govt.) that they have the power > to ask for compiler-independent packages. Sockets are more or less realistic to support at the standard's level, though very difficult. >>> I doubt that the best answer to these questions can >>> be summed up by saying, "Mirror Posix sockets!". >> >> What was the question? (:-)) > > The original question was, "Why no socket package in the standard?". > > Let me rephrase it: "Why no ISO/IEC 14519:2001 package in the standard?" I cannot say. I do not care much about POSIX, maybe, others do not either. Why is it relevant to sockets? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 14:59 ` Dmitry A. Kazakov @ 2011-05-24 16:07 ` Adam Beneschan 2011-05-24 19:21 ` Dmitry A. Kazakov 2011-05-25 0:21 ` Yannick Duchêne (Hibou57) 2011-05-24 16:10 ` Georg Bauhaus 2011-05-25 0:57 ` Yannick Duchêne (Hibou57) 2 siblings, 2 replies; 121+ messages in thread From: Adam Beneschan @ 2011-05-24 16:07 UTC (permalink / raw) On May 24, 7:59 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > On Tue, 24 May 2011 16:28:32 +0200, Georg Bauhaus wrote: > > On 24.05.11 14:53, Dmitry A. Kazakov wrote: > > >> Communication between programs > >> is distribution, the annex E. > > > Yes. If the endpoints of communication are Ada partitions. > > Otherwise ...? > > Non-Ada programs = non-programs. No offence to other languages meant, it is > just so that we cannot communicate them at this height of abstraction > level. What do you mean by "this height"? What height? From what I can tell, figuring out the correct level of abstraction is still part of the problem, a part that needs a lot of thought. Being able to communicate with programs written in other languages *is* a need, and I think that any package that would become part of the Ada standard would have to meet that need. And I think it could be done with some level of abstraction, i.e. with more than just a thin binding to the Unix socket library, and in a way that allows for different communications mechanisms than just sockets. (I have some experience with this. I wrote a message-communication package that had two different bodies, one that implemented the messages with VMS mailboxes, and another that used sockets to communicate with a Solaris host. This was due to requirements imposed by the customer, and it was set up to communicate specifically with a program written by the customer. But the package specification was the same in both cases and was general enough that I was able to reuse it for other purposes. So I'm convinced this is doable, but difficult to do in a way that will meet the needs of as many users as possible.) -- Adam ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 16:07 ` Adam Beneschan @ 2011-05-24 19:21 ` Dmitry A. Kazakov 2011-05-25 0:53 ` Yannick Duchêne (Hibou57) 2011-05-25 0:21 ` Yannick Duchêne (Hibou57) 1 sibling, 1 reply; 121+ messages in thread From: Dmitry A. Kazakov @ 2011-05-24 19:21 UTC (permalink / raw) On Tue, 24 May 2011 09:07:42 -0700 (PDT), Adam Beneschan wrote: > On May 24, 7:59�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: >> On Tue, 24 May 2011 16:28:32 +0200, Georg Bauhaus wrote: >>> On 24.05.11 14:53, Dmitry A. Kazakov wrote: >> >>>> Communication between programs >>>> is distribution, the annex E. >> >>> Yes. �If the endpoints of communication are Ada partitions. >>> Otherwise ...? >> >> Non-Ada programs = non-programs. No offence to other languages meant, it is >> just so that we cannot communicate them at this height of abstraction >> level. > > What do you mean by "this height"? What height? From what I can > tell, figuring out the correct level of abstraction is still part of > the problem, a part that needs a lot of thought. Whatever level it might be, it cannot be lower than the language level (Ada is a higher level typed language). > Being able to communicate with programs written in other languages > *is* a need, and I think that any package that would become part of > the Ada standard would have to meet that need. You cannot do that in a standard way because many of not most other language do not have means for that. This is why lower level protocols are used, e.g. sockets. > And I think it could > be done with some level of abstraction, i.e. with more than just a > thin binding to the Unix socket library, and in a way that allows for > different communications mechanisms than just sockets. (I have some > experience with this. I wrote a message-communication package that > had two different bodies, one that implemented the messages with VMS > mailboxes, and another that used sockets to communicate with a Solaris > host. This was due to requirements imposed by the customer, and it > was set up to communicate specifically with a program written by the > customer. But the package specification was the same in both cases > and was general enough that I was able to reuse it for other > purposes. So I'm convinced this is doable, but difficult to do in a > way that will meet the needs of as many users as possible.) If there were some messaging standard that could be done. Still that would not make it communication with programs, because messages are not much higher level than streams. The RPCs are higher. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 19:21 ` Dmitry A. Kazakov @ 2011-05-25 0:53 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-25 0:53 UTC (permalink / raw) Le Tue, 24 May 2011 21:21:43 +0200, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> a écrit: >> Being able to communicate with programs written in other languages >> *is* a need, and I think that any package that would become part of >> the Ada standard would have to meet that need. > > You cannot do that in a standard way because many of not most other > language do not have means for that. This is why lower level protocols > are used, e.g. sockets. Right. Ada has provisions to do it a cleaner (and less one-arbitrary-technology-tied) way. -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 16:07 ` Adam Beneschan 2011-05-24 19:21 ` Dmitry A. Kazakov @ 2011-05-25 0:21 ` Yannick Duchêne (Hibou57) 2011-05-25 11:25 ` Peter C. Chapin 1 sibling, 1 reply; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-25 0:21 UTC (permalink / raw) Le Tue, 24 May 2011 18:07:42 +0200, Adam Beneschan <adam@irvine.com> a écrit: > What do you mean by "this height"? What height? From what I can > tell, figuring out the correct level of abstraction is still part of > the problem, a part that needs a lot of thought. Indeed, communication with the outside world, is a master concern for a program. I do not see a reason why this should be restricted to files and pipes as it is actually in the Ada standard. This is not an option, this is a requirement. > Being able to communicate with programs written in other languages > *is* a need, and I think that any package that would become part of > the Ada standard would have to meet that need. And I think it could > be done with some level of abstraction, i.e. with more than just a > thin binding to the Unix socket library, and in a way that allows for > different communications mechanisms than just sockets. As I replied to Georg, I agree too with the need of more abstraction (that's a good idea). I came to start with sockets, because this is actually the first and straightforward thing you think about when you have that need. But I agree more abstraction would be welcome, as limiting this to sockets, would be as much a damage, as the lack of support for communication beyond files. > (I have some > experience with this. I wrote a message-communication package that > had two different bodies, one that implemented the messages with VMS > mailboxes, and another that used sockets to communicate with a Solaris > host. This was due to requirements imposed by the customer, and it > was set up to communicate specifically with a program written by the > customer. But the package specification was the same in both cases > and was general enough that I was able to reuse it for other > purposes. So I'm convinced this is doable, but difficult to do in a > way that will meet the needs of as many users as possible.) > > -- Adam Well, what would you think about these abstract properties (I will talk about channels, to use a term introduced bu Georg after Erlang concepts) : * A channel may be data conservative or non-conservative - Conservative: all data sent between peers will be received - Non-Conservative: some data sent between peers may be lost. - Socket analogy: TCP vs UDP * A channel may be relative time conservative or non-conservative - Conservative: any data chunk sent after a previous one, will arrive after that previous one. - Non-Conservative: data chunk sent after a previous one, may be received at the same time as the previous after it was delayed as well after the previous. - Socket analogy: the Nagle algorithm is disabled vs enabled. * A channel may act as a sequence or as a kind of set - As a sequence: data arrives in the same order as sent. - As a set: data arrives in any order, order does not matter. - Socket analogy: TCP vs UDP (not a perfect analogy for UDP). * A channel with the “sequence” property and the “relative time conservative” property, may be either have real-time requirement or not have real time requirement. * A channel may have a global or a local identity (global or local, is a property of the identity). * A channel identity may have aliases (which would not be required, there could be only one), and during one session, only one of its identifier would be the canonical one (luckily, otherwise this would be mess-prone). Honestly, this aspect seems a bit tricky to me. I still have questions about blocking/non-blocking, although task would probably be involved here (any way, Ada already allows I/O to be potentially blocking). What about this first draft of a draft ? :) -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-25 0:21 ` Yannick Duchêne (Hibou57) @ 2011-05-25 11:25 ` Peter C. Chapin 0 siblings, 0 replies; 121+ messages in thread From: Peter C. Chapin @ 2011-05-25 11:25 UTC (permalink / raw) On Wed, 25 May 2011 02:21:26 +0200, Yannick Duchêne (Hibou57) wrote: > Indeed, communication with the outside world, is a master concern for a > program. I do not see a reason why this should be restricted to files > and pipes as it is actually in the Ada standard. This is not an option, > this is a requirement. You asked originally why there is no support for sockets in the Ada standard itself (as opposed to an auxiliary operating system standard). I think the length of this thread is your answer: it's a contentious issue. There are just so many ways to deal with network communication that it's very unclear how one would standardize it at the language or standard library level. Files are a bit different since most systems support files in a similar way... at least when it comes to the basics. Even with files, however, issues arise. Peter ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 14:59 ` Dmitry A. Kazakov 2011-05-24 16:07 ` Adam Beneschan @ 2011-05-24 16:10 ` Georg Bauhaus 2011-05-24 19:36 ` Dmitry A. Kazakov 2011-05-25 0:57 ` Yannick Duchêne (Hibou57) 2 siblings, 1 reply; 121+ messages in thread From: Georg Bauhaus @ 2011-05-24 16:10 UTC (permalink / raw) On 24.05.11 16:59, Dmitry A. Kazakov wrote: > On Tue, 24 May 2011 16:28:32 +0200, Georg Bauhaus wrote: > >> On 24.05.11 14:53, Dmitry A. Kazakov wrote: >>> >>> Communication between programs >>> is distribution, the annex E. >> >> Yes. If the endpoints of communication are Ada partitions. >> Otherwise ...? > > Non-Ada programs = non-programs. No offence to other languages meant, it is > just so that we cannot communicate them at this height of abstraction > level. But we do have an ORB style of distribution; and since ORBs can be language neutral, Non-Ada programs might be programs, again. >> From a programmer perspective, sockets may well be about >> how to send a String value to some "Port" on some >> "machine" identifiable via DNS. > > That is not Ada's programmer perspective. OK. >> If these issues are central to Ada programming, and future-proof, >> there might be funding for isolating a few requirements. Then start >> from these requirements. > > From CAN Open, ASAP, ASAM etc? Are you kidding? No, I mean transport as a concept, considering pay load, buffers, timeouts, latency; interaction with possible RTSs; things that matter to programming the level in question. E.g., is there anything special regarding interrupt handling when it comes to receiving data? (Likely not, I think?) >> The original question was, "Why no socket package in the standard?". >> >> Let me rephrase it: "Why no ISO/IEC 14519:2001 package in the standard?" > > I cannot say. I do not care much about POSIX, maybe, others do not either. > Why is it relevant to sockets? http://www.cs.scranton.edu/~beidler/Ada/posix/posix-sockets-internet.html Or so I thought, at least. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 16:10 ` Georg Bauhaus @ 2011-05-24 19:36 ` Dmitry A. Kazakov 0 siblings, 0 replies; 121+ messages in thread From: Dmitry A. Kazakov @ 2011-05-24 19:36 UTC (permalink / raw) On Tue, 24 May 2011 18:10:49 +0200, Georg Bauhaus wrote: > On 24.05.11 16:59, Dmitry A. Kazakov wrote: >> On Tue, 24 May 2011 16:28:32 +0200, Georg Bauhaus wrote: >> >>> On 24.05.11 14:53, Dmitry A. Kazakov wrote: >>>> >>>> Communication between programs >>>> is distribution, the annex E. >>> >>> Yes. If the endpoints of communication are Ada partitions. >>> Otherwise ...? >> >> Non-Ada programs = non-programs. No offence to other languages meant, it is >> just so that we cannot communicate them at this height of abstraction >> level. > > But we do have an ORB style of distribution; and since ORBs > can be language neutral, Non-Ada programs might be programs, > again. Yes. That would be a very different level, and usage under 1%. >>> If these issues are central to Ada programming, and future-proof, >>> there might be funding for isolating a few requirements. Then start >>> from these requirements. >> >> From CAN Open, ASAP, ASAM etc? Are you kidding? > > No, I mean transport as a concept, considering pay load, > buffers, timeouts, latency; interaction with possible RTSs; > things that matter to programming the level in question. > E.g., is there anything special regarding interrupt handling > when it comes to receiving data? (Likely not, I think?) Those look non-functional (QoS etc). What about starting with the functional part. That looks pretty weak. >>> The original question was, "Why no socket package in the standard?". >>> >>> Let me rephrase it: "Why no ISO/IEC 14519:2001 package in the standard?" >> >> I cannot say. I do not care much about POSIX, maybe, others do not either. >> Why is it relevant to sockets? > > http://www.cs.scranton.edu/~beidler/Ada/posix/posix-sockets-internet.html > > Or so I thought, at least. I see, you meant POSIX sockets. BTW, IPPROTO_RAW does not work under Windows (I didn't test VxWorks). Does it mean that Ada standard should require RTL to provide an NDIS to hack that? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 14:59 ` Dmitry A. Kazakov 2011-05-24 16:07 ` Adam Beneschan 2011-05-24 16:10 ` Georg Bauhaus @ 2011-05-25 0:57 ` Yannick Duchêne (Hibou57) 2 siblings, 0 replies; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-25 0:57 UTC (permalink / raw) Le Tue, 24 May 2011 16:59:52 +0200, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> a écrit: >> Let me rephrase it: "Why no ISO/IEC 14519:2001 package in the standard?" > > I cannot say. I do not care much about POSIX Me too. To care about POSIX and to care about IPC (remote included) are two disjoint matters (you may care to both, just one, or none, these are not correlated). -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 14:28 ` Georg Bauhaus 2011-05-24 14:59 ` Dmitry A. Kazakov @ 2011-05-24 23:20 ` Yannick Duchêne (Hibou57) 2011-05-25 0:32 ` Georg Bauhaus 2011-05-25 7:52 ` Dmitry A. Kazakov 1 sibling, 2 replies; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-24 23:20 UTC (permalink / raw) Le Tue, 24 May 2011 16:28:32 +0200, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> a écrit: > From a programmer perspective, sockets may well be about > how to send a String value to some "Port" on some > "machine" identifiable via DNS. Not only, the concern is also about the protocol behavior, that is mainly reliable/non-reliable, stream/non-stream. What make the difference between stream and non-stream, is the reliability… TCP/IP is looking like a PIPE, except for its identity, UDP/IP is not. > A more general approach to sending data around. That's what socket > programs do very frequently, I think, at least when they stream text, > for example. From the programmer's point of view, they use text based > protocols. Not datagrams or packages or anything. This defines one use > case of (technically sockets based) data communication. I do not see what fund your proclamation “Not datagrams or packages or anything”. UDP is really used when it does not matter a lot when some data is lost on reception or emission (used for example, for some kind of continuous real-time stream). > Why insist on sockets, then? Good question. May be talking about IPC would be wiser then. After all, IPC could be seen as a primitive for RPC, which Ada already talks about. > Which is why I had hoped to remind that Ada programs, even when > operating a network, might not profit at all from a standard sockets > package, if they do not use sockets, but do control networked > communication. Be pragmatic. Nothing is totally 0 or totally 1. The kind of application you are pointing, are the most rare, the one targeted by sockets, are the most common of the two. > Yes. But at least we might try to learn, for the purpose of > standardization, > what a typical transport level issue is versus what an application level > issue Reliability levels (and identity also). > is---not so much about how solutions are built around sockets whenever > these happen to be available. Standards work seems a good opportunity > to isolate, in abstract terms, what a transport level issue is. (And > what it > might or might not have to do with Ada, or sockets, see below.) :-) > If these issues are central to Ada programming, and future-proof, > there might be funding for isolating a few requirements. Then start > from these requirements. I welcome this “isolating a few requirements”, cause as replied elsewhere, some part of the BSD sockets would probably not be welcome (raw sockets). > Or, if sockets are as important as, say, timers, or windows---if they > are important, then enlighten industry (or govt.) that they have the > power > to ask for compiler-independent packages. These would not even > need ISO standardization, just compiler independence, to be used > by industry. May be an option, I agree. Still that as replied elsewhere, you still lack an answer to the other option : why would fund the rejection ? > No one else has the power. Pragmatism would suggest the community of active developers (proprietary or not). > Remembering industry's built-in rewards system for anti-co-operation, > its power to influence the software makers towards generally useful > packages is unlikely to be employed, though. (Packages that could > be used with a different compiler! By a different company!?) There is no way to be afraid of such things with sockets. Or do you see some ? > The original question was, "Why no socket package in the standard?". > > Let me rephrase it: "Why no ISO/IEC 14519:2001 package in the standard?" There is no way to rephrase it this way. POSIX is not comparable to sockets. -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 23:20 ` Yannick Duchêne (Hibou57) @ 2011-05-25 0:32 ` Georg Bauhaus 2011-05-25 0:49 ` Yannick Duchêne (Hibou57) ` (2 more replies) 2011-05-25 7:52 ` Dmitry A. Kazakov 1 sibling, 3 replies; 121+ messages in thread From: Georg Bauhaus @ 2011-05-25 0:32 UTC (permalink / raw) On 5/25/11 1:20 AM, Yannick Duchêne (Hibou57) wrote: >> Which is why I had hoped to remind that Ada programs, even when >> operating a network, might not profit at all from a standard sockets >> package, if they do not use sockets, but do control networked communication. > Be pragmatic. Nothing is totally 0 or totally 1. Bits are, in general, totally 0 or totally 1. > The kind of application you are pointing, are the most rare, Really? I understand that < 32 bits µcontrollers are the most widespread computer systems. Is it true that they use UDP, say, to send and receive signals along the wire, if any? >> Or, if sockets are as important as, say, timers, or windows---if they >> are important, then enlighten industry (or govt.) that they have the power >> to ask for compiler-independent packages. These would not even >> need ISO standardization, just compiler independence, to be used >> by industry. > May be an option, I agree. Still that as replied elsewhere, you still lack an answer to the other option : why would fund the rejection ? Why fund rejection? No money needed there. >> No one else has the power. > Pragmatism would suggest the community of active developers (proprietary or not). The community of active developers tends to be part of, and to be paid by, the industry (and govt.). Not every developer has the time, the resources, and the freedom to write the stuff that everyone needs. Things seem to go well as regards POSIX, likely including free software development. >> Remembering industry's built-in rewards system for anti-co-operation, >> its power to influence the software makers towards generally useful >> packages is unlikely to be employed, though. (Packages that could >> be used with a different compiler! By a different company!?) > There is no way to be afraid of such things with sockets. Or do you see some ? I wouldn't be surprised! >> The original question was, "Why no socket package in the standard?". >> >> Let me rephrase it: "Why no ISO/IEC 14519:2001 package in the standard?" > There is no way to rephrase it this way. POSIX is not comparable to sockets. Why? POSIX defines Socket, Socket Address, Connection, Datagram, etc. It has a section "Networking Services" that starts with "Sockets Overview". ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-25 0:32 ` Georg Bauhaus @ 2011-05-25 0:49 ` Yannick Duchêne (Hibou57) 2011-05-25 7:55 ` Pascal Obry 2011-05-25 8:05 ` Dmitry A. Kazakov 2 siblings, 0 replies; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-25 0:49 UTC (permalink / raw) Le Wed, 25 May 2011 02:32:36 +0200, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> a écrit: >> May be an option, I agree. Still that as replied elsewhere, you still >> lack an answer to the other option : why would fund the rejection ? > > Why fund rejection? No money needed there. Sorry, was mislead by a similar french word which has another meaning. I meant “what would base/justify the rejection” -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-25 0:32 ` Georg Bauhaus 2011-05-25 0:49 ` Yannick Duchêne (Hibou57) @ 2011-05-25 7:55 ` Pascal Obry 2011-05-25 8:38 ` Georg Bauhaus 2011-05-25 8:05 ` Dmitry A. Kazakov 2 siblings, 1 reply; 121+ messages in thread From: Pascal Obry @ 2011-05-25 7:55 UTC (permalink / raw) To: Georg Bauhaus Le 25/05/2011 02:32, Georg Bauhaus a écrit : > Bits are, in general, totally 0 or totally 1. Hum... Don't you remember the weak-bit from Copywrite tool that was able to write in a floppy disk a bit that could be 0 or 1. This was used as a software copy control at this time. Copywrite was able to mimic that to bypass the protection. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net - http://v2p.fr.eu.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver keys.gnupg.net --recv-key F949BD3B ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-25 7:55 ` Pascal Obry @ 2011-05-25 8:38 ` Georg Bauhaus 0 siblings, 0 replies; 121+ messages in thread From: Georg Bauhaus @ 2011-05-25 8:38 UTC (permalink / raw) On 5/25/11 9:55 AM, Pascal Obry wrote: > Le 25/05/2011 02:32, Georg Bauhaus a écrit : >> Bits are, in general, totally 0 or totally 1. > > Hum... Don't you remember the weak-bit from Copywrite tool that was able to write in a floppy disk a bit that could be 0 or 1. This was used as a software copy control at this time. Copywrite was able to mimic that to bypass the protection. These are tits, then, not bits. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-25 0:32 ` Georg Bauhaus 2011-05-25 0:49 ` Yannick Duchêne (Hibou57) 2011-05-25 7:55 ` Pascal Obry @ 2011-05-25 8:05 ` Dmitry A. Kazakov 2 siblings, 0 replies; 121+ messages in thread From: Dmitry A. Kazakov @ 2011-05-25 8:05 UTC (permalink / raw) On Wed, 25 May 2011 02:32:36 +0200, Georg Bauhaus wrote: > On 5/25/11 1:20 AM, Yannick Duch�ne (Hibou57) wrote: > >> The kind of application you are pointing, are the most rare, > > Really? I understand that < 32 bits �controllers are the most > widespread computer systems. Is it true that they use UDP, > say, to send and receive signals along the wire, if any? It is difficult to say. Modern protocols are such a huge complex mess, that TCP/IP stack were a minor concern here. In my experience UDP is pretty rare in process automation. For example XCP runs on top of UDP. TCP/IP is more widely used, but like UDP almost always with something on top of it, e.g. DLMS, ModBus etc. Anyway, I would like to stress that it is not data exchange which makes troubles. Before you get on data, you must configure the slaves. This stuff is in relation 90 to 10 (or more) to data exchange. So, if Ada standardized the exchange, that would be unusable anyway. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 23:20 ` Yannick Duchêne (Hibou57) 2011-05-25 0:32 ` Georg Bauhaus @ 2011-05-25 7:52 ` Dmitry A. Kazakov 1 sibling, 0 replies; 121+ messages in thread From: Dmitry A. Kazakov @ 2011-05-25 7:52 UTC (permalink / raw) On Wed, 25 May 2011 01:20:53 +0200, Yannick Duchêne (Hibou57) wrote: > What make the difference between > stream and non-stream, is the reliability… No, packets can be reliable as well. Stream enforces an sequential order on the data items. BTW, many, if not most industrial protocols, which use TCP/IP, add a packet layer on top of it. This makes packets reliable. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 10:00 ` Georg Bauhaus 2011-05-24 12:53 ` Dmitry A. Kazakov @ 2011-05-24 19:38 ` Yannick Duchêne (Hibou57) 2011-05-24 19:54 ` Ludovic Brenta ` (3 more replies) 1 sibling, 4 replies; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-24 19:38 UTC (permalink / raw) Le Tue, 24 May 2011 12:00:24 +0200, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> a écrit: > 1. The reason simply is that each and every of them has started > by offering some glue code for the BSD/POSIX socket functions. BSD is the standard C API for sockets, even the POSIX one, intially based on the BSD specification, was kept close enough. The POSIX specification seems to only differs in the way to get host by name / address. > .NET languages will likely just use a .NET class. Which is probably a tick binding to the socket API (if I'm wrong with this, tell me). > But there have been and will be difficulties when porting > the languages' alleged "standard" libraries to non-POSIX > (or non-.NET) operating systems. Perhaps the difficulties > are even conceptual ones whenever POSIX sockets don't really > meet the networking requirements. What networking requirement ? This thread is not about OSI layers packages for Ada, it's only about sockets, which is either OSI layer 4 or 5 (depending on the point of view). > Define > > Commercially_Important_Platforms := { > ∃ target | POSIX(target) IN { False, True } > } > > How large is the subset defined by POSIX(target) = False? > Is POSIX/Sockets the best Ada solution when this is the case? Be pragmatic : the standard socket API is the BSD socket API, then as said above, there are only little differences between the POSIX and BSD socket specification, and then after, sockets does not implies POSIX. POSIX is one thing, sockets is another. > 2. In the light of Ada's history regarding standardization, > there is, I believe, networking knowledge that warrants more > than canonization of a practical workaround---which might fail > if requirements are actually different. What workaround ? > Opposing a get-that-duct-tape-solution-out–the-door style for > standardization, I'd imagine starting from questions like the > following and then weigh POSIX sockets as the possible answer: Why not, POSIX would be OK, indeed, as it provides the same. But there should be good reason to introduce POSIX here. This would be OK if there was support for POSIX in the Ada standard, and this is actually not. > - What should programs be able to do when communicating data > along some network connection? Answered by the socket specification : there are raw, datagram, stream, blocking and none-blocking sockets, with IPv4 or IPv6 addresses. > - Should there be a layered approach? How much detail? Sockets already belong to its layer, but Ada is not concerned about it. This is not about creating a network package hierarchy, this is about a socket package only (may be a hierarchy, if it appears to be cleaner this way). > - Where in the language will this integrate nicely? > (E.g. package structure? What types if any? Or anything > that has already been mentioned.) Streams in some part, but not always, has some usage of sockets does not have stream behavior (like UDP). This would probably requires two sockets type : streams and none-stream. > - Is sockets the right approach? Consider Erlang! Seems Erlang actually provides sockets. > - Is sockets the right approach? Consider a CAN! A can 8-) ? > I doubt that the best answer to these questions can > be summed up by saying, "Mirror Posix sockets!". Why ? Thousands of applications are working nice with either POSIX or BSD sockets, and this was not cause of any big troubles I could hear about, unlike stack or buffer overflow, lack of typing and the like. Sockets are a mostly secure things. And Ada has tasking defined in the language, which can be useful for sockets (think about the "select" operation, while not formally required, is often used in conjunction with sockets). > [*] > http://pike.ida.liu.se/generated/manual/modref/ex/predef_3A_3A/Stdio/Port.html > > [**] http://www.snobol4.org/csnobol4/curr/doc/snobol4.html > > [***] "Haskell's networking functions almost always correspond > directly to familiar C function calls." > http://book.realworldhaskell.org/read/sockets-and-syslog.html OK, will get some time to read these. -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 19:38 ` Yannick Duchêne (Hibou57) @ 2011-05-24 19:54 ` Ludovic Brenta 2011-05-24 20:10 ` Yannick Duchêne (Hibou57) ` (2 more replies) 2011-05-24 21:42 ` Yannick Duchêne (Hibou57) ` (2 subsequent siblings) 3 siblings, 3 replies; 121+ messages in thread From: Ludovic Brenta @ 2011-05-24 19:54 UTC (permalink / raw) "Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes: >> Opposing a get-that-duct-tape-solution-out–the-door style for >> standardization, I'd imagine starting from questions like the >> following and then weigh POSIX sockets as the possible answer: > Why not, POSIX would be OK, indeed, as it provides the same. But there > should be good reason to introduce POSIX here. This would be OK if > there was support for POSIX in the Ada standard, and this is actually > not. Wrong. http://en.wikibooks.org/wiki/Ada_Programming/Platform/POSIX says: "POSIX.5 is an IEEE (IEEE Standard 1003.5b-1996) and ISO (ISO/IEC 14519:2001) standard defining an Ada interface to the POSIX system calls." Florist is a Free Software implementation of POSIX.5. The only nit you might pick is that POSIX.5 is not included by reference in the Ada Reference Manual. Personally I don't really care. If I need to and if my target system is POSIX compliant (which it always is in practice), I can write a standard Ada program using the standard sockets interface which is part of the standard POSIX.5. Oh, and I think I did mention GNAT.Sockets. So what are people complaining about, again? -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 19:54 ` Ludovic Brenta @ 2011-05-24 20:10 ` Yannick Duchêne (Hibou57) 2011-05-24 21:57 ` Ludovic Brenta 2011-05-25 2:47 ` Shark8 2011-05-25 9:12 ` Thomas Løcke 2 siblings, 1 reply; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-24 20:10 UTC (permalink / raw) Le Tue, 24 May 2011 21:54:13 +0200, Ludovic Brenta <ludovic@ludovic-brenta.org> a écrit: > Wrong. http://en.wikibooks.org/wiki/Ada_Programming/Platform/POSIX says: > > "POSIX.5 is an IEEE (IEEE Standard 1003.5b-1996) and ISO (ISO/IEC > 14519:2001) standard defining an Ada interface to the POSIX system > calls." Yes. I did not say there is not standard POSIX Ada, I instead said POSIX Ada is not part of the Ada standard. > Oh, and I think I did mention GNAT.Sockets. So what are people > complaining about, again? GNAT specific, that's a big enough point (I will have to check it : I'm also afraid this may make use of some GNAT internals). As Jean-Pierre underlined in a message in this same thread, maintaining a standard is not the same as adding a vendor specific feature when this pleased this vendor or single person. GNAT.Sockets, is vendor specific. I don't want the use of Sockets in Ada source, to be an advertising for GNAT, I would prefer it to be an advertising for Ada as a language (while the reason is not about advertising, but about a pressing requirement in the real world), be it GNAT (which I still enjoy, of course), Aonix, Janus, and others. If you use GNAT specific stuff, this is not Ada anymore, this GNAT (there is no legitimate way to reduce Ada to GNAT, whatever how much good GNAT is). -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 20:10 ` Yannick Duchêne (Hibou57) @ 2011-05-24 21:57 ` Ludovic Brenta 2011-05-24 22:35 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 121+ messages in thread From: Ludovic Brenta @ 2011-05-24 21:57 UTC (permalink / raw) "Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes: > Le Tue, 24 May 2011 21:54:13 +0200, Ludovic Brenta > <ludovic@ludovic-brenta.org> a écrit: >> Wrong. http://en.wikibooks.org/wiki/Ada_Programming/Platform/POSIX says: >> >> "POSIX.5 is an IEEE (IEEE Standard 1003.5b-1996) and ISO (ISO/IEC >> 14519:2001) standard defining an Ada interface to the POSIX system >> calls." > Yes. I did not say there is not standard POSIX Ada, I instead said > POSIX Ada is not part of the Ada standard. That's because making POSIX part of Ada would restrict Ada to working only on POSIX targets. >> Oh, and I think I did mention GNAT.Sockets. So what are people >> complaining about, again? > GNAT specific, that's a big enough point [...] OK. So, what you're complaining about is that sockets are not part of Ada. Thay are not. Furthermore, they cannot be part of Ada or any other general-purpose language definition because (a) general-purpose languages must work on targets that do not have sockets and (b) mandating that the language provide sockets on targets that don't have them is a bad idea. Therefore, sockets must be in an optional, target-specific library; preferably one with a standard interface. That's what POSIX.5 is. Ada with POSIX.5 is in this respect in a better position than all other languages mentioned in this thread, i.e. it has good, official standards for both the language and the socket interface. And if you're so keen on standards, why are you still using a non-standard, proprietary operating system? -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 21:57 ` Ludovic Brenta @ 2011-05-24 22:35 ` Yannick Duchêne (Hibou57) 2011-05-24 23:34 ` Adam Beneschan 2011-05-24 23:35 ` Ludovic Brenta 0 siblings, 2 replies; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-24 22:35 UTC (permalink / raw) Le Tue, 24 May 2011 23:57:48 +0200, Ludovic Brenta <ludovic@ludovic-brenta.org> a écrit: > So, what you're complaining about is that sockets are not part of Ada. > Thay are not. Furthermore, they cannot be part of Ada or any other > general-purpose language definition because (a) general-purpose > languages must work on targets that do not have sockets and (b) > mandating that the language provide sockets on targets that don't have > them is a bad idea. Some systems does not even have anything like files… Ada still define file types. Some systems does not have dynamic memory allocation except stack… Ada still define the "new" operator and storage pools. Some systems never deals with character and only bother about numbers… Ada still define character types and character handling (and encoding, as of Ada 2012). Some systems have files, while no directory… Ada still defines directory traversal facilities. (some people may extend this list) These all shows your objection is not relevant : pragmatism is, however. Above that, really more application are already concerned about remote data transfer than with remote procedure call, but Ada defines the latter and not the former (I suspect some some corporation interest in this choice). Here, Ada supports the less widely used, and not the most widely used. Except if you want it to be restricted to some niches, that's not good. > And if you're so keen on standards, why are you still using a > non-standard, proprietary operating system? How does this relate to Ada standard please ? 8-| Whether or not I am using a proprietary or none-proprietary OS, a proprietary or none-proprietary browser, this is not relevant here, and I expect you agree I am free to choose. By the way, there is not event something like a standard OS (there may be proprietaries or not, but none is standard). <confident>Well… if you really want to know : I use one proprietary and one non-proprietary OS and a proprietary browser which is not the one provided by the provider of the proprietary OS ;-) And I wish in the future, to add a proprietary OS to what is available to me (Mac OSX).</confident> -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 22:35 ` Yannick Duchêne (Hibou57) @ 2011-05-24 23:34 ` Adam Beneschan 2011-05-24 23:40 ` Ludovic Brenta 2011-05-24 23:35 ` Ludovic Brenta 1 sibling, 1 reply; 121+ messages in thread From: Adam Beneschan @ 2011-05-24 23:34 UTC (permalink / raw) On May 24, 3:35 pm, Yannick Duchêne (Hibou57) <yannick_duch...@yahoo.fr> wrote: > Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour > les chiens. All right, I have to ask for a translation. I don't speak French and can only figure out some of the words here. We have a beagle that makes some pretty bizarre sounds sometimes, but this probably isn't about that. :) -- thanks, Adam ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 23:34 ` Adam Beneschan @ 2011-05-24 23:40 ` Ludovic Brenta 2011-05-24 23:50 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 121+ messages in thread From: Ludovic Brenta @ 2011-05-24 23:40 UTC (permalink / raw) Adam Beneschan writes: > On May 24, 3:35 pm, Yannick Duchêne (Hibou57) > <yannick_duch...@yahoo.fr> wrote: > >> Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour >> les chiens. > > All right, I have to ask for a translation. I don't speak French and > can only figure out some of the words here. We have a beagle that > makes some pretty bizarre sounds sometimes, but this probably isn't > about that. :) "Whenever cats meow and sing bizarrely, it's not for dogs." I too need a translation... -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 23:40 ` Ludovic Brenta @ 2011-05-24 23:50 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-24 23:50 UTC (permalink / raw) Le Wed, 25 May 2011 01:40:40 +0200, Ludovic Brenta <ludovic@ludovic-brenta.org> a écrit: > "Whenever cats meow and sing bizarrely, it's not for dogs." > > I too need a translation... Stop joking french guy ;) Adam, “not for the dogs” (literally « pas pour les chiens »), is a french expression meaning “not for nothing” (i.e. “there is a purpose” or “that really means something”). Actually, this cannot be really translated into English (or any other language else than french), as this plays with french words polysemy. P.S. I still enjoy dogs, along with beagles, as I feel of any other forms of life ;) -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 22:35 ` Yannick Duchêne (Hibou57) 2011-05-24 23:34 ` Adam Beneschan @ 2011-05-24 23:35 ` Ludovic Brenta 2011-05-25 3:07 ` Shark8 1 sibling, 1 reply; 121+ messages in thread From: Ludovic Brenta @ 2011-05-24 23:35 UTC (permalink / raw) Yannick Duchêne writes on comp.lang.ada: > These all shows your objection is not relevant : pragmatism is, > however. Your insistence that BSD sockets ought to be part of the Ada language definition is anything *but* pragmatic, especially when there already exists a standard for sockets, called POSIX.5, an implementation of which is readily available at no cost. Oh BTW: no, you do not need all of POSIX if you "just" want to use sockets. If you were pragmatic, you'd be busy writing your sockets application right now, using Florist. > By the way, there is not event something like a standard OS (there may > be proprietaries or not, but none is standard). POSIX is a standard. A POSIX-compliant OS is a standard OS. An OS that refuses to comply with POSIX, or any other standard, is non-standard. Even MVS aka z/OS is standard in that sense. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 23:35 ` Ludovic Brenta @ 2011-05-25 3:07 ` Shark8 2011-05-25 4:01 ` Yannick Duchêne (Hibou57) ` (2 more replies) 0 siblings, 3 replies; 121+ messages in thread From: Shark8 @ 2011-05-25 3:07 UTC (permalink / raw) On May 24, 6:35 pm, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote: > Yannick Duchêne writes on comp.lang.ada: > > > > By the way, there is not event something like a standard OS (there may > > be proprietaries or not, but none is standard). > > POSIX is a standard. A POSIX-compliant OS is a standard OS. An OS that > refuses to comply with POSIX, or any other standard, is non-standard. > > Even MVS aka z/OS is standard in that sense. > > -- > Ludovic Brenta. And, it is useful/instructive to realize that just because something is a [part of a] standard does NOT mean that standard requires/says anything useful. This was something I learned from a mathematics professor (though about 'definitions' rather than 'standards') and is important enough that it should be remembered from time-to-time. {IIRC as far as POSIX is concerned, MS Windows has been POSIX complaint since 2000... and this says NOTHING about how portable binaries (or their sources) are between Windows and unix/linux computers.} ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-25 3:07 ` Shark8 @ 2011-05-25 4:01 ` Yannick Duchêne (Hibou57) 2011-05-25 7:39 ` Georg Bauhaus ` (2 more replies) 2011-05-25 7:40 ` Why no socket package in the standard ? Georg Bauhaus 2011-05-25 7:49 ` Ludovic Brenta 2 siblings, 3 replies; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-25 4:01 UTC (permalink / raw) Le Wed, 25 May 2011 05:07:06 +0200, Shark8 <onewingedshark@gmail.com> a écrit: > {IIRC as far as POSIX is concerned, MS Windows has been POSIX > complaint > since 2000... and this says NOTHING about how portable binaries (or > their > sources) are between Windows and unix/linux computers.} Also funny to note two things. 1) There exist a “Windows Services for UNIX”, alias “Subsystem for UNIX-based Applications”. See http://technet.microsoft.com/fr-fr/library/bb496506(en-us).aspx 2) Linux is not fully POSIX compliant See https://www.opengroup.org/platform/single_unix_specification/uploads/40/13450/POSIX_and_Linux_Application_Compatibility_Final_-_v1.0.pdf (and it appears no one would want to pay the average $15000 fee required to pass compliance test which would be required anyway) That was just to tease a bit the author of the claim :-P POSIX does not make an OS better or worse than another, as POSIX is meaningful only where POSIX is a requirement, and that is restricted to some application areas (as an example, most desktop users don't care at all). This provides no other added value than that. Then I don't believe POSIX is a standard the same way Ada is a standard. Ada started as a standard from requirements, while POSIX started as a standard from existing features : its purpose was to be a standard for UNIX systems… so anyone can bet this is not surprising then if UNIces seems more POSIX compliant than others. Or may be UNIX is the only one legitimate OS base ? (I believe someones believe this, indeed). POSIX is not more a standard than PHP or Python are. I am not even sure a POSIX platform make designing a compliant Ada compiler easier (at least as an example, the Linux thread model is not that cool, not to talk about file locking, which is often required with concurrent task). Apologizes to others for that crooked post. -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-25 4:01 ` Yannick Duchêne (Hibou57) @ 2011-05-25 7:39 ` Georg Bauhaus 2011-05-25 7:42 ` Ludovic Brenta 2011-05-25 10:44 ` Peter C. Chapin 2 siblings, 0 replies; 121+ messages in thread From: Georg Bauhaus @ 2011-05-25 7:39 UTC (permalink / raw) On 5/25/11 6:01 AM, Yannick Duchêne (Hibou57) wrote: > POSIX does not make an OS better or worse than another, > as POSIX is meaningful only where POSIX is a requirement, > and that is restricted to some application areas (as an > example, most desktop users don't care at all). > This provides no other added value than that. When programs are written for POSIX, chances are that you can compile them. This is a consequence of POSIX being a widely supported standard. POSIX is a much better starting point than that huge non-standard obstacle that gets in the way of portability: Unix-C+autoconf. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-25 4:01 ` Yannick Duchêne (Hibou57) 2011-05-25 7:39 ` Georg Bauhaus @ 2011-05-25 7:42 ` Ludovic Brenta 2011-05-25 10:46 ` Manuel Collado 2011-05-25 10:44 ` Peter C. Chapin 2 siblings, 1 reply; 121+ messages in thread From: Ludovic Brenta @ 2011-05-25 7:42 UTC (permalink / raw) Yannick Duchêne wrote on comp.lang.ada: > 1) There exist a “Windows Services for UNIX”, alias “Subsystem for > UNIX-based Applications”. > See http://technet.microsoft.com/fr-fr/library/bb496506(en-us).aspx Which confirms that Windows is not POSIX-compliant out of the box but requires an add-on. > 2) Linux is not fully POSIX compliant > See https://www.opengroup.org/platform/single_unix_specification/uploads/... > (and it appears no one would want to pay the average $15000 fee > required to pass compliance test which would be required anyway) It is funny that after reading the first paragraph of that document you should claim that: > POSIX is not more a standard than PHP or Python are. Come on. POSIX started as an IEEE standard and has been an ISO standard (specifically ISO/IEC 9945) since 1996. How much more standard do you want it to be? -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-25 7:42 ` Ludovic Brenta @ 2011-05-25 10:46 ` Manuel Collado 0 siblings, 0 replies; 121+ messages in thread From: Manuel Collado @ 2011-05-25 10:46 UTC (permalink / raw) El 25/05/2011 9:42, Ludovic Brenta escribi�: > Yannick Duch�ne wrote on comp.lang.ada: >> 1) There exist a �Windows Services for UNIX�, alias �Subsystem for >> UNIX-based Applications�. >> See http://technet.microsoft.com/fr-fr/library/bb496506(en-us).aspx > > Which confirms that Windows is not POSIX-compliant out of the box but > requires an add-on. IMHO, the most POSIX compliant Windows add-on is Cygwin. Much more than Microsoft's �Windows Services for UNIX�. And it includes GPL Ada, if that matters ;-) -- Manuel Collado - http://lml.ls.fi.upm.es/~mcollado ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-25 4:01 ` Yannick Duchêne (Hibou57) 2011-05-25 7:39 ` Georg Bauhaus 2011-05-25 7:42 ` Ludovic Brenta @ 2011-05-25 10:44 ` Peter C. Chapin 2011-05-25 15:28 ` Yannick Duchêne (Hibou57) 2 siblings, 1 reply; 121+ messages in thread From: Peter C. Chapin @ 2011-05-25 10:44 UTC (permalink / raw) On Wed, 25 May 2011 06:01:06 +0200, Yannick Duchêne (Hibou57) wrote: > Then I don't believe POSIX is a standard the same way Ada is a standard. > Ada started as a standard from requirements, while POSIX started as a > standard from existing features : its purpose was to be a standard for > UNIX systems… so anyone can bet this is not surprising then if UNIces > seems more POSIX compliant than others. Or may be UNIX is the only one > legitimate OS base ? (I believe someones believe this, indeed). POSIX is > not more a standard than PHP or Python are. I think that's an inaccurate characterization of POSIX. POSIX is, in fact, a standard. It was originally created by the IEEE. See, for example: http://pubs.opengroup.org/onlinepubs/009695399/ From the abstract: "This standard defines a standard operating system interface and environment, including a command interpreter (or "shell"), and common utility programs to support applications portability at the source code level. This standard is the single common revision to IEEE Std 1003.1-1996, IEEE Std 1003.2-1992, and the Base Specifications of The Open Group Single UNIX Specification, Version 2. This standard is intended to be used by both applications developers and system implementors. It comprises four major components (each in an associated volume)" It is true that POSIX was designed to standardize the existing practice in the Unix community. This is typical of the way standards are usually created; it is the history of the Ada standard is unusual. It also true that autoconf is a travesty... a throwback to a darker age when the POSIX standard did not exist (or at least was not widely implemented). Peter ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-25 10:44 ` Peter C. Chapin @ 2011-05-25 15:28 ` Yannick Duchêne (Hibou57) 2011-05-25 16:36 ` Ludovic Brenta 0 siblings, 1 reply; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-25 15:28 UTC (permalink / raw) Le Wed, 25 May 2011 12:44:20 +0200, Peter C. Chapin <PChapin@vtc.vsc.edu> a écrit: > It also true that autoconf is a travesty... a throwback to a darker age > when the POSIX standard did not exist (or at least was not widely > implemented). I do not know that much about Autoconf, so I can't really understand what that mean and implies (someone else here also say a bit the same as you too). -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-25 15:28 ` Yannick Duchêne (Hibou57) @ 2011-05-25 16:36 ` Ludovic Brenta 2011-05-25 16:46 ` Yannick Duchêne (Hibou57) ` (2 more replies) 0 siblings, 3 replies; 121+ messages in thread From: Ludovic Brenta @ 2011-05-25 16:36 UTC (permalink / raw) Yannick Duchêne wrote on comp.lang.ada: > Peter C. Chapin a écrit: >> It also true that autoconf is a travesty... a throwback to a darker age >> when the POSIX standard did not exist (or at least was not widely >> implemented). > > I do not know that much about Autoconf, so I can't really understand what > that mean and implies (someone else here also say a bit the same as you > too). Make was invented to overcome the deficiencies of C, notably the lack of modular programming and dependency management. Automake was invented to overcome the deficiencies of make, notably the poor maintainability of Makefiles. Configure was invented to overcome the deficiencies of early UNIX systems, notably the lack of conformance to POSIX, and their impact of the maintenance of Automake files. Autoconf was invented to overcome the deficiencies of Configure, notably the sheer size and horror of the configure scripts, which routinely consist of hundreds of thousands of lines of illegible POSIX shell code. The novice programmer adds corrective code. The master programmer removes defective code. Enough said :) -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-25 16:36 ` Ludovic Brenta @ 2011-05-25 16:46 ` Yannick Duchêne (Hibou57) 2011-05-26 12:10 ` Maciej Sobczak 2011-05-26 14:50 ` Adam Beneschan 2 siblings, 0 replies; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-25 16:46 UTC (permalink / raw) Le Wed, 25 May 2011 18:36:17 +0200, Ludovic Brenta <ludovic@ludovic-brenta.org> a écrit: > [… long worthy wordings …] > Enough said :) and Good enough. Thanks for the piece of history, that's crystal-clear now. -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-25 16:36 ` Ludovic Brenta 2011-05-25 16:46 ` Yannick Duchêne (Hibou57) @ 2011-05-26 12:10 ` Maciej Sobczak 2011-05-26 12:42 ` Ludovic Brenta 2011-05-26 14:50 ` Adam Beneschan 2 siblings, 1 reply; 121+ messages in thread From: Maciej Sobczak @ 2011-05-26 12:10 UTC (permalink / raw) On 25 Maj, 18:36, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote: > Make was invented to overcome the deficiencies of C, notably the lack > of modular programming and dependency management. Umm, no. Make is a general-purpose project management system that can be used to manage any file-system related build activity. Compiling C programs is one of the most trivial and boring things that make can be used for. -- Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-26 12:10 ` Maciej Sobczak @ 2011-05-26 12:42 ` Ludovic Brenta 2011-05-26 14:36 ` Georg Bauhaus 2011-05-26 18:20 ` Maciej Sobczak 0 siblings, 2 replies; 121+ messages in thread From: Ludovic Brenta @ 2011-05-26 12:42 UTC (permalink / raw) Maciej Sobczak wrote on comp.lang.ada: > On 25 Maj, 18:36, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote: > >> Make was invented to overcome the deficiencies of C, notably the lack >> of modular programming and dependency management. > > Umm, no. > Make is a general-purpose project management system that can be used > to manage any file-system related build activity. Compiling C programs > is one of the most trivial and boring things that make can be used > for. I know (I've used make myself for such purposes) but that does not change anything to what I wrote. C was designed as a systems programming language, by and for kernel hackers, and was used as a general-purpose language. Similarly, make started as a hack to overcome the deficiencies of C and was then extended for other, more general uses. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-26 12:42 ` Ludovic Brenta @ 2011-05-26 14:36 ` Georg Bauhaus 2011-05-26 15:56 ` Ludovic Brenta 2011-05-26 18:20 ` Maciej Sobczak 1 sibling, 1 reply; 121+ messages in thread From: Georg Bauhaus @ 2011-05-26 14:36 UTC (permalink / raw) On 26.05.11 14:42, Ludovic Brenta wrote: > Maciej Sobczak wrote on comp.lang.ada: >> On 25 Maj, 18:36, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote: >> >>> Make was invented to overcome the deficiencies of C, notably the lack >>> of modular programming and dependency management. >> >> Umm, no. >> Make is a general-purpose project management system that can be used >> to manage any file-system related build activity. Compiling C programs >> is one of the most trivial and boring things that make can be used >> for. > > I know (I've used make myself for such purposes) but that does not > change anything to what I wrote. > > C was designed as a systems programming language, by and for kernel > hackers, and was used as a general-purpose language. Similarly, make > started as a hack to overcome the deficiencies of C and was then > extended for other, more general uses. How does the make program helps with adding modules to C and its file scope? ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-26 14:36 ` Georg Bauhaus @ 2011-05-26 15:56 ` Ludovic Brenta 0 siblings, 0 replies; 121+ messages in thread From: Ludovic Brenta @ 2011-05-26 15:56 UTC (permalink / raw) Georg Bauhaus writes on comp.lang.ada: > On 26.05.11 14:42, Ludovic Brenta wrote: >> Maciej Sobczak wrote on comp.lang.ada: >>> On 25 Maj, 18:36, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote: >>> >>>> Make was invented to overcome the deficiencies of C, notably the lack >>>> of modular programming and dependency management. >>> >>> Umm, no. >>> Make is a general-purpose project management system that can be used >>> to manage any file-system related build activity. Compiling C programs >>> is one of the most trivial and boring things that make can be used >>> for. >> >> I know (I've used make myself for such purposes) but that does not >> change anything to what I wrote. >> >> C was designed as a systems programming language, by and for kernel >> hackers, and was used as a general-purpose language. Similarly, make >> started as a hack to overcome the deficiencies of C and was then >> extended for other, more general uses. > > How does the make program helps with adding modules to C and its file > scope? It helps a little bit by deciding which source files are out of date WRT their header files and corresponding object files, then deciding in which order to call the compiler and linker. This however requires a lot of labor to teach Make about the dependencies, and is of course a partial solution only. Just as C was a partial solution to the problem of programming as a human activity :) -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-26 12:42 ` Ludovic Brenta 2011-05-26 14:36 ` Georg Bauhaus @ 2011-05-26 18:20 ` Maciej Sobczak 2011-05-26 18:29 ` Yannick Duchêne (Hibou57) ` (2 more replies) 1 sibling, 3 replies; 121+ messages in thread From: Maciej Sobczak @ 2011-05-26 18:20 UTC (permalink / raw) On 26 Maj, 14:42, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote: > Similarly, make > started as a hack to overcome the deficiencies of C Sorry, but here: http://en.wikipedia.org/wiki/Make_%28software%29 there is nothing about it. Any references to C in this article are qualified with "for example", which is in line with what I've said. Could you please share the source of your information? I'm genuinely interested. -- Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-26 18:20 ` Maciej Sobczak @ 2011-05-26 18:29 ` Yannick Duchêne (Hibou57) 2011-05-26 20:46 ` Georg Bauhaus 2011-05-26 18:31 ` Vinzent Hoefler 2011-05-27 11:44 ` Stephen Leake 2 siblings, 1 reply; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-26 18:29 UTC (permalink / raw) Le Thu, 26 May 2011 20:20:33 +0200, Maciej Sobczak <see.my.homepage@gmail.com> a écrit: > On 26 Maj, 14:42, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote: > >> Similarly, make >> started as a hack to overcome the deficiencies of C > > Sorry, but here: > > http://en.wikipedia.org/wiki/Make_%28software%29 > > there is nothing about it. Any references to C in this article are > qualified with "for example", which is in line with what I've said. Wikipedia is not the owner of the truth (although it may dream to register this as an owned trademark). I heard the same about Make, as what Ludovic said. And then, the first time I had to face this ugly Make (and its silly file format), was for C/C++. Typically, when you have to deal with a Makefile, this is about C sources (and if its big enough, you also have multiple sources of nightmare). That's a fact that C compilers, cannot handle dependencies without the help of an external tool (add this to the preprocessor). -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-26 18:29 ` Yannick Duchêne (Hibou57) @ 2011-05-26 20:46 ` Georg Bauhaus 2011-05-26 21:02 ` Yannick Duchêne (Hibou57) 2011-05-26 21:59 ` Ludovic Brenta 0 siblings, 2 replies; 121+ messages in thread From: Georg Bauhaus @ 2011-05-26 20:46 UTC (permalink / raw) On 5/26/11 8:29 PM, Yannick Duchêne (Hibou57) wrote: > Le Thu, 26 May 2011 20:20:33 +0200, Maciej Sobczak <see.my.homepage@gmail.com> a écrit: > >> On 26 Maj, 14:42, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote: >> >>> Similarly, make >>> started as a hack to overcome the deficiencies of C >> >> Sorry, but here: >> >> http://en.wikipedia.org/wiki/Make_%28software%29 >> >> there is nothing about it. Any references to C in this article are >> qualified with "for example", which is in line with what I've said. > > Wikipedia is not the owner of the truth (although it may dream to register this as an owned trademark). I heard the same about Make, as what Ludovic said. And then, the first time I had to face this ugly Make (and its silly file format), was for C/C++. Typically, when you have to deal with a Makefile, this is about C sources (and if its big enough, you also have multiple sources of nightmare). > > That's a fact that C compilers, cannot handle dependencies without the help of an external tool (add this to the preprocessor). > Make (or similar) is still good for building Ada programs, in particular, portable Ada programs (between compilers), and its associated documentation and the tests. Ada compilers typically include their own driver programs that have it their own non-portable ways, and Ada library related programs. These will detect Ada sources only after they know about how and where to find them. In the case of GNAT, this used to boil down to combining gnatchop, gnatmake, and possibly a special file that would list mappings from files to compilation units, or file name patterns that would allow identifying compilation units in the file system. Or setting variables such as ADA_INCLUDE_PATH. For example, gnatmake is not enough if your program is this: procedure Hello; -- offer greetings to the world with Ada.Text_IO; procedure Hello is begin Ada.Text_IO.Put_Line("Hello, World!"); end Hello; I think gprbuild or at least a GNAT specific project file is needed. In the case of ObjectAda or other frontends built around AdaMagic a program called adareg or similar will permit adding files and paths to the Ada libary; files can consist of more than one compilation unit, no chopping is needed (even though a 1:1 correspondence has been recommended). Additional programs include adamake or adabuild or adacomp. I understand that IBM Rational Apex is using a sophisticated Ada library management software. Make (or similar) on top of this is fairly simple to use and gives you another level of simple configuration. E.g., set environment variables that a GNAT project file will read; use VPATH if you have GNU make and easily switch configurations. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-26 20:46 ` Georg Bauhaus @ 2011-05-26 21:02 ` Yannick Duchêne (Hibou57) 2011-05-26 21:44 ` Georg Bauhaus 2011-05-26 21:59 ` Ludovic Brenta 1 sibling, 1 reply; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-26 21:02 UTC (permalink / raw) Le Thu, 26 May 2011 22:46:09 +0200, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> a écrit: > In the case of ObjectAda or other frontends built around AdaMagic > a program called adareg or similar will permit adding files and > paths to the Ada libary; files can consist of more than one > compilation unit, no chopping is needed (even though a 1:1 > correspondence has been recommended). Yes, I know the standard does not requires a single compilation unit per file, while GNAT can't handle this. This may be a big enough difference between Ada compilers. Except that, all are able to handle dependencies, and all you need is typically a search path and a mapping from compilation unit name to file names. This is simpler than what many Makefiles looks like. > compilation unit, no chopping is needed (even though a 1:1 > correspondence has been recommended). Recommended by whom ? -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-26 21:02 ` Yannick Duchêne (Hibou57) @ 2011-05-26 21:44 ` Georg Bauhaus 0 siblings, 0 replies; 121+ messages in thread From: Georg Bauhaus @ 2011-05-26 21:44 UTC (permalink / raw) On 5/26/11 11:02 PM, Yannick Duchêne (Hibou57) wrote: > Le Thu, 26 May 2011 22:46:09 +0200, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> a écrit: >> In the case of ObjectAda or other frontends built around AdaMagic >> a program called adareg or similar will permit adding files and >> paths to the Ada libary; files can consist of more than one >> compilation unit, no chopping is needed (even though a 1:1 >> correspondence has been recommended). > Yes, I know the standard does not requires a single compilation unit per file, while GNAT can't handle this. This may be a big enough difference between Ada compilers. Except that, all are able to handle dependencies, and all you need is typically a search path and a mapping from compilation unit name to file names. This is simpler than what many Makefiles looks like. > > >> compilation unit, no chopping is needed (even though a 1:1 >> correspondence has been recommended). > Recommended by whom ? > I think by one of the makers of the front end, considering advantages that 1:1 may have when computing compilation requirements after changes. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-26 20:46 ` Georg Bauhaus 2011-05-26 21:02 ` Yannick Duchêne (Hibou57) @ 2011-05-26 21:59 ` Ludovic Brenta 2011-05-27 7:54 ` Georg Bauhaus 2011-05-27 13:12 ` Simon Wright 1 sibling, 2 replies; 121+ messages in thread From: Ludovic Brenta @ 2011-05-26 21:59 UTC (permalink / raw) Georg Bauhaus writes on comp.lang.ada: > Make (or similar) is still good for building Ada programs, in > particular, portable Ada programs (between compilers), and its > associated documentation and the tests. Make is a wrapper around shell scripts (the rules in Makefiles are shell scripts). You can use a Makefile as a wrapper around the compiler driver but you might as well avoid Make and use shell scripts directly because you do not need Make to figure dependencies or order of compilation out. In fact, Make's built-in rules and dependency engine might get in the way. Makefiles tend not to be portable between operating systems anyway; that's what Automake and Configure are for :) > For example, gnatmake is not enough if your program is this: > > procedure Hello; > -- offer greetings to the world > > with Ada.Text_IO; > procedure Hello is > begin > Ada.Text_IO.Put_Line("Hello, World!"); > end Hello; > > I think gprbuild or at least a GNAT specific project file is needed. Huh? $ gnatmake hello gcc-4.4 -c hello.adb gnatbind -x hello.ali gnatlink hello.ali $ ./hello Hello, World! What is missing that makes gnatmake "not enough"? > In the case of ObjectAda or other frontends built around AdaMagic a > program called adareg or similar will permit adding files and paths to > the Ada libary; files can consist of more than one compilation unit, > no chopping is needed (even though a 1:1 correspondence has been > recommended). Additional programs include adamake or adabuild or > adacomp. > > I understand that IBM Rational Apex is using a sophisticated Ada > library management software. > > Make (or similar) on top of this is fairly simple to use and gives you > another level of simple configuration. E.g., set environment variables > that a GNAT project file will read; use VPATH if you have GNU make and > easily switch configurations. No, Makefiles wrappers around compiler drivers + Ada library management would be complicated and difficult to maintain. You'd be better off with even simpler shell scripts or, why not, gprmake. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-26 21:59 ` Ludovic Brenta @ 2011-05-27 7:54 ` Georg Bauhaus 2011-05-27 13:12 ` Simon Wright 1 sibling, 0 replies; 121+ messages in thread From: Georg Bauhaus @ 2011-05-27 7:54 UTC (permalink / raw) On 5/26/11 11:59 PM, Ludovic Brenta wrote: > Georg Bauhaus writes on comp.lang.ada: >> Make (or similar) is still good for building Ada programs, in >> particular, portable Ada programs (between compilers), and its >> associated documentation and the tests. > > Make is a wrapper around shell scripts (the rules in Makefiles are shell > scripts). A rule system is more than a wrapper just like an Ada compiler's Find_Dependencies routine is more than a recursive ls(1) (assuming the compiler does use just file based search). Plus, some make programs don't assume a sh(1) or anything available withUnix. > you do not need Make to figure dependencies or order of > compilation out. A project is not fully built when just the Ada part is built. How would I have the customer run XSL transformation for doc generation using, as you suggest, sh(1) on Windows(TM)? Will GPRClean remove intermediate files in non-Ada parts like make would? (I don't know about this; the GPR docs are extensive, and seem to concentrate on building Ada programs.) >> For example, gnatmake is not enough if your program is this: $ cat Hello.ada procedure Hello; -- offer greetings to the world with Ada.Text_IO; procedure Hello is begin Ada.Text_IO.Put_Line("Hello, World!"); end Hello; $ Gnatmake cannot translate the Ada program above. It has more than one separately compilable unit: $ gnatmake -gnatf -gnatv Hello.ada gcc -c -gnatf -gnatv -x ada hello.ada GNAT GPL 2010 (20100603) Copyright 1992-2010, Free Software Foundation, Inc. Compiling: hello.ada (source file time stamp: 2011-05-27 07:07:02) 4. with Ada.Text_IO; | >>> end of file expected, file can have only one compilation unit 8 lines: 1 error gnatmake: "hello.ada" compilation error > why not, gprmake. The PATH issues in GPR* have again been mentioned. Yes, they can be solved, and they are documented. Just like: Yes, one can write range checks in C, and the secret C standard + compiler documentation + machine documentation will say how. Besides, $ grep -i gprmake /opt/GNAT2010/share/doc/gnat/txt/* $ I have yet to find the section detailing the "added" part from the following promising sentence, quoted from gnat_ugn (GPL 2010): "Tools like `gnatmake' only know about Ada, while other tools like `gprbuild' know about many more languages such as C, C++, Fortran, assembly and others can be added dynamically." ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-26 21:59 ` Ludovic Brenta 2011-05-27 7:54 ` Georg Bauhaus @ 2011-05-27 13:12 ` Simon Wright 2011-05-27 15:43 ` Ludovic Brenta 1 sibling, 1 reply; 121+ messages in thread From: Simon Wright @ 2011-05-27 13:12 UTC (permalink / raw) Ludovic Brenta <ludovic@ludovic-brenta.org> writes: > You'd be better off with even simpler shell scripts or, why not, > gprmake. Pretty sure gprmake is obsolete now. I'm not happy that gprbuild isn't part of GCC or in a public repo, but there you go. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-27 13:12 ` Simon Wright @ 2011-05-27 15:43 ` Ludovic Brenta 0 siblings, 0 replies; 121+ messages in thread From: Ludovic Brenta @ 2011-05-27 15:43 UTC (permalink / raw) Simon Wright writes on comp.lang.ada: > Ludovic Brenta <ludovic@ludovic-brenta.org> writes: > >> You'd be better off with even simpler shell scripts or, why not, >> gprmake. > > Pretty sure gprmake is obsolete now. I'm not happy that gprbuild isn't > part of GCC or in a public repo, but there you go. Yes, sorry, I meant gprbuild not gprmake. I share your feelings about the availability of the sources. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-26 18:20 ` Maciej Sobczak 2011-05-26 18:29 ` Yannick Duchêne (Hibou57) @ 2011-05-26 18:31 ` Vinzent Hoefler 2011-05-26 19:05 ` Ludovic Brenta ` (2 more replies) 2011-05-27 11:44 ` Stephen Leake 2 siblings, 3 replies; 121+ messages in thread From: Vinzent Hoefler @ 2011-05-26 18:31 UTC (permalink / raw) Maciej Sobczak wrote: > On 26 Maj, 14:42, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote: > >> Similarly, make >> started as a hack to overcome the deficiencies of C > > Sorry, but here: > > http://en.wikipedia.org/wiki/Make_%28software%29 > > there is nothing about it. Any references to C in this article are > qualified with "for example", which is in line with what I've said. > > Could you please share the source of your information? I'm genuinely > interested. <http://en.wikipedia.org/wiki/Stuart_Feldman> 1977, Bell Labs, UNIX, first FORTRAN 77 compiler. I'd suspect, this compiler wasn't written in FORTRAN itself, so the logical conclusion would be that the compiler was witten in C (like almost anything for UNIX, especially at that time) and thus 'make' was written to simplify the task of compiling those compiler's sources. ;) Vinzent. -- A C program is like a fast dance on a newly waxed dance floor by people carrying razors. -- Waldi Ravens ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-26 18:31 ` Vinzent Hoefler @ 2011-05-26 19:05 ` Ludovic Brenta 2011-05-26 19:14 ` Yannick Duchêne (Hibou57) 2011-05-27 2:02 ` anon 2 siblings, 0 replies; 121+ messages in thread From: Ludovic Brenta @ 2011-05-26 19:05 UTC (permalink / raw) Vinzent Hoefler writes on comp.lang.ada: > Maciej Sobczak wrote: > >> On 26 Maj, 14:42, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote: >> >>> Similarly, make >>> started as a hack to overcome the deficiencies of C >> >> Sorry, but here: >> >> http://en.wikipedia.org/wiki/Make_%28software%29 >> >> there is nothing about it. Any references to C in this article are >> qualified with "for example", which is in line with what I've said. >> >> Could you please share the source of your information? I'm genuinely >> interested. > > <http://en.wikipedia.org/wiki/Stuart_Feldman> > > 1977, Bell Labs, UNIX, first FORTRAN 77 compiler. > > I'd suspect, this compiler wasn't written in FORTRAN itself, so the > logical conclusion would be that the compiler was witten in C (like > almost anything for UNIX, especially at that time) and thus 'make' was > written to simplify the task of compiling those compiler's sources. ;) And that leads to http://www.faqs.org/docs/artu/ch15s04.html: | Make originated with a visit from Steve Johnson (author of yacc, | etc.), storming into my office, cursing the Fates that had caused him | to waste a morning debugging a correct program (bug had been fixed, | file hadn't been compiled, cc *.o was therefore unaffected). As I had | spent a part of the previous evening coping with the same disaster on | a project I was working on, the idea of a tool to solve it came up. It | began with an elaborate idea of a dependency analyzer, boiled down to | something much simpler, and turned into Make that weekend. Use of | tools that were still wet was part of the culture. Makefiles were text | files, not magically encoded binaries, because that was the Unix | ethos: printable, debuggable, understandable stuff. -- Stuart Feldman -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-26 18:31 ` Vinzent Hoefler 2011-05-26 19:05 ` Ludovic Brenta @ 2011-05-26 19:14 ` Yannick Duchêne (Hibou57) 2011-05-26 19:44 ` Ludovic Brenta 2011-05-27 2:02 ` anon 2 siblings, 1 reply; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-26 19:14 UTC (permalink / raw) Le Thu, 26 May 2011 20:31:28 +0200, Vinzent Hoefler <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> a écrit: > I'd suspect, this compiler wasn't written in FORTRAN itself, so the > logical conclusion would be that the compiler was witten in C (like > almost anything for UNIX, especially at that time) and thus 'make' > was written to simplify the task of compiling those compiler's sources. > ;) So Make was… Yet Another Compiler-Compiler ? :-D -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-26 19:14 ` Yannick Duchêne (Hibou57) @ 2011-05-26 19:44 ` Ludovic Brenta 0 siblings, 0 replies; 121+ messages in thread From: Ludovic Brenta @ 2011-05-26 19:44 UTC (permalink / raw) Yannick Duchêne wrote on comp.lang.ada: > Le Thu, 26 May 2011 20:31:28 +0200, Vinzent Hoefler > <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> a écrit: >> I'd suspect, this compiler wasn't written in FORTRAN itself, so the >> logical conclusion would be that the compiler was witten in C (like >> almost anything for UNIX, especially at that time) and thus 'make' >> was written to simplify the task of compiling those compiler's >> sources. ;) > > So Make was… Yet Another Compiler-Compiler ? :-D No, Make was made over one weekend to Make Yet Another Compiler-Compiler :) -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-26 18:31 ` Vinzent Hoefler 2011-05-26 19:05 ` Ludovic Brenta 2011-05-26 19:14 ` Yannick Duchêne (Hibou57) @ 2011-05-27 2:02 ` anon 2 siblings, 0 replies; 121+ messages in thread From: anon @ 2011-05-27 2:02 UTC (permalink / raw) In the mid 1970s, AT&T and Bell Labs sold their OS by saying you provide a C compiler you can get a secure OS written in 100% C. So, the Fortran && compiler was written in C. In <op.vv3pqqq5lzeukk@jellix.jlfencey.com>, "Vinzent Hoefler" <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> writes: >Maciej Sobczak wrote: > >> On 26 Maj, 14:42, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote: >> >>> Similarly, make >>> started as a hack to overcome the deficiencies of C >> >> Sorry, but here: >> >> http://en.wikipedia.org/wiki/Make_%28software%29 >> >> there is nothing about it. Any references to C in this article are >> qualified with "for example", which is in line with what I've said. >> >> Could you please share the source of your information? I'm genuinely >> interested. > ><http://en.wikipedia.org/wiki/Stuart_Feldman> > >1977, Bell Labs, UNIX, first FORTRAN 77 compiler. > >I'd suspect, this compiler wasn't written in FORTRAN itself, so the >logical conclusion would be that the compiler was witten in C (like >almost anything for UNIX, especially at that time) and thus 'make' >was written to simplify the task of compiling those compiler's sources. ;) > > >Vinzent. > >-- >A C program is like a fast dance on a newly waxed dance floor by people carrying >razors. > -- Waldi Ravens ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-26 18:20 ` Maciej Sobczak 2011-05-26 18:29 ` Yannick Duchêne (Hibou57) 2011-05-26 18:31 ` Vinzent Hoefler @ 2011-05-27 11:44 ` Stephen Leake 2 siblings, 0 replies; 121+ messages in thread From: Stephen Leake @ 2011-05-27 11:44 UTC (permalink / raw) Maciej Sobczak <see.my.homepage@gmail.com> writes: > On 26 Maj, 14:42, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote: > >> Similarly, make >> started as a hack to overcome the deficiencies of C > > Sorry, but here: > > http://en.wikipedia.org/wiki/Make_%28software%29 > > there is nothing about it. Any references to C in this article are > qualified with "for example", which is in line with what I've said. The "Origin" section (which is what we are talking about) is very short, and implies (as Ludovic said) that 'make' was originally written to help compile C code (since that was the primary language on Unix at the time). -- -- Stephe ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-25 16:36 ` Ludovic Brenta 2011-05-25 16:46 ` Yannick Duchêne (Hibou57) 2011-05-26 12:10 ` Maciej Sobczak @ 2011-05-26 14:50 ` Adam Beneschan 2011-05-26 15:57 ` Ludovic Brenta 2 siblings, 1 reply; 121+ messages in thread From: Adam Beneschan @ 2011-05-26 14:50 UTC (permalink / raw) On May 25, 9:36 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote: > Yannick Duchêne wrote on comp.lang.ada: > > > Peter C. Chapin a écrit: > >> It also true that autoconf is a travesty... a throwback to a darker age > >> when the POSIX standard did not exist (or at least was not widely > >> implemented). > > > I do not know that much about Autoconf, so I can't really understand what > > that mean and implies (someone else here also say a bit the same as you > > too). > > Make was invented to overcome the deficiencies of C, notably the lack > of modular programming and dependency management. > > Automake was invented to overcome the deficiencies of make, notably > the poor maintainability of Makefiles. > > Configure was invented to overcome the deficiencies of early UNIX > systems, notably the lack of conformance to POSIX, and their impact of > the maintenance of Automake files. > > Autoconf was invented to overcome the deficiencies of Configure, > notably the sheer size and horror of the configure scripts, which > routinely consist of hundreds of thousands of lines of illegible POSIX > shell code. I was going to ask what was the invention to overcome the deficiencies of autoconf, but I think I figured it out ... rm -rf, right? -- Adam ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-26 14:50 ` Adam Beneschan @ 2011-05-26 15:57 ` Ludovic Brenta 2011-05-27 11:46 ` Stephen Leake 0 siblings, 1 reply; 121+ messages in thread From: Ludovic Brenta @ 2011-05-26 15:57 UTC (permalink / raw) Adam Beneschan writes on comp.lang.ada: > On May 25, 9:36 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote: >> Yannick Duchêne wrote on comp.lang.ada: >> >>> Peter C. Chapin a écrit: >>>> It also true that autoconf is a travesty... a throwback to a darker >>>> age when the POSIX standard did not exist (or at least was not >>>> widely implemented). >> >>> I do not know that much about Autoconf, so I can't really understand >>> what that mean and implies (someone else here also say a bit the >>> same as you too). >> >> Make was invented to overcome the deficiencies of C, notably the lack >> of modular programming and dependency management. >> >> Automake was invented to overcome the deficiencies of make, notably >> the poor maintainability of Makefiles. >> >> Configure was invented to overcome the deficiencies of early UNIX >> systems, notably the lack of conformance to POSIX, and their impact >> of the maintenance of Automake files. >> >> Autoconf was invented to overcome the deficiencies of Configure, >> notably the sheer size and horror of the configure scripts, which >> routinely consist of hundreds of thousands of lines of illegible >> POSIX shell code. > > I was going to ask what was the invention to overcome the deficiencies > of autoconf, but I think I figured it out ... rm -rf, right? Opinions differ but I'd tend to side with you :) -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-26 15:57 ` Ludovic Brenta @ 2011-05-27 11:46 ` Stephen Leake 2011-05-27 12:21 ` Dmitry A. Kazakov 0 siblings, 1 reply; 121+ messages in thread From: Stephen Leake @ 2011-05-27 11:46 UTC (permalink / raw) Ludovic Brenta <ludovic@ludovic-brenta.org> writes: > Adam Beneschan writes on comp.lang.ada: >> On May 25, 9:36 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote: >>> Yannick Duchêne wrote on comp.lang.ada: >>> >>>> Peter C. Chapin a écrit: >>>>> It also true that autoconf is a travesty... a throwback to a darker >>>>> age when the POSIX standard did not exist (or at least was not >>>>> widely implemented). >>> >>>> I do not know that much about Autoconf, so I can't really understand >>>> what that mean and implies (someone else here also say a bit the >>>> same as you too). >>> >>> Make was invented to overcome the deficiencies of C, notably the lack >>> of modular programming and dependency management. >>> >>> Automake was invented to overcome the deficiencies of make, notably >>> the poor maintainability of Makefiles. >>> >>> Configure was invented to overcome the deficiencies of early UNIX >>> systems, notably the lack of conformance to POSIX, and their impact >>> of the maintenance of Automake files. >>> >>> Autoconf was invented to overcome the deficiencies of Configure, >>> notably the sheer size and horror of the configure scripts, which >>> routinely consist of hundreds of thousands of lines of illegible >>> POSIX shell code. >> >> I was going to ask what was the invention to overcome the deficiencies >> of autoconf, but I think I figured it out ... rm -rf, right? > > Opinions differ but I'd tend to side with you :) No! Ada and gprbuild :) we finally got it right :) -- -- Stephe ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-27 11:46 ` Stephen Leake @ 2011-05-27 12:21 ` Dmitry A. Kazakov 2011-05-27 12:49 ` Make, Automake, Configure, Autocong, GPRbuild etc (was: Why no socket package in the standard ?) Ludovic Brenta 0 siblings, 1 reply; 121+ messages in thread From: Dmitry A. Kazakov @ 2011-05-27 12:21 UTC (permalink / raw) On Fri, 27 May 2011 07:46:43 -0400, Stephen Leake wrote: > Ludovic Brenta <ludovic@ludovic-brenta.org> writes: > >> Adam Beneschan writes on comp.lang.ada: >>> On May 25, 9:36�am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote: >>>> Yannick Duch�ne wrote on comp.lang.ada: >>>> >>>>> Peter C. Chapin a �crit: >>>>>> It also true that autoconf is a travesty... a throwback to a darker >>>>>> age when the POSIX standard did not exist (or at least was not >>>>>> widely implemented). >>>> >>>>> I do not know that much about Autoconf, so I can't really understand >>>>> what that mean and implies (someone else here also say a bit the >>>>> same as you too). >>>> >>>> Make was invented to overcome the deficiencies of C, notably the lack >>>> of modular programming and dependency management. >>>> >>>> Automake was invented to overcome the deficiencies of make, notably >>>> the poor maintainability of Makefiles. >>>> >>>> Configure was invented to overcome the deficiencies of early UNIX >>>> systems, notably the lack of conformance to POSIX, and their impact >>>> of the maintenance of Automake files. >>>> >>>> Autoconf was invented to overcome the deficiencies of Configure, >>>> notably the sheer size and horror of the configure scripts, which >>>> routinely consist of hundreds of thousands of lines of illegible >>>> POSIX shell code. >>> >>> I was going to ask what was the invention to overcome the deficiencies >>> of autoconf, but I think I figured it out ... rm -rf, right? >> >> Opinions differ but I'd tend to side with you :) > > No! Ada and gprbuild :) we finally got it right :) No, it was only one step forward. There are still mseinstall, rpmbuild, dpkg mess around there. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 121+ messages in thread
* Make, Automake, Configure, Autocong, GPRbuild etc (was: Why no socket package in the standard ?) 2011-05-27 12:21 ` Dmitry A. Kazakov @ 2011-05-27 12:49 ` Ludovic Brenta 2011-05-27 13:10 ` Make, Automake, Configure, Autocong, GPRbuild etc Dmitry A. Kazakov 0 siblings, 1 reply; 121+ messages in thread From: Ludovic Brenta @ 2011-05-27 12:49 UTC (permalink / raw) Dmitry A. Kazakov wrote on comp.lang.ada: > On Fri, 27 May 2011 07:46:43 -0400, Stephen Leake wrote: >> Ludovic Brenta writes: >>> Adam Beneschan writes on comp.lang.ada: >>>> Ludovic Brenta wrote: >>>>> Yannick Duchêne wrote on comp.lang.ada: >>>>>> Peter C. Chapin a écrit: >>>>>>> It also true that autoconf is a travesty... a throwback to a >>>>>>> darker age when the POSIX standard did not exist (or at least >>>>>>> was not widely implemented). >>>>>> >>>>>> I do not know that much about Autoconf, so I can't really >>>>>> understand what that mean and implies (someone else here >>>>>> also say a bit the same as you too). >>>>> >>>>> Make was invented to overcome the deficiencies of C, notably >>>>> the lack of modular programming and dependency management. >>>>> >>>>> Automake was invented to overcome the deficiencies of make, >>>>> notably the poor maintainability of Makefiles. >>>>> >>>>> Configure was invented to overcome the deficiencies of early >>>>> UNIX systems, notably the lack of conformance to POSIX, and >>>>> their impact on the maintenance of Automake files. >>>>> >>>>> Autoconf was invented to overcome the deficiencies of >>>>> Configure, notably the sheer size and horror of the configure >>>>> scripts, which routinely consist of hundreds of thousands of >>>>> lines of illegible POSIX shell code. >>>> >>>> I was going to ask what was the invention to overcome the >>>> deficiencies of autoconf, but I think I figured it out ... >>>> rm -rf, right? >>>> >>> Opinions differ but I'd tend to side with you :) >> >> No! Ada and gprbuild :) we finally got it right :) > > No, it was only one step forward. There are still mseinstall, > rpmbuild, dpkg mess around there. I think it is appropriate to separate the building of the binary software from the packaging for a particular target platform. For starters, the author of the software does not necessarily have access to all target operating systems. The package maintainer requires intimate knowledge of the target operating system, its package management system, its policies, the names of existing packages, etc. These are different concerns best addressed by different build systems. The things you mentioned (mseinstall, rpmbuild, dpkg) naturally sit on top of the build system provided as part of the software source distribution. I don't think they should be merged. That said, simplicity in both the build system and the packaging is of course a Good Thing. In Debian I've taken that approach to extremes at times, bypassing the fragile Autoconf-based build system of some software and replacing it with a single GPR project file and a couple of rules in the packaging Makefile. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Make, Automake, Configure, Autocong, GPRbuild etc 2011-05-27 12:49 ` Make, Automake, Configure, Autocong, GPRbuild etc (was: Why no socket package in the standard ?) Ludovic Brenta @ 2011-05-27 13:10 ` Dmitry A. Kazakov 2011-05-27 15:45 ` Ludovic Brenta 0 siblings, 1 reply; 121+ messages in thread From: Dmitry A. Kazakov @ 2011-05-27 13:10 UTC (permalink / raw) On Fri, 27 May 2011 05:49:26 -0700 (PDT), Ludovic Brenta wrote: > Dmitry A. Kazakov wrote on comp.lang.ada: >> On Fri, 27 May 2011 07:46:43 -0400, Stephen Leake wrote: >>> Ludovic Brenta writes: >>>> Adam Beneschan writes on comp.lang.ada: >>>>> Ludovic Brenta wrote: >>>>>> Yannick Duch�ne wrote on comp.lang.ada: >>>>>>> Peter C. Chapin a �crit: >>>>>>>> It also true that autoconf is a travesty... a throwback to a >>>>>>>> darker age when the POSIX standard did not exist (or at least >>>>>>>> was not widely implemented). >>>>>>> >>>>>>> I do not know that much about Autoconf, so I can't really >>>>>>> understand what that mean and implies (someone else here >>>>>>> also say a bit the same as you too). >>>>>> >>>>>> Make was invented to overcome the deficiencies of C, notably >>>>>> the lack of modular programming and dependency management. >>>>>> >>>>>> Automake was invented to overcome the deficiencies of make, >>>>>> notably the poor maintainability of Makefiles. >>>>>> >>>>>> Configure was invented to overcome the deficiencies of early >>>>>> UNIX systems, notably the lack of conformance to POSIX, and >>>>>> their impact on the maintenance of Automake files. >>>>>> >>>>>> Autoconf was invented to overcome the deficiencies of >>>>>> Configure, notably the sheer size and horror of the configure >>>>>> scripts, which routinely consist of hundreds of thousands of >>>>>> lines of illegible POSIX shell code. >>>>> >>>>> I was going to ask what was the invention to overcome the >>>>> deficiencies of autoconf, but I think I figured it out ... >>>>> rm -rf, right? >>>>> >>>> Opinions differ but I'd tend to side with you :) >>> >>> No! Ada and gprbuild :) we finally got it right :) >> >> No, it was only one step forward. There are still mseinstall, >> rpmbuild, dpkg mess around there. > > I think it is appropriate to separate the building of the binary > software from the packaging for a particular target platform. For > starters, the author of the software does not necessarily have access > to all target operating systems. The package maintainer requires > intimate knowledge of the target operating system, its package > management system, its policies, the names of existing packages, etc. Exactly why the things I mentioned are garbage. Why such an intimate knowledge is needed for packaging and is no more needed for building binaries? Why intimacy of system directories is more intimate than privacy of machine instructions, object and binary formats? > These are different concerns best addressed by different build > systems. The things you mentioned (mseinstall, rpmbuild, dpkg) > naturally sit on top of the build system provided as part of the > software source distribution. I don't think they should be merged. Not merged, abstracted away, packaging is a trivial concept comparing to compilation, optimization and linkage. UNIX tools are so complicated, because it is a long standing tradition to have it as broken as possible. If C, make, autoconf & Co. are that bad, why dpkg should be any better? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Make, Automake, Configure, Autocong, GPRbuild etc 2011-05-27 13:10 ` Make, Automake, Configure, Autocong, GPRbuild etc Dmitry A. Kazakov @ 2011-05-27 15:45 ` Ludovic Brenta 0 siblings, 0 replies; 121+ messages in thread From: Ludovic Brenta @ 2011-05-27 15:45 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: >> These are different concerns [building vs. packaging] best addressed >> by different build systems. The things you mentioned (mseinstall, >> rpmbuild, dpkg) naturally sit on top of the build system provided as >> part of the software source distribution. I don't think they should >> be merged. > > Not merged, abstracted away, packaging is a trivial concept comparing to > compilation, optimization and linkage. OK, then I agree with you. > UNIX tools are so complicated, because it is a long standing tradition > to have it as broken as possible. If C, make, autoconf & Co. are that > bad, why dpkg should be any better? I never said dpkg et al were any better; only that they address different problems than the build machinery used during development of the software. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-25 3:07 ` Shark8 2011-05-25 4:01 ` Yannick Duchêne (Hibou57) @ 2011-05-25 7:40 ` Georg Bauhaus 2011-05-25 10:48 ` Pascal Obry 2011-05-25 7:49 ` Ludovic Brenta 2 siblings, 1 reply; 121+ messages in thread From: Georg Bauhaus @ 2011-05-25 7:40 UTC (permalink / raw) On 5/25/11 5:07 AM, Shark8 wrote: > MS Windows has been POSIX complaint since 2000... Nice. ;-) ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-25 7:40 ` Why no socket package in the standard ? Georg Bauhaus @ 2011-05-25 10:48 ` Pascal Obry 0 siblings, 0 replies; 121+ messages in thread From: Pascal Obry @ 2011-05-25 10:48 UTC (permalink / raw) To: Georg Bauhaus Le 25/05/2011 09:40, Georg Bauhaus a �crit : > On 5/25/11 5:07 AM, Shark8 wrote: > >> MS Windows has been POSIX complaint since 2000... > > Nice. ;-) Well Windows 2000 had a POSIX subsystem (that probably almost nobody has ever used) completely separate to the Win32 one. This was done to be able to enter some european market IIRC, no? Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net - http://v2p.fr.eu.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver keys.gnupg.net --recv-key F949BD3B ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-25 3:07 ` Shark8 2011-05-25 4:01 ` Yannick Duchêne (Hibou57) 2011-05-25 7:40 ` Why no socket package in the standard ? Georg Bauhaus @ 2011-05-25 7:49 ` Ludovic Brenta 2 siblings, 0 replies; 121+ messages in thread From: Ludovic Brenta @ 2011-05-25 7:49 UTC (permalink / raw) Shark8 wrote on comp.lang.ada: > On May 24, 6:35 pm, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote: >> Yannick Duchêne writes on comp.lang.ada: >>> By the way, there is not event something like a standard OS (there may >>> be proprietaries or not, but none is standard). >> >> POSIX is a standard. A POSIX-compliant OS is a standard OS. An OS that >> refuses to comply with POSIX, or any other standard, is non-standard. >> >> Even MVS aka z/OS is standard in that sense. > > And, it is useful/instructive to realize that just because something > is a [part of a] standard does NOT mean that standard requires/says > anything useful. The reason why I mentioned POSIX is because the OP declared BSD sockets to be "the standard" and wanted this included in the Ada language definition. POSIX is "the standard" as far as sockets are concerned and POSIX.5 is "the standard Ada socket interface". But you are right; just because someone wants sockets in Ada does not mean that sockets are necessarily the best solution, or even useful at all, for the problem at hand. > This was something I learned from a mathematics professor (though > about 'definitions' rather than 'standards') and is important enough > that it should be remembered from time-to-time. > > {IIRC as far as POSIX is concerned, MS Windows has been POSIX > complaint since 2000... and this says NOTHING about how portable > binaries (or their sources) are between Windows and unix/linux > computers.} Actually it does; POSIX is all about source compatibility. Of course, if you want source compatibility, your application must comply with the standard, i.e. not use any non-standard features (i.e. you can use sockets but no GUI for example). This brings us back to the question of the usefulness of a particular standard for a particular problem. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 19:54 ` Ludovic Brenta 2011-05-24 20:10 ` Yannick Duchêne (Hibou57) @ 2011-05-25 2:47 ` Shark8 2011-05-25 9:12 ` Thomas Løcke 2 siblings, 0 replies; 121+ messages in thread From: Shark8 @ 2011-05-25 2:47 UTC (permalink / raw) On May 24, 2:54 pm, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote: > Oh, and I think I did mention GNAT.Sockets. So what are people > complaining about, again? > > -- > Ludovic Brenta. As near as I can tell "Ada doesn't have BSD's POSIX SOCKETS!!"... but I might be reading into the text what's not there. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 19:54 ` Ludovic Brenta 2011-05-24 20:10 ` Yannick Duchêne (Hibou57) 2011-05-25 2:47 ` Shark8 @ 2011-05-25 9:12 ` Thomas Løcke 2 siblings, 0 replies; 121+ messages in thread From: Thomas Løcke @ 2011-05-25 9:12 UTC (permalink / raw) On 05/24/2011 09:54 PM, Ludovic Brenta wrote: > Florist is a Free Software implementation of POSIX.5. The only nit you > might pick is that POSIX.5 is not included by reference in the Ada > Reference Manual. Personally I don't really care. If I need to and if > my target system is POSIX compliant (which it always is in practice), I > can write a standard Ada program using the standard sockets interface > which is part of the standard POSIX.5. > > Oh, and I think I did mention GNAT.Sockets. So what are people > complaining about, again? The Florist package from libre.adacore.com appears to have dumped POSIX sockets. At least I can't find them anywhere. Is there another Florist package available out there in the wild? Or am I just missing something completely obvious? -- Thomas Løcke Email: tl at ada-dk.org Web: http//:ada-dk.org http://identi.ca/thomaslocke ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 19:38 ` Yannick Duchêne (Hibou57) 2011-05-24 19:54 ` Ludovic Brenta @ 2011-05-24 21:42 ` Yannick Duchêne (Hibou57) 2011-05-24 23:09 ` Georg Bauhaus 2011-05-24 23:11 ` Georg Bauhaus 3 siblings, 0 replies; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-24 21:42 UTC (permalink / raw) Le Tue, 24 May 2011 21:38:03 +0200, Yannick Duchêne (Hibou57) <yannick_duchene@yahoo.fr> a écrit: >> - What should programs be able to do when communicating data >> along some network connection? > Answered by the socket specification : there are raw, datagram, stream, > blocking and none-blocking sockets, with IPv4 or IPv6 addresses. > Now, was thinking raw socket should be stripped away : these are rather limited on Windows according to a Winsock FAQs [*], and there are good reasons for that; this is because a raw socket overrides OS drivers. This in turn can lead to security risk and efficiency troubles to not talk about system stability (ouch). Raw socket is useful to implement your own protocol over IP… which make it of a limited audience; there is no way to expect Ada to support such a low level topic (would be like introducing direct device access along with file access). [*] I did not check for UNIcies. -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 19:38 ` Yannick Duchêne (Hibou57) 2011-05-24 19:54 ` Ludovic Brenta 2011-05-24 21:42 ` Yannick Duchêne (Hibou57) @ 2011-05-24 23:09 ` Georg Bauhaus 2011-05-24 23:25 ` Yannick Duchêne (Hibou57) 2011-05-25 9:06 ` Dmitry A. Kazakov 2011-05-24 23:11 ` Georg Bauhaus 3 siblings, 2 replies; 121+ messages in thread From: Georg Bauhaus @ 2011-05-24 23:09 UTC (permalink / raw) On 5/24/11 9:38 PM, Yannick Duchêne (Hibou57) wrote: > The POSIX specification seems to only differs in the way to get host by name / address. POSIX differs by being a standard. > What networking requirement ? In ISO Ada standardization, requirements seem the reasonable criteria by which to proceed. > This thread is not about OSI layers packages for Ada, it's only about sockets, Then use the sockets from the Ada-POSIX binding and say a few strong words when your Ada vendor wishes to talk you into its compiler specific language packages. > Be pragmatic Hell, no, I'm really fed up with cleaning up after pseudo pragmatism. When it comes to standardization, the topos "pragmatic" has a very different meaning, an Ada meaning, not one of advertising an existing binding for language blessing. One aspect is that is must be practically possible to implement a feature. I don't expect SMB/CIFS in Ada either, even though it is just as ubiquitous, and even when using it means being "pragmatic". >> 2. In the light of Ada's history regarding standardization, >> there is, I believe, networking knowledge that warrants more >> than canonization of a practical workaround---which might fail >> if requirements are actually different. > What workaround ? When the requirements include "networking", then why would a language make the requirements more specific than need be by providing a standard package restricted to BSD Socket techniques? >> - What should programs be able to do when communicating data >> along some network connection? > Answered by the socket specification : there are raw, datagram, stream, blocking and none-blocking sockets, with IPv4 or IPv6 addresses. IP? >> - Is sockets the right approach? Consider Erlang! > Seems Erlang actually provides sockets. More prominently, and crucially, Erlang has channels built into the language, even into the syntax. That's the things by which you compare, design, and standardize languages, IMHO. >> - Is sockets the right approach? Consider a CAN! > A can 8-) ? A CAN is real, it is wide spread, it is not that new, and has money associated with it. I'm not familiar with one, but I am aware of its existence, and certainly that is a network to be considered if networking stuff is to be added to Ada proper. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 23:09 ` Georg Bauhaus @ 2011-05-24 23:25 ` Yannick Duchêne (Hibou57) 2011-05-25 9:06 ` Dmitry A. Kazakov 1 sibling, 0 replies; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-24 23:25 UTC (permalink / raw) Le Wed, 25 May 2011 01:09:49 +0200, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> a écrit: > More prominently, and crucially, Erlang has channels > built into the language Yes, channels is a good abstraction. -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 23:09 ` Georg Bauhaus 2011-05-24 23:25 ` Yannick Duchêne (Hibou57) @ 2011-05-25 9:06 ` Dmitry A. Kazakov 1 sibling, 0 replies; 121+ messages in thread From: Dmitry A. Kazakov @ 2011-05-25 9:06 UTC (permalink / raw) On Wed, 25 May 2011 01:09:49 +0200, Georg Bauhaus wrote: > A CAN is real, it is wide spread, it is not that new, and > has money associated with it. Yes, but 1. CAN is dying, to be superseded by EtherCAT, XCP etc. 2. CAN requires special adaptors (vendors are IXXAT, Vector, NI), which have no standardized interface. You need to standardize that interface first, i.e. do the job sockets did for Ethernet adapters. 3. Raw CAN is only 20% or so. Most vendors use CAN Open on its top. CAN Open is an utter mess. 4. Raw CAN is useless at the application level, because it has only 8 bytes of data (if you don't mess with IDs, which would give another 11 bits). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 19:38 ` Yannick Duchêne (Hibou57) ` (2 preceding siblings ...) 2011-05-24 23:09 ` Georg Bauhaus @ 2011-05-24 23:11 ` Georg Bauhaus 2011-05-24 23:28 ` Yannick Duchêne (Hibou57) 3 siblings, 1 reply; 121+ messages in thread From: Georg Bauhaus @ 2011-05-24 23:11 UTC (permalink / raw) On 5/24/11 9:38 PM, Yannick Duchêne (Hibou57) wrote: >> I doubt that the best answer to these questions can >> be summed up by saying, "Mirror Posix sockets!". > Why ? Because design of networked applications in general, following a language standard, cannot be addressed by the QoI of some Unix library only. In particular when this is about language standardization. Millions of programs run fairly well and call C library functions. That's not a compelling reason to add more from the C library to the Ada standard, is it? Threads, POSIX style threads, are ubiquitous as well. Should they get an Annex, too? ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 23:11 ` Georg Bauhaus @ 2011-05-24 23:28 ` Yannick Duchêne (Hibou57) 2011-05-24 23:57 ` Georg Bauhaus 0 siblings, 1 reply; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-24 23:28 UTC (permalink / raw) Le Wed, 25 May 2011 01:11:47 +0200, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> a écrit: > Threads, POSIX style threads, are ubiquitous as well. > Should they get an Annex, too? Ada has task, POSIX threads may be just a flavor or a material to start with to implement Ada task as specified by Ada. -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 23:28 ` Yannick Duchêne (Hibou57) @ 2011-05-24 23:57 ` Georg Bauhaus 2011-05-25 0:36 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 121+ messages in thread From: Georg Bauhaus @ 2011-05-24 23:57 UTC (permalink / raw) On 5/25/11 1:28 AM, Yannick Duchêne (Hibou57) wrote: > Le Wed, 25 May 2011 01:11:47 +0200, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> a écrit: >> Threads, POSIX style threads, are ubiquitous as well. >> Should they get an Annex, too? > Ada has task, POSIX threads may be just a flavor or a material to start with to implement Ada task as specified by Ada. Exactly. And the same may be true of BSD Sockets. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 23:57 ` Georg Bauhaus @ 2011-05-25 0:36 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-25 0:36 UTC (permalink / raw) Le Wed, 25 May 2011 01:57:36 +0200, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> a écrit: > On 5/25/11 1:28 AM, Yannick Duchêne (Hibou57) wrote: >> Le Wed, 25 May 2011 01:11:47 +0200, Georg Bauhaus >> <rm.dash-bauhaus@futureapps.de> a écrit: >>> Threads, POSIX style threads, are ubiquitous as well. >>> Should they get an Annex, too? >> Ada has task, POSIX threads may be just a flavor or a material to start >> with to implement Ada task as specified by Ada. > > Exactly. And the same may be true of BSD Sockets. Nice to meet you here Georg :) -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 7:07 ` Maciej Sobczak 2011-05-24 7:19 ` Thomas Løcke @ 2011-05-24 7:25 ` Dmitry A. Kazakov 2011-05-24 21:22 ` Maciej Sobczak 2011-05-24 22:04 ` Yannick Duchêne (Hibou57) 1 sibling, 2 replies; 121+ messages in thread From: Dmitry A. Kazakov @ 2011-05-24 7:25 UTC (permalink / raw) On Tue, 24 May 2011 00:07:55 -0700 (PDT), Maciej Sobczak wrote: > On 24 Maj, 08:24, georg bauhaus <rmhost.bauh...@maps.arcor.de> wrote: > >> Which modern, post 1990, language supports sockets in the language? > > In the language? Probably none, as this does not belong to the > language. That is an interesting question. Actually sockets could belong to the language. Consider for example the select statement containing alternatives of a socket's select. > It might, however, be part of the standard library. There are many difficulties on that path. When people are demanding sockets they forget that beyond TCP/IP and UDP there is a lot of other stuff communicated over sockets, e.g. multi-cast protocols, raw sockets and so on. These are barely standardized. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 7:25 ` Dmitry A. Kazakov @ 2011-05-24 21:22 ` Maciej Sobczak 2011-05-25 9:14 ` Dmitry A. Kazakov 2011-05-24 22:04 ` Yannick Duchêne (Hibou57) 1 sibling, 1 reply; 121+ messages in thread From: Maciej Sobczak @ 2011-05-24 21:22 UTC (permalink / raw) On 24 Maj, 09:25, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > > In the language? Probably none, as this does not belong to the > > language. > > That is an interesting question. Actually sockets could belong to the > language. Consider for example the select statement containing alternatives > of a socket's select. Still, they (sockets) don't have to be part of the language to be select-ready. It is enough to make them protected objects with appropriate entries. The problem is, neither Ada nor the operating system make it easy to do this kind of integration in a sufficiently efficient way. Which brings some interesting point for the future language evolution: make it possible to write "select hooks" - that is, protected procedures that are called automatically when any task attempts to call some entry in any way, including its use in the select statement. Something like: protected Example is entry Lets_Go when Ready is ... -- this procedure is called when Lets_Go is used -- it is executed *before* evaluation of the barrier in Lets_Go procedure Lets_Go_Hook is begin -- ... -- perhaps set Ready or whatever end Lets_Go_Hook; private Ready : Boolean; end Example; With this language feature I can imagine a relatively efficient implementation of a socket library where socket objects are selectable in the Ada sense. Nitpick: implement Ada 2005 before that. Please. ;-) > > It might, however, be part of the standard library. > > There are many difficulties on that path. When people are demanding sockets > they forget that beyond TCP/IP and UDP there is a lot of other stuff > communicated over sockets, e.g. multi-cast protocols, raw sockets and so > on. These are barely standardized. So what? Standardize the stuff that is obvious to standardize and don't throw the baby out with the water. Just don't give people more reasons for not learning Ada. -- Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 21:22 ` Maciej Sobczak @ 2011-05-25 9:14 ` Dmitry A. Kazakov 2011-05-25 11:54 ` Maciej Sobczak 0 siblings, 1 reply; 121+ messages in thread From: Dmitry A. Kazakov @ 2011-05-25 9:14 UTC (permalink / raw) On Tue, 24 May 2011 14:22:42 -0700 (PDT), Maciej Sobczak wrote: > On 24 Maj, 09:25, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: > >>> In the language? Probably none, as this does not belong to the >>> language. >> >> That is an interesting question. Actually sockets could belong to the >> language. Consider for example the select statement containing alternatives >> of a socket's select. > > Still, they (sockets) don't have to be part of the language to be > select-ready. It is enough to make them protected objects with > appropriate entries. 1. We need to be able to cancel connect/accept/send/receive from an AST or timed entry call. 2. We should never do any I/O related stuff on the context of a protected action. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-25 9:14 ` Dmitry A. Kazakov @ 2011-05-25 11:54 ` Maciej Sobczak 2011-05-25 12:26 ` Dmitry A. Kazakov 0 siblings, 1 reply; 121+ messages in thread From: Maciej Sobczak @ 2011-05-25 11:54 UTC (permalink / raw) On 25 Maj, 11:14, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > > Still, they (sockets) don't have to be part of the language to be > > select-ready. It is enough to make them protected objects with > > appropriate entries. > > 1. We need to be able to cancel connect/accept/send/receive from an AST or > timed entry call. No problem, use non-blocking I/O as an underlying implementation. > 2. We should never do any I/O related stuff on the context of a protected > action. No problem - the protected object need not represent the socket directly, it might as well be a proxy only representing its current state, in which case no I/O happens in the protected context. Both solutions above have been used in YAMI4: http://www.inspirel.com/yami4/ where in the high-level Ada interface outgoing messages are represented as protected objects exactly with the purpose of making them selectable. It is true, however, that YAMI4 operates at a much higher level of abstraction (messages vs. sockets) and this type of library design might not be adequate with something as low-level as sockets. On the other hand, asynchronous communication services (instead of naive use of basic socket API) could potentially solve this problem. Looks like an interesting project idea... -- Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-25 11:54 ` Maciej Sobczak @ 2011-05-25 12:26 ` Dmitry A. Kazakov 0 siblings, 0 replies; 121+ messages in thread From: Dmitry A. Kazakov @ 2011-05-25 12:26 UTC (permalink / raw) On Wed, 25 May 2011 04:54:20 -0700 (PDT), Maciej Sobczak wrote: > On 25 Maj, 11:14, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: > >>> Still, they (sockets) don't have to be part of the language to be >>> select-ready. It is enough to make them protected objects with >>> appropriate entries. >> >> 1. We need to be able to cancel connect/accept/send/receive from an AST or >> timed entry call. > > No problem, use non-blocking I/O as an underlying implementation. The problem is not the implementation, but the interface. If sockets to be a part of the language they should use language means for handling synchronization issues. >> 2. We should never do any I/O related stuff on the context of a protected >> action. > > No problem - the protected object need not represent the socket > directly, it might as well be a proxy only representing its current > state, in which case no I/O happens in the protected context. I meant handling the states, doing I/O from a protected action would be just illegal. But it is also inadmissible to handle read/write completion from there. Yes you could release some waiting tasks and pass the I/O buffer to one of them, this is how sockets are dealt with now. Such a clumsy design does not deserve standardization, IMO. I think that "task" is a more suitable abstraction for socket. task type Connect_Socket is entry Connect (...); entry Receive (...); entry Send (...) end Socket; -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 7:25 ` Dmitry A. Kazakov 2011-05-24 21:22 ` Maciej Sobczak @ 2011-05-24 22:04 ` Yannick Duchêne (Hibou57) 2011-05-25 9:19 ` Dmitry A. Kazakov 1 sibling, 1 reply; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-24 22:04 UTC (permalink / raw) Le Tue, 24 May 2011 09:25:38 +0200, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> a écrit: > There are many difficulties on that path. When people are demanding > sockets > they forget that beyond TCP/IP and UDP there is a lot of other stuff > communicated over sockets This can be abstracted down. The purpose of different protocols is not to make things more complex, but to provide different level of reliability, which make some like streams and some others not. Unlike Unicode encoding introduced in Ada 2012, the protocols list is not closed, however, TCP/IP and UDP/IP are still the widely used. This could be compared to the topic old character code pages : there was many, but Ada still supported the most widely used one beyond pure ANSI : ISO 8859-1. There may be no worry to support TCP/IP and UDP/IP above any others, the same way. A question : what is the state of the use of IP based protocols in the embedded-boards area ? I use to see references to TCP and UDP usages in some embedded stuffs, but I am not mastering anything in that area… unlike many others here. -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 22:04 ` Yannick Duchêne (Hibou57) @ 2011-05-25 9:19 ` Dmitry A. Kazakov 0 siblings, 0 replies; 121+ messages in thread From: Dmitry A. Kazakov @ 2011-05-25 9:19 UTC (permalink / raw) On Wed, 25 May 2011 00:04:19 +0200, Yannick Duch�ne (Hibou57) wrote: > Le Tue, 24 May 2011 09:25:38 +0200, Dmitry A. Kazakov > <mailbox@dmitry-kazakov.de> a �crit: >> There are many difficulties on that path. When people are demanding sockets >> they forget that beyond TCP/IP and UDP there is a lot of other stuff >> communicated over sockets > This can be abstracted down. Hmm, how would you abstract, say, PGM? > A question : what is the state of the use of IP based protocols in the > embedded-boards area? VxWorks provides a full implementation of TCP/IP stack and UDP. We are using both (through GNAT sockets). I have no idea about bare-boards. I guess it depends on the board. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 6:24 ` georg bauhaus 2011-05-24 7:07 ` Maciej Sobczak @ 2011-05-24 19:17 ` Yannick Duchêne (Hibou57) 2011-05-24 19:30 ` J-P. Rosen 2011-05-24 22:39 ` Georg Bauhaus 1 sibling, 2 replies; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-24 19:17 UTC (permalink / raw) Le Tue, 24 May 2011 08:24:40 +0200, georg bauhaus <rmhost.bauhaus@maps.arcor.de> a écrit: > Two questions: > > Which modern, post 1990, language supports sockets in the language? As pointed by others in this thread (with reference and examples) as well as pointed in the opening message, the answer is : near to all well known languages. Although optional, even a so much few famous language as SML, makes reference to it in its standard library: http://www.standardml.org/Basis/overview.html#section:8 > Which language supports features of modern file storage? (That is, file > attributes, files as documents (standardized ca. 1984),... ) > Note that these capabilities are available with file archives, too. These are not as much standard as sockets are. As an example, file attributes handling are always annotated with platform provision in the Python standard library. Even such a basic things to me, as file's creation time, is not universally available (does not exist in standard Linux distribution at least). This is not comparable to widespread of sockets. -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 19:17 ` Yannick Duchêne (Hibou57) @ 2011-05-24 19:30 ` J-P. Rosen 2011-05-24 19:49 ` Yannick Duchêne (Hibou57) 2011-05-24 22:39 ` Georg Bauhaus 1 sibling, 1 reply; 121+ messages in thread From: J-P. Rosen @ 2011-05-24 19:30 UTC (permalink / raw) Le 24/05/2011 21:17, Yannick Duchêne (Hibou57) a écrit : >> Which modern, post 1990, language supports sockets in the language? > As pointed by others in this thread (with reference and examples) as > well as pointed in the opening message, the answer is : near to all well > known languages. > Hmm... all languages I've seen mentionne so far have no official standard. As long as the language is designed by a single person/company/body, providing bindings as the author pleases is easy. When it comes to standardization, you have to account for various operating systems and lots of "details" that make it a lot more difficult. Matthew Heaney (I hope I got it spelled right) had a very nice containers library. Ask him about what happened when turning it into a standard... ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 19:30 ` J-P. Rosen @ 2011-05-24 19:49 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-24 19:49 UTC (permalink / raw) Le Tue, 24 May 2011 21:30:39 +0200, J-P. Rosen <rosen@adalog.fr> a écrit: > Hmm... all languages I've seen mentionne so far have no official > standard. > > As long as the language is designed by a single person/company/body, > providing bindings as the author pleases is easy. When it comes to > standardization, you have to account for various operating systems and > lots of "details" that make it a lot more difficult. If these languages was mentioned here, this was not to suggest the Ada standard should be managed the same way these languages are. You're right to point these languages are not standardized (and that's really a problem). But the topic is not concerned about it : if the fact "socket are part of many and many libraries" was introduced, this was to point how much useful it is to softwares… especially with the increase of remote communication needs, servers and things looking like servers, client-server design, etc. This is, I feel, as much demanded as real-time (and safety) features. > Matthew Heaney (I hope I got it spelled right) had a very nice > containers library. Ask him about what happened when turning it into a > standard... Thanks for the notice -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 19:17 ` Yannick Duchêne (Hibou57) 2011-05-24 19:30 ` J-P. Rosen @ 2011-05-24 22:39 ` Georg Bauhaus 2011-05-24 22:54 ` Yannick Duchêne (Hibou57) 1 sibling, 1 reply; 121+ messages in thread From: Georg Bauhaus @ 2011-05-24 22:39 UTC (permalink / raw) On 5/24/11 9:17 PM, Yannick Duchêne (Hibou57) wrote: > Le Tue, 24 May 2011 08:24:40 +0200, georg bauhaus <rmhost.bauhaus@maps.arcor.de> a écrit: >> Two questions: >> >> Which modern, post 1990, language supports sockets in the language? > As pointed by others in this thread (with reference and examples) as well as pointed in the opening message, the answer is : near to all well known languages. It says "hard to find a modern language that doesn't support the Sockets API". Ada does support the sockets API, of course, just like the others do. Pretty much the same way in all bindings. Let's see the well known "modern" languages of post 1990. Java, C#. Well, maybe the P* scripting languages, though these have roots/version inthe late 1980s. Will sockets APIs help with JVM or .NET? On the contrary: Ada -> JVM gives you the best sockets for the platform directly, *not* by having it added to the Ada standard, but by simply offering the JVM/.NET classes. Which aren't BSD style. > Although optional, even a so much few famous language as SML, ML. A language that got started in the 1970s. SML, being written in SML and C, got a binding to BSD internet sockets. A fairly thin interface if you look close. I mentioned extended attributes and no standardization at all because in this case 1) standardization work need not refer to any implementation; it can stay purely abstract. 2) virtually all standard file systems support EAs 3) virtually all archive formats support EAs 4) many programs make assumptions about EAs of files (such as the type of a file's contents) but lack Ada style explicitness. That' another standard that should live outside language definitions. While fewer modern OSs have support BSD sockets (remember, TCP/IP was an add-on to OS/2 and Windows, and to larger IBM computers, I believe), I thought that - if Ada was to standardize a binding, then that's new. Something standard that is not about an abstraction, but rather about including some historic incident like BSD sockets, in the language description. - it seems completely sufficient to agree, outside the standard, on an API that can be used with any Ada compiler. No standardization is needed at all. - Wait. We *do* have Ada Posix binding with an ISO number; since Posix sockets do the trick, there is no need to add them to Ada. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 22:39 ` Georg Bauhaus @ 2011-05-24 22:54 ` Yannick Duchêne (Hibou57) 2011-05-24 23:54 ` Georg Bauhaus 0 siblings, 1 reply; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-24 22:54 UTC (permalink / raw) Le Wed, 25 May 2011 00:39:58 +0200, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> a écrit: > - if Ada was to standardize a binding, then that's new. > Something standard that is not about an abstraction, That's about abstraction, otherwise socket could be defined atop of Ada streams (defining pipes over Ada streams, would be OK as an example, but defining sockets above Ada streams, would not). > but > rather about including some historic incident like BSD > sockets, in the language description. Where do you think Unicode (now partially supported by Ada) is rooted ? Answer : one of the topmost code page at sometime. > - it seems completely sufficient to agree, outside the standard, > on an API that can be used with any Ada compiler. No > standardization is needed at all. OK. Let say it is not required, so "not" may be an option. But to answer the topic, you should now give an answer to why this should not. If "don't" is an option, "do" is still an option too. > - Wait. We *do* have Ada Posix binding with an ISO number; since > Posix sockets do the trick, there is no need to add them to Ada. Bringing all of POSIX just to get sockets, is too heavy. And sockets can live without POSIX (in some extent, even POSIX could live without sockets, which is not a major part of this standard, as far as I understand it). -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 22:54 ` Yannick Duchêne (Hibou57) @ 2011-05-24 23:54 ` Georg Bauhaus 2011-05-25 0:34 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 121+ messages in thread From: Georg Bauhaus @ 2011-05-24 23:54 UTC (permalink / raw) On 5/25/11 12:54 AM, Yannick Duchêne (Hibou57) wrote: > Le Wed, 25 May 2011 00:39:58 +0200, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> a écrit: >> - if Ada was to standardize a binding, then that's new. >> Something standard that is not about an abstraction, > That's about abstraction, An abstraction like "network data communication" which would be similar to Sequential File. Whichever way the latter happens to be available in the external environment, you can open the file, read or write items, close it, etc. >> but >> rather about including some historic incident like BSD >> sockets, in the language description. > Where do you think Unicode (now partially supported by Ada) is rooted ? http://www.unicode.org/history/earlyyears.html Specifically, you can see how requirements were weighed and how the process didn't just revolve around just one precendent. They also noticed how they had been wrong assuming things. (In the following quote, I have replaced some Unicode specifics with letters to better show the general pattern in the process): "But all of a sudden, we could see the light go on in both of our faces: we had assumed that the standard ABC was a XYZ standard. We were so, so wrong. You needed WYZX to represent even the most common N. Worse yet, some P could be both G and H. We weren't in Kansas anymore!" I'm guessing that the same is going to happen if the Ada standard were to quickly adopt BSD Sockets. >> - it seems completely sufficient to agree, outside the standard, >> on an API that can be used with any Ada compiler. No >> standardization is needed at all. > OK. Let say it is not required, so "not" may be an option. Because a language standard is about things more general than a specific networking library. >> - Wait. We *do* have Ada Posix binding with an ISO number; since >> Posix sockets do the trick, there is no need to add them to Ada. > Bringing all of POSIX just to get sockets, is too heavy. The POSIX binding is ISO standardized. In a POSIX environment, such as Unix, Ada compilers would naturally be running on POSIX anyway. So it's already there. If not, then adding the binding will not mean that by using POSIX sockets you will also be dragging in POSIX threads, IMHO?. A language that allows a Max_Tasks => 0 restriction but threads when a programmer wishes to with a POSIX package? ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 23:54 ` Georg Bauhaus @ 2011-05-25 0:34 ` Yannick Duchêne (Hibou57) 2011-05-25 1:20 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-25 0:34 UTC (permalink / raw) Le Wed, 25 May 2011 01:54:02 +0200, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> a écrit: > An abstraction like "network data communication" which > would be similar to Sequential File. Whichever way the > latter happens to be available in the external environment, > you can open the file, read or write items, close it, > etc. IPC have unavoidable properties, which are as real as physics is, and which cannot be expressed in terms of file access. File access is somewhat pure and simpler than IPC, and is just a particular case of IPC, which (the latter) is wider. > http://www.unicode.org/history/earlyyears.html > > Specifically, you can see how requirements were weighed > and how the process didn't just revolve around just one > precendent. Will read this later (I interested in Unicode since very long). Any way, Unicode code points still match ISO 8859-1 (which does not require mapping). > "But all of a sudden, we could see the light go on in both > of our faces: we had assumed that the standard ABC was a XYZ > standard. We were so, so wrong. You needed WYZX to represent > even the most common N. Worse yet, some P could be both G > and H. We weren't in Kansas anymore!" Oops, will have to read this again and again before I am sure I've understood (where does this quote originates ? a novel ?). > I'm guessing that the same is going to happen if the Ada > standard were to quickly adopt BSD Sockets. Stooooop. I agreed for a better abstraction multiple since your last replies ;) >>> - it seems completely sufficient to agree, outside the standard, >>> on an API that can be used with any Ada compiler. No >>> standardization is needed at all. >> OK. Let say it is not required, so "not" may be an option. > > Because a language standard is about things more general > than a specific networking library. You said this after you though I wanted BSD sockets, strictly. But that is not, I want, not BSD sockets, but the functionalities BSD sockets provides. And these are not available through the file nor the stream interface of actual Ada. -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-25 0:34 ` Yannick Duchêne (Hibou57) @ 2011-05-25 1:20 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-25 1:20 UTC (permalink / raw) Le Wed, 25 May 2011 02:34:16 +0200, Yannick Duchêne (Hibou57) <yannick_duchene@yahoo.fr> a écrit: >> "But all of a sudden, we could see the light go on in both >> of our faces: we had assumed that the standard ABC was a XYZ >> standard. We were so, so wrong. You needed WYZX to represent >> even the most common N. Worse yet, some P could be both G >> and H. We weren't in Kansas anymore!" > Oops, will have to read this again and again before I am sure I've > understood (where does this quote originates ? a novel ?). OK, you did a rewritten excerpt of http://www.unicode.org/history/earlyyears.html Now I understand (at least I feel) -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 1:22 Why no socket package in the standard ? Yannick Duchêne (Hibou57) 2011-05-24 1:39 ` Yannick Duchêne (Hibou57) 2011-05-24 6:24 ` georg bauhaus @ 2011-05-24 12:38 ` AdaMagica 2011-05-24 15:00 ` Yannick Duchêne (Hibou57) 2011-05-24 18:29 ` anon 2011-06-02 2:41 ` Randy Brukardt 4 siblings, 1 reply; 121+ messages in thread From: AdaMagica @ 2011-05-24 12:38 UTC (permalink / raw) On 24 Mai, 03:22, Yannick Duchêne (Hibou57) <yannick_duch...@yahoo.fr> wrote: > There is AdaSockets,http://www.rfc1149.net/devel/adasockets.html > Nice, but still not part of the standard, and I cannot see a reason why, See Ada 2005 Rationale http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-9-3-8.html ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 12:38 ` AdaMagica @ 2011-05-24 15:00 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-24 15:00 UTC (permalink / raw) Le Tue, 24 May 2011 14:38:56 +0200, AdaMagica <christ-usch.grein@t-online.de> a écrit: > See Ada 2005 Rationale > http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-9-3-8.html Thanks AdaMagica :) -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 1:22 Why no socket package in the standard ? Yannick Duchêne (Hibou57) ` (2 preceding siblings ...) 2011-05-24 12:38 ` AdaMagica @ 2011-05-24 18:29 ` anon 2011-05-24 19:08 ` Yannick Duchêne (Hibou57) 2011-06-02 2:41 ` Randy Brukardt 4 siblings, 1 reply; 121+ messages in thread From: anon @ 2011-05-24 18:29 UTC (permalink / raw) Ada was designed to be "Portable" and "System Independent and Secure" which means that most system library packages such as Sockets are not apart of the main Ada language. To the Ada programmer, Ada removes the concerns of how it communicates with other components, like from server task communication to and from a client task. No, programmer needs to know if the system is using system-wide stacks or queues or if the communication is via a parallel, serial or network port. This may explain why "Annex E. Distributed Systems" is thin in it scope. The main problem is that since Ada 95 the design has been more toward "oops" programming than modifying the run-time system to keep up with new technology. Plus, there is no language that contains Sockets as apart of it standard library. C, C++, Java, Fortran, etc. have no references to Sockets in their standard language. Sockets is an add on system library package to all languages and that includes Ada. For Ada, the main problem here is that most Ada programmers spend their time writing application and not "Add On" libraries for Ada. They just bind what they need instead of building the complete library package for future projects. In <op.vvyoslycule2fv@douda-yannick>, =?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= writes: >Hello one again, > >According to http://www.ibm.com/developerworks/linux/library/l-sockpit/ >> First introduced into the 4.2 BSD UNIX=C2=AE operating system, >> the Sockets API is now a standard feature of any operating system.In = > >> fact, it's hard to find a modern language that doesn'tsupport the = > >> Sockets API. > >This may help Ada (and be useful too) to add sockets in standard package= >s. > >There is AdaSockets, http://www.rfc1149.net/devel/adasockets.html >which has cool licensing terms: >> This library lets you use BSD sockets from Ada (TCP, UDP and multicast= >). >> It is released under the GNAT Modified General Public License, which = > >> means >> that you can freely AdaSockets in a proprietary application without = > >> having >> it contaminate your code. > >Nice, but still not part of the standard, and I cannot see a reason why,= > = > >such a fundamental thing, at least as fundamental as file access and = > >standard I/O streams are, is not part of the standard packages. May be a= > = > >candidate for an optional annex at least ? Already discussed or not ? > >Sorry for any inconvenience if I ever missed something there (this = > >question seems so much basic I can't avoid feeling I've missed something= >). > > >-- = > >Si les chats miaulent et font autant de vocalises bizarres, c=E2=80=99es= >t pas pour = > >les chiens. >=E2=80=9C c++; /* this makes c bigger but returns the old value */ =E2=80= >=9D [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 18:29 ` anon @ 2011-05-24 19:08 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 121+ messages in thread From: Yannick Duchêne (Hibou57) @ 2011-05-24 19:08 UTC (permalink / raw) Le Tue, 24 May 2011 20:29:56 +0200, <anon@att.net> a écrit: > Plus, there is no language that contains Sockets as apart of it standard > library. C, C++, Java, Fortran, etc. have no references to Sockets in > their standard language. Yes, but all of these comes with near-standard sockets library (near-standard, because there is one and single you can always rely on, even WSA sockets are close enough to BSD sockets). Moreover, nothings disallow Ada to be ahead, … one more time. -- Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour les chiens. “ c++; /* this makes c bigger but returns the old value */ ” [Anonymous] ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-05-24 1:22 Why no socket package in the standard ? Yannick Duchêne (Hibou57) ` (3 preceding siblings ...) 2011-05-24 18:29 ` anon @ 2011-06-02 2:41 ` Randy Brukardt 2011-06-02 13:55 ` Florian Weimer 4 siblings, 1 reply; 121+ messages in thread From: Randy Brukardt @ 2011-06-02 2:41 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1608 bytes --] "Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message news:op.vvyoslycule2fv@douda-yannick... >Hello one again, > >According to http://www.ibm.com/developerworks/linux/library/l-sockpit/ >> First introduced into the 4.2 BSD UNIX� operating system, >> the Sockets API is now a standard feature of any operating system.In >> fact, it's hard to find a modern language that doesn'tsupport the >> Sockets API. > >This may help Ada (and be useful too) to add sockets in standard packages. We had a project for this in Ada 2005, but no one stepped forward to do the extensive work needed. After the effort to create the wording for Ada.Directories, I wasn't about to volunteer to create any more packages... Defining a package spec is easy enough (many have done that), but describing what it does in a target-independent way is a much bigger job. Note that there is no ISO standard (so far as I'm aware) that describes BSD Sockets, so we'd have to recreate at least some description of those in the Ada Standard. Languages without formal standards (or formal standards for their libraries) don't have this problem -- the libraries do whatever they do, and often that is good enough. And that's fine for Ada too, so long as you don't expect the Standard to include such things... [Note that Ada also doesn't include a standard GUI, a standard program run ("exec"), or many other things that are widely used. We tried to do "exec" and couldn't come up with a consistent definition of what it does -- and then gave up.] Randy. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-06-02 2:41 ` Randy Brukardt @ 2011-06-02 13:55 ` Florian Weimer 2011-06-02 20:38 ` anon 2011-06-02 21:34 ` Randy Brukardt 0 siblings, 2 replies; 121+ messages in thread From: Florian Weimer @ 2011-06-02 13:55 UTC (permalink / raw) * Randy Brukardt: > Defining a package spec is easy enough (many have done that), but describing > what it does in a target-independent way is a much bigger job. Note that > there is no ISO standard (so far as I'm aware) that describes BSD Sockets, > so we'd have to recreate at least some description of those in the Ada > Standard. I believe they are part of ISO/IEC 9945:2002. However, it turns out that there already is an ISO standard for an Ada interface to BSD sockets (which happens to include a file system interface, too): ISO/IEC 14519:2001. Efforts to standardize operating system interfaces should rather concentrate on liberating that document to increase adoption, addressing open issues, if necessary; and not be wasted on duplicating it. I think this offers a cautionary tale why proprietary standards can be really, really bad. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-06-02 13:55 ` Florian Weimer @ 2011-06-02 20:38 ` anon 2011-06-02 20:44 ` Florian Weimer 2011-06-02 21:18 ` J-P. Rosen 2011-06-02 21:34 ` Randy Brukardt 1 sibling, 2 replies; 121+ messages in thread From: anon @ 2011-06-02 20:38 UTC (permalink / raw) If the ARG was doing it job then RM 1.2 Normative References would list a number of extra IEC/ISO standards. But it seams that the only standards are for the character set and a couple of references standards for external languages like C and Fortran. I think most would say where's the IEEE Math standards 754-2008 before adopting a BSD standard, IEEE 754 standard, have existed since 1985 before Ada 95, so why it is not include in Ada 2005 and beyond. So, when you get into "Standards", Ada needs a great deal of work. In <87k4d4z6b6.fsf@mid.deneb.enyo.de>, Florian Weimer <fw@deneb.enyo.de> writes: >* Randy Brukardt: > >> Defining a package spec is easy enough (many have done that), but describing >> what it does in a target-independent way is a much bigger job. Note that >> there is no ISO standard (so far as I'm aware) that describes BSD Sockets, >> so we'd have to recreate at least some description of those in the Ada >> Standard. > >I believe they are part of ISO/IEC 9945:2002. > >However, it turns out that there already is an ISO standard for an Ada >interface to BSD sockets (which happens to include a file system >interface, too): ISO/IEC 14519:2001. Efforts to standardize operating >system interfaces should rather concentrate on liberating that >document to increase adoption, addressing open issues, if necessary; >and not be wasted on duplicating it. I think this offers a cautionary >tale why proprietary standards can be really, really bad. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-06-02 20:38 ` anon @ 2011-06-02 20:44 ` Florian Weimer 2011-06-02 21:18 ` J-P. Rosen 1 sibling, 0 replies; 121+ messages in thread From: Florian Weimer @ 2011-06-02 20:44 UTC (permalink / raw) > I think most would say where's the IEEE Math standards 754-2008 before > adopting a BSD standard, IEEE 754 standard, have existed since 1985 > before Ada 95, so why it is not include in Ada 2005 and beyond. Does Ada really use the IEEE 754 floating point model? I don't think so---the RM allows optimizations which are generally frowned upon for reasons I do not entirely understand (such as increasing the accuracy of operations by reassociation). ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-06-02 20:38 ` anon 2011-06-02 20:44 ` Florian Weimer @ 2011-06-02 21:18 ` J-P. Rosen 2011-06-04 21:35 ` anon 1 sibling, 1 reply; 121+ messages in thread From: J-P. Rosen @ 2011-06-02 21:18 UTC (permalink / raw) Le 02/06/2011 22:38, anon@att.net a �crit : > I think most would say where's the IEEE Math standards 754-2008 before > adopting a BSD standard, IEEE 754 standard, have existed since 1985 > before Ada 95, so why it is not include in Ada 2005 and beyond. > Because there are many machines that do not conform to IEEE, and it is widely recognized that forcing IEEE arithmetic was a major flaw in Java. Ada did not make the same error. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Adalog a d�m�nag� / Adalog has moved: 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-06-02 21:18 ` J-P. Rosen @ 2011-06-04 21:35 ` anon 2011-06-05 8:39 ` J-P. Rosen 0 siblings, 1 reply; 121+ messages in thread From: anon @ 2011-06-04 21:35 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1965 bytes --] Why should the problem with Java and IEEE-754 cause any problem with Ada? Ada is designed with System Independent. No other Language, System or Virtual Machine should influent the design of Ada. And this includes the CPU and/or FPU. Note: Library package "Interfaces" and it sub-packages are be used to interface between language and system but these packages should not alter Ada or influent its design. An example is: type Big_Integer is range - 2 ** 255 - 1 .. 2 ** 255 - 1 ; -- or type Big_Float is digits 64 ; which only a few special systems can handle those types but Ada should so long as the functions are defined for this type. Either by the compiler or external math library during linking. Now, having a generic Ada math package or design would insure at least for math that Ada is System Independent. And using a standard like IEEE 754 would insure application accuracy while maintaining that System Independent. Note: The math functions may be defined as low-level functions but they are used as medium to high priority function. ISO/IEC/IEEE 60559:2011 (standard IEEE-754) has been approved. So, for Ada 2012 it could be added. In <is8unu$7np$1@dont-email.me>, "J-P. Rosen" <rosen@adalog.fr> writes: >Le 02/06/2011 22:38, anon@att.net a �crit : >> I think most would say where's the IEEE Math standards 754-2008 before >> adopting a BSD standard, IEEE 754 standard, have existed since 1985 >> before Ada 95, so why it is not include in Ada 2005 and beyond. >> >Because there are many machines that do not conform to IEEE, and it is >widely recognized that forcing IEEE arithmetic was a major flaw in Java. > >Ada did not make the same error. > >-- >--------------------------------------------------------- > J-P. Rosen (rosen@adalog.fr) >Adalog a d�m�nag� / Adalog has moved: >2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX >Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-06-04 21:35 ` anon @ 2011-06-05 8:39 ` J-P. Rosen 2011-06-07 1:50 ` anon 0 siblings, 1 reply; 121+ messages in thread From: J-P. Rosen @ 2011-06-05 8:39 UTC (permalink / raw) Le 04/06/2011 23:35, anon@att.net a �crit : > Now, having a generic Ada math package or design would insure at least > for math that Ada is System Independent. And using a standard like IEEE > 754 would insure application accuracy while maintaining that System > Independent. > The trouble is that numerical intensive applications often need efficient implementations. If you require IEEE arithmetic, and you are on a machine whose hardware does not support IEEE-754 (note: supports and not implements, since IEEE-754 is a software standard), you have a choice of 1) implement the whole standard in software and say bye-bye to efficiency, or 2) ignore the standard and use the native floating-point, which is a failure of the standardization. The Ada model allows portable guaranteed bounds to inaccurracy, without requiring any particular arithmetic model, and is therefore efficiently implementable on any hardware. That was part of the requirements. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Adalog a d�m�nag� / Adalog has moved: 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-06-05 8:39 ` J-P. Rosen @ 2011-06-07 1:50 ` anon 0 siblings, 0 replies; 121+ messages in thread From: anon @ 2011-06-07 1:50 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2748 bytes --] Actually, for any "numerical intensive applications" or High-Performance computing need to be "Parallel" to be efficient. Any other way of coding is totally, a waste of time. Ada 95 should of had threads, and by 2005 a parallel design should of been in place. In paralleling an algorithm there are two main designs, The first is to add a paralleling optimizer component to the Ada compiler. This component optimizes an algorithm by rewriting parts in parallel form. But most of these optimizers requires standardization of the arithmetic processes such as using 754. The second method is to allow the Ada programmer to construct a parallel routines. In the second case Ada is not parallel or even threaded. Using "Distributed Parallel" design might gives some help depending upon the lag time between systems. Too long a lag time kill the efficient also. Using IEEE-754 standards on an Intel processor for example which does not fully support the 754 standards can easily done. By providing a conversion or interfacing packages to deal with those non-implement designs and as for efficiency its a trade off of being fast or being accurate. With efficiency using less accuracy finding someone with GPS, being off a couple of meters might not hurt, but using a laser in the operating room accuracy counts more than efficiency. And using standards is more "portable" than depending on the computer systems or the OS. In <isffbc$2jj$1@dont-email.me>, "J-P. Rosen" <rosen@adalog.fr> writes: >Le 04/06/2011 23:35, anon@att.net a �crit : >> Now, having a generic Ada math package or design would insure at least >> for math that Ada is System Independent. And using a standard like IEEE >> 754 would insure application accuracy while maintaining that System >> Independent. >> >The trouble is that numerical intensive applications often need >efficient implementations. > >If you require IEEE arithmetic, and you are on a machine whose hardware >does not support IEEE-754 (note: supports and not implements, since >IEEE-754 is a software standard), you have a choice of 1) implement the >whole standard in software and say bye-bye to efficiency, or 2) ignore >the standard and use the native floating-point, which is a failure of >the standardization. > >The Ada model allows portable guaranteed bounds to inaccurracy, without >requiring any particular arithmetic model, and is therefore efficiently >implementable on any hardware. That was part of the requirements. >-- >--------------------------------------------------------- > J-P. Rosen (rosen@adalog.fr) >Adalog a d�m�nag� / Adalog has moved: >2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX >Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-06-02 13:55 ` Florian Weimer 2011-06-02 20:38 ` anon @ 2011-06-02 21:34 ` Randy Brukardt 2011-06-05 11:06 ` Florian Weimer 1 sibling, 1 reply; 121+ messages in thread From: Randy Brukardt @ 2011-06-02 21:34 UTC (permalink / raw) "Florian Weimer" <fw@deneb.enyo.de> wrote in message news:87k4d4z6b6.fsf@mid.deneb.enyo.de... >* Randy Brukardt: > >> Defining a package spec is easy enough (many have done that), but >> describing >> what it does in a target-independent way is a much bigger job. Note that >> there is no ISO standard (so far as I'm aware) that describes BSD >> Sockets, >> so we'd have to recreate at least some description of those in the Ada >> Standard. > > I believe they are part of ISO/IEC 9945:2002. You're right; I had forgotten that POSIX had an ISO standard. (I don't think we can reference the IEEE standards.) But one wonders about the wisdom of requiring a particular OS interface for Ada -- Ada is supposed to be target-independent. Perhaps it would be OK to reference a small piece of it. > However, it turns out that there already is an ISO standard for an Ada > interface to BSD sockets (which happens to include a file system > interface, too): ISO/IEC 14519:2001. Efforts to standardize operating > system interfaces should rather concentrate on liberating that > document to increase adoption, addressing open issues, if necessary; > and not be wasted on duplicating it. I think this offers a cautionary > tale why proprietary standards can be really, really bad. The POSIX standard is too low-level, IMHO, to be a very useful inclusion in the Ada standard. We have higher-level concepts in Ada for file management and tasking, for example (and Ada 2012 has a small amount of locale support as well), and that would seem to be appropriate for sockets as well. POSIX has it's place, of course, but it seems fine for it to be a separate standard -- most users have no reason to be writing at such a low level. Randy. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-06-02 21:34 ` Randy Brukardt @ 2011-06-05 11:06 ` Florian Weimer 2011-06-05 13:45 ` Dmitry A. Kazakov 0 siblings, 1 reply; 121+ messages in thread From: Florian Weimer @ 2011-06-05 11:06 UTC (permalink / raw) * Randy Brukardt: > But one wonders about the wisdom of requiring a particular OS > interface for Ada -- Ada is supposed to be target-independent. > Perhaps it would be OK to reference a small piece of it. For all its faults, there is no alternative to BSD sockets. All systems supporting TCP and UDP use those concepts, even if they are very far away from the original UNIX concepts in other aspects. Even the XTI interface was retrofitted to match the BSD sockets concepts, even though the TLI interfaces suggested a closer correspondence to the TCP state in the network. ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-06-05 11:06 ` Florian Weimer @ 2011-06-05 13:45 ` Dmitry A. Kazakov 2011-06-05 14:51 ` Florian Weimer 0 siblings, 1 reply; 121+ messages in thread From: Dmitry A. Kazakov @ 2011-06-05 13:45 UTC (permalink / raw) On Sun, 05 Jun 2011 13:06:59 +0200, Florian Weimer wrote: > * Randy Brukardt: > >> But one wonders about the wisdom of requiring a particular OS >> interface for Ada -- Ada is supposed to be target-independent. >> Perhaps it would be OK to reference a small piece of it. > > For all its faults, there is no alternative to BSD sockets. So what? Ada's interface to TCP/IP stack and other network stacks need not to be thin. On the contrary it should be as abstract as possible in order to remain independent on any OS-specific mess. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-06-05 13:45 ` Dmitry A. Kazakov @ 2011-06-05 14:51 ` Florian Weimer 2011-06-05 15:30 ` Dmitry A. Kazakov 2011-06-07 2:49 ` Randy Brukardt 0 siblings, 2 replies; 121+ messages in thread From: Florian Weimer @ 2011-06-05 14:51 UTC (permalink / raw) * Dmitry A. Kazakov: > On Sun, 05 Jun 2011 13:06:59 +0200, Florian Weimer wrote: > >> * Randy Brukardt: >> >>> But one wonders about the wisdom of requiring a particular OS >>> interface for Ada -- Ada is supposed to be target-independent. >>> Perhaps it would be OK to reference a small piece of it. >> >> For all its faults, there is no alternative to BSD sockets. > > So what? Ada's interface to TCP/IP stack and other network stacks need not > to be thin. On the contrary it should be as abstract as possible in order > to remain independent on any OS-specific mess. Sorry, I have no idea what you're talking about. What would an API look like that is more abstract than BSD sockets? Would it parametrize aspects such as congestion control and packet fragmentation? ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-06-05 14:51 ` Florian Weimer @ 2011-06-05 15:30 ` Dmitry A. Kazakov 2011-06-07 2:49 ` Randy Brukardt 1 sibling, 0 replies; 121+ messages in thread From: Dmitry A. Kazakov @ 2011-06-05 15:30 UTC (permalink / raw) On Sun, 05 Jun 2011 16:51:36 +0200, Florian Weimer wrote: > * Dmitry A. Kazakov: > >> On Sun, 05 Jun 2011 13:06:59 +0200, Florian Weimer wrote: >> >>> * Randy Brukardt: >>> >>>> But one wonders about the wisdom of requiring a particular OS >>>> interface for Ada -- Ada is supposed to be target-independent. >>>> Perhaps it would be OK to reference a small piece of it. >>> >>> For all its faults, there is no alternative to BSD sockets. >> >> So what? Ada's interface to TCP/IP stack and other network stacks need not >> to be thin. On the contrary it should be as abstract as possible in order >> to remain independent on any OS-specific mess. > > Sorry, I have no idea what you're talking about. What would an API > look like that is more abstract than BSD sockets? You would have a root controlled type with derived instances in particular for TCP/IP (one for listening another for connection): Root_Network_Communication_Type (abstract) | Connection_Oriented_Type (abstract) | TCP_IP_Socket_Type (abstract) | TCP_IP_Client_Type (concrete) > Would it > parametrize aspects such as congestion control and packet > fragmentation? Options will be set using primitive operations rather than that awful stuff characteristic for C bindings, just Set_No_Delay (Connection : in out TCP_IP_Socket_Type); Reset_No_Delay (Connection : in out TCP_IP_Socket_Type); Similarly, idiotic BSD sockets' structures for dealing with names and addresses will be replaced with properly designed Ada types. Where is a problem? A more interesting issue would be integrating asynchronous I/O into Ada tasking, e.g. socket select. I think the implementation should provide a task type with corresponding entries, e.g. task type Network_IO is entry Received ( Connection : out not null access TCP_IP_Socket_Type'Class; Buffer : in out Octet_Array; Last : out Positive); entry Connected ... entry Sent ... entry Closed ... entry Assign_Sockets ... (Will Ada 2012 support "out access"?) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: Why no socket package in the standard ? 2011-06-05 14:51 ` Florian Weimer 2011-06-05 15:30 ` Dmitry A. Kazakov @ 2011-06-07 2:49 ` Randy Brukardt 1 sibling, 0 replies; 121+ messages in thread From: Randy Brukardt @ 2011-06-07 2:49 UTC (permalink / raw) "Florian Weimer" <fw@deneb.enyo.de> wrote in message news:87pqms8h6v.fsf@mid.deneb.enyo.de... >* Dmitry A. Kazakov: > >> On Sun, 05 Jun 2011 13:06:59 +0200, Florian Weimer wrote: ... >>> For all its faults, there is no alternative to BSD sockets. >> >> So what? Ada's interface to TCP/IP stack and other network stacks need >> not >> to be thin. On the contrary it should be as abstract as possible in order >> to remain independent on any OS-specific mess. > > Sorry, I have no idea what you're talking about. What would an API > look like that is more abstract than BSD sockets? Would it > parametrize aspects such as congestion control and packet > fragmentation? BSD sockets is full of bizarre operational requirements which make it quite a bit more complex than necessary. One way to abstract it (lightly) is shown by Tom Moran's NC.Sockets (originally part of Claw). It probably would be better to abstract it even further (Tom wasn't trying to write a portable abstraction of sockets, it only worked out to be most of that). Randy. ^ permalink raw reply [flat|nested] 121+ messages in thread
end of thread, other threads:[~2011-06-07 2:49 UTC | newest] Thread overview: 121+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-05-24 1:22 Why no socket package in the standard ? Yannick Duchêne (Hibou57) 2011-05-24 1:39 ` Yannick Duchêne (Hibou57) 2011-05-24 6:11 ` tmoran 2011-05-24 17:23 ` Pascal Obry 2011-05-24 19:10 ` Yannick Duchêne (Hibou57) 2011-05-25 15:12 ` Tero Koskinen 2011-05-25 18:43 ` Tero Koskinen 2011-05-25 19:08 ` Yannick Duchêne (Hibou57) 2011-05-24 6:24 ` georg bauhaus 2011-05-24 7:07 ` Maciej Sobczak 2011-05-24 7:19 ` Thomas Løcke 2011-05-24 7:35 ` Ludovic Brenta 2011-05-24 10:00 ` Georg Bauhaus 2011-05-24 12:53 ` Dmitry A. Kazakov 2011-05-24 14:28 ` Georg Bauhaus 2011-05-24 14:59 ` Dmitry A. Kazakov 2011-05-24 16:07 ` Adam Beneschan 2011-05-24 19:21 ` Dmitry A. Kazakov 2011-05-25 0:53 ` Yannick Duchêne (Hibou57) 2011-05-25 0:21 ` Yannick Duchêne (Hibou57) 2011-05-25 11:25 ` Peter C. Chapin 2011-05-24 16:10 ` Georg Bauhaus 2011-05-24 19:36 ` Dmitry A. Kazakov 2011-05-25 0:57 ` Yannick Duchêne (Hibou57) 2011-05-24 23:20 ` Yannick Duchêne (Hibou57) 2011-05-25 0:32 ` Georg Bauhaus 2011-05-25 0:49 ` Yannick Duchêne (Hibou57) 2011-05-25 7:55 ` Pascal Obry 2011-05-25 8:38 ` Georg Bauhaus 2011-05-25 8:05 ` Dmitry A. Kazakov 2011-05-25 7:52 ` Dmitry A. Kazakov 2011-05-24 19:38 ` Yannick Duchêne (Hibou57) 2011-05-24 19:54 ` Ludovic Brenta 2011-05-24 20:10 ` Yannick Duchêne (Hibou57) 2011-05-24 21:57 ` Ludovic Brenta 2011-05-24 22:35 ` Yannick Duchêne (Hibou57) 2011-05-24 23:34 ` Adam Beneschan 2011-05-24 23:40 ` Ludovic Brenta 2011-05-24 23:50 ` Yannick Duchêne (Hibou57) 2011-05-24 23:35 ` Ludovic Brenta 2011-05-25 3:07 ` Shark8 2011-05-25 4:01 ` Yannick Duchêne (Hibou57) 2011-05-25 7:39 ` Georg Bauhaus 2011-05-25 7:42 ` Ludovic Brenta 2011-05-25 10:46 ` Manuel Collado 2011-05-25 10:44 ` Peter C. Chapin 2011-05-25 15:28 ` Yannick Duchêne (Hibou57) 2011-05-25 16:36 ` Ludovic Brenta 2011-05-25 16:46 ` Yannick Duchêne (Hibou57) 2011-05-26 12:10 ` Maciej Sobczak 2011-05-26 12:42 ` Ludovic Brenta 2011-05-26 14:36 ` Georg Bauhaus 2011-05-26 15:56 ` Ludovic Brenta 2011-05-26 18:20 ` Maciej Sobczak 2011-05-26 18:29 ` Yannick Duchêne (Hibou57) 2011-05-26 20:46 ` Georg Bauhaus 2011-05-26 21:02 ` Yannick Duchêne (Hibou57) 2011-05-26 21:44 ` Georg Bauhaus 2011-05-26 21:59 ` Ludovic Brenta 2011-05-27 7:54 ` Georg Bauhaus 2011-05-27 13:12 ` Simon Wright 2011-05-27 15:43 ` Ludovic Brenta 2011-05-26 18:31 ` Vinzent Hoefler 2011-05-26 19:05 ` Ludovic Brenta 2011-05-26 19:14 ` Yannick Duchêne (Hibou57) 2011-05-26 19:44 ` Ludovic Brenta 2011-05-27 2:02 ` anon 2011-05-27 11:44 ` Stephen Leake 2011-05-26 14:50 ` Adam Beneschan 2011-05-26 15:57 ` Ludovic Brenta 2011-05-27 11:46 ` Stephen Leake 2011-05-27 12:21 ` Dmitry A. Kazakov 2011-05-27 12:49 ` Make, Automake, Configure, Autocong, GPRbuild etc (was: Why no socket package in the standard ?) Ludovic Brenta 2011-05-27 13:10 ` Make, Automake, Configure, Autocong, GPRbuild etc Dmitry A. Kazakov 2011-05-27 15:45 ` Ludovic Brenta 2011-05-25 7:40 ` Why no socket package in the standard ? Georg Bauhaus 2011-05-25 10:48 ` Pascal Obry 2011-05-25 7:49 ` Ludovic Brenta 2011-05-25 2:47 ` Shark8 2011-05-25 9:12 ` Thomas Løcke 2011-05-24 21:42 ` Yannick Duchêne (Hibou57) 2011-05-24 23:09 ` Georg Bauhaus 2011-05-24 23:25 ` Yannick Duchêne (Hibou57) 2011-05-25 9:06 ` Dmitry A. Kazakov 2011-05-24 23:11 ` Georg Bauhaus 2011-05-24 23:28 ` Yannick Duchêne (Hibou57) 2011-05-24 23:57 ` Georg Bauhaus 2011-05-25 0:36 ` Yannick Duchêne (Hibou57) 2011-05-24 7:25 ` Dmitry A. Kazakov 2011-05-24 21:22 ` Maciej Sobczak 2011-05-25 9:14 ` Dmitry A. Kazakov 2011-05-25 11:54 ` Maciej Sobczak 2011-05-25 12:26 ` Dmitry A. Kazakov 2011-05-24 22:04 ` Yannick Duchêne (Hibou57) 2011-05-25 9:19 ` Dmitry A. Kazakov 2011-05-24 19:17 ` Yannick Duchêne (Hibou57) 2011-05-24 19:30 ` J-P. Rosen 2011-05-24 19:49 ` Yannick Duchêne (Hibou57) 2011-05-24 22:39 ` Georg Bauhaus 2011-05-24 22:54 ` Yannick Duchêne (Hibou57) 2011-05-24 23:54 ` Georg Bauhaus 2011-05-25 0:34 ` Yannick Duchêne (Hibou57) 2011-05-25 1:20 ` Yannick Duchêne (Hibou57) 2011-05-24 12:38 ` AdaMagica 2011-05-24 15:00 ` Yannick Duchêne (Hibou57) 2011-05-24 18:29 ` anon 2011-05-24 19:08 ` Yannick Duchêne (Hibou57) 2011-06-02 2:41 ` Randy Brukardt 2011-06-02 13:55 ` Florian Weimer 2011-06-02 20:38 ` anon 2011-06-02 20:44 ` Florian Weimer 2011-06-02 21:18 ` J-P. Rosen 2011-06-04 21:35 ` anon 2011-06-05 8:39 ` J-P. Rosen 2011-06-07 1:50 ` anon 2011-06-02 21:34 ` Randy Brukardt 2011-06-05 11:06 ` Florian Weimer 2011-06-05 13:45 ` Dmitry A. Kazakov 2011-06-05 14:51 ` Florian Weimer 2011-06-05 15:30 ` Dmitry A. Kazakov 2011-06-07 2:49 ` Randy Brukardt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox