- Haskell-Cafe - Haskell.org

intToWord32
by John Velman 28 Oct '04

28 Oct '04

I'm trying to test TclHaskell under Hugs98-Nov2003, compiled from source. My current problem with getting it to work seems to be a failure to load the function intToWord32. Well, here is a partial transcript of a session run from within the TclHaskell src directory (after compiling TclPrim.so): ------------- bash-2.05b$ hugs __ __ __ __ ____ ___ _________________________________________ || || || || || || ||__ Hugs 98: Based on the Haskell 98 standard ||___|| ||__|| ||__|| __|| Copyright (c) 1994-2003 ||---|| ___|| World Wide Web: http://haskell.org/hugs || || Report bugs to: hugs-bugs(a)haskell.org || || Version: November 2003 _________________________________________ Haskell 98 mode: Restart with command line option -98 to enable extensions Type :? for help Prelude> :load "../demo/Demo.hs" ERROR "./TclPrim.hs":49 - Undefined variable "intToWord32" Word> :names Hugs.Array.! Hugs.Prelude.!! Hugs.Prelude.$ Hugs.Prelude.$! Hugs.Prelude.% Hugs.Prelude.&& Hugs.Prelude.() Hugs.Prelude.* Hugs.Prelude.** Hugs.Prelude.+ ....[snipped many lines] Hugs.Int.intToInt16 Hugs.Int.intToInt32 Hugs.Int.intToInt8 Hugs.Prelude.intToRatio Hugs.Word.intToWord16 Hugs.Word.intToWord32 ... [snipped the rest] ---------------------- So ':names' thinks there is such a thing, but the loader doesn't? I see that intToWord32 is declared with the keyword "primitive" -- i.e., specifically, from Word.hs in the library: primitive intToWord32 "intToWord32" :: Int -> Word32 I'm having trouble finding this syntax in the documentation, but, as I recall -- perhaps incorrectly -- I ran across some gopher documentation that indicated that the "intToWord32" in quotation marks was supposed to be the file name where the foreign primitive could be found. Using "locate" I can't find any files by the name of "intToWord32" in my system. Perhaps this is the Undefined variable in question. Finally, I'm running on a Linux system, Slackware 9, 400Mhz pentium II, 128 mb memory. Any advice or references to documentation will be appreciated. (By the way -- I decided to try TclHaskell because it seemed to be the simplest way to get a graphical interface to an application going! Any advice here will be appreciated as well.) Thanks, John Velman

2 1

exitFailure under forkProcess
by John Goerzen 28 Oct '04

28 Oct '04

Hello, I'm having a little weird situation here. Whenever I call exitFailure under forkProcess, I get: (progname): forkProcess: uncaught exception Test program: import System.Exit import System.Posix.Process main = forkProcess exitFailure If you remove the forkProcess call, the program properly silently exits with exit code 1. I have no idea why it is displaying this message to stderr when called under forkProcess. I argue that it shouldn't. It is perfectly valid to return with an error code from a child process, and absolutely necessary in some cases when your later waitpid() call needs to know what happened. (Or, in Haskell, getProcessStatus()). Thoughts?

6 13

Text.XML.HaXML.HaskellToXml DRIFT example
by S. Alexander Jacobson 27 Oct '04

27 Oct '04

Does someone have an example of how to use DRIFT to convert a Haskell type into XML? The documentation appears rather sparse... -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

3 3

ArrowLoop examples?
by Einar Karttunen 27 Oct '04

27 Oct '04

Hello Are there any examples of using ArrowLoop outside the signal functions? Instances are declared for ordinary functions and Kleisli arrows, but how should they be actually used? - Einar Karttunen

2 1

RE: [Haskell-cafe] exitFailure under forkProcess
by Simon Marlow 27 Oct '04

27 Oct '04

On 26 October 2004 22:29, John Goerzen wrote: > Hello, > > I'm having a little weird situation here. > > Whenever I call exitFailure under forkProcess, I get: > > (progname): forkProcess: uncaught exception > > Test program: > > import System.Exit > import System.Posix.Process > main = forkProcess exitFailure That's a bug, and I've just fixed it. The problem was that we weren't wrapping the child process in the usual default exception handler which catches ExitException and actually performs the exit. Cheers, Simon

1 0

REMINDER: Contributions to the HC&A Report (November 2004 edition)
by Andres Loeh 27 Oct '04

27 Oct '04

Dear Haskellers, the deadline for the November 2004 edition of the Haskell Communities and Activities is approaching quickly -- but there are still a few days left to make sure that the report contains a section on *your* project, on the interesting stuff that you've been doing, using or affecting Haskell in some way. In particular, any information regarding upcoming, Haskell-related, events is highly appreciated (conferences, workshops, summer schools ...). Many FP research groups have not yet updated their reports. Furthermore, please have a look at http://haskell.org/topics.html * Is your project listed, but not yet updated? Please write a short update! * Is a project listed that you are no longer working on? Write up what you are working on instead, and tell me if someone else has picked up the project. * Is something you have heard about not in the list? Please let me know ... There is still time to write a completely new entry, on a new compiler, tool, library, company, user group, idea, ... -- as long as there is a connection to the Haskell language, there is a place for it in the report! Submissions are due by the end of this week, that is Friday, 29 October 2004. Please mail your entries to hcar at haskell dot org, in plain text or pseudo-(La)TeX format. I look forward to receiving your contributions. Thanks a lot, Andres (current editor) -- Haskell Communities and Activities Report (http://haskell.org/communities) 11/2004 edition submission deadline: 29 October 2004 <hcar(a)haskell.org>

2 2

RE: [Haskell-cafe] Are handles garbage-collected?
by Simon Marlow 26 Oct '04

26 Oct '04

On 24 October 2004 20:51, Sven Panne wrote: > IMHO it would be best to use explicit bracketing where possible, and > hope for the RTS/GC to try its best when one runs out of a given > resource. Admittedly the current Haskell implementations could be > improved a little bit in the last respect. Indeed, GHC could/should try to free up file descriptors when they run out. It's a bit tricky though. At the moment performGC doesn't actually run any finalizers. It schedules a thread to run the finalizers, and you hope the thread runs soon. So if you're running performGC for the purposes of finalization, then almost certainly (performGC >> yield) is better. I've been wondering whether having a more synchronous kind of finalizer would be a good thing. Nevertheless, I agree with the general sentiment on this thread that file descriptors shouldn't be treated as a resource in the same way as memory. Cheers, Simon

15 22

RE: [Haskell-cafe] Re: Are handles garbage-collected?
by Simon Marlow 26 Oct '04

26 Oct '04

On 26 October 2004 10:42, Malcolm Wallace wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> I didn't mean fully synchronous, just "more synchronous". For >> example, the finalization routine could be run directly after >> garbage collection. Hugs & nhc98 already do this, because they don't >> support Haskell finalizers. > > Actually, nhc98 supports both C and Haskell finalisers, with the same > signatures as in ghc: > > newForeignPtr :: FinalizerPtr a -> Ptr a -> IO (ForeignPtr a) > newConcForeignPtr :: IO () -> Ptr a -> IO (ForeignPtr a) > > C finalisers are run during garbage collection, Haskell finalisers > are run immediately afterwards. In fact, you cannot run a Haskell > finaliser during GC, because you don't have a valid heap to run it in. But don't you run into problems in the implementation of newConcForeignPtr, when the Haskell finalizer needs the value of a thunk that was already under evaluation when the GC happened? ie. the need for concurrency that stopped this from becoming part of the official FFI. Cheers, Simon

2 1

Re: Are handles garbage-collected?
by oleg＠pobox.com 26 Oct '04

26 Oct '04

Simon Marlow wrote: > I've been wondering whether having a more synchronous kind of > finalizer would be a good thing. Hans Boehm in his POPL2003 paper "Destructors, Finalizers, and Synchronization" persuasively argued that finalizers _must_ be asynchronous. That assertion is the title of Section 3.5 of the paper. Peter Simons wrote: > input -> iodriver --> connection handler --+ > | /|\ | > output <--+ +-----------------------------+ > (Event, State) > ... > The I/O driver is a StateT monad which calls the (various) > connection handlers every time new input is available from > the network. The handlers are StateT monads, too, and their > respective state is stored in the I/O driver's state when > they return. > ... > The only solution I would know is to put the entire state of > the connection handler into an MVar, so that any changes to > it are immediate for the I/O driver. But that approach feels > like overkill to me. It seems you don't need to store the whole state in MVar: it's enough to store a `clean-up' action. Suppose there exists an MVar known to both a connection handler and the iodriver. The type of MVar's value is Maybe (IO ()). When the connection handler opens a Handle, it places a Just action that will close the handle. If the connection handler makes it to the end without getting an exception, it, right before returning to the iodriver, replaces that cleanup action with Nothing. The iodriver, upon getting control back, checks the MVar and executes whatever action is outstanding. The action can refer to any context it needs for the clean-up. Come to think of it, perhaps MVar is overkill. From your description, it seems that each connection handle has its own private piece of state inside the iodriver state. Perhaps it is not so much to ask to add an IORef (Maybe (IO ())) to that state. The iodriver will check that IORef upon getting control back from the control handler; Or the driver can scan all these IORefs upon receiving an event, an exception, etc. Perhaps a more general approach is a special Handle leasing component. Can we assume that a connection handler has a specific ID? Can we assume that all alive connection handlers can be enumerated (it seems so from the above description: iodriver is aware of all alive connection handlers). If these assumptions hold, we can introduce one level of indirection. Whenever a connection handler needs a Handle, it applies to the Lord of Handles (LoH), passing its own id and the file name. The LoH gives an id of a handle (or the handle itself). The LoH also stores the allocated Handle and the component ID in its tables. From time to time (or on certain events) the LoH checks all the open handles to see if the corresponding connection handlers are still alive.

2 1

RE: [Haskell-cafe] Re: Are handles garbage-collected?
by Simon Marlow 26 Oct '04

26 Oct '04

On 26 October 2004 03:51, oleg(a)pobox.com wrote: > Simon Marlow wrote: >> I've been wondering whether having a more synchronous kind of >> finalizer would be a good thing. > > Hans Boehm in his POPL2003 paper "Destructors, Finalizers, and > Synchronization" persuasively argued that finalizers _must_ be > asynchronous. That assertion is the title of Section 3.5 of the paper. I didn't mean fully synchronous, just "more synchronous". For example, the finalization routine could be run directly after garbage collection. Hugs & nhc98 already do this, because they don't support Haskell finalizers. Just a thought, anyway (and I've read that paper, it's great). Cheers, Simon

2 1