GHC 7.10.2 compilation error in CV.Matrix in the use of ‘fromEnum’

[robstewart57]

There is an ambiguity of deep in CV.Image because Control.Lens exports deep. It can be resolved with:

-    getSize (Mutable i) = evaluate (deep (getSize i))
+    getSize (Mutable i) = evaluate (CV.Image.deep (getSize i))

Once that is resolved, I'm getting two errors in CV.Matrix:

[20 of 62] Compiling CV.Matrix        ( CV/Matrix.hs, dist/build/CV/Matrix.o )

CV/Matrix.hs:145:83:
    Could not deduce (Enum r0) arising from a use of ‘fromEnum’
    from the context (Exists (Matrix a),
                      Args (Matrix a) ~ Size (Matrix a))
      bound by the type signature for
                 invert :: (Exists (Matrix a), Args (Matrix a) ~ Size (Matrix a)) =>
                           Matrix a -> Matrix a
      at CV/Matrix.hs:141:11-88
    The type variable ‘r0’ is ambiguous
    Note: there are several potential instances:
      instance Enum CV.Image.CvtCodes -- Defined at CV/Image.chs:474:10
      instance Enum CV.Image.CvtFlags -- Defined at CV/Image.chs:515:10
      instance Enum ImageDepth -- Defined at CV/Image.chs:963:10
      ...plus 76 others
    In the second argument of ‘(.)’, namely ‘fromEnum’
    In the expression: fromIntegral . fromEnum
    In the third argument of ‘c'cvInvert’, namely
      ‘(fromIntegral . fromEnum $ c'CV_LU)’

CV/Matrix.hs:145:94:
    Could not deduce (Num r0) arising from a use of ‘c'CV_LU’
    from the context (Exists (Matrix a),
                      Args (Matrix a) ~ Size (Matrix a))
      bound by the type signature for
                 invert :: (Exists (Matrix a), Args (Matrix a) ~ Size (Matrix a)) =>
                           Matrix a -> Matrix a
      at CV/Matrix.hs:141:11-88
    The type variable ‘r0’ is ambiguous
    Note: there are several potential instances:
      instance RealFloat a => Num (Data.Complex.Complex a)
        -- Defined in ‘Data.Complex’
      instance Data.Fixed.HasResolution a => Num (Data.Fixed.Fixed a)
        -- Defined in ‘Data.Fixed’
      instance forall (k :: BOX) (f :: k -> *) (a :: k).
               Num (f a) =>
               Num (Data.Monoid.Alt f a)
        -- Defined in ‘Data.Monoid’
      ...plus 67 others
    In the second argument of ‘($)’, namely ‘c'CV_LU’
    In the third argument of ‘c'cvInvert’, namely
      ‘(fromIntegral . fromEnum $ c'CV_LU)’
    In the expression:
      c'cvInvert c_m c_c (fromIntegral . fromEnum $ c'CV_LU)

Have others come across this error? and have others been able to compile this CV library with GHC 7.10?

[TomMD]

@robstewart57 Good to see you're still in Haskell land. I have my own fork at TomMD/CV that I used before switching to the all-Haskell but much less performant and feature-ful friday library (TomMD/friday). Last I checked, my fork was less rotted though the code quality is still lacking (no top-level type signatures, mutability issues, etc). For example, my code currently builds for me (now that I unrotted for 7.10 and manually fixed c2hs).

Beware of haskell/c2hs#151 and in general lack of language pragma, which was hidden by the lack of explicit type signatures.

[robstewart57]

Hi @TomMD https://github.com/TomMD

Good to see you're still in Haskell land.

Absolutely :-)

I have my own fork at TomMD/CV that I used before switching to the all-Haskell but much less performant and feature-ful friday library (TomMD/friday).

Interesting. I've taken a look, the library doesn't depend on repa or accelerate. Were you ever tempted to build friday on top of these array data parallel libraries?

For example, my code currently builds for me (now that I unrotted for 7.10 and manually fixed c2hs).

Excellent thanks, I'll give your fork a try with GHC 7.10. Might you update hackage with your frk on CV? My current use case is to parse firewire camera signals into image frames in Haskell, based on this code: https://github.com/aleator/bindings-dc1394/blob/master/Examples/HelloWorld.hs

Once I can reproduce this, I'd like to map the firewire camera signals into accelerate arrays to allow me to run image processing applications on GPUs, i.e. reading from firewire and accelerating on the GPU, via Haskell on the host.

On 31 October 2015 at 00:36, Thomas M. DuBuisson [email protected] wrote:

@robstewart57 https://github.com/robstewart57 Good to see you're still in Haskell land. I have my own fork at TomMD/CV that I used before switching to the all-Haskell but much less performant and feature-ful friday library (TomMD/friday). Last I checked, my fork was less rotted though the code quality is still lacking (no top-level type signatures, mutability issues, etc). For example, my code currently builds for me (now that I unrotted for 7.10 and manually fixed c2hs).

Beware of haskell/c2hs#151 https://github.com/haskell/c2hs/issues/151 and in general lack of language pragma, which was hidden by the lack of explicit type signatures.

— Reply to this email directly or view it on GitHub https://github.com/aleator/CV/issues/53#issuecomment-152680132.

[TomMD]

Repa's performance is less than impressive - I'm quite happy with Friday on vector. I did try to do my own work (such as an ALPR using SCW) with repa but that never did progress.

Since I'm not the CV maintainer (or the friday maintainer) I am not uploading these to hackage.

WRT getting camera input, I am really confused by you talking about firewire. Most libraries I see talk to an OS specific API to get frames and are agnostic to the way in which the camera is connected. For example, I recently patched ffmpeg-light to work with AVFoundation (and probably video4linux2, see my fork of that).

[robstewart57]

On 31 October 2015 at 02:55, Thomas M. DuBuisson [email protected] wrote:

Repa's performance is less than impressive - I'm quite happy with Friday on vector. I did try to do my own work (such as an ALPR using SCW) with repa but that never did progress.

It's interesting that Friday using highly optimised (sequential) vector code outperforms repa's parallel scheduler with threads in the implementation of repa's `computeP and computerUnboxedP. Are there rewrite rules for fusing vector operations that are being frequently fired in applications using Friday?

Since I'm not the CV maintainer (or the friday maintainer) I am not uploading these to hackage.

OK. Then it's good that stack supports the specification in stack.yaml of github repositories as locations to find libraries, i.e. to point my stack.yaml at your CV fork :-)

WRT getting camera input, I am really confused by you talking about firewire. Most libraries I see talk to an OS specific API to get frames and are agnostic to the way in which the camera is connected. For example, I recently patched ffmpeg-light to work with AVFoundation (and probably video4linux2, see my fork of that).

I'm intending to use the bindings-dc1394 library as the low level binding to libdc1394 for consuming data from firewire cameras http://hackage.haskell.org/package/bindings-dc1394 . See this example https://github.com/aleator/bindings-dc1394/blob/master/Examples/HelloWorld.hs . The function getFrame maps data into an openCV Image structure. What I'd like to do is map the data coming from the bindings-dc1394 c'dc1394video_frame_t'image and map it into a 2D array, probably an accelerate 2D array so as to move it across to a GPU for processing with accelerate-cuda.

—

Reply to this email directly or view it on GitHub https://github.com/aleator/CV/issues/53#issuecomment-152688550.