So I decided to try out the Haskell Platform instead of just installing GHC directly. To be honest, I didn't really notice much difference, except for the files being installed in a different place. But then, initially HP ~= GHC; presumably the plan is for it to grow as time goes on. Anyway, I'm sure you can all see where I'm going with this: Latest Gtk2hs binary for Windows doesn't seem to like the latest HP installation. A few things: - It is unclear to be which Gtk2hs binaries require which GHC version. Can we tabulate this information somewhere? - It is also unclear to me which HP versions contain what stuff. The HP page tells you all about the *current* HP version, and contains a link to a raw directory listing for the older versions. (I especially love the way the server truncates the filenames to just before where the version number starts. Very helpful. :-D ) Can we get propper descriptions for _all_ releases of HP? A table summarising the GHC version and major packages/versions in each release would be nice. - Any idea why the HP says "beta" on it? - Apart from HP providing GHC 6.10.4 while Gtk2hs currently requires 6.10.3, it appears that the Gtk2hs installer package doesn't like GHC being installed in a path with spaces. Apparently Gtk2hs has a bug tracker. (I only just discovered this, so perhaps it needs to be more prominent?) Somebody pointed out this bug 6 months ago. Somebody else posted a potential fix a month ago. There is no visible activity from the developers. (I emphasize "visible". Maybe they've seen this and they're working on it, but there's no visible indication of activity.) Gtk2hs is currently the *only* GUI binding that actually works on Windows. It's always been slightly frustrating that every time a new version of GHC comes out, us Windows users have to beg for somebody to build a new binary. (Linux users, on the other hand, can just download the sources and compile them with any compiler they like.) Presumably going forward Gtk2hs will synchronise to the (less frequent) HP releases rather than the individual GHC releases, so many this particular frustration will be reduced. (It would be even less frustrating if Gtk2hs was *in* HP, but I gather this won't ever happen.) Of course, being able to actually build C bindings on Windows would be even better, but this is apparently infeasible... :-( That being the case, I'll settle for just a little bit more documentation.
Hello Andrew, Saturday, December 5, 2009, 6:40:23 PM, you wrote:
prominent?) Somebody pointed out this bug 6 months ago. Somebody else posted a potential fix a month ago. There is no visible activity from the developers.
Developer. many Haskell problems is due to the fact that we have a few volunteers doing things and lot of consumers begging for features :)
Gtk2hs is currently the *only* GUI binding that actually works on Windows.
i thought that wx and even qt are in rather good shape now -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Bulat Ziganshin wrote:
Hello Andrew,
Saturday, December 5, 2009, 6:40:23 PM, you wrote:
prominent?) Somebody pointed out this bug 6 months ago. Somebody else posted a potential fix a month ago. There is no visible activity from the developers.
Developer. many Haskell problems is due to the fact that we have a few volunteers doing things and lot of consumers begging for features :)
That *does* in fact seem to be a recurring problem, yes. Now, how to fix this...?
Gtk2hs is currently the *only* GUI binding that actually works on Windows.
i thought that wx and even qt are in rather good shape now
I did try to get wxHaskell going once or twice. And the SDL binding. (I wasn't aware we have Qt now...) I've never got any of them to work yet. :-( Interestingly, while you can't compile bindings to external C libraries, GHC does appear to ship with all the header files for Windows, which is odd. It seems if you try to FFI to a standard Win32 function, it magically knows where the hell the header files are, and it Just Works(tm). Hell, I even followed a C++ guide to Win32 programming and managed to translate an "open a blank window" program to Haskell, and it worked. Maybe somebody just needs to sit down and write a nice binding for doing native GUI stuff under Win32?
Hello Andrew, Saturday, December 5, 2009, 10:14:17 PM, you wrote:
I did try to get wxHaskell going once or twice. And the SDL binding. (I wasn't aware we have Qt now...) I've never got any of them to work yet.
it depends on when you have tried. wx made significant progress in last year or two -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Hi Andrew, On 5 Dec 2009, at 16:15, Bulat Ziganshin wrote:
Saturday, December 5, 2009, 6:40:23 PM, you wrote:
Gtk2hs is currently the *only* GUI binding that actually works on Windows.
i thought that wx and even qt are in rather good shape now
Thanks for the vote, Bulat. wxHaskell installs out of the box easily on Windows now. See http:// haskell.org/haskellwiki/WxHaskell/Building. The hardest part is building wxWidgets itself. Prerequisites are: - MinGW C++ compiler Make, with MSys shell (to build wxWidgets) - wx-config binary for Windows To build wxWidgets, download the Windows source package from wxWidgets. 1) You will need the Windows port of wx-config in your path. This can be downloaded from http://wxconfig.googlepages.com/ 2) You will need to compile wxWidgets using MSys. We have tested against MinGW 5.1.6 with g++ compiler, MinGW Make, MSYS-1.0.11, wxMSW-2.8.10, which are the latest versions, and can be downloaded from their respective websites. I used a completely clean install of the latest Haskell Platform to validate the procedure. Please note: all commands to be entered in an MSys shell. cd /c/path/to/wxWidgets-2.8.10/build/msw mingw32-make -f makefile.gcc BUILD=release MONOLITHIC=1 SHARED=1 UNICODE=1 set PATH=$PATH:/c/path/to/wx-config set WXWIN=/c/path/to/wxWidgets-2.8.10 set WXCFG=gcc_dll/mswu At this point you have installed and configured wxWidgets on Windows. The Haskell part is more or less trivial: cabal install wx I'd encourage you to try wxHaskell again, and let us know how you get on. Regards Jeremy -- Jeremy O'Donoghue jeremy.odonoghue@gmail.com
Am Samstag 05 Dezember 2009 20:14:17 schrieb Andrew Coppin:
Bulat Ziganshin wrote:
Hello Andrew,
Saturday, December 5, 2009, 6:40:23 PM, you wrote:
prominent?) Somebody pointed out this bug 6 months ago. Somebody else posted a potential fix a month ago. There is no visible activity from the developers.
Developer. many Haskell problems is due to the fact that we have a few volunteers doing things and lot of consumers begging for features :)
That *does* in fact seem to be a recurring problem, yes.
Now, how to fix this...?
How about: get the sources, try proposed fix, if it works, send Duncan(*) the patch? Even better, become a gtk2hs developer yourself (though that's more work and probably requires some serious knowledge of gtk). (*) for gtk2hs, would be somebody else for other packages of course.
Gtk2hs is currently the *only* GUI binding that actually works on Windows.
i thought that wx and even qt are in rather good shape now
I did try to get wxHaskell going once or twice. And the SDL binding. (I wasn't aware we have Qt now...) I've never got any of them to work yet. :-(
Interestingly, while you can't compile bindings to external C libraries, GHC does appear to ship with all the header files for Windows, which is odd. It seems if you try to FFI to a standard Win32 function, it magically knows where the hell the header files are, and it Just Works(tm). Hell, I even followed a C++ guide to Win32 programming and managed to translate an "open a blank window" program to Haskell, and it worked. Maybe somebody just needs to sit down and write a nice binding for doing native GUI stuff under Win32?
Maybe you could try to be that somebody? I'm sure the Windows folks would appreciate it very much. Or, if you think that's beyond your ken, try organising the writing. Perhaps create a windows-haskell mailing list where Windows users can help each other making things work on Windows.
Daniel Fischer wrote:
Am Samstag 05 Dezember 2009 20:14:17 schrieb Andrew Coppin:
Bulat Ziganshin wrote:
Developer. many Haskell problems is due to the fact that we have a few volunteers doing things and lot of consumers begging for features :)
That *does* in fact seem to be a recurring problem, yes.
Now, how to fix this...?
How about:
get the sources, try proposed fix, if it works, send Duncan(*) the patch? Even better, become a gtk2hs developer yourself (though that's more work and probably requires some serious knowledge of gtk).
In order to do this, I'd have to know how to build Gtk2hs from source on Windows. I imagine this is quite nontrivial.
Interestingly, while you can't compile bindings to external C libraries, GHC does appear to ship with all the header files for Windows, which is odd. It seems if you try to FFI to a standard Win32 function, it magically knows where the hell the header files are, and it Just Works(tm). Hell, I even followed a C++ guide to Win32 programming and managed to translate an "open a blank window" program to Haskell, and it worked. Maybe somebody just needs to sit down and write a nice binding for doing native GUI stuff under Win32?
Maybe you could try to be that somebody? I'm sure the Windows folks would appreciate it very much
The thought has certainly crossed my mind. If I could write such a package, I imagine a lot of people would find it seriously useful. Native Windows GUI programs, without any 3rd party DLLs to distribute with your compiled binary... It'd be great, wouldn't it? Of course, thinking about how great it would be doesn't get the code written. ;-) I'd have to learn how to call Win32 from C first, for a start... o_O The various I/O libraries sometimes return weird results, and I'm told this is because GHC is using the emulated POSIX interfaces rather than native Win32 calls. I did think about turning my attention to fixing that. However, I notice the next version of GHC seems to have a radically reworked set of I/O libraries, so maybe it's already fixed?
Am Samstag 05 Dezember 2009 21:31:39 schrieb Andrew Coppin:
Daniel Fischer wrote:
Am Samstag 05 Dezember 2009 20:14:17 schrieb Andrew Coppin:
Bulat Ziganshin wrote:
Developer. many Haskell problems is due to the fact that we have a few volunteers doing things and lot of consumers begging for features :)
That *does* in fact seem to be a recurring problem, yes.
Now, how to fix this...?
How about:
get the sources, try proposed fix, if it works, send Duncan(*) the patch? Even better, become a gtk2hs developer yourself (though that's more work and probably requires some serious knowledge of gtk).
In order to do this, I'd have to know how to build Gtk2hs from source on Windows. I imagine this is quite nontrivial.
I thought in this case, it was a proposed change in the installer, so you'd only have to change that and could leave the gtk2hs binary untouched. Of course that can only work if Windows installers are some sort of script or otherwise customisable. Are they?
Interestingly, while you can't compile bindings to external C libraries, GHC does appear to ship with all the header files for Windows, which is odd. It seems if you try to FFI to a standard Win32 function, it magically knows where the hell the header files are, and it Just Works(tm). Hell, I even followed a C++ guide to Win32 programming and managed to translate an "open a blank window" program to Haskell, and it worked. Maybe somebody just needs to sit down and write a nice binding for doing native GUI stuff under Win32?
Maybe you could try to be that somebody? I'm sure the Windows folks would appreciate it very much
The thought has certainly crossed my mind. If I could write such a package, I imagine a lot of people would find it seriously useful. Native Windows GUI programs, without any 3rd party DLLs to distribute with your compiled binary... It'd be great, wouldn't it?
Of course, thinking about how great it would be doesn't get the code written. ;-) I'd have to learn how to call Win32 from C first, for a start... o_O
Yes, of course, ultra posse nemo obligatur. As long as you can't do something, you can only hope somebody else can and does.
--- On Sat, 12/5/09, Daniel Fischer
--- On Sat, 12/5/09, Andrew Coppin
Hell, I even followed a C++ guide to Win32 programming and managed to translate an "open a blank window" program to Haskell, and it worked. Maybe somebody just needs to sit down and write a nice binding for doing native GUI stuff under Win32?
Well there's http://haskell.org/ghc/docs/latest/html/libraries/Win32/Graphics-Win32.html for opening blank windows. ;) This relates to my question a couple days ago about a good cross platform 2d library. I wonder why there isnt a Haskell library that follows in the footsteps of Java's Swing - by that I mean, just have a very simple low level way of opening a window, getting mouse clicks, and an abstracted drawing layer... and make the GUIs with that. The GUIs are drawn and not OS widgets. That's exactly why I was looking for something like Cairo. My interest is in composable fudgets (stealing the word from fudgets). This way every platform can share the same GUI library and HP can ship with the minimal tools to open a window and draw on every system. Plus OS guis are the wrong thing for Haskell. You need to retain the power to make better abstractions.
2009/12/5 Andrew Coppin
Interestingly, while you can't compile bindings to external C libraries,
Ah Mr Coppin, maybe you should change "you" to "I". I had (Haskell bindings) SDL-0.5.3 working August last year - so I think I would be using GHC 6.8.3 at that time, the version of the SDL C library was 1.2.13. SDL has no prepared package in the Cygwin package manager, so you have to download it yourself. I seem to remember it being more tricky to get SDL working under Cygwin as a C library (you need extra DirectX header files at least), than it was to compile the Haskell binding once the C library was working. Instructions for compiling the C library for Cygwin are on the SDL website. I haven't tried it since as I don't need SDL for anything I do, but don't I think it would be any harder (lemmih's binding seems to be pretty stable and at the time I used it, it was impressively tidy). Best wishes again Stephen
participants (6)
-
Andrew Coppin -
Bulat Ziganshin -
Daniel Fischer -
Jeremy O'Donoghue -
M Xyz -
Stephen Tetley