Open anowacki opened 4 years ago
What's the use case?
I like the idea of 32-bit support, but this is fundamentally harder and more time-consuming than you make it sound. It's not as simple as changing all my Int64
declarations to Int
.
Dependencies are the issue. I implicitly assume 64-bit architecture for SeisIO because my dependencies don't test 32-bit and neither do their viable alternatives. Surprisingly many Julia packages are only tested on, and seemingly developed for, 64-bit Linux. Extending support to 32-bit Windows is a deep dive into unknown territory.
I would almost certainly approve a PR for this, if you wanted to create one, assuming tests pass and code coverage remains at current levels. I can't do it myself without demonstrated widespread need, though. I simply don't have time.
Okay, thanks very much for clarifying that 32-bit OSes are not currently supported—it was mainly a clarification issue. It might be worth stating somewhere in the docs/readme which platforms are supported, since you can't declare compatibility to the package manager.
As far as use-cases: it's nice to support these systems if it's not too much work since you never know what sort of old laptop you might end up with in the field (or teaching). I've used 32-bit Windows with students only this year and it was great to be able to do some rudimentary processing with them of their data using Julia rather than faff about with proprietary software, and without installing something like MinGW, Cygwin, and so on. (Julia's actually pretty nice like that—download the exe and the world of packages is right there at the REPL). I've also serviced stations in the UK using a cheapo Intel Atom-based Windows machine which was 32-bit. It would have been even cooler if I could have read the SEGY files directly in Julia! I think that sort of thing would be a great killer feature of SeisIO and it seems well within the scope of the package.
Of your direct dependencies, only Glob.jl and DSP.jl don't test on x86 Windows as far as I can see. (32-bit Linux is another story apparently.) I've never had any problems with either of those packages running 32-bit Windows CI tests for my packages, so maybe one option is to declare 'partial' support for it—"I'll make sure my own tests pass, but you're on your own if my dependencies start breaking".
If I can find time, I'll scope out how much work changing to native integers would be for SeisIO, but as you say, it looks like there are a lot of types to change (or remove). But another marking wave approaches...
It's still not that simple. I'm glad to hear that only DSP and Glob are left -- that's certainly changed -- but what if one breaks? Moreover, neither of us has carefully checked indirect dependencies, of which there are many.
maybe one option is to declare 'partial' support for it—"I'll make sure my own tests pass, but you're on your own if my dependencies start breaking".
I'm sorry, but no. This is a published work; a warning like that would be irresponsible.
I've used 32-bit Windows with students only this year
How common are 32-bit Windows machines at your university?
The main reason I created SeisIO with 64-bit machines in mind is that 32-bit computers were already rare by mid-2016. For example, 32-bit Steam users were only 2.1% of the total in December 2017. I know gaming statistics have a bias -- new games are usually for cutting-edge hardware, of course -- but that number is almost certainly even lower now.
Portability is a major goal of SeisIO, but 32-bit Windows is simply not a priority. Julia language appears to prioritize development similarly: from what I can tell, most code is developed for 64-bit architectures and adapted for 32-bit later.
I've also serviced stations in the UK using a cheapo Intel Atom-based Windows machine which was 32-bit.
Interesting. How do you plan to use the Julia language to service field instruments with a 10-year-old netbook?
No need to apologise—your package, your choice! Thanks for giving some clarity. As I said, perhaps mentioning that in the installation instructions would be nice. Possibly throwing an informative error at the start of the module on 32-bit machines would be nice too, as that should happen at the start of precompilation before hitting the no-method errors later.
I think we're a bit off-topic here, but:
How common are 32-bit Windows machines at your university?
For teaching in the field, (un)surprisingly common. If these things keep running a few Geodes and the teaching software well (and don't connect to the internet), there's no real need to replace them.
Interesting. How do you plan to use the Julia language to service field instruments with a 10-year-old netbook?
(It's not 10 years old, but though it does a decent job it's still not the most pleasant experience. But sometimes the machine you plan to use proves not to be 100% reliable, so taking a backup with decent battery life is in my view vital.)
On the occasion I have in mind I had to do the conversion to SAC in something else, but then picked and located events in Julia whilst in the vehicle waiting for something. And like I say, it was actually easier to install than other options. (I'm sure you have similar field analysis stories.)
On the occasion I have in mind I had to do the conversion to SAC in something else, but then picked and located events in Julia whilst in the vehicle waiting for something. And like I say, it was actually easier to install than other options. (I'm sure you have similar field analysis stories.)
I understand, but the task you're describing is rare. SeisIO is a volunteer effort with no current grants of my own. Because of other (mainly financial) obligations, until that changes, I need to prioritize my time based on which use cases are most common. Your example is a rare scenario; most researchers would do this with something like HYPOELLIPSE.
Great to see all the progress with SeisIO!
I was wondering—are 32-bit platforms supported by SeisIO? Or are they explicitly not supported?
I ask because I am experimenting with using SeisIO for IO, and I think that 32-bit Windows builds fail because integers literals are
Int32
s on that platform, and there are lots of cases where type signatures for methods are restricted toInt64
s in SeisIO. As integer literals areInt
s, they are different between 64- and 32-bit platforms.The particular failure which stops the build is here: https://github.com/jpjones76/SeisIO.jl/blob/7b1bffad726189ce90f8846c92057191f9461801/src/Types/KWDefs.jl#L134 but I think that's just the first place where one of these is encountered.
If 32-bit Windows (and I presume Linux—I haven't tested that) is a target, then there may be quite a few places where either explicit conversion to
Int64
fromInt
will be necessary when the methods are restricted, or signatures will need to be made less restrictive. The latter feels more Julian, but again you may have reasons to restrict types so strongly.(Conversion to the correct type for typed fields of a (
mutable
)struct
happens automatically by default, but I guess this is overridden for a reason in SeisIO since there are inner constructors which replace the default ones forSLDefs
andFiltDefs
.)I haven't had any issues supporting 32-bit OSes before, so hopefully if this isn't something you planned to provide for, maybe it wouldn't be too big of an ask. Very happy to help.