What is OpenDX? Open Visualization Data Explorer is a visualization framework that gives users the ability to apply advanced visualization and analysis techniques to their data. These techniques can be applied to help users gain new insights into data from applications in a wide variety of fields including science, engineering, medicine and business. Data Explorer provides a full set of tools for manipulating, transforming, processing, realizing, rendering and animating data and allow for visualization and analysis methods based on points, lines, areas, volumes, images or geometric primitives in any combination. Data Explorer is discipline-independent and easily adapts to new applications and data. The integrated object-oriented graphical user interface is intuitive to learn and easy to use. For more information, select the What is IBM Open Visualization Data Explorer? link listed below. See sample images: http://www.research.ibm.com/dx/imageGallery/index.html Reproducible: Always Steps to Reproduce: 1. 2. 3.
I think this is the latest official website: http://www.opendx.org/
This looks really interesting but it's going to take a fair bit of work to get ebuilds together for it. I'm taking a little time to try it out and see what happens.
Status update: I've got an opendx ebuild I think will work fairly well, and I'm working on ebuilds for some dependencies: HDF4, CDF, and jasper. I'm still on the first of those three due to some time constraints.
Created attachment 20505 [details] opendx-4.3.0.ebuild
Created attachment 20506 [details] license
Reassigning to sci so the rest can see what's going on and help with dependency ebuilds if they want. =) Ebuilds still need to be made for HDF4 (HDF5 is in portage already, but this doesn't work with it), CDF (http://nssdc.gsfc.nasa.gov/cdf/cdf_home.html), and Jasper (http://www.ece.uvic.ca/~mdadams/jasper/). I tried to start on HDF4 but haven't gotten anywhere.
an experimental hdf4 version is in portage now. About CDF - doesn't netcdf work? I 'll give it a try.
I believe cdf and netcdf are distinct entities, but not 100% sure.
please note that 4.3.2 is out
I noticed a little late that there already was a "jasper" ebuild around - see bug 35358
Created attachment 22338 [details, diff] patch for the ebuild Patch for the old ebuild. This compiles fine on my system, even seems to run, but it has several problems to be addressed: - the USE orgy of the old ebuild seemed a bit much for me - do you really think we should introduce so many local USE flags for this? - I disabled CDF support, it currently only uses netCDF. - it installs stuff to /usr/dx which is not very nice, FHS-wise. We should make it go into FHS-compliant locations before releasing an ebuild. - I am sure I have forgotten something :-)
In my opinion, everything that has a possibility of being a USE flag should be. Thus the "orgy." If they can't be global, they'll have to be local. Would you rather force-disable things people may want, or force-enable unnecessary dependencies? I see the current solution as better than those options. Why disable CDF? Just because of no ebuild, or is there more? Is /usr/share/dx FHS-compliant?
Ok, having all those USE flags probably makes sense - just please announce them on -core before silently using them and add them to use.local.desc if they can't be made global. And we will have to test a few more compile time option combinations for this monster... I currently disabled CDF just because it's not yet there. No other idea behind that. But I think before adding CDF we should check if it offers anything better than netCDF. About the jasper dependency - we have it in now, but grepping through the opendx sources I get the impression that this is no direct dependency. Perhaps it is used by ImageMagick if available? We should check this. /usr/share/dx wouldn't be any better since only platform-independent files belong into share. If we can't force it to split up properly without producing a total mess, maybe /usr/dx is ok for a start. Not FHS, but /usr/kde and /usr/qt aren't FHS-compliant either...
Agree on the USE flags and compile-time options. IRT the USE orgy, I seem to remember even more configure options with image types but I'll be on a dialup connection for the next three weeks so not much downloading will be happening. http://www.opendx.org/compiling-dx.html : "CDF, netCDF and HDF are data file format libraries. CDF and netCDF are required to run the samples and tutorial." More tips and functions for each library here: http://www.opendx.org/compiling-libs.html I don't see anything clear for jasper either. Perhaps we should fix our imagemagick build to use it, since it doesn't now. I wasn't thinking clearly when I asked about the FHS thing, forgive me. =) It's been a long few days.
Created attachment 22540 [details, diff] patch for old ebuild Ok, brought back the USE flags and added CDF to portage. This works quite nicely for me (still installs into /usr/dx) - please test and report if you find problems or if this can go into portage. I disabled java support since I was not able to make it compile properly with java enabled.
Patrick, You've really done some fantastic work here, with all the libs and the work on this. Nice job! I'll download and take a look at this over the next couple of days. The only problem I have with it is that the image format USE flags (at least tiff, I don't remember what else) require the imagemagick flag AFAIK. Do you know if nested USE works yet? For example: imagemagick? ( >=media-gfx/imagemagick-5.3.3 media-gfx/jasper tiff? ( media-libs/tiff ) mpeg? ( media-libs/mpeg ) ) And so forth... again I know I don't have all the options quite right.
Nested USE works. At least I used it in the last ethereal ebuild :-) About tiff support, different from the documentation I think that imagemagick is not required. From the ./configure run: configure: checking for TIFF support ...... checking tiff.h usability... yes checking tiff.h presence... yes checking for tiff.h... yes checking tiffio.h usability... yes checking tiffio.h presence... yes checking for tiffio.h... yes checking for TIFFOpen in -ltiff... yes checking if TIFF package is complete... yes That doesn't look like an indirect dependency. Looks like the documentation is not up-to-date regarding this aspect - perhaps we should report this when we have a final tested version of the ebuild. Jasper is different, I think it's something that should better be handled by the imagemagick ebuild.
Hey guys, so what's the status on this? I am asking because I see hdf flag listed in use.local.desc and referencing this package, but apparently the opendx itself is not in the tree. Actually my interest was in hdf use flag. The thing is app-sci/octave has optional support for hdf5 and, potentially, it might be worth using one common flag (and thus making it global). However I see that opendx uses plain hdf[4], so technically this is different. Although it still should work with plain hdf use flag, - every app will use the corresponding version of hdf (they come as different packages because of format incompatibilities). So it might be worth sticking with just one flag.. What do you think? For now I added hdf5 to use.local.desc, but this will need to be revisited, when this bug gets resolved. George
Patrick's modified the ebuild some, but he's away for the month of January. I'm not sure whether he has further local modifications that aren't up here so I'm hesitant to commit this. IRT the hdf USE, I think this might be a good hdf4 flag and you could use either hdf or hdf5 for the "new hdf." It might be a good idea to have separate flags in case a package supports both hdf4 and and hdf5, although I'm not aware of any.
I didn't change anything since the last patch you find here - indeed I was hoping to find a working OpenDX in portage when I am back :-) The ebuild will still need a bit work, for example the jasper stuff seems to belong into imagemagick. No reaction from the graphics guys so far, see bug #36349 for that problem.
Created attachment 25551 [details] opendx 4.3.2 ebuild
Created attachment 25552 [details] opendx-samples 4.3.2 ebuild Hi folks, I made these ebuilds for opendx and opendx-samples. They are very simple, and do not have USE flags for installation customizing, but worked very well for me, including with javadx. Maybe it helps. -- Nilton
Created attachment 26546 [details] opendx-4.3.2.ebuild Here's my latest ebuild. A full build of 4.3.2 (all USE enabled) dies, however. Haven't tracked it down yet.
Created attachment 26547 [details] failed compilation log of 4.3.2 If anyone cares to contribute ideas, take a look.
Hm, a different error this time. Made it through compilation, got this on install. sh ../mkinstalldirs /usr/local/build/portage/opendx-4.3.2/image//usr/dx/html make install-data-hook make[4]: Entering directory `/usr/local/build/portage/opendx-4.3.2/work/dx-4.3.2/html' make[4]: *** No rule to make target `install-data-hook'. Stop.
Donnie, perhaps it's a parallel build problem?
Heh, I actually had that idea earlier today but I forgot it. Thanks for reminding me.
Managed to reproduce the problem in comment #25 with a non-parallel build.
OK, this is a little odd. It was the doc flag I added (`use_with doc installhtml`). Whether it's on or off, it seems broken, but if it's not there at all it works.
use_enable, rather
Created attachment 26672 [details] opendx-4.3.2.ebuild So, here's my final version. Patrick, wanna look over this and try it out?
Donnie, I'd say let's bring this into portage as soon as possible and attract testers. I just removed the dependency on bug 36349 because jasper support is nice, but we can survive without it. Agree?
Sounds good.
Donnie, just for the case you're waiting for me to commit this - I am waiting for you do commit it :-)
Heh, OK. I was. I'll commit soon.
Donnie, could you please make a last minute change before committing? We are allowed to mirror the sources.
Committed. Thanks for playing.
