Segmentation fault about accelerate HOT 6 CLOSED

I forgot the other module:

module PortablePixmap where

data PixMap = Pixmap Integer Integer Int [(Int,Int,Int)]

createPixmap::Integer -> Integer -> Int -> [(Int,Int,Int)] -> PixMap
createPixmap width height max colours = Pixmap width height max colours

instance Show PixMap where
    showsPrec prec (Pixmap x y z rgbs) = showHeader x y z . showRGB rgbs


showHeader::Integer -> Integer -> Int -> ShowS
showHeader x y z    = showString "P6\n" . showBanner .
              shows x . showReturn .
              shows y . showReturn .
              shows z . showReturn

showRGB::[(Int,Int,Int)] ->  ShowS
showRGB []      = id
showRGB ((r,g,b):rest)  = showChar (toEnum r) .
              showChar (toEnum g) .
              showChar (toEnum b) .
              showRGB rest

showSpace  = showChar ' '
showReturn = showChar '\n'

showBanner = showString "# Portable pixmap created by Haskell Program :\n" .
         showString "#\tPortablePixmap.lhs (Jon.Hill 28/5/92)\n"

(this I took from the mandelbrot set generator in nofib, I should probably use Gloss for displaying the image instead)

from accelerate.

Strange that I had never run into this before. This should be fixed now, and I added the test to the examples package.
Thanks!

from accelerate.

For reference, here's a link to the new bit of doc:

https://github.com/AccelerateHS/accelerate-cuda/blob/4575f474fa85d15bf48a88a4abb59ec62992d1cf/Data/Array/Accelerate/CUDA.hs#L85

from accelerate.

Would it be a solution to walk the AST (during or before convertAcc) and force all the input arrays, before doing anything with the context?

Wouldn't that be a built-in equivalent of the seq Simon uses above? The Accelerate computation is strict in all the arrays that gets used, so I don't think this approach would force anything that isn't due to be forced anyway.

Shall we keep this issue open until a fix for the underlying issue is found? As Simon pointed out, behavior should not differ from the interpreter.

from accelerate.

I think this is actually in relation to #48, but yes, I see your point. If we make the right things strict in the library, the user shouldn't have to deal with adding seq themselves.

from accelerate.

this issue was related to finalisers, migrate these comments to #48 which is about seq and dependent computations.

from accelerate.