Prev: Larger matrices
Next: Problems with Ada.Streams.Read (blocking)
From: Robert A Duff on 10 Aug 2008 18:15
anon(a)anon.org (anon) writes:

> If your doing a direct conversion from C to Ada using sockets then you
> might need to use the lower-level socket package, "GNAT.Sockets.Thin".
> This package has direct library links to the sockets library routines,
> bypassing the extra layer of code in "GNAT.Sockets".

GNAT.Sockets.Thin says:

-- This package provides a target dependent thin interface to the sockets
-- layer for use by the GNAT.Sockets package (g-socket.ads). This package
-- should not be directly with'ed by an applications program.

which means that AdaCore feels free to change the interface in
incompatible ways at any time.

- Bob
From: anon on 10 Aug 2008 19:34
What's your point? "GNAT.Sockets.Thin" is a universal interface to the
system socket library just like "Interface.C" is for interfacing C code. Plus,
most socket routines are standardized, in todays OS. Only the single
"GNAT.Sockets.Constants" file is altered, due to system control flags, but
most of the constants that are used for normal socket functions are
standardized as well.

And since Adacore (GNAT) is the only game around for Ada-2005 specs
there is no reason to get upset with portability because what vendor would
you port your code to!


In <wccsktcecuk.fsf(a)shell01.TheWorld.com>, Robert A Duff <bobduff(a)shell01.TheWorld.com> writes:
>anon(a)anon.org (anon) writes:
>
>> If your doing a direct conversion from C to Ada using sockets then you
>> might need to use the lower-level socket package, "GNAT.Sockets.Thin".
>> This package has direct library links to the sockets library routines,
>> bypassing the extra layer of code in "GNAT.Sockets".
>
>GNAT.Sockets.Thin says:
>
>-- This package provides a target dependent thin interface to the sockets
>-- layer for use by the GNAT.Sockets package (g-socket.ads). This package
>-- should not be directly with'ed by an applications program.
>
>which means that AdaCore feels free to change the interface in
>incompatible ways at any time.
>
>- Bob

From: Robert A Duff on 10 Aug 2008 21:31
anon(a)anon.org (anon) writes:

> What's your point?

My point is that AdaCore might change the interface GNAT.Sockets.Thin
on whim, whereas it won't change the interface GNAT.Sockets so easily,
since the latter is a documented interface. That's all -- if you're
happy with such, use GNAT.Sockets.Thin as you like.

>... "GNAT.Sockets.Thin" is a universal interface to the
> system socket library just like "Interface.C" is for interfacing C code. Plus,
> most socket routines are standardized, in todays OS. Only the single
> "GNAT.Sockets.Constants" file is altered, due to system control flags, but
> most of the constants that are used for normal socket functions are
> standardized as well.
>
> And since Adacore (GNAT) is the only game around for Ada-2005 specs
> there is no reason to get upset with portability because what vendor would
> you port your code to!
>
>
> In <wccsktcecuk.fsf(a)shell01.TheWorld.com>, Robert A Duff <bobduff(a)shell01.TheWorld.com> writes:
>>anon(a)anon.org (anon) writes:
>>
>>> If your doing a direct conversion from C to Ada using sockets then you
>>> might need to use the lower-level socket package, "GNAT.Sockets.Thin".
>>> This package has direct library links to the sockets library routines,
>>> bypassing the extra layer of code in "GNAT.Sockets".
>>
>>GNAT.Sockets.Thin says:
>>
>>-- This package provides a target dependent thin interface to the sockets
>>-- layer for use by the GNAT.Sockets package (g-socket.ads). This package
>>-- should not be directly with'ed by an applications program.
>>
>>which means that AdaCore feels free to change the interface in
>>incompatible ways at any time.
>>
>>- Bob
From: anon on 11 Aug 2008 14:26
Your just trying to make Trouble and Destroy Ada! Because in that concept
you should NEVER use "GNAT.Sockets" either. That means that Ada will be
cripple because it will NEVER be able to use the Internet or Com ports, or
USB because those I/O packages are not define in the RM. Because these
extra hardware packages are not apart of the RM they must be defined
somewhere, and Adacore has choosen to places these hardware packages in
its GNAT subpackages. And in most cases they use "STADARDIZE" calls
into the OS or hardware. But in you concept the only hardware I/O package
for GNAT Ada are disk, keyboard, or simple video aka basically OS and BIOS
I/O calls. But a language must have I/O and the ability to expand beyond its
RM or it DIES! But may be that's what you want!

This "STADARDIZE" calls concepts explains one reason why the UART
package has taken so long to become apart of the GNAT system, there is
no true standards on calls for the UART even though the ports and functions
have been well defined for years.

And there is only vendor that does not maintains a level of Standardizing
behavior, and that is Sun with Java. In evey new version of Java there are
some routines that have been "DEPRECATED", but most people do not say
"DO NOT USE" that routine or package because SUN may change it. That's
because those progammers and uses want JAVA to be succeed.

So, if you want GNAT Ada to succeed as well, do not cut any package down.
You should show the person who ask the question how it should be done. And
in this case, either by writing code, given a package. Or posting a link to a
telnet program written in Ada that they can download and check out for
themselves.



In <wcctzds5oc4.fsf(a)shell01.TheWorld.com>, Robert A Duff <bobduff(a)shell01.TheWorld.com> writes:
>anon(a)anon.org (anon) writes:
>
>> What's your point?
>
>My point is that AdaCore might change the interface GNAT.Sockets.Thin
>on whim, whereas it won't change the interface GNAT.Sockets so easily,
>since the latter is a documented interface. That's all -- if you're
>happy with such, use GNAT.Sockets.Thin as you like.
>
>>... "GNAT.Sockets.Thin" is a universal interface to the
>> system socket library just like "Interface.C" is for interfacing C code. Plus,
>> most socket routines are standardized, in todays OS. Only the single
>> "GNAT.Sockets.Constants" file is altered, due to system control flags, but
>> most of the constants that are used for normal socket functions are
>> standardized as well.
>>
>> And since Adacore (GNAT) is the only game around for Ada-2005 specs
>> there is no reason to get upset with portability because what vendor would
>> you port your code to!
>>
>>
>> In <wccsktcecuk.fsf(a)shell01.TheWorld.com>, Robert A Duff <bobduff(a)shell01.TheWorld.com> writes:
>>>anon(a)anon.org (anon) writes:
>>>
>>>> If your doing a direct conversion from C to Ada using sockets then you
>>>> might need to use the lower-level socket package, "GNAT.Sockets.Thin".
>>>> This package has direct library links to the sockets library routines,
>>>> bypassing the extra layer of code in "GNAT.Sockets".
>>>
>>>GNAT.Sockets.Thin says:
>>>
>>>-- This package provides a target dependent thin interface to the sockets
>>>-- layer for use by the GNAT.Sockets package (g-socket.ads). This package
>>>-- should not be directly with'ed by an applications program.
>>>
>>>which means that AdaCore feels free to change the interface in
>>>incompatible ways at any time.
>>>
>>>- Bob

From: Samuel Tardieu on 11 Aug 2008 14:59
>>>>> "anon" == anon <anon(a)anon.org> writes:

anon> You should show the person who ask the question how it should be
anon> done. And in this case, either by writing code, given a
anon> package. Or posting a link to a telnet program written in Ada
anon> that they can download and check out for themselves.

Wow, good advice! Why didn't you follow it yourself? Where is your
code or your link?

You're a troll.

Sam
--
Samuel Tardieu -- sam(a)rfc1149.net -- http://www.rfc1149.net/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Larger matrices
Next: Problems with Ada.Streams.Read (blocking)