Il giorno 10 ago 2016, alle ore 19:18, Oliver Charles ha scritto:

Hi all,

Hi,

I'm trying to interface with a Basler USB3 camera http://www.baslerweb.com/en/products/ from a Haskell application, but I'm experiencing some difficulty. The camera comes with a C++ library that makes it fairly straight forward. The following code can be used to acquire a camera source:

PylonAutoInitTerm pylon; CInstantCamera camera( CTlFactory::GetInstance().CreateFirstDevice()); camera.RegisterConfiguration( (CConfigurationEventHandler*) NULL, RegistrationMode_ReplaceAll, Cleanup_None); cout << "Using device " << camera.GetDeviceInfo().GetModelName() << endl;

Using the inline-c and inline-c-cpp libraries, I am trying to perform this same call from a Haskell executable. I have the following:

{-# LANGUAGE QuasiQuotes, TemplateHaskell #-}

import qualified Language.C.Inline as C import qualified Language.C.Inline.Cpp as C

C.context C.cppCtx

C.include "pylon/PylonIncludes.h" C.include "iostream"

C.using "namespace Pylon"; C.using "namespace std";

main :: IO () main = [C.block| void { PylonAutoInitTerm pylon;

CInstantCamera camera( CTlFactory::GetInstance().CreateFirstDevice()); camera.RegisterConfiguration( (CConfigurationEventHandler*) NULL, RegistrationMode_ReplaceAll, Cleanup_None); cout << "Using device " << camera.GetDeviceInfo().GetModelName() << endl; }|]

However, when the resulting executable is ran, it hangs - failing to print "Using device".

inline-c generates a Test.cpp file, which contains

#include "pylon/PylonIncludes.h"

#include "iostream"

using namespace Pylon;

using namespace std;

extern "C" { void inline_c_Main_0_e23f0c6a0bc10367be76252744bf4e6c74493314() {

PylonAutoInitTerm pylon;

CInstantCamera camera( CTlFactory::GetInstance().CreateFirstDevice()); camera.RegisterConfiguration( (CConfigurationEventHandler*) NULL, RegistrationMode_ReplaceAll, Cleanup_None); cout << "Using device " << camera.GetDeviceInfo().GetModelName() << endl;

}

}

If I modify this exact file, I can turn it into something that can be run, by simply adding:

int main() { inline_c_Main_0_e23f0c6a0bc10367be76252744bf4e6c74493314(); }

At this point, I can now compile that very C++ code with G++ and run it:

[nix-shell:~/work/circuithub/receiving-station]$ g++ Test.cpp -I/home/ollie/work/circuithub/receiving-station/pylon5/include -L/home/ollie/work/circuithub/receiving-station/pylon5/lib64 -Wl,-E -lpylonbase -lpylonu tility -lGenApi_gcc_v3_0_Basler_pylon_v5_0 -lGCBase_gcc_v3_0_Basler_pylon_v5_0 -Wl,--enable-new-dtags -Wl,-rpath,/home/ollie/work/circuithub/receiving-station/pylon5/lib64

[nix-shell:~/work/circuithub/receiving-station]$ ./a.out GetDeviceDiscoveryInfo: bFunctionClass = 14, bFunctionSubClass = 3, bFunctionProtocol = 0. Device is not an U3V device. GetDeviceDiscoveryInfo: bFunctionClass = 14, bFunctionSubClass = 3, bFunctionProtocol = 0. Device is not an U3V device. Using device acA3800-14um

So as we can see, the C++ code is not the problem.

Does anyone know why I don't see the same behaviour from my Haskell application? I imagine there might be some thread trickery happening behind the scenes, but I don't know what to even begin looking for.

Thanks, let me know if you need any more information.

the first step I would suggest you is to separate each single function call to the library interlacing them with print statements to see where exactly the hang happens. Then, I’ve never used inline-c-cpp before: which kind of FFI call is C.block supposed to generate? I mean a ‘safe’ call or an ‘unsafe’ call?

- Ollie

Regards, Nicola