Replace __Dymola_checkBox by standard conform one
Remove dummy annotations
Use standard conform annotation for DocumentationClass
Use standard conform annotation for checkBox
Clean up code
Fix typos
Fix typo
Add MCOS test files
Version 1.5.30 release
Version 1.5.29 release
Thanks for reporting. I notice that the test_mat_file.f90 does not used the provided fartran interface in ./matio/src/fortran at all and instead uses own binding interfaces.
Thank you for your effort in the MATIO library and I have successfully compiled this library using ifort and gcc as well as a gfortran/gcc on ALMAlinux 9.3. I did not manage to compile it with icc and ifort (newest API version). I have a test program for writing a MAT file but I can't get this to work and I guess my knowledge of c is reason for this but I have not found a solution for this (after extensive search). The test program : ++++++++++++++++++++++++++++++++++++++++++ program test_mat_file...
it is working now, see the correct code below: program test_mat_file use, intrinsic :: iso_c_binding implicit none type(c_ptr) :: matfile character(kind=c_char, len=*), parameter :: filename = 'zzz.mat'//c_null_char character(kind=c_char, len=*), parameter :: header = 'HEADERSTRING'//c_null_char character(kind=c_char, len=*), parameter :: varname = 'reeks'//c_null_char real(c_double), target, dimension(1000) :: d integer :: i type(c_ptr) :: matvar integer(c_size_t), dimension(2) :: dims integer,...
Potential regression in LoadPixelDataRLE8 since 3.19.0
Version 1.5.28 release
Thanks for your efforts and report. Unfortunately Fortran interface is not tested. I gave up on https://github.com/tbeu/matio/issues/51 as I failed. (That#s why it says "help wanted".) I would appreciate if we could set up a CI stage to build and run the Fortran interface.
This is known issue in matio about the opaque data type, see e.g. https://github.com/tbeu/matio/issues/77 . How did you create the file in MATLAB? Can you use struct as workaround?
This is known issue in matio about the opaque data type, see e.g. https://github.com/tbeu/matio/issues/77. How did you create the file in MATLAB? Can you use struct as workaround?
This is know issue in matio about the opaque data type, see e.g. https://github.com/tbeu/matio/issues/77. How did you create the file in MATLAB? Can you use struct as workaround?
Yes, MATLAB R2023a is supported. Code snippet LGTM. Can you attach the MAT file here for reproduction on my side?
Version 1.5.27 release
The memory passed to Mat_VarCreate needs to be contiguous (3 * 4 * 2 * 8 bytes in your example), which is not the case for std::vector<std::vector<...>>.
Right, pretty likely a duplicate. Thanks for the pointer.
Right, pretty likely a duplicate.
The zlib example code (demonstrated in http://zlib.net/zlib_how.html and available from http://zlib.net/zpipe.c) is reported as "Uninitialized variable: out" on line 70. The out buffer is indeed unitialized, but passed as strm.next_out to deflate function where it is used. I'd consider this as an edge case. What is best practice here? I know I can silence the error diagnostic via // cppcheck-suppress uninitvar comment.
Seems I can't edit the topic typo defalte->deflate.
The zlib example code (demonstrated in http://zlib.net/zlib_how.html and available from http://zlib.net/zpipe.c) is reported as "Uninitialized variable: out" on line 70. The out buffer is indeed unitialized, but passed as strm.next_out to deflate function where it is used. out no longer is used in the driver code, thus it shold be all fine. I'd consider this as an edge case. What is best practice here? I know I can silence the error diagnostic via // cppcheck-suppress uninitvar comment.
I kow I can suppress diagnostic messages with // cppcheck-suppress uninitvar But how can I do it for C89 block comments? I did not get /* // cppcheck-suppress uninitvar */ working.
I kow I can suppress diagnostic messages with // cppcheck-suppress uninitvar But how can I do it for C89? I did not get /* // cppcheck-suppress uninitvar */ working?
The idea is to use the -i flag for file to directory paths to be ignored.
Hi, I am having trouble writing a 3 dimensional std::vector<double> into a mat file. The data needs to be written to a struct with multiple fields. I have managed to write the data of a 1 dimensional vector successfully. However for the 3 dimensional case the saved values in the .mat are incorrect. Below is the code that I used. There is a struct called 'a' which contains the fields 'freq' and 'eth'.</double> 'freq' - stores the content of a 1 dimensional vector. This works perfectly 'eth'- stores...
Version 1.5.26 release
Bump libtool version number
Bump version and NEWS for v1.5.25
Add pre-commit config
Update ignore file [skip ci]
Version 1.5.25 release
Update test datasets
Version 1.5.24 release
See open issues to undocumented opaque type in https://github.com/tbeu/matio/issues/148, https://github.com/tbeu/matio/issues/100, https://github.com/tbeu/matio/issues/99, https://github.com/tbeu/matio/issues/98 and https://github.com/tbeu/matio/issues/77.
pkg-config file incorrect for static linking
Right. Fixed and force-pushed by 1f3bc4af.
Thanks for your feedback. Plase give b7bd42a5 another try.
pkg-config file incorrect for static linking
Should be fixed as proposed by ee6e04a5. Please confirm if the static linking is successful in your env. Thanks.
Thanks for testing. Seems matio is not ready for parallel file I/O.
I doubt that parallel reading is supported for MAT v4 and v5 files. Did you try MAT v7.3 files?
I do not know what you tried, but removing MAT73=1, HAVE_HDF5=1, H5_BUILT_AS_DYNAMIC_LIB, H5_NO_DEPRECATED_SYMBOLS from the pre-processor defines and hdf5.lib from the link dependencies worked for me.
Enable AC_USE_SYSTEM_EXTENSIONS to avoid implicit function declarations
Thanks for the patch. Merged by https://github.com/tbeu/matio/commit/66ba48751a4bbf91070ca9680d0d65237ceb3872 (and later mirrored to SF).
No, hdf5 is an optional dependency as written in the Readme, section 2.1: https://sourceforge.net/p/matio/matio/ci/master/tree/README.md#21-dependencies Matio has two optional dependencies.
When building on mingw you can go for autotools or cmake - whatever you prefer.
Sure, mingw is tested as part of the CI.
Version 1.5.22 release
Did you have a look at section 4.1.2 of the user's guide? Can you also provide the missing file fields.mat. static_cast<const double*> could be const_cast<double*>.
Please provide an SSCCE , similar as given here.
Which version of matio do you use? Should be possible in latest version v1.5.21. See test case write_char_utf8 for an example.
In https://ci.appveyor.com/project/tbeu/matio/build/job/78insi47y9l4hpu7#L167 it says that "autoconf-2.71-1-any.pkg.tar.zst is corrupted", while it worked one month ago as expected: https://ci.appveyor.com/project/tbeu/matio/builds/39615429/job/i9bopwwt7j5jkha5?fullLog=true#L166 . Why it is failing and do I need to fix it on my side? Thank you for your support.
locks up for truncated files
locks up for truncated files
Resolved by v1.5.18.
the use of `mktemp' is dangerous, better use `mkstemp'
Resolved by v1.5.18.
Version 1.5.21 release
Version 1.5.20 release
Version 1.5.19 release
Version 1.5.18 release
Please check the Readme file(s): Matio requires HDF5 version ≥ 1.8.x. matio_hdf5.m4 is the appropriate check if HDF >= version 1.8.x is available. If it is, then HAVE_HDF5 is defined, otherwise HAVE_HDF5 is undefined.
Make RTIambassador subtypable
Ah, that does the trick. Thanks. The merge request is invalid then.
I can check later if the ambassdor object is properly deallocated.
My main issue is that I need to specify/implement the required callback functions. This can only be done using inheritance, right? Without that flag I get an error from the Python run-time that RTIambassador is not a valid class for subtyping.
My main issue is that I need to specify/implement the required callback functions. This can only be done using inheritance, right? Without that flag I get an error from he Python run-time that RTIambassador is not a valid class for subtyping.
Make RTIambassador subtypable
Make RTIambassador subtypable
With the new master I now get the message Could NOT find Python: Found unsuitable major version "3", but required major version is exact version "2" Python 3.7 is what I have installed and what is detected.
Duplicate of https://github.com/tbeu/matio/issues/98?
Copied from https://github.com/tbeu/matio#222-configure-options --enable-extended-sparse=yes Enable extended sparse matrix data types not supported in MATLAB. MATLAB only supports double-precision sparse data. With this flag, matio will read sparse data with other types (i.e. single-precision and integer types).
It seems you built matio with --enable-extended-sparse=yes (which is the default and the expected behaviour). Try building with --disable-extended-sparse and you won't be able to create sparse MAT files that MATLAB cannot read.
Thanks for the feedback. Glad to see that this repo is alive. I will provide a new PR with dedicated CMake fixes (there is one more linker issue in MSVC when building the import libs for the python libs).
Fiy CMake Python detection
Fix Python detection
No, it definitely is not a funfact since it tells you if reading from file was successful. And in case of error you need to react and roll back.
This is wrong from the very beginning and bugs me for years. I already introduced variables readresult to improve the situation. One day, l think I will change the Read... and Inflate... functions to change the return value to a simple success/error value since this is the relevant information.
If you find a proper solution I would be grateful if you could provide a patch. Thanks.
The configure file is generated and should not be edited. The corresponding source for the va_copy issue is config/matio_va_copy.m4. That specific file was added by f2e924ac81e22cd1243fe79f668e80d6d87af383 by an external contributor. I will ask him.
I never built for iOS. Does https://github.com/szanni/ios-autotools help to build matio? Section 2 of the matio Readme is on building.
Well, what is the real issue? There is documentation and build scripts (using GNU autotools) provided, that build the library.
Version 1.5.17 release
Update test datasets
Version 1.5.16 release
Well, fell free to fork https://github.com/tbeu/matio and replace every call of malloc/calloc/free by the appropriate CUDA methods. (Also realloc is used, but you can skip this for now.) Then, run or debug your test application linking against libmatio and see how it works out. If it does, I can add a new handler to overwrite the default memory functions (similar like Mat_LogInit) and use these callback functions throughout the library.
There are plenty of calls to malloc/calloc in the libmatio library. Furthermore, I did not get your context. Do you want to read or write MAT files? Which MAT file version? Hope it is not v7.3, since then you would also need to adapt the hdf5 library.
Version 1.5.16 release
Version 1.5.15 release
Did you read about Mat_VarWriteAppend in the user's guide? Though I have to admit that MAT-file was not invented for streaming.
Did you read about Mat_VarWriteAppend in the user's guide? Though I have to admit that MAT-file was not inveneted for streaming.
Version 1.5.14 release
Version 1.5.14 release
Version 1.5.13 release