Hi Hans [and other folks on Hugs Bugs]
I've been busy missing a paper deadline for the last week - hence not many
responses to bug reports, no new releases, etc. Anyway, I see I missed
this message this morning. Hans replied to most of it - here's my comments
based on knowing Hugs but not knowing Macs.
Alastair
> Peter Pudney writes:
> >The :r command doesn't [reload automatically after editing?]. After
> >editing a script, you must reload using the :l
> >command.
Hans Aberg responds:
> This problem is due to the fact that the editor is launched
> asynchronously (as a separate process), and I see no easy way around this:
> On an UNIX machine, Hugs is halted, hanging until the editor has finished.
> On a Mac, one would need to have the editor and Hugs at least sending
> signals to each other. So there is no easy fix, as I see it.
The same problem occurs in Windows - so you should be able to use the
same fix: change machdep::startEdit to return FALSE if the editor
hasn't completed yet.
> >Haskore does not load. I tried changing the path to HaskoreLoader in the
> >Haskore.hs script, but then the System file gave an error.
>
> Haskore experts should answer this; I recall that Haskore did not load
> with the Hugs 1.3 I compiled with the Tenon BSD UNIX. I think Haskore might
> need some MIDI support, or something, in order to work.
You don't need MIDI support to load Haskore - though it might be useful
since Haskore's main output format is MIDI!
I'd guess that the problem is in the file {Hugs}/lib/hugs/Haskore.hs
which reads:
-- This grabs all of Haskore
module Haskore(module HaskoreLoader) where
import "../Haskore/src/HaskoreLoader" as HaskoreLoader
The idea is that we put just one module in your standard path and it
loads in all the rest. We didn't want to put all of Haskore on your
standard path because module names like "Basics", "Chords", "Monads"
and "Fractals" could easily collide with module names in different
applications. (In the Graphics library, I avoided this problem
by attaching the prefix "Graphics" to every single module name - pretty
tedious.)
Anyway, I think the problem is that this filename is fine on Unix and
PCs but won't work for Macs.
> >Environment variables, particularly the search paths, should be read from a
> >preferences file.
>
> This is not difficult to add, if somebody bothers to write the routine.
There's only really one important environment variable for Hugs - HUGSFLAGS.
In it, we put the heap size, the flags, the editor command, the search path,
etc. In fact, everything you can set using the :set command.
On Win32, we don't just read HUGSFLAGS, we also read a registry
value with the name:
"SOFTWARE\Haskell\Hugs\" ++ HUGS_VERSION ++ "\"Options"
which has exactly the same format as HUGSFLAGS - that is, it's a
big soup of option flags. The code that processes flags looks
like this:
readOptions("-p\"%s> \" -r$$"); // default values for prompt and repeat
#if USE_REGISTRY
readOptions(readRegString("Options","")); // overridden by registry
#endif
readOptions(fromEnv("HUGSFLAGS","")); // overridden by env var
for (i=1; i<argc; ++i) // overridden by command line
...
If there's an easy way to read a line of flags from a file, this is the place
to do so.
Incidentally, yes, it is a shame that the options are all stuffed together
into a single blob. We went for this approach because it is easy to
make it work on a wide variety of platforms - even if it's a little
ungainly on Win95 or whatever.
> >I have my own Haskell libraries, and scripts scattered over
> >many different folders. Every time I start Hugs I have to re-enter absolute
> >search paths for the libraries, then :cd to the working directory.
>
> There might be exciting solutions, like tracing aliases when opening
> files. The real problem is that my compiler does not support that in its
> ISO C file reading rountines, so such low level routines would have to be
> rewritten.
You can still use projects if you want. And if portability to non-Macs
isn't important, you could use the "import "Foo:Bar" as Bar" trick.
> >Command-. does not seem to interrupt long IO sequences.
>
> This is a problem with the MacOS, which has poor parallel process
> handling: It simply allows Hugs to get too much time, so that it looses the
> interrupts from the keyboard. The best fix is getting a better OS (such as
> Rhapsody).
But maybe there's a kludge we can use in the meantime.
For example, the evaluation part of Hugs calls the macro allowBreak
on a regular basis to test whether the evaluation has been interrupted.
This is required to get round problems in DOS signal handling but isn't
needed on real operating systems so the macro can be set to nothing.
On HugsForWindows (a GUI version of Hugs that runs on Windows 3.1, WIN95 and
Win-NT), the macro is redefined to test the event queue and dispatch any
pending events.
Are either of these tricks applicable?
> >A simple editor for recalling and editing the previous command or expression
> >would make the system much easier to use.
>
> This was done by Mark Jones in his Gofer; I think nobody has the time
> doing all the work right now (especially in view of the changes that is
> expected to happen with the Mac the next year).
I wonder if readline or editline is available for the Mac. Here's
the relevant comment from options.h
/* Define if a command line editor is available and should be used.
* There are two choices of command line editor that can be used with Hugs:
* GNU readline and editline (from comp.sources.misc, vol 31, issue 71)
*/
#define USE_READLINE 0
