swarm-support
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Swarm 1.4.1 changes


From: Marcus G. Daniels
Subject: Re: Swarm 1.4.1 changes
Date: 27 Feb 1999 11:14:45 -0800

>>>>> "HH" == Ho-Sheng Hsiao <address@hidden> writes:

HH>  - Is gcc 2.8.1 really needed? I know 2.8.x has some upgrades to
HH> the objc core. However, the last I've heard, 2.8.x wasn't
HH> suitable for compiling critical components (like the kernel or
HH> other software). Has 2.8.x stabalized? Or is there a way to run
HH> the 2.7.x version by default, but run only 2.8 when compiling
HH> Swarm?

The Linux kernel is different because it uses some GNU C extensions,
and has expectations about the semantics of some incompletely
specified language constructs, e.g. inlining.

gcc 2.8 or egcs-1.1 are suitable for compiling portable code.
Feature-wise, gcc 2.8 is not really needed for Swarm.  It is just that
we have a hard enough time testing multiple platforms, never mind
multiple platforms and multiple toolchains.

HH> I've never heard of HDF5 -- what the heck is it?

Essentially it is a database oriented toward scientific data.
It provides efficient, parallel access to named objects, which may be
very large. 

Suppose you have three dimensional array in C: int ary[1000000][30][10]. 
What HDF5 does is let you say: "here is the type of my thing, and here
is where it resides in memory".  HDF5 then looks at what kind of
machine, you are using, takes complete notes, and then dumps the data
in native format to storage.  If someone should load this array on
another sort of machine, one where the integers changed from 32 to 64
bits, say, HDF5 takes care of those conversions transparently.  In the
common case of using the same workstation, the data requires no
conversion and is can be read and written in native format.  Supposing
`ary' is too big to really deal with in physical memory, HDF5 also
provides features for navigating the space by slice or by defining a
subspace.  There is also the option of transparent gzip compression of
large objects.

HH>  - Is there a way to compile the core Swarm libraries (non-gui:
HH> defobject, collection, activity, objectbase, random) only? I
HH> don't need the GUI tools yet, and so I'd rather not go around
HH> compiling BLT, tk, and tcl.

If you are using Debian, Redhat, or Solaris, we have binary
distributions of those things.  Although it is possible to avoid
use of tkobjc, simtools and simtoolgui, we don't really have a documented
procedure for doing it.  If you really care, trace through initSwarm
in simtools.m and you'll see how to initialize module by module.  Gridturtles,
although, dated, does this as well.
(We should get to the point where each module can self-initialize using
linker magic, but we aren't there yet.)

HH>  - Finally: the two libraries, libffi and ffcall (same thing, or
HH> not?)  what role do these play in the library?

These (alternative) libraries provide a portable dynamic callout
interface for MessageProbes.  In old versions of Swarm, this was done
using a compiler feature, but that feature has since been deprecated,
effectively.  ffcall is the more complete library, but we didn't want
to require its use since it has a stronger license than Swarm (GPL).
libffi uses the same license as Swarm (LGPL).

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]