a few fixes

[emmt]

A few changes to:

• have methods like readheader and readkey also available at the low level interface;
• fix a bug in readheader (buffer overflow) when dealing with keywords longer than 8 characters (e.g. HIERARCH keywords), the 3 byte buffers are now large enough to store the complete FITS card (which is safe although probably too large but that's only 3x81 bytes....);
• optimize parse_header_val (having the try...catch statements used in last resort) and remove trailing spaces in string vales (according to FITS convetion that trailing spaces are insignificant).

[kbarbary]

Can you rebase your branch on the current master? After merging #25, the parse_header_val function has changed. You'll have to resolve the conflicts in that function. (rebase is preferable to merge in this case!).

This looks good except I'm not in favor of having readkey and readheader work on the low-level interface. I think we should eventually move away from the low-level API and instead try to ensure that the high-level interface suits everyone's needs. So, I'd rather not add new functionality unless it is just a thin wrapper for cfitsio like the rest of the low-level API. Since this discussion goes beyond this PR, I've opened a new issue for it: #27.

[emmt]

We have rebased, the current pull request should be OK the access of readheader/readkey at lowlevel have been removed as you suggested

Le 08/04/2015 18:01, Kyle Barbary a écrit :

Can you rebase your branch on the current master? After merging #25 https://github.com/JuliaAstro/FITSIO.jl/pull/25, the |parse_header_val| function has changed. You'll have to resolve the conflicts in that function. (rebase is preferable to merge in this case!).

This looks good except I'm not in favor of having |readkey| and |readheader| work on the low-level interface. I think we should eventually move away from the low-level API and instead try to ensure that the high-level interface suits everyone's needs. So, I'd rather not add new functionality unless it is just a thin wrapper for cfitsio like the rest of the low-level API. Since this discussion goes beyond this PR, I've opened a new issue for it: #27 https://github.com/JuliaAstro/FITSIO.jl/issues/27.

— Reply to this email directly or view it on GitHub https://github.com/JuliaAstro/FITSIO.jl/pull/26#issuecomment-90959953.

[kbarbary]

Looks good! Merging...

For future reference, your rebase seems to have gone a bit wonky - there's multiple commits on this branch with the same comment (though the end result is fine). If it helps, I've written down a very short guide to rebase here ("what happens when the upstream branch is updated?").

[emmt]

Thank you for pointing this link. I am not yet very comfortable with Git and GitHub principles...

Looks good! Merging...

For future reference, your rebase seems to have gone a bit wonky - there's multiple commits on this branch with the same comment (though the end result is fine). If it helps, I've written down a very short guide to rebase here http://sncosmo.readthedocs.org/en/v1.0.x/contributing.html#what-happens-when-the-upstream-branch-is-updated ("what happens when the upstream branch is updated?").