2011/9/22 Philip Nienhuis <pr.nienh...@hccnet.nl>:
> Carnë Draug wrote:
>>
>> 2011/9/21 Philip Nienhuis<pr.nienh...@hccnet.nl>:
>>>
>>> Carnė Draug wrote:
>>>>
>>>> Hi Philip,
>>>>
>>>> an user (Juan Pablo Carbajal) has recently submitted some new
>>>> functions for inclusion in octave-forge to load SVG files. While in
>
> :
> <snip>
>>>
>>> Are the returned SVG structures only, or predominantly, useful within the
>>> scope of image processing?
>>> => if Yes, IMO the image pkg would be more appropriate
>>> => if No, the io pkg could be used.
>>> In either case a separate "svg" section would be appropriate.
>>
>> I don't think they will ever be used in the realm of image processing.
>
> Good, I love clear answers :-)
>
>
>> But I also see that it doesn't fit on the IO package perfectly. It
>> occurred to me now, that maybe a new package, geometry, would be
>> appropriate for the following reasons. Juan has also submitted some
>> other functions
>
> Oh I don't mind having them in io - my concern is that unwary users need to
> be able to find certain functions in a package which best serves the
> particular purpose (and has a name that relates to that)
>
>
> <snip>
>>>
>>> Regardless of what the files do, I don't know what they are used for, or
>>> can
>>> be used for, or are intended to be used for, so I can't maintain them
>>> anyway.
>>> But OK let's say I only maintain the "package" (= the "container") :-)
>>
>> That's what I meant yes. I wouldn't dream of imposing anyone with
>> maintaining somebody else's code. Apologies if it sounded otherwise.
>
> Don't worry, but until recently I was in a luxurious position of only having
> to care about the spreadsheet scripts :-)
> Looking at the image package's contents there may be other situations,
> indeed.
>
>
> Then:
>
> Juan Pablo Carbajal wrote:
>> On Wed, Sep 21, 2011 at 10:59 PM, Juan Pablo Carbajal
>> <carba...@ifi.uzh.ch> wrote:
>>> 2011/9/21 Philip Nienhuis<pr.nienh...@hccnet.nl>:
> :
> <snip>
>>>> I would like the files to comply a little bit more to coding standards,
>>>> i.e.
>>>> - space between arguments after commas
>>>> - space between function calls and left paren but not between variable
>>>> names
>>>> and indices
>>>> - spaces around operators
>>>> all of this for better readability.
>>>> ("a bit more" because I think the style is already quite good)
>>>> In addition I don't like uppercase in function names and -calls <snip>
>>> I am happy to comply to standards as soon as I can find them. I did my
>>> best to make the functions look as Octave functions, but observation
>>> isn't flawless. I can improve the syntax, no problem. Concerning
>>> naming of functions, what do you suggest? load_svg instead?
>
> Yes, I think so.
>
> As to style: I once read (IIRC on this list) a posting of one of the admins
> that coding rules for the "main" branch would be more "strict" than for
> those in the "extra" branch, as "main" would be the most closely linked to
> core octave. Well, I'm not so strict, but I try to adhere to the guidelines
> e.g., here:
>
> http://wiki.octave.org/wiki.pl?action=browse&diff=1&id=StandardsMFiles
>
> ....not so much for the sake of blindly following conventions but only
> because these guidelines make it easy (for me at least) to more quickly
> grasp what some code does.
> And as I wrote, your code is quite good in this respect.
>
> And for an example of discussion on coding style and the reasons pro/con,
> see here:
> http://octave.1599824.n4.nabble.com/Question-on-performance-coding-style-and-competitive-software-td1655155.html
>
> Draw your own conclusions....
>
>
>>> Regarding the maintenance of the files. I can offer to send new
>>> versions and extensions as they are generated. I wouldn't qualify for
>>> a maintainer of any of the two packages.
>
> Sure. Just wait what the finally "chosen" maintainer has to say.
>
>
>>> I can start creating documentation for the /doc folder. I am afraid,
>>> though that I have no clue how to do it. I will check other packages.
>
> Texinfo is hard (because I don't know it). But there are examples in the
> "fixed" package.
> FYI, I don't speak texinfo either. The docs for the io pkg are still just
> html 8-(
>
>
> <snip>
>> I forgto about the Matlab issue
>>
>> Matlad doesn't complaint when it finds %%, the code might look ugly in
>> the matlab editor, but nothing else. My colleagues complaint if they
>> find ##.
>
> Obviously yes if the file is to be used in ML too.
>
> BTW, in the OF dev guide
>
> http://octave.sourceforge.net/developers.html
>
> in "where does your code belong" it is stated that code that should also run
> in ML belongs in the "extra" branch. But again, in practice this is not very
> strict (not even in the io pkg).
>
>
> Anyway, I forgot to thank for your contribution, sorry, so I do it now:
> thanks!!
>
> Philip
>
Hi Philip,
Thanks for your mail.
Things have changed a little bit now. All the files will go into a new
package geometry.
In my opinion changing "%%" to "##" is just Ctrl-h, or even less for
vim users. But as you may known many ML users are already in the Dark
side and they do not like to touch "horrible" source code. If it is
required that %% goes ## I will do it, and then I will provide my
colleagues with ML compatible versions.
Regards,
--
M. Sc. Juan Pablo Carbajal
-----
PhD Student
University of Zürich
http://ailab.ifi.uzh.ch/carbajal/
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Octave-dev mailing list
Octave-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/octave-dev
