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 notifications@github.com
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 haskell/c2hs#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
#53 (comment).

[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 notifications@github.com
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
#53 (comment).