add a README.me with an example

[volodymyrss]

No description provided.

[dsavchenko]

I saw the example in the README and I wonder if one always needs to create the ArrayBuffer for files manually. May it be integrated in the lib (like it probably was before) ?

Also, I remember, at least in the original code there were parts responsible for large files, to not load them into memory completely. Not sure if it was really functional... But using ArrayBuffer is always loading the entire file, am I right ?
This is a bit unrelated to our current use-case (probably only relevant if using as a node lib), still interesting to know.

[francoismg]

I saw the example in the README and I wonder if one always needs to create the ArrayBuffer for files manually. May it be integrated in the lib (like it probably was before) ?

Also, I remember, at least in the original code there were parts responsible for large files, to not load them into memory completely. Not sure if it was really functional... But using ArrayBuffer is always loading the entire file, am I right ? This is a bit unrelated to our current use-case (probably only relevant if using as a node lib), still interesting to know.

Yes we could have the lib handle file loading and just have the user provide some url but then it will rely on a callback of some sort. I thought it would make more sense for the lib to only focus on file parsing rather than handling file loading but I can change it if you prefer it that way no problem.

ArrayBuffer is always loading the entire file yes as far as I know. The previous version that was dealing with that was using an arraybuffer when the user provided an url and the filereader api when it was a local file (or file object). The parser would only load the headers and then each "classes" had to either load thing themselves if it was a file object or could just function as usual if provided with a buffer.

I didn't think it made much sense to keep it since it made the code less clear and that we were not going to use it but it was hard to totally understand so maybe I missed something.

I'm not totally sure that it was working since I only worked with url when trying the library but if you think it would make sense to add it back so it can work with local file we could try no problem.

[dsavchenko]

Yes we could have the lib handle file loading and just have the user provide some url but then it will rely on a callback of some sort. I thought it would make more sense for the lib to only focus on file parsing rather than handling file loading but I can change it if you prefer it that way no problem.

Couldn't it be used both ways, either accepting ArrayBuffer or file path with a similar API ?
If that's complicated, then we just keep it as-is for a moment.

I'm not totally sure that it was working since I only worked with url when trying the library but if you think it would make sense to add it back so it can work with local file we could try no problem.

You are right that we currently (and in the foreseeable future) don't need this way of operation, so this was more the question out of curiosity. In the distant future, if we continue to support this library, this could be added.

[dsavchenko]

Unrelated to previous comment.
I think we need to add to the README a reference to the original library with some description of how it was transformed to become this repo (coffescript version etc.), what's kept, what's dropped etc.

[francoismg]

Couldn't it be used both ways, either accepting ArrayBuffer or file path with a similar API ? If that's complicated, then we just keep it as-is for a moment.

Yes it could but then the user would have to provide a callback. I will try that and let you know

[francoismg]

Unrelated to previous comment. I think we need to add to the README a reference to the original library with some description of how it was transformed to become this repo (coffescript version etc.), what's kept, what's dropped etc.

ok I can do that no problem

[dsavchenko]

Yes it could but then the user would have to provide a callback.

In current example, readFile function which uses FITSReader inside is provided as a callback to getFile. will it be different from this approach?
I don't know, probably I'm just thinking too "pythonic" here, and the way you propose is a preferred js way...

[francoismg]

Yes it could but then the user would have to provide a callback.

In current example, readFile function which uses FITSReader inside is provided as a callback to getFile. will it be different from this approach? I don't know, probably I'm just thinking too "pythonic" here, and the way you propose is a preferred js way...

We could use a promise like in the getFile approach yes, the call to parseFile() would return a promise instead of a fits object directly and then the promise would resolve with the fits object when loading and parsing are complete. I will just need to test that it doesn't break anything since it would be a bit different than just having a callback executed but it should be fine yes. Will try that and push the changes when it's ok