Carlo, Carlo de Falco wrote: > 2010/11/5 Philip Nienhuis<pr.nienh...@hccnet.nl>: >> Hi Levente (is that your first name or family name?) >> >> please cc the octave-forge developers mailing list too (now added) >> >> Read on... >> >> Levente Torok wrote: >>> Dear Philip Nienhuis, >>> >>> I am searching for you as a maintainer of io package on octave-forge. >>> I was suggested on octave-maintainers list to turn to you with my idea >>> to put savevtk savevtkvector functions into package io since doesnt >>> seem to fit the core functionality and for having a separate package >>> supporting a simple file export to vtk file format is not worth. (NB: >>> this file format is for mayavi too) >>> Please have a look at the enclosed two files and insert them into >>> package io if you find it appropriate. >> >> I'll be happy to add them if you agree to "maintain" them. >> I know next to nothing about VTK or mayavi so I can't offer any support. >> User questions are conveyed directly to you, OK? >> >> I hope to be able to update the io pkg before the end of the year; I >> have many bugfixes and enhancements in svn and several more pending on >> my box at home. >> >> >> Then, please try to adhere to Octave coding style: >> >> - 2 spaces rather than tabs (but I still use tabs in my own scripts so I >> don't mind this particular one) >> >> - spaces between internal function name and left paren; no space between >> array name and left paren or bracket >> >> - functions end with "endfunction" rather than "return" >> >> - appropriate end statements: if- elseif -else - endif / for - endfor / >> while - endwhile / etc. >> >> - spaces after commas in argument lists (e.g., "(a, b, c)" instead of >> "(a,b,c)") >> >> - are you sure your function shouldn't return some value, for successful >> writing or not? I see no write error catching structures at all >> >> - I think you should check for the return value of fopen and perhaps >> also fprintf to see if the calls succeeded (hint: fprintf returns the >> number of characters written). >> A try-catch or unwind_protect construct could be around the fprintf >> statements to maybe avoid dangling file pointers. Upon errors and >> ensuing break out of savevtk....() the output file will probably be >> closed anyway but personally I like more graceful solutions. >> >> - comments start with # rather than % >> >> - in the Updates: section in the headers, please add some short >> description of what the update was all about >> >> - The copyright sections in the headers seem incomplete >> >> - in savevtk.m an empty line is needed between the copyright statement >> and the texinfo header >> >> - the texinfo headers seem a bit odd to me. Have a look at e.g. the >> Excel or OpenOffice.org scripts for examples >> >> - would a test case or some test section be useful? >> >> But OK, maybe I am just too picky.... >> >> >> Please try to incorporate these style thingies as much as possible and >> resend them to me, OK? >> >> Thanks + best wishes, >> >> Philip >> > > > Hi, > > FYI there are already functions for 'UnstructuredGrid' vtk files in > the package 'fpl' and we have functions for 'StructuredGrid' vtk files > in geopdes (http://geopdes.sourceforge.net) that we would also like to > move into 'fpl', maybe it would make more sense to keep all this > functions in one place? should all vtk functions go into 'fpl' or > should maybe 'fpl' be merged with 'io'?
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). 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). Philip ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
