I just spent the evening writing a library that's a thin layer over Gtk2hs. It took an age to get it to compile, but eventually it worked. Yay! When I ran it, I got this: Test2: gtk/Graphics/UI/Gtk/Gdk/PixbufData.hs.pp:58:0: No instance nor default method for class operation Data.Array.Base.getNumElements Er... wow. OK, at this point, I am completely stumped. Any hints? (Also, the documentation for Graphics.UI.Gtk.Misc.DrawingArea suggests that you may want to draw a Pixbuf using the pixbufRenderToDrawable function - but GHC complains that this function doesn't exist. I had to use drawPixbuf instead. Wow that has a lot of parameters... In particular, the final two don't seem to be documented. Interesting. They're both 0 in the "fastdraw" demo.)
On Sat, Dec 08, 2007 at 08:33:36PM +0000, Andrew Coppin wrote:
I just spent the evening writing a library that's a thin layer over Gtk2hs. It took an age to get it to compile, but eventually it worked. Yay!
When I ran it, I got this:
Test2: gtk/Graphics/UI/Gtk/Gdk/PixbufData.hs.pp:58:0: No instance nor default method for class operation Data.Array.Base.getNumElements
Er... wow.
OK, at this point, I am completely stumped. Any hints?
That's pretty obviously a bug - Graphics.UI.Gtk.Gdk.PixbufData doesn't fully implement the (M)Array class.
(Also, the documentation for Graphics.UI.Gtk.Misc.DrawingArea suggests that you may want to draw a Pixbuf using the pixbufRenderToDrawable function - but GHC complains that this function doesn't exist. I had to use drawPixbuf instead. Wow that has a lot of parameters... In particular, the final two don't seem to be documented. Interesting. They're both 0 in the "fastdraw" demo.)
Stefan
Stefan O'Rear wrote:
On Sat, Dec 08, 2007 at 08:33:36PM +0000, Andrew Coppin wrote:
I just spent the evening writing a library that's a thin layer over Gtk2hs. It took an age to get it to compile, but eventually it worked. Yay!
When I ran it, I got this:
Test2: gtk/Graphics/UI/Gtk/Gdk/PixbufData.hs.pp:58:0: No instance nor default method for class operation Data.Array.Base.getNumElements
Er... wow.
OK, at this point, I am completely stumped. Any hints?
That's pretty obviously a bug - Graphics.UI.Gtk.Gdk.PixbufData doesn't fully implement the (M)Array class.
Well OK, but... how come nobody else has tripped over this before?
On Sat, 2007-12-08 at 13:08 -0800, Stefan O'Rear wrote:
On Sat, Dec 08, 2007 at 08:33:36PM +0000, Andrew Coppin wrote:
I just spent the evening writing a library that's a thin layer over Gtk2hs. It took an age to get it to compile, but eventually it worked. Yay!
When I ran it, I got this:
Test2: gtk/Graphics/UI/Gtk/Gdk/PixbufData.hs.pp:58:0: No instance nor default method for class operation Data.Array.Base.getNumElements
Er... wow.
OK, at this point, I am completely stumped. Any hints?
That's pretty obviously a bug - Graphics.UI.Gtk.Gdk.PixbufData doesn't fully implement the (M)Array class.
The MArray class changed in ghc-6.8 and we didn't notice until the gtk2hs release was already out. So there are a couple workarounds, either grab the darcs version of the 0.9.12 branch which contains the fix: http://darcs.haskell.org/gtk2hs-branches/gtk2hs-0.9.12/ Or use the released version with ghc-6.6.x rather than 6.8.x, since 6.6 has the previous different MArray interface. Or use the unsafe indexing operators which bypass the bounds check which calls getNumElements. Duncan
Duncan Coutts wrote:
On Sat, 2007-12-08 at 13:08 -0800, Stefan O'Rear wrote:
That's pretty obviously a bug - Graphics.UI.Gtk.Gdk.PixbufData doesn't fully implement the (M)Array class.
The MArray class changed in ghc-6.8 and we didn't notice until the gtk2hs release was already out.
Ah. I knew there'd be a reason...
So there are a couple workarounds, either grab the darcs version of the 0.9.12 branch which contains the fix: http://darcs.haskell.org/gtk2hs-branches/gtk2hs-0.9.12/
Or use the released version with ghc-6.6.x rather than 6.8.x, since 6.6 has the previous different MArray interface.
Or use the unsafe indexing operators which bypass the bounds check which calls getNumElements.
Eeek! I just recompiled my existing working code with 6.8.1, and sure enough it's broken. I was assuming that the new code I added was the problem, but no, apparently it's the change of compiler [and hence libraries]. Well that changes things... What do I need to compile the darcs version? Just GHC? Or do I need the GTK+ header files? (Remember, I'm on Windows here.)
On Mon, 2007-12-10 at 10:40 +0000, Andrew Coppin wrote:
What do I need to compile the darcs version? Just GHC? Or do I need the GTK+ header files? (Remember, I'm on Windows here.)
Ah, that's a bit harder. It's not for the feint of heart. I've not updated the instructions in a while. The old ones are here: http://haskell.org/gtk2hs/archives/2005/06/24/building-from-source-on-window... but we now use the official Gtk+ windows binaries and headers rather than the ones from http://gladewin32.sourceforge.net/ Our new header bundles are here: http://haskell.org/gtk2hs/win32/ and scripts are here: http://darcs.haskell.org/gtk2hs/tools/win32/ You'd want the win32-build-* ones. You also need mingw of course. I would not recommend starting from darcs but from a tarball and then copying over the two changed files from darcs. The reason for that is that trying to get autoconf and automake working on windows is more trouble than it's worth (I've never done it) where as the tarball contains pre-generated autoconf/automake stuff. Duncan
Duncan Coutts wrote:
On Mon, 2007-12-10 at 10:40 +0000, Andrew Coppin wrote:
What do I need to compile the darcs version? Just GHC? Or do I need the GTK+ header files? (Remember, I'm on Windows here.)
Ah, that's a bit harder. It's not for the feint of heart.
I've not updated the instructions in a while. The old ones are here: http://haskell.org/gtk2hs/archives/2005/06/24/building-from-source-on-window...
but we now use the official Gtk+ windows binaries and headers rather than the ones from http://gladewin32.sourceforge.net/
Our new header bundles are here: http://haskell.org/gtk2hs/win32/ and scripts are here: http://darcs.haskell.org/gtk2hs/tools/win32/ You'd want the win32-build-* ones.
You also need mingw of course. I would not recommend starting from darcs but from a tarball and then copying over the two changed files from darcs. The reason for that is that trying to get autoconf and automake working on windows is more trouble than it's worth (I've never done it) where as the tarball contains pre-generated autoconf/automake stuff.
Duncan
Uh... or maybe I could just wait until the next binary release. :-} *runs away*
Andrew Coppin wrote:
Duncan Coutts wrote:
On Mon, 2007-12-10 at 10:40 +0000, Andrew Coppin wrote:
What do I need to compile the darcs version? Just GHC? Or do I need the GTK+ header files? (Remember, I'm on Windows here.)
Ah, that's a bit harder. It's not for the feint of heart.
I've not updated the instructions in a while. The old ones are here:
http://haskell.org/gtk2hs/archives/2005/06/24/building-from-source-on-window...
but we now use the official Gtk+ windows binaries and headers rather than the ones from http://gladewin32.sourceforge.net/
Our new header bundles are here: http://haskell.org/gtk2hs/win32/ and scripts are here: http://darcs.haskell.org/gtk2hs/tools/win32/ You'd want the win32-build-* ones.
You also need mingw of course. I would not recommend starting from darcs but from a tarball and then copying over the two changed files from darcs. The reason for that is that trying to get autoconf and automake working on windows is more trouble than it's worth (I've never done it) where as the tarball contains pre-generated autoconf/automake stuff.
Duncan
Uh... or maybe I could just wait until the next binary release. :-}
*runs away*
I can understand that. However, the prudent thing to do is not to upgrade to a new ghc release until things have settled a bit; especially not if you want to avoid fixing library bugs (mostly build related) and most especially if you are on Windows. Ghc-6.6.1 is stable and IME most of the hackage stuff works out-of-the-box. (Note that Duncan gave you similar advice, although maybe it got lost beyond all the scary installation tips concerning gtk2hs under ghc-6.8.1;) Or /is/ there a special reason you need to use ghc-6.8.1? Cheers Ben
Ben Franksen wrote:
Andrew Coppin wrote:
Uh... or maybe I could just wait until the next binary release. :-}
*runs away*
I can understand that. However, the prudent thing to do is not to upgrade to a new ghc release until things have settled a bit; especially not if you want to avoid fixing library bugs (mostly build related) and most especially if you are on Windows. Ghc-6.6.1 is stable and IME most of the hackage stuff works out-of-the-box. (Note that Duncan gave you similar advice, although maybe it got lost beyond all the scary installation tips concerning gtk2hs under ghc-6.8.1;) Or /is/ there a special reason you need to use ghc-6.8.1?
Not really I guess. I was rather excited about the new debugger, but other than that I guess I just like to use the newest version of everything. And it would be annoying to have to downgrade now. Still, it looks like there's an easy workaround for this particular issue. (And I'm already explicitly checking array bounds anyway...)
On Dec 8, 2007 6:33 PM, Andrew Coppin
(Also, the documentation for Graphics.UI.Gtk.Misc.DrawingArea suggests that you may want to draw a Pixbuf using the pixbufRenderToDrawable function - but GHC complains that this function doesn't exist. I had to use drawPixbuf instead. Wow that has a lot of parameters... In particular, the final two don't seem to be documented. Interesting. They're both 0 in the "fastdraw" demo.)
Just for the record: http://library.gnome.org/devel/gdk/unstable/gdk-Drawing-Primitives.html#gdk-... I have found that it's eventually useful to try to look at Gtk+ "official C" documentation when coding with a binding (not only with Gtk2Hs, but also Gtk#, PyGtk, etc). (Also, it seem the second argument should be "Maybe GC" as the C documentation says it could be a NULL value.) HTH, -- Felipe.
participants (5)
-
Andrew Coppin -
Ben Franksen -
Duncan Coutts -
Felipe Lessa -
Stefan O'Rear