>>>>
At 21:02 +0200 1999/08/15, S. Doaitse Swierstra wrote:<<<<
When running my program in the heap profiling version of Hugs on my Mac nothing happens.
I think that Pablo is better off than me answering your other questions (but he is on the move right now, and may not be able to read your bug report).
But if the interrupt <command-.> works poorly in the Heap Profiler, that is most likely due to the fact that the MacOS uses cooperative multitasking, and not preemptive multitasking as UNIX and Mach. It means that in order for other processes needs to get time released from the program running in front, so for that reason, the Hugs Mac port code is sprayed by such time releases to other processes. But in the profiler parts of the code of the Hugs Profiler I guess there are no such time releases, and so if a lot of profiling is done, the process recording the keystrokes at your keyboard does not get enough time to record the interrupt you make, and so the interrupt does not work for that reason.
I do not think it is the bad functioning of the <command-.> that bothers me. It is the message about the {_Gc Black Hole}, that is appearing when i run the heap profiling version. Note that this message does not occur if I use the normal Hugs version; in that case the program runs just fine.
>>>>
The fix is to either spray also the profiler parts of the code with such releases, or waiting for a Mac OS with preemptive multitasking (such as MacOS X).<<<<
It is not easy to make a good interrupt with a program using dynamic data structures in a cooperative multitasking environment. For example, if you compute faculty k! with
foldl' (*) 1 [2..k]
for large k (say 10000), then you can watch the clock in the menu bar of your Mac to see that it first switches in seconds, but progressively the clock takes longer leaps. The interrupt also progressively works more poorly. The reason is that these processes get less and less time released from Hugs, as the multiprecision multiplication loop only releases time to other processes once, regardless of the length of the numbers multiplied. So when the numbers multiplied gets larger, other processes gets less time.
In other words, in cooperative multitasking, every process needs to have an estimate on how long time it takes to compute, in order to be able to release an appropriate amount of time to other processes.
I think myself that it is not worth the effort, given the relatively low output, to fix these kind of problems. But if there are any volunteers, the sources are freely available via the <http://haskell.org/hugs> page.
Hans Aberg
* Email: Hans Aberg <mailto:[EMAIL PROTECTED]>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
__________________________________________________________________________
S. Doaitse Swierstra, Department of Computer Science, Utrecht University
(Prof. Dr) P.O.Box 80.089, 3508 TB UTRECHT, the Netherlands
Mail: mailto:[EMAIL PROTECTED]
WWW: http://www.cs.uu.nl/
PGP Public Key: http://www.cs.uu.nl/people/doaitse/
tel: +31 (30) 253 3962, fax: +31 (30) 2513791
__________________________________________________________________________
