* Re: q: pkg for network/UNIX programming; system dependencies
1997-05-29 0:00 q: pkg for network/UNIX programming; system dependencies Ken Raeburn
@ 1997-05-30 0:00 ` Jon S Anthony
[not found] ` <339302B7.5044@pseserv6.fw.hac.com>
1997-05-30 0:00 ` Corey Minyard
1997-05-31 0:00 ` Nick Roberts
2 siblings, 1 reply; 7+ messages in thread
From: Jon S Anthony @ 1997-05-30 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: q: pkg for network/UNIX programming; system dependencies
1997-05-29 0:00 q: pkg for network/UNIX programming; system dependencies Ken Raeburn
1997-05-30 0:00 ` Jon S Anthony
@ 1997-05-30 0:00 ` Corey Minyard
1997-05-30 0:00 ` W. Wesley Groleau (Wes)
1997-05-31 0:00 ` Nick Roberts
2 siblings, 1 reply; 7+ messages in thread
From: Corey Minyard @ 1997-05-30 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: q: pkg for network/UNIX programming; system dependencies
1997-05-30 0:00 ` Corey Minyard
@ 1997-05-30 0:00 ` W. Wesley Groleau (Wes)
0 siblings, 0 replies; 7+ messages in thread
From: W. Wesley Groleau (Wes) @ 1997-05-30 0:00 UTC (permalink / raw)
> > 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.
----------------------------------------------------------------------
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: system dependencies
1997-05-29 0:00 q: pkg for network/UNIX programming; system dependencies Ken Raeburn
1997-05-30 0:00 ` Jon S Anthony
1997-05-30 0:00 ` Corey Minyard
@ 1997-05-31 0:00 ` Nick Roberts
2 siblings, 0 replies; 7+ messages in thread
From: Nick Roberts @ 1997-05-31 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 7+ messages in thread