loadlibrary and calllib again?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

loadlibrary and calllib again?

NJank
Recently tried porting some Matlab code calling an external dll (for REFPROP, if anyone's curious), and discovered library load support isn't implemented. Found a few discussions about it from 2010-2014 [1,2], and one of the issues was that MATLAB compatibly library calls would require a classdef implementation that didn't exist yet, making it a formidable project, too much for GSOC, etc. There was an attempted implementation that hasn't been touched since 2013. [3]

Since classdef has been (at least somewhat [4]) implemented since 4.0, I'm just wondering if the argument has changed at all. Not at all familiar with the details, are any of the current classdef limits still roadblocks to a loadlibrary function? 

Would that bitbucket code still be a viable starting point or is it not a compatible approach with octave's current state? Is it at the point where it would make sense to put together a description in the projects page or even on the GSOC suggested projects list?



Reply | Threaded
Open this post in threaded view
|

Re: loadlibrary and calllib again?

K_G_
I recently spent a while looking for a solution for this exact problem as well (running the REFPROP Matlab code through Octave) and hit the same wall. I hadn't seen that some of the issues with the classdef implementation may have been overcome, and I would definitely be interested to hear what others may have to say regarding the possibility of the loadlibrary function being supported in the future.

As it stands, there may be a potential workaround for you (depending on the operating system you're using): In my searches I came across "CoolProp" which seems to be an alternative to REFPROP that also gives the ability to utilize the REFPROP routines directly instead of the CoolProp ones. They have a variety of wrappers made for it, including information for generating an Octave wrapper by use of a .oct file. I ran into a couple of snags on Windows, but it looks like it should be quite a bit easier if you happen to be running Linux.

The above might be a good workaround for you, but I'd definitely be interested to hear if anyone has any comments on whether a loadlibrary function is still prohibitively difficult to make.
Reply | Threaded
Open this post in threaded view
|

Re: loadlibrary and calllib again?

NJank


On May 9, 2017 1:15 PM, "K_G_" <[hidden email]> wrote:
I recently spent a while looking for a solution for this exact problem as
well (running the REFPROP Matlab code through Octave) and hit the same wall.
I hadn't seen that some of the issues with the classdef implementation may
have been overcome, and I would definitely be interested to hear what others
may have to say regarding the possibility of the loadlibrary function being
supported in the future.

As it stands, there may be a potential workaround for you (depending on the
operating system you're using): In my searches I came across " CoolProp
<http://www.coolprop.org/>  " which seems to be an alternative to REFPROP
that also gives the ability to  utilize the REFPROP routines directly
<http://www.coolprop.org/coolprop/REFPROP.html#refprop>   instead of the
CoolProp ones. They have a variety of wrappers made for it, including
information for generating an  Octave wrapper
<http://www.coolprop.org/dev/coolprop/wrappers/index.html>   by use of a
.oct file. I ran into a couple of snags on Windows, but it looks like it
should be quite a bit easier if you happen to be running Linux.

The above might be a good workaround for you, but I'd definitely be
interested to hear if anyone has any comments on whether a loadlibrary
function is still prohibitively difficult to make.

I did look at coolprop, unfortunately running windows. I did play with the wrapper, but even their demo didn't run error free on 4.2.1. I noticed it was last tested on 3.x, not sure if things changed enough since then to explain the incompatibility. Haven't had time to debug.