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

Nicola Gigante nicola.gigante at gmail.com
Mon Aug 15 10:35:17 UTC 2016


> Il giorno 10 ago 2016, alle ore 19:18, Oliver Charles <ollie at ocharles.org.uk> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160815/d11a47c6/attachment-0001.html>


More information about the Haskell-Cafe mailing list