At 10:20 +1100 97/11/17, Peter Pudney wrote:
>Over the weekend I spent some time using Hugs PPC. Here are my comments.
..
>However, Hugs PPC does
>have a few bugs, and is not very friendly.
Since I am responsible for the no-frills Mac PPC port of Hugs, perhaps I
should give an answer:
To begin with, a lot exciting Mac GUI features could be added, but only
by a dedicated Mac programmer with lots of time. Programming a Mac is
sufficiently tricky and time consuming to give the pro's a hard time. In
addition, Mac's are now switching to a new OS, called Rhapsody
<http://www.macos.apple.com/macos/releases/rhapsody/>
which is Mach kernel based (a kernel devoped at Carnegie-Mellon, more
general than the UNIX kernel), with a completely new set of GUI headers
(called the "Yellow Box"); the yellow box also runs on MSOS PC compatibles.
Developers who have tried it, says that they can relatively easy develop
GUI's.
As Rhapsody is planned to come along the next year, I do not see much of
a point developing a GUI for Hugs PPC, except for a dedicated enthusiast.
If you really need Hugs UNIX/Xwindows features on a Mac, you could buy
the Tenon <http://wwww.tenon.com/> BSD UNIX/Mach (plus their ported apps
CD), which should compile the UNIX version of Hugs; I have not tried
compiling Hugs 1.4 yet, but Hugs 1.3 compiled (pretty much) without a
change.
So the no-frills Hugs PPC can only be expected to have features
compilable with ISO-C.
>A couple of times I got the dreaded internal graph error thingy. I believe
>the
>problem has been identified, so I guess this will be fixed in the next
>release.
So, Hugs has support for MS Windows graphics and Xwindows, but not for
MacOS windows graphics; this one would have to write all new.
>Be warned,
>though, that the only programming I have done on a Mac are with HyperCard and
>MacGofer, so I really don't have a clue about the feasibility of these
>changes.
If you want to have a look at what you might expect to do, take a look at
the file "launch.c" in the hugs/src/mac directory that I wrote. Simple
things are incredibly complicated on a Mac right now.
>The :r command doesn't [reload automatically after editing?]. After
>editing a script, you must reload using the :l
>command.
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.
>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.
>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.
>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.
>Using :cd to change the working directory is tedious. Could we have
>command in
>the File menu, with a standard open dialogue, to do this?
The problem with adding _any_ type of GUI feature to the Mac is that the
Mac uses a global event queue, which has to be maintained by the program.
Therefore, you would expect having to write the program in a completely new
style, not just the source code with modifications.
>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).
>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).
>The :f and :e commands do not find the correct line. Is there a way to get
>BBEdit Lite to jump to a line?
I wrote a Mac version of the UNIX system() function call, which calls the
program the file was created with. In order to get the right line number
too, one would have to pass that to the editors through special MacOS
commands.
>Line numbers reported by Hugs PPC don't match BBEdit Lite line numbers if the
>script contains long paragraphs with soft wrapping. I have no idea what
>you can
>do about this. Soft wrapping is a useful feature for literate scripts.
Well, soft wrapping is just something that is displayed on the screen,
and as Hugs reads the contents of the file, there is nothing to do about
it. Just turn off the softwrapping feature for the files with source code.
This is a problem you will experience with any compiler, not just Hugs, I
think.
>I think I may have had trouble trying the change the path using the :s
>command,
>because the path I wanted would not fit on one line. Is is possible to enter
>commands and expressions longer than a line? If not, this is a problem.
It would be great if Hugs had a feature enabling one to split a line onto
several input lines (say by ending it with a back-slash, or something). One
could compile with a wider window (right now it is 80), but it is easy to
break that to.
>It would be useful if the Hugs PPC window was resizable.
The reason it is not resizeable is that just uses the standard console
window supplied by the compiler, and Symantec has so far not bothered
supplying a better window. Once, there was a fellow who made a better
console window, but Apple has since changed its GUI headers, so it does not
compile anymore. So, all that is needed, is somebody with the time writing
a new console window; such programming is rather time consuming. (From time
to time one hear people claiming to have a version within fourteen days, or
so, but I have never seen such a version actually happen.)
So summing up, sorry for all the features missing. Letting the
environment variables be read from a file could probably be added
relatively easy, but the other stuff requires a lot of time and effort.
With the new Rhapsody OS, if now Apple can get a CEO to run the company, it
might be worthwhile, but not with Mac OS.
Hans Aberg
* Email: Hans Aberg <mailto:[EMAIL PROTECTED]>
* AMS member listing: <http://www.ams.org/cml/>
