- Glasgow-haskell-users

RE: GHC and UNICODE...
by Simon Marlow 22 Dec '03

22 Dec '03

> something I have wanted to do is modify Alex so that ∀ turns into the > regular expression 0xe2 0x88 0x80 (and so forth) so that ghc (whose > lexer is generated from alex) can simply accept utf8 input. I also really want to get GHC accepting UTF-8 source files, but I don't think this is the best way to go about it. Sure, you can run Alex over the UTF-8 source, but the grammar will be huge. A simpler way is to take advantage of the fact that Haskell only uses 5 classes of Unicode characters: uniSmall, uniLarge, uniWhite, uniSymbol, and uniDigit. Alex has a good input abstraction behind which you can hide the translation from UTF-8 to Char, so you can map these 5 classes of unicode characters onto 5 special Char values, and use Alex unmodified. Well, perhaps Alex will need a small modification so that its upper bound on Char values is variable (currently it is fixed at 255). Then you have to think about whether GHC keeps strings internally in UTF-8 or expanded unicode. Perhaps UTF-8 is initially easier (not much change to the FastString type), but this might have further ramifications. Hmmm... looks like a good project to put on the GHC Task List! Cheers, Simon

1 0

RE: How to force finalization of ForeignPtr
by Simon Marlow 22 Dec '03

22 Dec '03

[ forwarded to ffi(a)haskell.org ] > In the current implementation there is no way to > force finalization of the foreign ptr if there are > still references to it. In this scenario > the finalization will be executed during the next > garbage collection. In some cases it is known that the > foreign pointer value is not used anymore but the > references still exist in the stack and they cannot be > freed from the collector. In such cases I want to be > able to explicitly finalize the foreign pointers. For > that reason I wrote the following simple function: > > module FinalizeForeignPtr(finalizeForeignPtr) where > > import GHC.ForeignPtr > import Data.IORef > > finalizeForeignPtr :: ForeignPtr a -> IO () > finalizeForeignPtr foreignPtr = do > finalizers <- readIORef refFinalizers > sequence_ finalizers > writeIORef refFinalizers [] > where > refFinalizers = case foreignPtr of > (ForeignPtr _ ref) -> ref > (MallocPtr _ ref) -> ref There's a race condition between multiple finalizeForeignPtrs, but apart from that it looks fine. I don't see any reason why we shouldn't have this. GHC's weak pointer interface has a similar function for running the finalizer early. Cheers, Simon

1 0

RE: ghc-6.2 compilation problems
by Simon Marlow 22 Dec '03

22 Dec '03

> This is ghc-6.2, trying to built it with ghc-6.2: > > > $ ./configure --with-x --enable-threaded-rts --enable-objectio > --enable-hopengl This looks like a problem with ObjectIO - Krasimir? Cheers, Simon

1 0

How to force finalization of ForeignPtr
by Krasimir Angelov 22 Dec '03

22 Dec '03

Dear GHC team, In the current implementation there is no way to force finalization of the foreign ptr if there are still references to it. In this scenario the finalization will be executed during the next garbage collection. In some cases it is known that the foreign pointer value is not used anymore but the references still exist in the stack and they cannot be freed from the collector. In such cases I want to be able to explicitly finalize the foreign pointers. For that reason I wrote the following simple function: module FinalizeForeignPtr(finalizeForeignPtr) where import GHC.ForeignPtr import Data.IORef finalizeForeignPtr :: ForeignPtr a -> IO () finalizeForeignPtr foreignPtr = do finalizers <- readIORef refFinalizers sequence_ finalizers writeIORef refFinalizers [] where refFinalizers = case foreignPtr of (ForeignPtr _ ref) -> ref (MallocPtr _ ref) -> ref The function uses the internal representation of the foreign pointer. Is there any other way to do this or I am missing something? If there is not any other way, then I think that the right place for this function is in the standard libraries. Any suggestions will be welcomed! Krasimir __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/

1 0

Concurrency problems with Handle
by Arie Peterson 21 Dec '03

21 Dec '03

Hello, After many hours of vain debugging, I suspect that GHC might not do what I think it should do. I made a module 'Telnet', exporting one function 'telnet', which takes a handle (an established connection) and returns an input channel, an output channel and a function to close the connection and clean up. The 'telnet' function creates two channels (input and output), one MVar and two threads: * One thread takes chars from the output channel and writes them into the handle. * The other thread reads chars from the handle and puts them in the input channel. * The MVar regulates writing access to the handle: the reader thread sometimes has to respond to telnet commands, but those responses must not be interspersed with ordinary data. Now, if I let one side of the connection send some characters: sequence_ $ take 10 $ repeat $ (writeChan outputChan 's') and I let the other side consume them: sequence_ $ take 10 $ repeat $ (putChar =<< readChan inputChan) then the characters are sent and received correctly, but the receiving side shows the characters only after the connection is closed. If I let both sides send and consume characters in turn, like this: sequence_ $ take 10 $ repeat $ threadDelay 250 >> (writeChan outputChan 's') >> (putChar =<< readChan inputChan) and sequence_ $ take 10 $ repeat $ (putChar =<< readChan inputChan) >> threadDelay 250 >> (writeChan outputChan 'c') , one character is sent, and the other end waits indefinitely before sending his character. Maybe some buffering mechanism is holding my characters? I already tried hFlush and setting buffering to NoBuffering on all handles. Could it have anything to with this? "One final note: the aaaa bbbb example may not work too well on GHC (see Scheduling, above), due to the locking on a Handle. Only one thread may hold the lock on a Handle at any one time, so if a reschedule happens while a thread is holding the lock, the other thread won't be able to run. The upshot is that the switch from aaaa to bbbbb happens infrequently. It can be improved by lowering the reschedule tick period. We also have a patch that causes a reschedule whenever a thread waiting on a lock is woken up, but haven't found it to be useful for anything other than this example :-)" (http://haskell.org/ghc/docs/latest/html/libraries/base/Control.Concurrent.h…) I tried all this both in compiled and interactive mode with GHC 6.0 and 6.2 on Windows 2000. Thanks for your time. Arie Peterson Telnet.hs, with many superfluous debugging output: ### module Telnet (telnet) where import Control.Concurrent (forkIO,killThread) import Control.Concurrent.Chan (Chan,newChan,readChan,writeChan) import Control.Concurrent.MVar (MVar,newMVar,takeMVar,putMVar) import System.IO (Handle,hGetChar,hPutChar) telnet :: Handle -> IO (Chan Char,Chan Char,IO ()) telnet handle = do inputChan <- newChan outputChan <- newChan writing <- newMVar () readerId <- forkIO $ reader handle inputChan writing writerId <- forkIO $ writer handle outputChan writing return ( inputChan, outputChan, do -- function to close connection takeMVar writing hPutChar handle '\255' -- IAC hPutChar handle '\244' -- IP (Interrupt Process) killThread readerId killThread writerId ) reader :: Handle -> Chan Char -> MVar () -> IO () reader handle inputChan writing = sequence_ . repeat $ do putStrLn "Telnet.reader: waiting for char in handle" c <- hGetChar handle putStrLn ("Telnet.reader: received " ++ show c) case c of '\255' -> hGetChar handle >>= \c -> putStrLn ("Telnet.reader: received " ++ show c) >> case c of '\255' -> writeChan inputChan '\255' -- escaped IAC '\254' -> respond '\253' -- received DONT, send WONT '\253' -> respond '\254' -- received WONT, send DONT '\252' -> respond '\253' -- received DO, send WONT '\251' -> respond '\254' -- received WILL, send DONT _ -> return () -- received unknown command, ignore c -> writeChan inputChan c where respond c = do d <- hGetChar handle putStrLn ("Telnet.reader: received " ++ show d ++ ", responding") takeMVar writing hPutChar handle '\255' hPutChar handle c hPutChar handle d putMVar writing () writer :: Handle -> Chan Char -> MVar () -> IO () writer handle outputChan writing = sequence_ . repeat $ do putStrLn "Telnet.writer: waiting for character in chan" c <- readChan outputChan putStrLn ("Telnet.writer: going to write: " ++ show c) takeMVar writing case c of '\255' -> hPutChar handle '\255' >> hPutChar handle '\255' -- escaped IAC _ -> hPutChar handle c putMVar writing () putStrLn ("Telnet.writer: written: " ++ show c)

1 0

ghc-6.2 compilation problems
by Duncan Coutts 19 Dec '03

19 Dec '03

I'm getting problems building ghc 6.2. It fails building the documentation (which I didn't really want anyway). I'm using the gentoo ebuild script. I've got haddock 0.6 installed. (That was my first error!) I'm hoping someone might know what is going wrong here. I'll report back to the gentoo ghc package maintainer. The build output is like so: ------------------------------------------------------------------------ ===fptools== Finished making `install-docs' in base haskell98 haskell-src network parsec QuickCheck readline OpenGL GLUT unix ... PWD = /var/tmp/portage/ghc-6.2/work/ghc-6.2/libraries ------------------------------------------------------------------------ rm -f libraries.txt ( cat libraries-header.txt ; echo ; \ for i in `for j in base haskell98 haskell-src network parsec QuickCheck readline OpenGL GLUT unix ; do echo $j ; done | sort -f` ; do \ grep -w name $i/package.conf.in | sed "s/^.*\"$.*$\".*$/[@\1@]/"; \ grep -v '^ *$' $i/prologue.txt; \ echo; \ done ; \ cat libraries-footer.txt ; echo ) > libraries.txt mkdir html /usr/bin/haddock --gen-index --gen-contents -o html \ \ -t "Haskell Hierarchical Libraries" \ -p libraries.txt \ --read-interface=base,base/base.haddock --read-interface=haskell98,haskell98/haskell98.haddock --read-interface=haskell-src,haskell-src/haskell-src.haddock --read-interface=network,network/network.haddock --read-interface=parsec,parsec/parsec.haddock --read-interface=QuickCheck,QuickCheck/QuickCheck.haddock --read-interface=readline,readline/readline.haddock --read-interface=OpenGL,OpenGL/OpenGL.haddock --read-interface=GLUT,GLUT/GLUT.haddock --read-interface=unix,unix/unix.haddock Fail: does not exist Action: openFileEx Reason: No such file or directory File: base/base.haddock make[1]: *** [html/index.html] Error 1 make[1]: Leaving directory `/var/tmp/portage/ghc-6.2/work/ghc-6.2/libraries' make: *** [install-docs] Error 1 !!! ERROR: dev-lang/ghc-6.2 failed. !!! Function src_install, Line 133, Exitcode 2 !!! (no error message) Duncan

1 0

Re: To show or not to show french accents
by MR K P SCHUPKE 19 Dec '03

19 Dec '03

>The problem is that if you are reading single bytes, 233 is >not necessarily é. Erm, Internationalisation is not my thin as such... but I can't help commenting that from a systems point of view this is an utterly bad sitiation to be in... I though Haskell used unicode? I thought in unicode the id of a character was fixed irrespective of language. Where is unicode support lacking? Regards, Keean Schupke.

2 1

ghc-6.2 compilation problems
by Michael Walter 19 Dec '03

19 Dec '03

This is ghc-6.2, trying to built it with ghc-6.2: $ ./configure --with-x --enable-threaded-rts --enable-objectio --enable-hopengl => [...] ------------------------------------------------------------------------ ==fptools== make all -wr; in /home/cm/Desktop/ghc-6.2/libraries/ObjectIO ------------------------------------------------------------------------ makefile:60: warning: overriding commands for target `HSobjectio.o' ../../mk/package.mk:196: warning: ignoring old commands for target `HSobjectio.o' rm -f Graphics/UI/ObjectIO/StdIOBasic.o; if [ ! -d Graphics/UI/ObjectIO/StdIOBasic_split ]; then mkdir Graphics/UI/ObjectIO/StdIOBasic_split; else /usr/bin/find Graphics/UI/ObjectIO/StdIOBasic_split -name '*.o' -print | xargs rm -f __rm_food; fi; ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -Iinclude -package-name objectio -O -Rghc-timing -package base -split-objs -c Graphics/UI/ObjectIO/StdIOBasic.hs -o Graphics/UI/ObjectIO/StdIOBasic.o -ohi Graphics/UI/ObjectIO/StdIOBasic.hi <<ghc: 119188216 bytes, 15 GCs, 1557314/3067356 avg/max bytes residency (2 samples), 19M in use, 0.00 INIT (0.00 elapsed), 0.78 MUT (3.73 elapsed), 0.20 GC (0.19 elapsed) :ghc>> (cd Graphics/UI/ObjectIO/ && /usr/bin/ld -r -x -o StdIOBasic.o StdIOBasic_split/*.o); rm -f Graphics/UI/ObjectIO/OS/Cutil_12.o; if [ ! -d Graphics/UI/ObjectIO/OS/Cutil_12_split ]; then mkdir Graphics/UI/ObjectIO/OS/Cutil_12_split; else /usr/bin/find Graphics/UI/ObjectIO/OS/Cutil_12_split -name '*.o' -print | xargs rm -f __rm_food; fi; ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -Iinclude -package-name objectio -O -Rghc-timing -package base -split-objs -c Graphics/UI/ObjectIO/OS/Cutil_12.hs -o Graphics/UI/ObjectIO/OS/Cutil_12.o -ohi Graphics/UI/ObjectIO/OS/Cutil_12.hi Graphics/UI/ObjectIO/OS/Cutil_12.hs:40: parse error on input ``' <<ghc: 3034668 bytes, 2 GCs, 47328/47328 avg/max bytes residency (1 samples), 5M in use, 0.00 INIT (0.00 elapsed), 0.01 MUT (0.02 elapsed), 0.01 GC (0.01 elapsed) :ghc>> make[2]: *** [Graphics/UI/ObjectIO/OS/Cutil_12.o] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/cm/Desktop/ghc-6.2/libraries' make: *** [build] Error 1

1 0

RE: Running a "final" finaliser
by Simon Marlow 19 Dec '03

19 Dec '03

> I hope this question isn't too stupid, but I can't find > any obvious way to do this from reading the ghc docs. > > What I want to do is call a final foreign function (a > library shutdown routine) when Haskell terminates, but > after all ForeignPtr finalisers have been run. > > I suppose I could implement some kind of finaliser > counter so the last finalizer could tell it was the > last finaliser and call the shutdown routine, but this > seems a little awkward, especially as these days the > FFI requires finalisers to be foreign functions. > > The other possibility that occurs to me is that I call > performGC at the very end of the program, immediately > before calling the library shutdown routine. But I'm > not too sure whether that will guarantee that all > finalizers have been run even if there are no live > references to foreign objects at that point. (Using > GC as described in the "non-stop Haskell" paper it > seems possible that finalisers won't be run immediately > in response to performGC.) Using an explicit reference count sounds fine to me. The runtime system doesn't support any ordering constraints between finalizers (it's a really hard problem in general), so the party line is "you have to code it up yourself". Actually, I seem to recall that we were going to disable the running of finalizers at the end of the program completely, in which case you would have to add your cleanup code in the main thread, with an appropriate exception handler. Cheers, Simon

2 1

RE: To show or not to show french accents
by Simon Marlow 19 Dec '03

19 Dec '03

This discussion is getting a little out of hand ;-) An instance of Show should (but doessn't have to): - generate a rendering of its argument as a String that (a) follows the Haskell lexical syntax, and (b) with an appropriate instance of Read can reconstruct the original value. - generate human-parseable output as far as possible. there are numerous holes and points to discuss here, but that would be more on-topic for the Haskell mailing list. The issue here is whether show on characters should render non-ASCII characters using an escape sequence. Doing so is clearly fine, because it is still in the Haskell lexical syntax, but it would also be fine (and possibly better) to render any character that is allowed unescape in the lexical syntax, literally (i.e. any character that is in 'graphic' or 'space' in the lexical syntax). Nevertheless, Haskell 98 specifies the use of escapes for characters >127, so our hands are tied anyway. Cheers, Simon

1 0