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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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.
Loading...