Drew correctly points out the difficulty of using the VPE and
data flow environment for robust or commercial products.
However, all of the DX functionality IS available through the
library routines, either directly in an explicit routine, or
through the valuable DXCallModule() function, which allows you
to run any module just as in the VPE. This also includes
Image and Display modules, with event handling.
Using this approach, we have created robust commercial products
entirely in C. without the dxexec or the VPE. These products make
extensive use of the DX functionality and data model inside, and
the Display module outside. They also provide excellent user
interactivity with complex 3D displays (much better than one can
get in the data flow environment). In general, we prototype in
the VPE, and then write the C version after we see where things
going, often as an iterative process. It has worked very well.
In my opinion, this is the ONLY way to write anything that is of
large size or complexity, and certainly anything that needs good
error handling. But, like everything else with DX, there is a
learning curve, but once over that, it becomes very nice to work
with (except for memory handling sometimes).
If you search back through the archives for my name in the
From or Body fields, you can see some discussion about this back
in 2000 or so.
Mike
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Andrew J.
Dolgert
Sent: Tuesday, May 31, 2005 10:07 AM
To: opendx2-users@lists.berlios.de
Subject: RE: [opendx-users] Usage model for OpenDX
Hi Matt,
You can set variables in a running copy of DX using DXLink, but you are
correct that you send them as text. There are helper routines in one of
the libraries that let you write a loadable module and external program
which talk with each other over sockets. These routines are commented
out in the Windows build, by the way, with a big #ifndef WIN32. You
would want to combine the two in order to have full control over DX.
Send data on the socket; change parameters through the script.
If you want to use shared memory, you have to write it yourself as a
loadable module in DX. On Windows, you have to roll your own anyway.
Writing a module isn't so bad, though. MPI is also available, as I
think about it, and implementations of MPI sometimes use shared memory
on local machines. I haven't looked into using MPI with DX and suspect
it is implemented mostly for parallel execution of modules, not for
receiving data from remote processes.
If you don't have a running copy of DX, then you can still use library
methods to decode arrays and such, but you can't load a DX net. Without
a DX net, what good is doing visualization in DX? I think this technique
is best for translators to/from DX. For instance, if your program wanted
to create a DX Object and then send it to DX, it could use the library
to make the relevant Arrays and Objects, then use _dxfExportBin_buffer
to turn this object into a byte stream, send the byte stream to DX, and
then have a DX module decode it with _dxfImportBin_buffer. More likely,
you'll write a DX module that receives data in your preferred format and
then creates the Object on the fly.
When you control DX from an external program, the simplest way is to
allow DX to show its own Image window. If you want the display in your
own program, then see the Tk example in the distribution. Every time you
try to rotate the image, you have to request that DX rotate the image
and return the result. If you want to test whether this will work well
enough for you, you could expand the Tk example to allow rotations. You
may want to do this to prove to yourself that DX can fulfill your
technical requirements.
I probably have some of this wrong b/c I know better the things I did
than everything doable in DX. People have wrenched this program into
all sorts of amazing capabilities over the years. While the data model
of DX is great and it is a very expressive visual language, it is not
good at being embedded in other programs because it runs as a separate
process, doesn't have structured error modes to the controlling process,
and the executive sometimes dies. All this is probably okay for an
academic tool, but, again, it depends on your requirements.
Drew Dolgert
Cornell Theory Center
