WinHugs for GHCi, prompt feature

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

WinHugs for GHCi, prompt feature

Neil Mitchell
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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: WinHugs for GHCi, prompt feature

Claus Reinke
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" <[hidden email]>
To: <[hidden email]>
Sent: Sunday, February 12, 2006 7:31 PM
Subject: 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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: WinHugs for GHCi, prompt feature

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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: WinHugs for GHCi, prompt feature

Bulat Ziganshin
In reply to this post by Neil Mitchell
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:[hidden email]



_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: WinHugs for GHCi, prompt feature

Neil Mitchell
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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: WinHugs for GHCi, prompt feature

Duncan Coutts
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

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: WinHugs for GHCi, prompt feature

Neil Mitchell
> 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.

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 :)

> 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).

> 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,
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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: WinHugs for GHCi, prompt feature

Duncan Coutts
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

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users