I never could learn a foreign language to save my life; your English is
fine.
dxmpi runs (as far as I know) on anything that supports MPI. I have it
running on several SPs now as well as on a Linux micro-cluster, which
amounts to a couple laptops and an old desktop box running Ethernet.
As far
Right you are, David. I was assuming that the name coming in to
_dxf_ExCacheStrPrepend began with / and ended with :, based evidence
aquired in a little test script. Turns out that the topmost macro isn't
considered an instance, so doesn't have the / or the :. Just in case my
assumption was
David,
A couple routines in _tiff.c got ifdeffed out - write_rev_uint32 and
write_rev_uint16. They're needed - why did they go away?
Greg
There's some problem in DXLink - has to do with the handshaking between the
server and the client. The server (dxui) hangs in select waiting for info
from the client - the startupui. When you kill startupui the select
releases, it prints an error message and gets on with its business. I
think
This is where we got off on Richard Gilliland's problem. If you are
getting undeffed STATSTRUCT without configure failing, then I think the fix
we put in to acinclude.m4 ought to fix it. If you get a chance, how about
updating acinclude.m4 and then run autoconf and configure to see if the fix
Wow. I'm *very* impressed. So when I call DXGetModuleId I'll still get a
string, but internally to the exec it holds the module id as a list of
integers, right? That means it should be transparent to anybody outside
the exec and that therefore uses the DXGetModuleId interface. I'll be
happy
The problem we are trying to deal with here is that some systems use a
function named stat and others, _stat. At the same time, the second arg
may be either (struct stat *) or (struct _stat *), and there's no apparent
correlation between the choice of the function and structure name. So we
have
This isn't a waste of time to me. This configuration stuff needs to work.
I'd really appreciate it if we could persist here. Could I get on your
system?
Greg
Richard Gillilan [EMAIL PROTECTED]@opendx.watson.ibm.com on
06/21/2000 10:38:52 AM
Please respond to opendx2-dev@lists.berlios.de
We look for sys/types.h in configure and its explicitly included in dx/dx.h
if its found, so we shouldn't be depending on it getting included by
another header. Of course, it uses $ac_cpp to look for it, so I imagine
its the same problem. Is HAVE_SYS_TYPES_H defined in config.h?
Greg
Richard
I'd say so, too. The ushort etc. problems indicate that as well. All of
these indicate that some simple preprocessing and compilations are failing
that shouldn't, and I'd bet a lot that they are all related and could
indicate other configure problems that are waiting to bite.
I've debugged a
The first test looks for a typedef in the headers; the second, for a
compiler built-in (like int). I suppose one thing thats not looked for is
a #define in the headers. I suppose one thing thats still not covered is a
#define in the header - that wouldn't show up in the cpp output, nor would
the
I don't think so ... I moved the socket header inclusion logic from all
over the place to dx/dx.h. I'd wonder where AF_INET is on Richard's
system. If its not in cygwin/socket.h, sys/socket.h or socket.h, then its
either not there, in which case it ought not to be trying to use the
internet
I think I've fixed this. The problem boiled down to when an include in a
Makefile.am actually happened. On some systems (our AIX boxes) the include
makes it all the way into Makefile, and is performed by make, so the
configured local.mk ought to be included. On other systems (eg. my cygwin)
I'm getting there. This is beginning to work smoothly on my system, though
I've had to fudge a bit along the way - most notably because, regardless of
how the file system is mounted, perl (at least, the one on my system)
insists on putting \r in there. So, I've had to tweak aclocal and
By the way, another problem thats arisen is that autoheader creates a file
autoh and then tries to move it to include/dxconfig.h.in.
Unfortunately, autoh is still open at that point, and so it can't
actually move it and it complains. When it does, you can just move the
file explicitly.
I guess Alzheimer's is setting in. I don't recall why I did that, but
there must have been some reason, and I'd guess it had to do with
conflicting file names when the headers all get put in one place. I don't
know - I'll re-install that stuff and check it out.
Greg
I gather you are considering using the call-module interface, so you need
the DX executive, which is C code. I would think that you'd go ahead and
compile it using the normal C compiler, then in your C++ code, you'd
declare the entry points extern C to keep C++ from mangling the names.
Another
Yes, I'll commit to a commit. This is certainly the sort of thing I'm
eager to get in there. I wonder - is this only SGI, or all SMP-supported
platforms?
By way of explaining myself, I've been working on a fairly large change to
make the GNU-based builds work with the MSVC compiler on Windows.
I don't know if it helps, but another approach might be to replace one huge
networks with a bunch of small networks, actually macros, invoked by name
through DXLink, that communicate by GetGloballing and SetGloballing named
objects in the cache. (There are hidden inputs to GetGlobal and SetGlobal
I could not get your current wrappers working under my Cygwin
environment.
Me either, since I went to Cygwin v.1. There are problems with it; look at
their mail archive under the threads Problems with sed, make and NT4 in
general, Post B20 Cygwin CRLF behavior and, for that matter, sin6_addr
Richard, if the X event loop (or whatever is driving your renderer) is
asynchronous with respect to DX, then objects can get deleted out from
under the renderer regardless of locking. Vanilla DX works because the fd
for the OpenGL renderer X display is registered with the
RegisterInputHandler
glyph is an AIX box, xl is a family of C compilers on AIX. I'm still
working on getting the changes I've made for MSVC to build smoothly
elsewhere.
Guess that was a bit cryptic.
Greg
Aarrggghh.I'm using B20, I think. Are you referring to the commercial
version? I don't mind upgrading, but I don't want to spend IBM's
hard-earned bucks here.
I'm building on the C drive, and thats where the Exceed XDK is.I'll
look into the binary mounts problem as time permits.
I
I'm about to check in the changes for building OpenDX using the MS
compilers under Cygwin. This is the version I used a couple weeks ago at
VDE2000, where it worked quite well.
Greg
OK, I'm working on it today.
Greg
Suhaib M. Siddiqi [EMAIL PROTECTED]@opendx.watson.ibm.com on
04/05/2000 05:27:30 PM
Please respond to opendx2-dev@lists.berlios.de
Sent by: [EMAIL PROTECTED]
To: opendx2-dev@lists.berlios.de
cc:
Subject: RE: [opendx-dev] Release
OK, believe it or
I'm sorry, I've been really busy lately. I guess we are all on board, I'll
start the process now. This'll include updating the version number and
marking the source tree. Then I'll build a tarball. Don't know if I can
finish this afternoon, off to sunny Miami this evening and back Tuesday
This is *with* the RedHat patches applied locally? Does this mean you are
back to the opinion that we ought to apply those patches prior to 4.1.0?
Greg
Suhaib M. Siddiqi [EMAIL PROTECTED] on 03/14/2000 03:32:55 PM
Please respond to opendx2-dev@lists.berlios.de
To:
Forgot my real reason to reply to this - thanks. That bugs been in there
since approximately the dawn of time.
Greg
Peter Daniel Kirchner [EMAIL PROTECTED]@opendx.watson.ibm.com on
03/02/2000 06:14:59 PM
Please respond to opendx2-dev@lists.berlios.de
Sent by: [EMAIL PROTECTED]
To:
Good point. I used this in debugging a non-DX piece of code.
Greg
David L. Thompson [EMAIL PROTECTED]@opendx.watson.ibm.com on
03/03/2000 10:18:49 AM
Please respond to opendx2-dev@lists.berlios.de
Sent by: [EMAIL PROTECTED]
To: opendx2-dev@lists.berlios.de
cc:
Subject: Re: [opendx-dev]
I semi-retired the machine that I did that on. I have our systems guy
bringing it back up. I'll let y'all know.
Greg
Suhaib M. Siddiqi [EMAIL PROTECTED]@opendx.watson.ibm.com on
02/23/2000 02:59:41 PM
Please respond to opendx2-dev@lists.berlios.de
Sent by: [EMAIL PROTECTED]
To:
OK, unfortunately I wasn't able to replicate it on our SGI machine. Any
chance I could get access to yours?
Greg
I'd say it was at advanced proof of concept level. It was certainly
useable, definitely cool, and I wrote some documentation.
Actually, I thought that was why you didn't support on-line creation of
callbacks. But you do allow your users to write and install custom
callbacks and widgets, which
No, I don't think so. Its unfortunate that 4.0.10 sorts less than 4.0.9,
but these are levels of revision. I intended that once we get a version
that seems to match the final product release in terms of stability, that
we bump to 4.1.0. I'm hoping we will be there with this go-round.
Greg
Shall we start the process of putting together a new OpenDX release? Seems
like about the right time. It sounds like the Lesstif guys are going to
roll a new release very soon; I agree that it'd be nice to hold off the
release until after that, but we can go ahead and get the process going.
If
I noticed that some internal names have been changed to avoid conflicts
with name-space collisions - good idea. In one of the most painful
(painful as in tedious - my idea of true pain is tedium) episodes in DX
history, we went through and changed all externally visible function names
to have a
Yep. I think its a good idea.
Greg
David Thompson [EMAIL PROTECTED] on 12/22/99 11:45:34 AM
Please respond to opendx2-dev@lists.berlios.de
To: opendx2-dev@lists.berlios.de
cc:
Subject: Re: [opendx-dev] Name-space collisions
For internal functions then, do you want them to be
Hm. Interesting. I spoke to Jiten - our systems guy. He tells me that
the address arises because commits are done essentially as local users on
the CVS machine. Right now replies to that address would hit the bit
bucket, although Lotus Notes users who use Reply To will have their reply
sent
People have been asking me when they can get a stable version that
includes JavaDX. I think it'd be a good idea to put out a new tarball
sometime soon that incorporates bug fixes on top of 4.0.9, test it, and
then anoint it golden at 4.1.0. What I'd like to do is to get everyone to
check in the
The standard way to test for memory leaks in DX is this.
1. Prepare a network that you believe demonstrates a memory leak - the
smaller the better.
2. Run DX with the flags -script -readahead off -cache off That'll
bring up dx at a prompt.
3 type:
include foo.net
Executive(flush cache);
That message comes from a signal handler. If you set the environment
variable DXUINOCATCHERROR, it won't install the signal handler, and your
debugger ought to show you where the real problem lies. As a guess, I bet
its running out of memory ungracefully - is your drive full?
Greg
40 matches
Mail list logo
