Read/Write Nifti files

The following thread is open to integrate niftiread, niftiwrite and niftiinfo routines in the Image toolbox. GNU Octave - Patches: patch #9853, [octave forge] (image) implement... [Savannah]
What are the next steps to facilitate the integration?

Your question is probably best addressed to the people who were in that patch thread: tagging @fangq, @carandraug, @Guillaume, and Hartmut (who doesn’t seem to be on Discourse).

Hi @adityaapte ,
if you are interested in helping with the mentioned patch, please continue with your communication directly in the Savannah bug tracker (the link you mentioned above). As you can read in this bug tracker, there was some discussion with the submitter of this patch two years ago, about how to integrate his code into Octave, bug at some point he never answered any more. So if you are interested, let’s continue there.
@arungiridhar I now eventually created my discourse account :slight_smile:

2 Likes

here is the latest code that is being prepared for review

I will add more tests, but functionality-wise, it has been working fine (and all current tests have passed).

The only thing I want to get some input is on formatting styles (also see the Savannah bug tracker). I want to hear more opinions on what is considered “acceptable” (not necessarily “preferred”) styles when contributing new units.

here is the “preferred” octave formatting style guide Octave style guide - Octave

Among all the styles, I can see using the following styles will break compatibility to MATLAB:

  • using # or ## for comments/docstrings
  • using endfunction/endfor/endif/endswitch

as someone who treats writing non-portable codes as a crime, I feel quite uncomfortable to adopt these two styles, because that means I will have to maintain two separate code bases with largely redundant codes, which is something I tried very hard to avoid.

I would like to know:

  • are the above two style requirements absolutely needed or %, %% and end are also acceptable (understandably not preferred)?

if the answer to the above question is yes, that at least allows me to maintain a single version to support both MATLAB and Octave moving forward.

1 Like

@fangq If I understand the context correctly, the Octave style guide you link to is for contributions to Octave core, not for packages like image which are external to core. Your maintaining a single package / toolbox for both Octave and Matlab is a good reason to use only those syntax features that are common to both languages. @Hartmut, your thoughts on this?

I think my opinion depends on what your plans are:

A) If you are planning to create a new and seperate Octave package, then I think it is your freedom to choose what style guide to use. It would then be possible and might even be a good choice to have a code base that can run under Octave and Matlab as well.

B) If you are planning to contribute to an existing Octave package, like the image package, I would say it is much better (you can think “required” at this place) to adhere to the style that is used in this existing package so far. Contributing to an existing package implies that the package maintainer (the present or any future package maintainer) will try to take care of the code after submission. E.g. adopt it to changes in core Octave, fix bugs, etc. And this is much easier if all of the code in one package follows the same “rules”, like for example coding style. And in the image package there already is a lot of code.

As someone involved in the image package, I would be very happy to include your mentioned code into the image package (=B). I know that this is more initial work for you to the adopt code to style guides. But it pays off in the way I explained above, because your code is then mostly taken care of in the future. My personal preference would therefore be to include your code to the existing image package (in the way discussed in the bug tracker). Your code would probably also benefit a wider audience, just because it gets more attention when included in a already established package.

When you create a new Octave package (=A), you would then probably be the maintainer yourself, right from the start. That makes it easier for you to do fast changes. But there are probably less eyes checking your code. You can have the code Matlab and at the same time Octave compatible. But it might be harder to keep the code “alive” once you stop your engagement and the package gets “orphaned”.

At the end it’s your decision how you want to publish your code (A or B). My personal preference, hope and suggestion would be B (=inclusion in image package), but it’s up to you.

Note: Please let’s try to keep the parts of the conversation, that are only related to patch 9853, mostly collected at the same place, which in this case is the bug tracker where the discussion started years ago.

3 Likes

B) If you are planning to contribute to an existing Octave package, like the image package, I would say it is much better (you can think “required” at this place) to adhere to the style that is used in this existing package so far. Contributing to an existing package implies that the package maintainer (the present or any future package maintainer) will try to take care of the code after submission.

yes, this was my intent and I absolutely respect maintainer’s preferences. My above post was trying to understand how strong/soft was these preferences. From your reply, it seems these are “required”, and I will follow such requirements to do the formatting.

1 Like