c. wrote: > Philip, > > On 15 Nov 2010, at 21:09, Philip Nienhuis wrote: > >> Oh I didn't know. Thank you for this info. >> I suppose Levente and I just followed Martin Helm's suggestion (in the >> maintainers-octave ML) to put them in IO. >> Googling around for vtk I got the impression that vtk is more related to >> graphics output than just plain file I/O but then again not so closely as to >> put the scripts in the plot pkg. >> >> So, if there's already a better home for<whatever>vtk in the fpl pkg I think >> it's a good idea to put them there. >> >> I'll wipe them from io svn (I uploaded them just yesterday). > > I didn't mean to say you should remove them, maybe io IS the right place for > functions that write vtk files? > what I meant is that, given that we have many different functions that save > to different vtk file formats, maybe we should > chose one single package where they all can be put together. > > I see different possible solutions and would be interested in hearing > somments from others > > solution 1) > putting all vtk-file related functions in fpl which is a package meant to be > used for allowing data visualization with external programs > > solution 2) > as many functions to output in third party file formats are in 'io' maybe the > vtk functions should also go there > > solution 3) > 'fpl' is composed of 3 different sets of functions: > [a] functions to output data in external file formats (.vtu and .dx) > [b] wrappers for controlling opendx visualization from within octave > [c] wrappers that produce plots in octave's own plotting system with a syntax > compatible to matlab's pde-toolbox (pdeplot, pdemesh) > so maybe we could get rid of 'fpl' by moving [a] into 'io' removing [b] (as > opendx is now obsolete and unmaintained) and moving [c] into 'bim' which is a > package similar to pdetool
I don't mind (as io-pkg maintainer) to have vtk stuff (and possibly other stuff too). Only thing is that I currently have little affinity with them as I don't know what those functions are supposed to do. Nor do I have time to dive into it. That means that real maintenance cannot be guaranteed by me. If enough developers agree that these functions had better go in the io-pkg, very well, but I can only maintain very basic stuff like -indeed- I/O error catching and perhaps some cosmetics. So in the io-pkg we get maintained and unmaintained scripts. Not very clear to casual octave users, but that is a consequence. But perhaps no big deal after all. What do the other devs think? >> Nevertheless, I think (some/most/all of) my remarks about style and error >> catching still hold (especially error catching as unwary users may have >> undue trouble figuring out exactly what went wrong when errors occur). > > I also think your comments did make sense Yep. Which brings up a relating issue: do we need some sort of quality review for accepting scripts or packages, or do we just accept everything which comes along? I only remember my first contribution to octave-forge 10 years back (funm.m) which was about as bare as the vtk scripts recently sent in by Levente Torok. Paul Kienzle helped me out to make them more robust; I suppose I now can return that favor to the community, but like PK at that time, I can only do some cosmetics. We didn't hear from the author (Levente Torok) since several weeks now. It's sometimes a bit difficult to weigh our own time for tuning scripts sent in by passing-by users against the usefulness of those scripts. If they are useful I don't mind putting in some effort; OTOH if the scripts are of little general use we should invest our time in more urgent stuff. Someone more knowledgeable in the field of vtk ...dx .... should have a say here. Please? Philip ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev