[Haskell-cafe] C call blocking indefinitely/behaving differently when called from Haskell

[Oliver Charles]

Hi all,

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.

- Ollie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160810/ebc8eca9/attachment.html>