Howdy Folks.
I've been looking for a way to have Hugs on a Mac use a GUI toolkit like Tcl/Tk. I prowled through the various GUI libraries listed under the Libraries and Tools For Haskell page under haskell.org and found none that supported Hugs on a Mac. Did I miss something or am I out of luck?
Thanks, ---Frank Seaton Taylor
The version of O'Hugs that was released September last year did actually contain an attempt to make the Tk bindings work on a Mac. The attempt was successful as far as the actual Tk interface was concerned, but unsuccessful in the sense that it wouldn't work side-by-side with the SIOUX text-based interface that O'Hugs (and most Mac versions of Hugs) normally uses. But this was Tk 8.1. Newer versions might very well run on the Mac together with SIOUX. In fact, trying that out is on my todo list for the upcoming new release of O'Hugs. And if anyone is eager to find out even sooner, the neccessary steps for porting any Tk variant of Hugs to the Mac should just be installing Tk and setting up the correct paths for the linker. Providing Tk actually is compatible with SIOUX, that is... -- Johan
At 14.21 -0800 0-11-13, Johan Nordlander wrote:
The version of O'Hugs that was released September last year did actually contain an attempt to make the Tk bindings work on a Mac.
What is this O'Hugs you are speaking about? -- The thing is that Hugs Mac port I and Pablo made consist of two parts, one that I made and another that Pablo maintained which I think derives from work you once made. We then combined that into one version. Would it not be better to combine efforts into one single Mac version? -- I have removed the DropUNIX package, and implemented AppleEvents on our version (not yet released). Hans Aberg
Hans Aberg wrote:
At 14.21 -0800 0-11-13, Johan Nordlander wrote:
The version of O'Hugs that was released September last year did actually contain an attempt to make the Tk bindings work on a Mac.
What is this O'Hugs you are speaking about?
O'Hugs is an implementation of O'Haskell, which is an object-oriented extension to Haskell developed at Chalmers. Have a look at http://www.cs.chalmers.se/~nordland/ohaskell/ O'Hugs itself is a derivative of Hugs 1.3b, consisting of a replacement for the IO monad, some syntactic enhancements, and a heavily modified type-checker.
-- The thing is that Hugs Mac port I and Pablo made consist of two parts, one that I made and another that Pablo maintained which I think derives from work you once made. We then combined that into one version.
Would it not be better to combine efforts into one single Mac version?
Absolutely! In fact this might be a good time to do that, since I'm in the process of taking up the maintenance responsibilities for Classic Hugs.
-- I have removed the DropUNIX package, and implemented AppleEvents on our version (not yet released).
This is good news, since I believe that makes the interpreter responsive to AppleEvents whenever it attempts to read the command line (right?). So let's coordinate our activities. Is there some place where I can get hold of your latest sources? -- Johan
At 09.17 -0800 0-11-14, Johan Nordlander wrote:
O'Hugs is an implementation of O'Haskell, which is an object-oriented extension to Haskell developed at Chalmers. Have a look at
http://www.cs.chalmers.se/~nordland/ohaskell/
O'Hugs itself is a derivative of Hugs 1.3b, consisting of a replacement for the IO monad, some syntactic enhancements, and a heavily modified type-checker.
OK. Thank you for the info.
-- I have removed the DropUNIX package, and implemented AppleEvents on our version (not yet released).
This is good news, since I believe that makes the interpreter responsive to AppleEvents whenever it attempts to read the command line (right?).
I tweaked the Hugs sources so that it is always responsive to AppleEvent's: When an AppleEvent is receive a Hugs primitive is called, and one has primitives to send AppleEvent's. The conversion goes over Hugs strings via the AEGizmo's package, plus some extensions I wrote using Flex/Bison. (Some AppleEvent's are hardwired and not sent to the Haskell interpreter, though.) This is why I want a thread-safe Hugs version, because if Hugs is up and running while receiving an event, it may break. On the other hand, even though experimental, this variation is the interesting one for everyone wanting to explore the limits of functional programming and events. :-)
So let's coordinate our activities. Is there some place where I can get hold of your latest sources?
I will send you the stuff in the mail, if that is OK with you. Hans Aberg
Hans Aberg writes:
I tweaked the Hugs sources so that it is always responsive to AppleEvent's: When an AppleEvent is receive a Hugs primitive is called, and one has primitives to send AppleEvent's. The conversion goes over Hugs strings via the AEGizmo's package, plus some extensions I wrote using Flex/Bison. (Some AppleEvent's are hardwired and not sent to the Haskell interpreter, though.)
This is why I want a thread-safe Hugs version, because if Hugs is up and running while receiving an event, it may break.
On the other hand, even though experimental, this variation is the interesting one for everyone wanting to explore the limits of functional programming and events. :-)
The way we've dealt with Windows and X11 events elsewhere is that events are placed ina queue which Haskell code can read out of. For example, in my graphics library, events like mouse movement and key strokes are put into a channel (a threadsafe queue) for the window that receives the queue. One tends to run one thread per window whose job is to deal with incoming events - possibly by forking off another thread to deal with the problem. Of course, we're limited a bit by the fact that Hugs only has cooperative multitasking but that works pretty well since most GUI's only deal with one event at a time anyway - the multi-threading is just a programming convenience. (Note that I'm not saying "all GUI's" - some would definitely benefit from preemptive multitasking.) -- Alastair Reid
At 14.35 -0700 0-11-14, Alastair Reid wrote:
I tweaked the Hugs sources so that it is always responsive to AppleEvent's: When an AppleEvent is receive a Hugs primitive is called, and one has primitives to send AppleEvent's. The conversion goes over Hugs strings via the AEGizmo's package, plus some extensions I wrote using Flex/Bison. (Some AppleEvent's are hardwired and not sent to the Haskell interpreter, though.)
This is why I want a thread-safe Hugs version, because if Hugs is up and running while receiving an event, it may break.
On the other hand, even though experimental, this variation is the interesting one for everyone wanting to explore the limits of functional programming and events. :-)
The way we've dealt with Windows and X11 events elsewhere is that events are placed ina queue which Haskell code can read out of. For example, in my graphics library, events like mouse movement and key strokes are put into a channel (a threadsafe queue) for the window that receives the queue. One tends to run one thread per window whose job is to deal with incoming events - possibly by forking off another thread to deal with the problem.
The MacOS uses different types of events, low-level events for mouse clicks, GUI etc., and high-level events, called AppleEvent's, for communication between programs. The low-level events are put into a queue by the OS, but I have not made a way for the Haskell code to read them. It might be a good idea though. I figure you build your own queues will allow to store low-level events for a longer period of time (like seconds). Right? For the high-level events, the AppleEvent's, one really want the Haskell code to have a look at them as soon as they arrive. For one thing, they often expire fairly soon, making a later reply impossible.
Of course, we're limited a bit by the fact that Hugs only has cooperative multitasking but that works pretty well since most GUI's only deal with one event at a time anyway - the multi-threading is just a programming convenience. (Note that I'm not saying "all GUI's" - some would definitely benefit from preemptive multitasking.)
If I should do any graphics programming, that should be multi-threaded, under MacOS X, then. I have done some graphics programming under cooperative multitasking, and I think it is too time-consuming, and does not lead to the structures I am interested in. So would still want to see a version of Hugs, or another interpreter which is thread-safe at least in its simplest form, that one can interrupt the current computations, set forth with some other for a while, and then return to the original. Note that this is not even full multi-tasking, because the interrupts are here stacked: One returns to the old computations in the reverse order of the interrupts. -- In true multi-tasking, one should be able to compute and halt the different threads in any order. Hans Aberg * Email: Hans Aberg <mailto:haberg@member.ams.org> * Home Page: <http://www.matematik.su.se/~haberg/> * AMS member listing: <http://www.ams.org/cml/>
At 14.35 -0700 0-11-14, Alastair Reid wrote:
The way we've dealt with Windows and X11 events elsewhere is that events are placed ina queue which Haskell code can read out of. For example, in my graphics library, events like mouse movement and key strokes are put into a channel (a threadsafe queue) for the window that receives the queue. One tends to run one thread per window whose job is to deal with incoming events - possibly by forking off another thread to deal with the problem.
I looked a little bit on MacOS X, and it seems it has a mechanism doing this stuff for you with respect to low-level events (the OS providing queues for each window). In addition unhandled events can migrate up to the object above it belongs to, eventually up to the program itself. There was some changes made to the classical event handling mechanism (I do not recall exactly what), so that windows can fade away instead of disappearing abruptly when closed. I think it had to something do with the ownership of events. A Hugs port then would merely need to have a mechanism reading into those queues. But I think a threaded version of Hugs would be better, so that one could set interrupts for certain types of arriving events, and safely execute some Haskell functions handling it, the way I unsafely made it for high-level events. So, again, it seems that one is better off porting to MacOS X, and not earlier versions of the MacOS. Hans Aberg
participants (3)
-
Alastair Reid -
Hans Aberg -
Johan Nordlander