WinHugs for GHCi, prompt feature
Hi, I'm working on a Windows Haskell GUI, a lot like WinHugs (stealing a lot of the code from WinHugs), which I want to make cross-compiler happy - i.e. Hugs, GHCi and Yhc at least. [See http://www-users.cs.york.ac.uk/~ndm/projects/winhaskell.php for a really old screen shot] The way I am operating with Hugs is by spawning a Hugs process as a separate process, and redirecting the stdin, stdout and stderr to my application. The hardest bit is figuring out when Hugs has run a computation and finished, the way I am doing this currently is by setting the prompt to escape characters, then when my program sees these special escape characters it can determine that the computation has finished and let the user enter the next one. The problem with GHCi is that I haven't been able to set the prompt, and therefore I can't detect when the computation is over, which makes it quite hard to operate with. So what I would really like is any one of: 1) Ability to set the prompt in GHCi 2) Some other mechanism to detect when the computation has finished 3) A way under Windows to detect when a console program is waiting on user input (which I have been entirely unable to find, and may just not exist) WinHaskell is currently perfectly useable with Hugs, and maybe a month or so away from release. I intend to start a darcs repo on tomorrow, if anyone is interested in it. Thanks Neil
Hi,
not a good week for such questions, as the Simons have gone on
holiday, but here are some pointers.
- check out the emacs mode for haskell, which does a similar thing
http://www.iro.umontreal.ca/~monnier/elisp/#haskell-mode
- if you are serious about this (more than just a few buttons for
the ghci/hugs commands;-), you might want to go for a tighter
integration with the interactive Haskell implementations.
of course, that should still be based on some interface, just
something more direct and more flexible than feeding the
command-line. there is no common standard (yet; another
item for haskell'?-), but
Hugs has (or had?) the Hugs Server API
http://cvs.haskell.org/cgi-bin/cvsweb.cgi/hugs98/src/server.c?rev=1.6
http://cvs.haskell.org/cgi-bin/cvsweb.cgi/hugs98/docs/server.tex?rev=1.6
GHC has the GHC API (which is also used for the Visual Studio plugin)
http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/main/GHC.hs
cheers,
claus
----- Original Message -----
From: "Neil Mitchell"
not a good week for such questions, as the Simons have gone on holiday, but here are some pointers. True, I forgot that...
- check out the emacs mode for haskell, which does a similar thing http://www.iro.umontreal.ca/~monnier/elisp/#haskell-mode
Thanks for the hint, from what I can tell (without having an Emacs near by), it just searches for "^\\*?[A-Z][\\._a-zA-Z0-9]*\\( \\*?[A-Z][\\._a-zA-Z0-9]*\\)*> " to be a prompt, which is hardly ideal...
- if you are serious about this (more than just a few buttons for the ghci/hugs commands;-), you might want to go for a tighter integration with the interactive Haskell implementations.
Its amazing what difference a few buttons makes, but yes, I am serious about turning this into something quite powerful. However, in order to make it quite powerful I don't think I really do need that much integration - just ":t" and a few others should be enough.
Hugs has (or had?) the Hugs Server API http://cvs.haskell.org/cgi-bin/cvsweb.cgi/hugs98/src/server.c?rev=1.6
Looks nice, but I know Hugs plays with setjmp longjmp internally, and thats one solid reason for wanting to be in a separate process from Hugs.
GHC has the GHC API (which is also used for the Visual Studio plugin)
As far as I was aware, the GHC API is about looking at the code (i.e. compiling and examining) - while the side I'm interested in is the execution. There are some big advantages to just spawning out to existing processes - the level of difference between Hugs/GHCi becomes much smaller, the program can just grab the users existing installation of the interpretter, and I'm not stuck tracking an unstable API. Of course, for higher levels of integration I need something better, but I hope this will suffice for a long time. Thanks Neil
Hello Neil, Sunday, February 12, 2006, 10:31:40 PM, you wrote: NM> I'm working on a Windows Haskell GUI, a lot like WinHugs (stealing a NM> lot of the code from WinHugs), which I want to make cross-compiler NM> happy - i.e. Hugs, GHCi and Yhc at least. [See NM> http://www-users.cs.york.ac.uk/~ndm/projects/winhaskell.php for a NM> really old screen shot] NM> The way I am operating with Hugs is by spawning a Hugs process as a NM> separate process, and redirecting the stdin, stdout and stderr to my i greatly support this project and method of its implementation. i will be a first user of your program :) i hope that that it will support uniform way to debug programs with all 3 compilers to be exact, i think that it will be even more greater to develop this program using Haskell itself and make it OS-independent. in this way, more haskellers may participate in this project and more haskellers can use the resulting graphical environment -- Best regards, Bulat mailto:bulatz@HotPOP.com
Hi,
i greatly support this project and method of its implementation. i will be a first user of your program :) i hope that that it will support uniform way to debug programs with all 3 compilers
Thanks, thats very encouraging and nice to hear!
to be exact, i think that it will be even more greater to develop this program using Haskell itself and make it OS-independent. in this way, more haskellers may participate in this project and more haskellers can use the resulting graphical environment
Indeed it would, but I fear that in opting for a cross platform toolkit like Gtk2Hs it will be impossible to add the final layer of polish and system integration that will change this from being useful to being a killer application. For example, linking with Gtk2Hs and GHC makes the binary 8Mb for hello world - the entire program so far is under 100Kb so that puts it in a whole different ballpark. Also things like drag and drop of files under Gtk2Hs don't work, and the toolbar would not be native, and therefore less pretty :) Of course, I am attempting to keep the cross platform bits and the user interaction bits separate, so hopefully it will be possible to have native ports of the system, but thats a way off yet. Someone has expressed interest in porting it to Mac. One of my friends, Mike Dodd's, is attempting to do a similar project but using Gtk2Hs - the details of which can be found at http://haskell.org/haskellwiki/Yhc/Yhe . This is already cross platform (Win, Mac, Linux) and written in Haskell. Thanks Neil
On Mon, 2006-02-13 at 18:55 +0000, Neil Mitchell wrote:
Indeed it would, but I fear that in opting for a cross platform toolkit like Gtk2Hs it will be impossible to add the final layer of polish and system integration that will change this from being useful to being a killer application. For example, linking with Gtk2Hs and GHC makes the binary 8Mb for hello world
Not true! At least not true any more. :-) I added support for GHC's "split-objs" feature to the Gtk2Hs build system and the size of a striped hello world GUI shrank from 2.7M to 250k. For reference a trivial program (main = print "hello world") is 190k on my system. This improvement will be included in the next release.
- the entire program so far is under 100Kb so that puts it in a whole different ballpark. Also things like drag and drop of files under Gtk2Hs don't work, and the toolbar would not be native, and therefore less pretty :)
Hmm. Drag 'n drop. Yeah we'll have to look into that. I believe it is supposed to work but we've not made those features available yet. You'll have to prod us or even better - send us a patch! ;-) The toolbar should be indistinguishable from a 'native' one because it uses the native WinXP theme API to do the drawing. Though I notice that when using the 'clasic' windows theme that it does indeed look a little different. Someone should file a bug against Gtk+'s windows theme.
Of course, I am attempting to keep the cross platform bits and the user interaction bits separate, so hopefully it will be possible to have native ports of the system, but thats a way off yet. Someone has expressed interest in porting it to Mac.
Yeah, Gtk+ is still a bit ugly on Mac. There is a company working on that however so I hope it'll be better in future: http://developer.imendio.com/wiki/Gtk_Mac_OS_X They're starting by getting Gtk+ to work without X11 and then getting the native theme right. This will probably take many months however. Duncan
I added support for GHC's "split-objs" feature to the Gtk2Hs build system and the size of a striped hello world GUI shrank from 2.7M to 250k. For reference a trivial program (main = print "hello world") is 190k on my system.
This improvement will be included in the next release.
Hmm. Drag 'n drop. Yeah we'll have to look into that. I believe it is supposed to work but we've not made those features available yet. Mike Dodd's was giving some prodding on my behalf, for Yhe. I think in
The toolbar should be indistinguishable from a 'native' one because it uses the native WinXP theme API Gtk applications stand out a mile from normal ones on Windows - I realise its a lot nicer on Linux. Java applications stand out more, wxWindows ones stand out less. There are many infidelities vs Windows,
Thats good to hear, although just Haskell's runtime system alone would dramatically increase the size the .exe - although now its not such a big concern. Of course, compiling with Yhc to bytecode files and dynamically linking Gtk2Hs would be even better :) the end he just got really confused by a pile of API documentation, all of which was only slightly true (mainly on the GTK side, not Gtk2Hs). In particular drag and drop of files, which is a bit harder than other data (apparently). particularly the menu bars are just all wrong (they have gradient shading of the wrong colour, windows ones are not gradiented). If there was some easy way to report these graphical bugs, I might give it a go. Anyway, developing applications with Gtk2Hs and Haskell is much nicer (and faster) than developing them with C and the Win32 API - so hopefully WinHaskell will be a proof of concept in C and the real AllHaskell can follow on after. Thanks Neil
On Mon, 2006-02-13 at 21:13 +0000, Neil Mitchell wrote:
Hmm. Drag 'n drop. Yeah we'll have to look into that. I believe it is supposed to work but we've not made those features available yet.
Mike Dodd's was giving some prodding on my behalf, for Yhe. I think in the end he just got really confused by a pile of API documentation, all of which was only slightly true (mainly on the GTK side, not Gtk2Hs). In particular drag and drop of files, which is a bit harder than other data (apparently).
Sorry the issue rather dropped off our radar. We've been concentrating on tree view api improvements recently.
There are many infidelities vs Windows, particularly the menu bars are just all wrong (they have gradient shading of the wrong colour, windows ones are not gradiented). If there was some easy way to report these graphical bugs, I might give it a go.
Just report them in the Gtk+ bugzilla: http://bugzilla.gnome.org/ File them against: the "Gtk+" application (which is in the "Platform" section) and select the "Win32" component. It's best if you can attach a screenshot of a Gtk+ and a native app and highlight the area that is different. A zoomed in screenshot would be even better. File one bug per issue, eg a different one for menus vs toolbars. Be sure to mention which Windows version you're using and which theme it's running. Duncan
participants (4)
-
Bulat Ziganshin -
Claus Reinke -
Duncan Coutts -
Neil Mitchell