Haymo Kutschbach
Haymo Kutschbach
In a perfect world this repo would host the managed source files + official binaries for all 'major' platforms targeted by .NET today. This would be: Windows, Linux, MacOS, each...
You mean, all binaries are included and it builds a multitargeting nuget package which we can consume for building and publishing .NET Framework + .NET Core (/5) projects? How could...
Excellent! Thank you!
We might add a note to the documentation about some restrictions implied by this packaging approach: * AnyCPU targets are not supported. Users must specify the platform configuration (x86, x64)...
PS: the term 'not supported' may sound a little too harsh. In fact, it means that the consumer of the HDF.PInvoke.Netstandard nuget package in such 'unsupported' scenarios must handle the...
Thanks for the clarification! I don't have a one-for-all solution and I doubt it exists today. What was easy in a .NET Framework world becomes at least unspecified in a...
> In other words, there is no way to tell if a dataset was written by a C or Fortran program. It always ends up in the file in C-order...
The key is this statement: > The hidden and problematic assumption is that HDF5 knows what a matrix is. HDF5 doesn't. Indeed this view is new to me and makes...
Thanks @JanWosnitza. Great effort and an interesting attempt to ease the handling of our id types. Just some points to consider: - Wrapping the id / err values into a...
> the user of the library can decide which one to use. Except that one still must decide which `HDF.PInvoke` to compile, no? So we wouldn't get rid of the...