[EMAIL PROTECTED]: |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?
Thanks. What you said is correct. One difference however is that, while the abstract Pointer DXGetModuleId returns is still a string, it is not of the same form as before. Before it was a human-readable string (e.g. "/main:0/BoxAndWhiskerPlot:1/BoxAndWisker:2/Compute:5"); now it's a sequence of hex numbers represented as a string (e.g. "00010000000200010003000200040005"). Both forms are unique to the executive per module instance. The latter usually takes less memory, is a little cheaper to build/compare/hash, and as a side effect abstracts module IDs a bit (DXGetModuleId). In the patch, the latter representation of module IDs is also used for cache tags. I toyed with the idea of using the original binary path data as a cache tag rather than using a string, but the potential performance benefit wasn't big enough to justify the extra effort. |That means it should be transparent to anybody outside the exec and that |therefore uses the DXGetModuleId interface. Right, as long as the client doesn't cast this abstract Pointer type to a string and expect to do direct module name/instance number parsing on it, it's transparent. The fact that it is a string at all isn't published through the interface. And from the comment in remote.c just above the DXGetModuleId() definition, it's apparent that DX API users shouldn't be assuming that Module IDs are strings of a particular form. So we should be fine. This abstraction issue popped up only once in making the changes to dxexec. The Get*/Set* module code (getset.c) was casting DXGetModuleId() to a string and parsing it. I implemented a few ModuleID query APIs so getset.c could find out what it needed without breaking the DXGetModuleId() abstraction. |I'll be happy to look at it, but I suspect that the only way to be really |comfortable with it is to run it awhile. On the other hand, you're |apparently running it on the mother of all networks, and if its OK there, |well, then. I'm sure you have a ton of Routes, Switches and macros in |there that will test all the nasty cases. I'm sure it hits quite a few of them, but there are standard modules it doesn't use at all (Supervise* for example). |There are quite a lot of changes between 4.1.0 and the CVS head. How about |running acvs update on your tree to square it up, try it out, and then do |your own checkin? I'd first copy your current state aside so that any bugs |that have been introduced since 4.1.0 (who, me?) won't interfere with your |main path of progress. | |Anybody who can hack the exec ought to be on the inside. If you agree, |I'll set it up. Sure. That'd be fine with me. While I don't have CVS access at work (firewall), I can delta off-hours. On that thread, is there a nightly CVS-latest tarball extracted and made available via HTTP or FTP? That would be helpful. I wasn't able to find this on the DX sites. Lately I've been extracting a CVS tree in the evenings, compressing it up, and e-mailing it into work (or putting it up on a private outside web server where I can grab it). I can automate this for my private use of course. But if a CVS->web tarbal/zipfile service would be useful to other developers (and it doesn't exist already), it might be worthwhile to serve this from opendx.org or research.ibm.com. Thanks, Randall -- Randall Hopper (mailto:[EMAIL PROTECTED]) EPA Scientific Visualization Center US EPA MD/24 ERC-1A; RTP, NC 27711
