Sockets

Sockets

[ProLogic]

What's the best way to implement and use TCP/IP sockets, client and
server... ??

Importing C functions, or... ?

Thanks
ProLogic

Re: Sockets

[Jean-Claude MAHIEUX]

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

Dear Sir,

our company has developped Ada95 IO packages for our products.
They provide IO classes that supports different transports such as TCP/IP,
deliver asynchronous notification, and can be extended to additional
transports by users.
This packages have been ported to various Ada95 compilers and various
platforms including VMS

--
Jean-Claude MAHIEUX
Top Graph'X Sales Manager
10 All�e de la Mare Jacob
91290 La Norville - FRANCE
Tel : +33 1 69 26 97 88
Fax : +33 1 69 26 97 89
Email : sales@topgraphx.com
URL : http://www.topgraphx.com
US Representative : sroliver@topgraphx.com

Re: Sockets

[David C. Hoos, Sr.]

----- Original Message ----- 
From: "ProLogic" <ProLogic@prologitech.ods.org>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: May 22, 2002 3:00 AM
Subject: Sockets


> What's the best way to implement and use TCP/IP sockets, client and
> server... ??
> 
> Importing C functions, or... ?
Have you looked at GNAT.Sockets?

Re: Sockets

[ProLogic]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote in message
news:mailman.1022064962.32541.comp.lang.ada@ada.eu.org...
>
> ----- Original Message -----
> From: "ProLogic" <ProLogic@prologitech.ods.org>
> Newsgroups: comp.lang.ada
> To: <comp.lang.ada@ada.eu.org>
> Sent: May 22, 2002 3:00 AM
> Subject: Sockets
>
>
> > What's the best way to implement and use TCP/IP sockets, client and
> > server... ??
> >
> > Importing C functions, or... ?
> Have you looked at GNAT.Sockets?
>
>
>

I have looked all over the internet, I cannot find any references to the
GNAT.Sockets package.
Can you please help...
thanks

Re: Sockets

[Preben Randhol]

On Wed, 22 May 2002 21:59:20 +1000, ProLogic wrote:
> I have looked all over the internet, I cannot find any references to the
> GNAT.Sockets package.
> Can you please help...

Which version of GNAT do you use? 

You should check AdaSockets?

http://www.rfc1149.net/devel/adasockets

Preben

Re: Sockets

[Simon Wright]

"ProLogic" <ProLogic@prologitech.ods.org> writes:

> I have looked all over the internet, I cannot find any references to
> the GNAT.Sockets package.

It's part of GNAT 3.14p.

Re: Sockets

[tmoran]

> What's the best way to implement and use TCP/IP sockets, client and
> server... ??
   For what OS and which compiler?  If you want Windows and something
portable across Gnat/Janus/ObjectAda/Rational, you could use Claw, a
GMGPL (free) version of which is available at www.adapower.com or
www.rrsoftware.com  There are examples of a web crawler and a simple
web server also available on www.adapower.com  As principal author
I am of course biased.  There are also other Ada socket implementations
with, I'm sure, their own advantages.

Re: Sockets

[Randy Brukardt]

ProLogic wrote in message <3ceb5091@news.comindico.com.au>...
>What's the best way to implement and use TCP/IP sockets, client and
>server... ??
>
>Importing C functions, or... ?


On Windows, you could use Claw.Sockets. The basic version is in the Claw
Introductory version (now under the GMGPL); there is a fancier version
in the full commercial version of Claw.

Claw.Sockets has been tested on all of the Windows compilers, it is not
specific to a single compiler as GNAT.Sockets is.

             Randy Brukardt.

Re: Sockets

[Preben Randhol]

On Wed, 22 May 2002 13:39:24 -0500, Randy Brukardt wrote:
> 
> Claw.Sockets has been tested on all of the Windows compilers, it is not
> specific to a single compiler as GNAT.Sockets is.

But it is spesific to a single platform. I find it less interesting to
have code that is compiler independant when it makes the code platform
independant.

Preben

Re: Sockets

[Preben Randhol]

On Wed, 22 May 2002 19:11:42 +0000 (UTC), Preben Randhol wrote:
> On Wed, 22 May 2002 13:39:24 -0500, Randy Brukardt wrote:
>> 
>> Claw.Sockets has been tested on all of the Windows compilers, it is not
>> specific to a single compiler as GNAT.Sockets is.
> 
> But it is spesific to a single platform. I find it less interesting to
> have code that is compiler independant when it makes the code platform
> independant.
  ^^^^^^^^^^
  dependant (of course) *BONK*

Preben

Re: Sockets

[David C. Hoos]

<snip>
> > independant.
>   ^^^^^^^^^^
>   dependant (of course) *BONK*
Well, if you want to get really precise, it's
dependent (from the Latin dependere).
 

Re: Sockets

[Marin David Condic]

It would be nice if we could have *both* compiler and platform independence.
The only way that is likely to happen is if there is eventually an
"Ada.Sockets" package delivered with all compilers. I'm sure people have
done a fine job with various implementations that are out there such that
you can find a package that will work with your particular compiler or your
particular platform and maybe even offer some portability, but this is
really the sort of thing that should be supported on all compilers for which
there is some kind of underlying Sockets implementation. (That covers a
*lot* of ground.) These days Sockets have become such a standard thing to
have and use in loads of apps that not having a standard way of getting at
it from within the language is almost like saying that file I/O isn't
supported by the language, but you can build a binding to OS calls to get
there... :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnaenrbe.122.randhol+abuse@kiuk0156.chembio.ntnu.no...
>
> But it is spesific to a single platform. I find it less interesting to
> have code that is compiler independant when it makes the code platform
> independant.
>

Re: Sockets

[chris.danx]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:acgsu8$g48$1@nh.pace.co.uk...
> It would be nice if we could have *both* compiler and platform
independence.
> The only way that is likely to happen is if there is eventually an
> "Ada.Sockets" package delivered with all compilers. I'm sure people have
> done a fine job with various implementations that are out there such that
> you can find a package that will work with your particular compiler or
your
> particular platform and maybe even offer some portability, but this is
> really the sort of thing that should be supported on all compilers for
which
> there is some kind of underlying Sockets implementation.


Then perhaps a sockets api is a good idea for the ARG API standards process?


Just a thought,
Chris

Re: Sockets

[Marin David Condic]

I'd lobby for that. Come to think of it, I *was* lobbying for that! :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"chris.danx" <spamoff.danx@ntlworld.com> wrote in message
news:CAoI8.13824$Uk6.2428050@news6-win.server.ntlworld.com...
>
> Then perhaps a sockets api is a good idea for the ARG API standards
process?
>

Re: Sockets

[Robert Dewar]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<uenpeerelvspf8@corp.supernews.com>...

> On Windows, you could use Claw.Sockets. The basic version is in the Claw
> Introductory version (now under the GMGPL); there is a fancier version
> in the full commercial version of Claw.
> 
> Claw.Sockets has been tested on all of the Windows compilers, it is not
> specific to a single compiler as GNAT.Sockets is.
> 
>              Randy Brukardt.

Yes, but Claw.Sockets works only with one particular proprietary operating
system (Windows in its various flavors from MS). GNAT.Sockets works on a
large variety of both proprietary and free operating systems, so from that
point of view it is more portable. We even have it working for cross
compilers like those generating code for VxWorks. So that's a different
view of portability :-)

Re: Sockets

[Randy Brukardt]

Robert Dewar wrote in message
<5ee5b646.0205221833.4780a61a@posting.google.com>...
>"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:<uenpeerelvspf8@corp.supernews.com>...
>
>> On Windows, you could use Claw.Sockets. The basic version is in the
Claw
>> Introductory version (now under the GMGPL); there is a fancier
version
>> in the full commercial version of Claw.
>>
>> Claw.Sockets has been tested on all of the Windows compilers, it is
not
>> specific to a single compiler as GNAT.Sockets is.
>>
>>              Randy Brukardt.
>
>Yes, but Claw.Sockets works only with one particular proprietary
operating
>system (Windows in its various flavors from MS). GNAT.Sockets works on
a
>large variety of both proprietary and free operating systems, so from
that
>point of view it is more portable. We even have it working for cross
>compilers like those generating code for VxWorks. So that's a different
>view of portability :-)

There's no particular reason that Claw Sockets couldn't be implemented
on another platform, there is very little in it that is Windows
specific. We just haven't had any reason to do so.

Indeed, it would be nice if Claw.Sockets was split completely out of
Claw, as it really doesn't have much to do with the GUI, and it is
annoying to drag in the GUI to use it. I suspect that the main change
would be the name (by making it a child of Claw, it by definition
includes the GUI stuff that is in the Claw package).

               Randy.

Re: Sockets

[Robert Dewar]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<uenpeerelvspf8@corp.supernews.com>...

> Claw.Sockets has been tested on all of the Windows compilers, it is not
> specific to a single compiler as GNAT.Sockets is.
> 
>              Randy Brukardt.

Incidentally, I don't know whether or not GNAT.Sockets would work on other
windows compilers, it might well. Most certainly we have not bothered to
test this out :-)

Re: Sockets

[tmoran]

> > Claw.Sockets has been tested on all of the Windows compilers, it is not
> > specific to a single compiler as GNAT.Sockets is.
> >
> >              Randy Brukardt.
>
> Incidentally, I don't know whether or not GNAT.Sockets would work on other
> windows compilers, it might well. Most certainly we have not bothered to
> test this out :-)
  I wonder how calls to System.Soft_Links would fare with other compilers?
  But Claw.Sockets and GNAT.Sockets are apples and oranges in thickness.
For instance, startup and shutdown are automatic in Claw, sockets are
Controlled types, you can specify a timeout on the Read call, and
asynchronous event calls use OO overriding of such routines as
When_Connect, When_Readable, etc.  It's just a different thing entirely.
  I'm sure Claw.Sockets could be implemented on non-Windows systems,
presumably also in a compiler independent way, but we haven't done it yet.

Re: Sockets

[Steve Doiel]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0205221834.653e070a@posting.google.com...
[snip]
> Incidentally, I don't know whether or not GNAT.Sockets would work on other
> windows compilers, it might well. Most certainly we have not bothered to
> test this out :-)

I can say that GNAT.Sockets doesn't work (without modification) with
ObjectAda 7.2.1.  It appears to be dependent on a few gnat specific
libraries.  It might not be very difficult to produce a portable version.

SteveD

Result using
  gnat.ads, g-socket.ads, g-socket.adb, g-socthi.ads, g-sockthi.adb,
g-soccon.ads, g-soliop.ads

--------------------Target: Win32 (Intel) Debug--------------------
Front end of ..\..\gnatsockets\g-socthi.ads succeeded with no errors.
g-socket.adb: Error: line 42 col 11 LRM:10.1.2(4), GNAT.OS_Lib not found in
Library, Ignoring With
g-socket.adb: Error: line 42 col 43 LRM:4.1.3(10), OS_Lib was not found in
the region of GNAT, Ignoring future references
g-socket.adb: Error: line 45 col 11 LRM:10.1.2(4), GNAT.Task_Lock not found
in Library, Ignoring With
g-socket.adb: Warning: line 48 col 8 LRM:2.8(11), Unrecognized pragma name
=> "Warnings", Continuing
g-socket.adb: Error: line 228 col 42 LRM:4.1(3), Direct name, Errno, is not
visible, Ignoring future references
g-socket.adb: Error: line 304 col 42 LRM:4.1(3), Direct name, Errno, is not
visible, Ignoring future references
g-socket.adb: Error: line 449 col 42 LRM:4.1(3), Direct name, Errno, is not
visible, Ignoring future references
g-socket.adb: Error: line 477 col 42 LRM:4.1(3), Direct name, Errno, is not
visible, Ignoring future references
g-socket.adb: Error: line 508 col 42 LRM:4.1(3), Direct name, Errno, is not
visible, Ignoring future references
g-socket.adb: Error: line 560 col 42 LRM:4.1(3), Direct name, Errno, is not
visible, Ignoring future references
g-socket.adb: Error: line 625 col 7 LRM:4.1(3), Direct name, Task_Lock, is
not visible, Ignoring future references
g-socket.adb: Error: line 629 col 29 LRM:4.1(3), Direct name, Errno, is not
visible, Ignoring future references
g-socket.adb: Error: line 630 col 10 LRM:4.1(3), Direct name, Task_Lock, is
not visible, Ignoring future references
g-socket.adb: Error: line 640 col 10 LRM:4.1(3), Direct name, Task_Lock, is
not visible, Ignoring future references
g-socket.adb: Error: line 661 col 7 LRM:4.1(3), Direct name, Task_Lock, is
not visible, Ignoring future references
g-socket.adb: Error: line 665 col 29 LRM:4.1(3), Direct name, Errno, is not
visible, Ignoring future references
g-socket.adb: Error: line 666 col 10 LRM:4.1(3), Direct name, Task_Lock, is
not visible, Ignoring future references
g-socket.adb: Error: line 676 col 10 LRM:4.1(3), Direct name, Task_Lock, is
not visible, Ignoring future references
g-socket.adb: Error: line 695 col 42 LRM:4.1(3), Direct name, Errno, is not
visible, Ignoring future references
g-socket.adb: Error: line 718 col 42 LRM:4.1(3), Direct name, Errno, is not
visible, Ignoring future references
g-socket.adb: Error: line 779 col 42 LRM:4.1(3), Direct name, Errno, is not
visible, Ignoring future references
g-socket.adb: Error: line 828 col 42 LRM:4.1(3), Direct name, Errno, is not
visible, Ignoring future references
g-socket.adb: Error: line 857 col 37 LRM:4.1.4(2) & 13.1(13), The attribute
Img is not supported by this implementation, Ignoring
g-socket.adb: Error: line 915 col 44 LRM:4.1.4(2) & 13.1(13), The attribute
Img is not supported by this implementation, Ignoring
g-socket.adb: Error: line 927 col 21 LRM:4.1.4(2) & 13.1(13), The attribute
Img is not supported by this implementation, Ignoring
g-socket.adb: Error: line 943 col 26 LRM:4.1(3), Direct name, Errno, is not
visible, Ignoring future references
g-socket.adb: Error: line 1000 col 42 LRM:4.1(3), Direct name, Errno, is not
visible, Ignoring future references
g-socket.adb: Error: line 1075 col 28 LRM:4.1.4(2) & 13.1(13), The attribute
Img is not supported by this implementation, Ignoring
g-socket.adb: Error: line 1180 col 42 LRM:4.1(3), Direct name, Errno, is not
visible, Ignoring future references
g-socket.adb: Error: line 1211 col 42 LRM:4.1(3), Direct name, Errno, is not
visible, Ignoring future references
g-socket.adb: Error: line 1240 col 42 LRM:4.1(3), Direct name, Errno, is not
visible, Ignoring future references
g-socket.adb: Error: line 1275 col 42 LRM:4.1(3), Direct name, Errno, is not
visible, Ignoring future references
g-socket.adb: Error: line 1363 col 42 LRM:4.1(3), Direct name, Errno, is not
visible, Ignoring future references
g-socket.adb: Error: line 1380 col 42 LRM:4.1(3), Direct name, Errno, is not
visible, Ignoring future references
Front end of ..\..\gnatsockets\g-socket.adb failed with 33 errors.
Front end of ..\..\gnatsockets\g-socket.ads succeeded with no errors.
Front end of ..\..\gnatsockets\g-socthi.adb succeeded with no errors.
Front end of ..\..\gnatsockets\g-soccon.ads succeeded with no errors.
Front end of ..\..\gnatsockets\gnat.ads succeeded with no errors.
Front end of ..\..\gnatsockets\g-soliop.ads succeeded with no errors.
Tool execution failed.

Re: Sockets

[Marin David Condic]

Given Randy's earlier post about the ARG being out looking for APIs, maybe
GNAT.Sockets should be proposed (the specification - not the whole thing) as
a potential Ada.Sockets. (Or CLAW.Sockets as an alternate?) In either case,
I wouldn't be too upset that the current underlying implementations aren't
portable across all compilers. What matters is if the spec is at least
common/portable across compilers. (Aonix isn't likely to want to adopt
anything named "GNAT.<whatever>" :-) It would be nice to take some Gnat code
that used sockets over to an ObjectAda compiler and have it go to town
without having to rewrite the points of contact with the Sockets interface
to the OS.

The good news about having an Ada.Sockets would be that since there are
already existing connections to Sockets that come with or will work with
most compilers, implementing it as an addition to the language would
probably mostly amount to a bunch of "renames" declarations. (Or at least a
really thin binding.) Each compiler may have its own specific underlying
package, but a common interfact to it would be really nice.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Steve Doiel" <nospam_steved94@attbi.com> wrote in message
news:83iH8.97025$Po6.204052@rwcrnsc52.ops.asp.att.net...
>
> I can say that GNAT.Sockets doesn't work (without modification) with
> ObjectAda 7.2.1.  It appears to be dependent on a few gnat specific
> libraries.  It might not be very difficult to produce a portable version.
>

Re: Sockets

[Preben Randhol]

On Fri, 24 May 2002 09:58:30 -0400, Marin David Condic wrote:
> Given Randy's earlier post about the ARG being out looking for APIs, maybe
> GNAT.Sockets should be proposed (the specification - not the whole thing) as
> a potential Ada.Sockets. (Or CLAW.Sockets as an alternate?) In either case,

Or Adasockets. I was under the impression that Adasockets is better than
at least GNAT.Sockets.

Preben

Re: Sockets

[Simon Wright]

Preben Randhol <randhol+abuse@pvv.org> writes:

> Or Adasockets. I was under the impression that Adasockets is better
> than at least GNAT.Sockets.

I had problems with AdaSockets, I found GNAT.Sockets much easier to
get on with. (Weren't they by the same author?)

It was quite simple to get GNAT.Sockets working on VxWorks (NB, if you
are using 3.14p with VxWorks I think you may find that GNAT.Sockets
assumes Linux conventions for various constants, which are different
from VxWorks -- and for once Linux is out on a limb. I have a patch,
originally for 3.14a1, mail me at simon.j.wright@amsjv.com)

Re: Sockets

[Preben Randhol]

On 25 May 2002 09:03:16 +0100, Simon Wright wrote:
> 
> I had problems with AdaSockets, I found GNAT.Sockets much easier to
> get on with. (Weren't they by the same author?)

The difference according to the maintainer of Adasockets is:

   GNAT.Sockets is officially supported by ACT while AdaSockets is not.
   GNAT.Sockets will always follow the simplest possible model, while
      AdaSockets won't.
   GNAT.Sockets is not object-oriented, AdaSockets is.
   GNAT.Sockets supports JGNAT, while AdaSockets don't.

Preben

Re: Sockets

[Robert Dewar]

Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrnaeuigj.pa.randhol+abuse@kiuk0156.chembio.ntnu.no>...
>    GNAT.Sockets is officially supported by ACT while AdaSockets is not.
>    GNAT.Sockets will always follow the simplest possible model, while
>       AdaSockets won't.
>    GNAT.Sockets is not object-oriented, AdaSockets is.
>    GNAT.Sockets supports JGNAT, while AdaSockets don't.
> 

GNAT.Sockets is also implemented on more targets

Re: Sockets

[Robert Dewar]

Simon Wright <simon@pushface.org> wrote in message news:<x7v8z68fyd7.fsf@pushface.org>...

> It was quite simple to get GNAT.Sockets working on VxWorks (NB, if you
> are using 3.14p with VxWorks I think you may find that GNAT.Sockets
> assumes Linux conventions for various constants, which are different
> from VxWorks -- and for once Linux is out on a limb. I have a patch,
> originally for 3.14a1, mail me at simon.j.wright@amsjv.com)

No, GNAT.Sockets does not assume Linux conventions. There are different
target dependent versions for various targets, including a VxWorks
specific set of units. We don't make judgments as to who is out on
a limb, but for sure there are differences and the current version
of GNAT.Sockets in GNAT Pro is implemented for all native targets
except OpenVMS, and all cross targets except Lynx (those two
will be filled in sometime in the near future).

Re: Sockets

[Simon Wright]

dewar@gnat.com (Robert Dewar) writes:

> Simon Wright <simon@pushface.org> wrote in message news:<x7v8z68fyd7.fsf@pushface.org>...
> 
> > It was quite simple to get GNAT.Sockets working on VxWorks (NB, if you
> > are using 3.14p with VxWorks I think you may find that GNAT.Sockets
> > assumes Linux conventions for various constants, which are different
> > from VxWorks -- and for once Linux is out on a limb. I have a patch,
> > originally for 3.14a1, mail me at simon.j.wright@amsjv.com)
> 
> No, GNAT.Sockets does not assume Linux conventions. There are different
> target dependent versions for various targets, including a VxWorks
> specific set of units. We don't make judgments as to who is out on
> a limb, but for sure there are differences and the current version
> of GNAT.Sockets in GNAT Pro is implemented for all native targets
> except OpenVMS, and all cross targets except Lynx (those two
> will be filled in sometime in the near future).

I did say 3.14{p,a1}! There was no official support for GNAT.sockets
on VxWorks in 3.14a1 though the source was in the RTL, and (for the NT
cross PPC 3.14a1) the version of GNAT.Sockets etc in the library was
the Linux one, I'm pretty sure. And GNAT.Sockets.Constants had Linux
constants in it. But it wasn't too hard to figure out, and we got it
working with a day or so's effort.

Of course anyone who wants to build a 3.14p/VxWorks cross is going to
have fun. Might be more productive to try with GCC 3.1.

Re: Sockets

[Robert Dewar]

Simon Wright <simon@pushface.org> wrote in message news:<x7v8z68fyd7.fsf@pushface.org>...

> I had problems with AdaSockets, I found GNAT.Sockets much easier to
> get on with. (Weren't they by the same author?)

Well GNAT.Sockets is part of GNAT, and authorship there is a shared
activity. We never implement anything like this without a general
discussion of the API. For sure GNAT.Sockets had the AdaSockets
as very visible input, so any differences between these packages
are 100% intentional :-)

Re: Sockets

[Marin David Condic]

Fine with me. Or AnythingelseSockets. It just seems a shame that most OS's
support sockets in ways that could even be characterized as "more standard"
than the way they support files, yet Ada doesn't have a "Standard" interface
to them. Maybe Adasockets makes a better proposal - send it to the ARG. I'm
sure that the message has been received & *something* will end up being the
conventional Ada answer to sockets. Probably also we'll get access to
directory structures and maybe some other OS services. Whatever we *do* get,
I just hope the process is established such that getting *more* stuff added
is easily accomplished.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnaeuer7.pa.randhol+abuse@kiuk0156.chembio.ntnu.no...
>
> Or Adasockets. I was under the impression that Adasockets is better than
> at least GNAT.Sockets.
>
> Preben

Sockets

[Maciej Sobczak]

Hi,

Let's say that I would like to write an Ada program that uses sockets 
and compile and run it on my Linux box.

There three ways to do this that I'm aware of:

1. Use GNAT runtime library. The advantage is that it will be portable 
to other platforms (as long as GNAT and its library is portable there).

2. Use C interfacing and call the system functions directly. The 
advantage is that it will be portable to other compilers on the same 
platform (no dependency on GNAT run-time libs).

3. Use Florist. The disadvantage is that I'm too lazy to install it 
(it's another package) and I don't want to impose this requirement on 
other lazy users of the same code.

Is the above correct? What would you recommend?

BTW - Unix sockets are of interest as well.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Sockets

[Roger Blum]

I am using ada sockets: http://www.rfc1149.net/devel/adasockets.html.en

Regards,
Roger

"Maciej Sobczak" <no.spam@no.spam.com> schrieb im Newsbeitrag 
news:ejemue$b5k$1@cernne03.cern.ch...
> Hi,
>
> Let's say that I would like to write an Ada program that uses sockets and 
> compile and run it on my Linux box.
>
> There three ways to do this that I'm aware of:
>
> 1. Use GNAT runtime library. The advantage is that it will be portable to 
> other platforms (as long as GNAT and its library is portable there).
>
> 2. Use C interfacing and call the system functions directly. The advantage 
> is that it will be portable to other compilers on the same platform (no 
> dependency on GNAT run-time libs).
>
> 3. Use Florist. The disadvantage is that I'm too lazy to install it (it's 
> another package) and I don't want to impose this requirement on other lazy 
> users of the same code.
>
> Is the above correct? What would you recommend?
>
> BTW - Unix sockets are of interest as well.
>
> -- 
> Maciej Sobczak : http://www.msobczak.com/
> Programming    : http://www.msobczak.com/prog/ 

Re: Sockets

[Maciej Sobczak]

Roger Blum wrote:
> I am using ada sockets: http://www.rfc1149.net/devel/adasockets.html.en

Same disadvantage as 3. from my first post.

However, thanks for the link.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Sockets

[Chad R. Meiners]

>From previous experience, installing adasocket is very easy.  I think I
just copied the correct package into my projected directory and with'd
it.  I think I may have had to set a linker switch, but it was pretty
painless.



On Nov 15, 5:43 am, Maciej Sobczak <no.s...@no.spam.com> wrote:
> Roger Blum wrote:
> > I am using ada sockets:http://www.rfc1149.net/devel/adasockets.html.enSame disadvantage as 3. from my first post.
>
> However, thanks for the link.
>
> --
> Maciej Sobczak :http://www.msobczak.com/
> Programming    :http://www.msobczak.com/prog/

Re: Sockets

[Marc A. Criley]

On Wed, 15 Nov 2006 11:43:50 +0100, Maciej Sobczak wrote:

> Roger Blum wrote:
>> I am using ada sockets: http://www.rfc1149.net/devel/adasockets.html.en
> 
> Same disadvantage as 3. from my first post.

I just distribute either the whole collection, or the required subset as
part of my source distribution.

-- Marc A. Criley
-- McKae Technologies
-- www.mckae.com
-- DTraq - Avatox - XIA - XML EZ Out

Re: Sockets

[Warner BRUNS]

Maciej Sobczak wrote:
> Hi,
> 
> Let's say that I would like to write an Ada program that uses sockets 
> and compile and run it on my Linux box.
> 
> There three ways to do this that I'm aware of:
> 
> 1. Use GNAT runtime library. The advantage is that it will be portable 
> to other platforms (as long as GNAT and its library is portable there).
> 
> 2. Use C interfacing and call the system functions directly. The 
> advantage is that it will be portable to other compilers on the same 
> platform (no dependency on GNAT run-time libs).
> 
> 3. Use Florist. The disadvantage is that I'm too lazy to install it 
> (it's another package) and I don't want to impose this requirement on 
> other lazy users of the same code.
> 
> Is the above correct? What would you recommend?
> 
> BTW - Unix sockets are of interest as well.
> 

I once tried to use POSIX functionality via Florist, but could not,
as (at least then, a year ago), Florist wants to be compiled by gnat.
So using Florist does not give you more portability than using
the gnat runtime.

Warner

Re: Sockets

[Simon Wright]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Let's say that I would like to write an Ada program that uses sockets
> and compile and run it on my Linux box.
>
> There three ways to do this that I'm aware of:
>
> 1. Use GNAT runtime library. The advantage is that it will be
> portable to other platforms (as long as GNAT and its library is
> portable there).

This is the one I would go for. Linux/Windows/Mac OS X/Solaris/[Alpha
UNIX]/VxWorks ...

> 2. Use C interfacing and call the system functions directly. The
> advantage is that it will be portable to other compilers on the same
> platform (no dependency on GNAT run-time libs).

Which other Ada compilers were you thinking of using on Linux? and
anyway interfacing to other languages might be one of the less
portable aspects.

> 3. Use Florist. The disadvantage is that I'm too lazy to install it
> (it's another package) and I don't want to impose this requirement
> on other lazy users of the same code.

No experience. But we would have had much trouble justifying an
external package without vendor support if the vendor package was
'good enough' (and GNAT.Sockets is certainly that, even if not
feature-free).

Re: Sockets.

[Simon Johnston]

> X-Newsreader: Gnus v5.0.15
>
>         In the tradition of not re-inventing the wheel, has anyone
> completed or working on a UNIX sockets binding for Ada95?  I once had
> contact with the author of Paradise over a year ago, and he said he would
> attempt it when GNAT advanced some more, but I've found nothing yet.

I have been trying to get help on this topic for some time. I am
using the Win32 bindings to access the Winsock API which may/may-not
be of use to you. My problem is actually using the binding once I
have it. If anyone has any experience please let me know.

>         In addition, would it be possible to define a generic package
> with a discriminant, and then use that discriminate to instantiate a
> generic private child package?  From what I can tell, the answer should
> be no, but I'm not sure.
>
>         The reason I ask is it would make a package abstracting a
> system-dependant but common function easier and smaller; you instantiate
> the abtracted generic with a discriminant describing your OS type, and
> the package then instantiates the low-level binding appropriate to that
> OS...
>
> -- Cerebus <tmiller@ims.advantis.com>
> "Just a thought."
>
>

with StandardDisclaimer; use StandardDisclaimer;
package Sig is
--,-------------------------------------------------------------------------.
--|Simon K. Johnston - Development Engineer (C++/Ada95) |ICL Retail Systems |
--|-----------------------------------------------------|3/4 Willoughby Road|
--|Unix Mail: skj@acm.org                               |Bracknell          |
--|Telephone: +44 (0)1344 476320 Fax: +44 (0)1344 476302|Berkshire          |
--|Internal : 7261 6320   OP Mail: S.K.Johnston@BRA0801 |RG12 8TJ           |
--|WWW URL  : http://www.acm.org/~skj/                  |United Kingdom     |
--`-------------------------------------------------------------------------'
end Sig;

Sockets.

[Timothy Miller]

X-Newsreader: Gnus v5.0.15

	In the tradition of not re-inventing the wheel, has anyone
completed or working on a UNIX sockets binding for Ada95?  I once had
contact with the author of Paradise over a year ago, and he said he would
attempt it when GNAT advanced some more, but I've found nothing yet.

	In addition, would it be possible to define a generic package
with a discriminant, and then use that discriminate to instantiate a
generic private child package?  From what I can tell, the answer should
be no, but I'm not sure.  

	The reason I ask is it would make a package abstracting a
system-dependant but common function easier and smaller; you instantiate
the abtracted generic with a discriminant describing your OS type, and
the package then instantiates the low-level binding appropriate to that
OS... 

-- Cerebus <tmiller@ims.advantis.com>
"Just a thought."