Philip Nienhuis wrote: >> I tend to use texinfo so that help pages appear correctly and I can >> include all of the documentation in a *.info in the directory with >> the functions and "doc <func>" can give more complete documentation >> including examples and context than the help file can. > > Hmmm, texinfo proficiency is not my greatest virtue :-) > > I did add texinfo-like stanzas in the m-file themselves, those 4 or 5 > codes I found in other m-files were at least comprehensible and it > looks OK in octave when using "help <script>".
Take a look at the comms and fixed packages documentation for ideas you can basically just use the mkdoc and mktexi scripts in octave-forge to allow you to include your existing help strings in the docs with the DOCSTRING macro and add some extra explanation around it.. > > Could WinTexmacs help here? Don't know... > >>> 3. Place to live in issue >>> ------------------------- >>> >>> My current idea is to put all the files in the IO package (licenses >>> permitting?). It doesn't really hurt if neither COM nor Java/ POI are >>> installed; xls stuff won't read .xls files then but at least xlsread.m >>> will still function as it did before (= read .csv files). >>> >> Not sure that is the best idea, as you'll be adding a dependency on >> the java package (that has been troublesome in the past). > > Well, dependency... the way I made it work is this: > > 1. <My xls stuff> first checks for ActiveX/COM. If not found, too bad, > try next .xls interface. So having the Windows package is helpful, but > it doesn't really depend on it. > 2. If no ActiveX/COM is found it tries Java. > If Java doesn't work it reverts to csvread stuff, so IMO there's no > real dependency on Java either. > 3. If Java is found to be working (by a try/catch on javaclasspath) > the classpath is checked for the Apache/POI classes. If not all of > them found, again csvread looms. > > And so on. > > Some interface method will eventually work, but the more options you > got installed the better the Excel file interface you might get. Al > sorted out by the scripts w/o much user intervention. > > All in all, that's why IMO it won't hurt to put it in the IO package. > But I'll happily accept better suggestions. Ok, then I suppose that means that the java and windows packages are "suggested", and you should use a keyword Suggested (that will be ignored by octave-forge) in the DESCRIPTION file of the io package if you include your files there. > > I think it is prnienhuis -a-t- users.sf.net > BTW When I reactivated it last summer, I was immediately drowned in > spam with that very sourceforge email address forged as sender, so I'm > a bit wary here. Apparently the sourceforge security system is a bit > leaky. > > Only thing I need to sort out is how ssl (putty?) works on Windows (I > already got the octave-forge svn on harddisk). I rarely use linux > these days but I might give svn/ssl a try there. > > I'll await more concrete directions on where to put all the xls scripts. Ok I added you as a developer.. Its not sourceforge that is sending the spam (read the headers) someone if using the e-mail address to spam you and trying to get around spam filters by using the destination e-mail address for the sender address (as this will be a valid address). Sourceforge e-mail addresses are fairly easy for spammers to get as they can basically get them from the sourceforge website. David ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
