q: pkg for network/UNIX programming; system dependencies

q: pkg for network/UNIX programming; system dependencies

[Ken Raeburn]

I'm thinking about working on a couple small spare-time UNIX projects in
Ada95 to help familiarize myself with the language.  Most such projects
I'm considering right now make use of networking, both TCP and UDP.

I'm looking for a package to help me deal with UNIX system-defined types,
socket- and network-related types and functionality, domain name service,
etc.  I've looked at the "paradise" package, which seems to have some of
what I want, but the latest version I could find is about 3 years old,
only works on SunOS and HP-UX and with three specific compilers (none of
which is GNAT), and is specifically conditionalized in various places for
those systems and compilers.  If that's the closest thing available, I'll
go with it; I just wanted to know if there's anything else.


Oh and a general question: How do you usually deal with OS or
configuration dependencies in Ada?  For example, some systems have the
utmpx functions, some don't; some have wait4, some don't.  Maybe I'm
building a package with a backwards-compatibility option enabled; maybe
it's disabled.  In C and UNIX, I'd use #ifdef and maybe an
autoconf-generated script to test the system characteristics and
user-provided options, and define some macros for conditional
compilation.

The conditionally-compiled region can be very small.  Of course, there
are times when it's large, and when it seems worthwhile to use a separate
source file.  But there are times when it isn't and it doesn't....

TIA,
Ken

Re: q: pkg for network/UNIX programming; system dependencies

[Corey Minyard]

Ken Raeburn <raeburn@cygnus.com> writes:

> I'm thinking about working on a couple small spare-time UNIX projects in
> Ada95 to help familiarize myself with the language.  Most such projects
> I'm considering right now make use of networking, both TCP and UDP.
> 
> I'm looking for a package to help me deal with UNIX system-defined types,
> socket- and network-related types and functionality, domain name service,
> etc.  I've looked at the "paradise" package, which seems to have some of
> what I want, but the latest version I could find is about 3 years old,
> only works on SunOS and HP-UX and with three specific compilers (none of
> which is GNAT), and is specifically conditionalized in various places for
> those systems and compilers.  If that's the closest thing available, I'll
> go with it; I just wanted to know if there's anything else.

I have a port of the forest-1.4 library (it compiles without error
under GNAT 3.09) with some limited Berkeley socket bindings at
http://www.concentric.net/~Minyard.  I understand that the standard
forest library is not as extensive as paradise, but I have never used
paradise.  The socket stuff I wrote is pretty limited, and I'm not an
Ada95 guru, so if anyone wants to take it and work on it, feel free.

> Oh and a general question: How do you usually deal with OS or
> configuration dependencies in Ada?  For example, some systems have the
> utmpx functions, some don't; some have wait4, some don't.  Maybe I'm
> building a package with a backwards-compatibility option enabled; maybe
> it's disabled.  In C and UNIX, I'd use #ifdef and maybe an
> autoconf-generated script to test the system characteristics and
> user-provided options, and define some macros for conditional
> compilation.
> 
> The conditionally-compiled region can be very small.  Of course, there
> are times when it's large, and when it seems worthwhile to use a separate
> source file.  But there are times when it isn't and it doesn't....

Under Ada, you generally have a file with the machine-dependent
portion of the code separated from the machine-indepenent portion.
You can link or copy the proper version to the right place to compile
it.

Ada has no conditional compilation like a #ifdef.  I and kind of
spoiled by the #ifdef, too, especially for small stuff, but having all
the machine-dependent stuff in a separate file makes porting a lot
easier because you know where all the stuff you have to fix is.

-- 
Corey Minyard               Internet:  minyard@acm.org
  Work: minyard@nortel.ca       UUCP:  minyard@wf-rch.cirr.com

Re: q: pkg for network/UNIX programming; system dependencies

[W. Wesley Groleau (Wes)]

> > I'm looking for a package to help me deal with UNIX system-defined types,
> > socket- and network-related types and functionality, domain name service,
> > etc.  I've looked at .....
> 
> I have a port of the forest-1.4 library (it compiles without error
> under GNAT 3.09) with some limited Berkeley socket bindings at
> http://www.concentric.net/~Minyard.  ......

FLORIST (Florida State upgrade to FOREST) might also help.

> > .... How do you usually deal with OS or
> > configuration dependencies in Ada?  .... 

> > ....  For example, some systems have the
> > utmpx functions, some don't; some have wait4, some don't.  

1. Use POSIX and other standards as much as possible.
2. Check your system's offerings very carefully.  Often you may
   find that the system offers a "standard" item that is almost
   as good as the "super-duper nonportable" item. 

> the machine-dependent stuff in a separate file makes porting a lot
> easier because you know where all the stuff you have to fix is.

Furr Shurr.

----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

Send me your advertisements!  I'll proofread and return them for only
$50.00 (US) per hundred words (plus a small fee per correction). For
full details, use a subject line of "Re: Proofreading Offer" on a
message of less than ten lines.
----------------------------------------------------------------------

Re: q: pkg for network/UNIX programming; system dependencies

[Jon S Anthony]

In article <tx1bu5ttzs3.fsf@cygnus.com> Ken Raeburn <raeburn@cygnus.com> writes:


> I'm thinking about working on a couple small spare-time UNIX projects in
> Ada95 to help familiarize myself with the language.  Most such projects
> I'm considering right now make use of networking, both TCP and UDP.

Why not use GLADE or ADEPT?  Both of these work with GNAT and give you
full distributed object style capabilities (per the DSA of Ada95).
ADEPT also gives you RMI interaction.

ADEPT: http://www.cs.tamu.edu/research/ADEPT/

GLADE: ftp.gnat.com:pub/gnat


> Oh and a general question: How do you usually deal with OS or
...
> it's disabled.  In C and UNIX, I'd use #ifdef and maybe an
> autoconf-generated script to test the system characteristics and
> user-provided options, and define some macros for conditional
> compilation.

You can just use this same technique if you want.  Just make sure you
run the result through the Ada compiler and not C compiler!

> The conditionally-compiled region can be very small.  Of course, there
> are times when it's large, and when it seems worthwhile to use a separate
> source file.  But there are times when it isn't and it doesn't....

Actually, using child packages, _separate_, and search lists, IMO this
really works out much better than conditional compilation.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: system dependencies

[Nick Roberts]

Ken Raeburn <raeburn@cygnus.com> wrote in article
<tx1bu5ttzs3.fsf@cygnus.com>...
[...]
> Oh and a general question: How do you usually deal with OS or
> configuration dependencies in Ada?  For example, some systems have the
> utmpx functions, some don't; some have wait4, some don't.  Maybe I'm
> building a package with a backwards-compatibility option enabled; maybe
> it's disabled.  In C and UNIX, I'd use #ifdef and maybe an
> autoconf-generated script to test the system characteristics and
> user-provided options, and define some macros for conditional
> compilation.
> 
> The conditionally-compiled region can be very small.  Of course, there
> are times when it's large, and when it seems worthwhile to use a separate
> source file.  But there are times when it isn't and it doesn't....


As a first resort, what you should do is to write your Ada program so that
it detects which environment it is running in (or has been compiled in),
and automatically adapts itself accordingly. So, if it may run under
environment A with useful procedure P1, or under environments B and C with
inferior procedure P2, you should write code like this:

if Environment_Group = A then
   P1;
else
   -- do things by hand here not done by P2
   P2;
end if;

This approach has the advantage of requiring only one version of your
source code, and the (immense) advantage that the software automatically
configures itself, in effect, thus avoiding accidents.

In those (unlikely) circumstances when, for reasons of reducing executable
size or increasing its speed, it is not acceptable to have 'shiralee' code,
put the different versions in separate files, and use configuration
management (or just file renaming!) to engage the right version when
compiling for each target. When you have to do this, it is vital that you
carefully document the different versions, and double-check to make sure
this documentation is comprehensive and accurate.

In all circumstances, it is important that you place all system-dependent
code in 'wrappers'. So, for example, if you have a procedure provided by
environment A which draws a line on the screen, but no such facility in
environments B and C (only pixel setting, say), you should write a wrapper
procedure to draw a line as follows:

procedure Draw_Line(P1, P2: in Point_Type) is
begin
   if Environment_Group = A then
      Fancy_GUI.Draw_Line(P1,P2);
   else
      -- routine which draws line using Set_Pixel(X,Y) procedure
   end if;
end;

You might then want to group all such wrapper stuff in a package, and this
package can then (if necessary) have different bodies (in separate files)
for different environments. I repeat, only do this if necessary. Observe
that, in this example, if Environment_Group and A are both static,
unnecessary code may be eliminated from the executable anyway.

Nick.

Re: q: pkg for network/UNIX programming; system dependencies

[Ken Raeburn]

Thanks for all the responses.  I'll check out florist and Corey
Minyard's version of forest.  I also intend to drop a line to the
paradise maintainer.

I've only looked at the DSA a little, but my impression is that the
Ada system manages the low-level details and gives the application
writer a high-level interface for remote calls.  I need to deal with
existing network protocols, so I have to have control at the lower
level.  And, being a network security weenie, I'm not inclined to
trust something that takes that control away from me without knowing
how the security issues are addressed...

As for handling system dependencies, "separate" and/or child packages
sound like the right solution.  And since I'd be targeting mostly
UNIXy systems, I can probably assume (or require) autoconf and m4
availability for generating/choosing the files to be compiled.

Thanks again...

Ken

Re: q: pkg for network/UNIX programming; system dependencies

[Robert Dewar]

<<No, don't use the C pre-processor with an Ada compiler!  Write your
own pre-processor with some variation of Ada-comment syntax.
Then you can make sure that none of your programmers are using
C-prepocessor macros and constants.
>>

The latest release of GNAT contains a preprocessor gantprep that a number of
our customers have found useful.