bmsherman / haskell-matlab Goto Github PK

Currently we have newtype MStruct = MStruct { mStruct :: [(String,MAnyArray)] }.
Instead, we could use newtype MStruct = MStruct { mStruct :: DM.Map String MAnyArray }

This would likely be a more pleasant interface to work with by default.

Is it possible to support Cabal-1.22., Cabal-1.23.?

The bin\glnxa64\ folder is not available on my system. How to proceed?

Error message: * Missing C libraries: mx, mat, eng

Currently there is no way to retrieve stdout of the MATLAB process; for this we need engOutputBuffer, and possibly some convenience APIs written atop it to make dealing with buffers less burdensome.

We could switch to using engOpenSingleUse as the default, as I believe it is a better (safer) default that would allow for Haskell-managed concurrent programming. I suppose we could migrate the existing engOpen-using functions to another name, though I can't immediately think of a good use of them other than to communicate with other applications via MATLAB.

Possibly related: #10

Currently, some errors, like those causes by improper (or buggy) use of clearVar, cause output to happen in stderr (I think). We could detect this in MATLAB with try-catch and return MATLAB incantation of Either. See here for a discussion on the issue of using try/catch, however.

So, other avenues of attack may need to be considered as well.

I try to build the package from hackage with lts-14.27 and the corresponding ghc 8.6.5. I have put the necessary extra libraries as flags to cabal or stack, as recommended in the read-me file, but cannot find the libeng.so (i.e. the linker complains Missing (or bad) C libraries: eng, eng. I assume the missing file is libeng.so which I saw in some other reports on problems with Matlab.

I have the current Matlab version R2022a and fear that is the cause. Any suggestions?

For some reason, the package does not seem to work on Windows machines. Haskell's FFI appears to interact differently with the MATLAB API than does, for example, calling the API directly using 64-bit C code compiled with GCC. Setting some internal MATLAB types to specifically be 32-bit resolves the issue; OS-specific conditional compilation allows the package to function correctly on Windows.

I am not sure why Windows seems to misbehave in this way, and how this issue can be resolved.

I am using MATLAB 2011b and tried to install by including the extra lib and include folders, but cabal still complains about "Missing C libraries: mx, mat, eng". I have used the command

cabal install --extra-lib-dirs="/usr/local/MATLAB/R2011b/bin/glnxa64/" --extra-include-dirs="/usr/local/MATLAB/R2011b/extern/include/"

Any help would be greatly appreciated. Thanks.

Oddly, this isn't something I'd thought of in MATLAB until working with haskell-matlab. But unlike JavaScript, which only has a double type, MATLAB actually does have (sized) integer types:

>> class(5)

ans =

    'double'

>> class(int8(5))

ans =

    'int8'

>> isinteger(5)

ans =

  logical

   0

>> isinteger(int8(5))

ans =

  logical

   1

>> foo = [int8(5) int8(3)]

foo =

  1×2 int8 row vector

   5   3

>> class(foo)

ans =

    'int8'

>> bar = [1:10]

bar =

     1     2     3     4     5     6     7     8     9    10

>> bar(foo)

ans =

     5     3

At the least, these do not currently have an MXArrayComponent instance, but there may be other missing instances as well.

The idea is that when writing FFI calls to the Engine, one often ends up calling anyMXArray for most arguments in the argument list to get the type to agree (i.e., everything becomes MAny). Not only is this slightly tedious, but having to maintain these rather-untyped argument lists all over the place seems a bit dangerous. It might be better to have that machinery all in one place: Engine.hsc in this package, rather than user-code.

Of course, as I recall, using HList can also be tedious (at least in Scala - I don't think I've used any of these datatypes in Haskell so far (that I recall), so take this with a grain of salt). And what this suggests is that we'd be leaking HList into the user API.

Why an HMap? It isn't good for ordered arguments, but could replace what is currently being used for VarArgIn (a regular Data.Map).

Maybe use a record to combine these ideas; some pseudo-code:

data EvalArgs = EvalArgs {args:: HList, varargin:: HMap}

MATLAB supports OOP through an internal system as well as interaction with the JVM. I'm not considering the second case (JVM) in this issue. And as far as I can tell, haskell-matlab doesn't currently support this (but see mObjectGetClass, mObjectSetClass). I'm not sure how useful it is either to model certain aspects of OOP, like inheritance, but we could possibly do this with typeclasses.

Some useful reading to start with:

• Passing a user-defined class to MEX
• OOP in Haskell

Hi, could you please update its dependencies to support ghc version 8.4.4, thanks in advance.

Hello,
This seems to be very useful! I understand I can save a 1-dimension vector using createColVector or something like this. How about matrix?
Kazuhiro

Related: #14

Due to my lack of knowing a way to create functions without files (other than anonymous functions - i.e., the severely crippled lambda-like construct available in MATLAB), I'm thinking it may be useful to have some MATLAB functions available to haskell-matlab's Engine API. Perhaps these could be stored in a tmp dir using System.IO.TMP.

These could be put in e.g. something like /tmp/haskell-matlab-<ReleaseID>, where ReleaseID could either be an actual release or the commit; if the directory is detected upon engine initialization, the files won't need to be created.

Especially instance methods, e.g.:

• mxArraySetOffset = error "mxArraySet undefined for MStruct: use mStructSet" The issue here, and why we can't use arrayDataSetDef, is that MStruct has no instance of Storable - I haven't checked to see if this is entirely possible.

From version 1.24 cabal supports specifying explicit dependencies for Custom setup scripts. Consider using cabal-version >= 1.24 and adding a 'custom-setup' section with a 'setup-depends' field that specifies the dependencies of the Setup.hs script itself. The 'setup-depends' field uses the same syntax as 'build-depends', so a simple example would be 'setup-depends: base, Cabal'.