January 2003 - Glasgow-haskell-users

Another question regarding Template Haskell
by Sean Seefried 12 Jan '03

12 Jan '03

Would it be possible to write a function "showFun" such that one could write a program f x y = x +y -- say main = putStrLn (show $(showFun f)) and the result of this program would be "f" I don't think it's possible at the moment because one can't reify expressions. Sean Seefried p.s. If I'm posting to the wrong group, I apologise, it's just that template-haskell doesn't seem to be a mail group just yet. I've posted to it and haven't seen any of my postings appear yet.

1 0

Why doesn't this Template Haskell program work?
by Sean Seefried 12 Jan '03

12 Jan '03

I compiled the following program with ghc-5.05.20030109 ---------- import Language.Haskell.THSyntax main = putStrLn (show $(lift ('a', 'b'))) instance (Lift a, Lift b) => Lift (a,b) where lift (a,b) = tup [lift a, lift b] ----- and received the following error message ------- ghc --make -fglasgow-exts -package haskell-src -package haskell98 Main.hs -o test Chasing modules from: Main.hs Compiling Main ( Main.hs, ./Main.o ) Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Loading package haskell-src ... linking ... done. ghc-5.05.20030109: panic! (the `impossible' happened, GHC version 5.05.20030109): nameModule zdfLiftZ2T{-a1dB-} Please report it as a compiler bug to glasgow-haskell-bugs(a)haskell.org, or http://sourceforge.net/projects/ghc/. ------ Why? Because if I compile the following program, -------- import Language.Haskell.THSyntax main = putStrLn (show $(tup [lift 'a', lift 'b'])) -------- it works just fine. Also, is the template-haskell mailing list active? Sean Seefried

1 0

Uninitialized UArray - feature or bug?
by Tomasz Zielonka 12 Jan '03

12 Jan '03

Hello! This is a little weird: Prelude> :m + Data.Array.Unboxed Prelude Data.Array.Unboxed> let f () = array (1, 5) [] :: UArray Int Int Prelude Data.Array.Unboxed> f () == f () False Are we giving away purity for efficiency? ;) If this behaviour is intended, maybe it should be documented? Maybe it would be a good idea to define default values for types which can be unboxed? Regards, Tom -- .signature: Too many levels of symbolic links

1 0

Shutting Down the RTS
by Wolfgang Thaller 12 Jan '03

12 Jan '03

I'm almost ready to send in a patch that should fix most of the current issues with the threaded RTS. But.... I'm stuck at the problem of terminating the RTS in a proper way. According to the GHC manual, a concurrent Haskell program should terminate when the main action terminates. This sounds reasonable and matches the behaviour of C programs on most platforms. In the threaded RTS, this behaviour has never been implemented. We can't simply return from schedule(), because we might no longer be running in the thread of the RTS main() routine. The thread where rts_mainEvalIO was called might be busy executing some foreign code that we know nothing about. (Im)possible solution #1: As soon as the main action terminates, call shutdownHaskellAndExit(). At first, this seems to work fine. But then, shutdownHaskellAndExit() comes along and tries to run finalizers. For every finalizer, the RTS is started back up again using rts_mainEvalIO(), and this time, we really have to exit by returning from rts_mainEvalIO(). Possible solution #2: Forget about running finalizers at program termination and just exit(). In most of the situations where I'd use finalizers, I don't need to run them upon program termination, the OS cleans up after me. Also, the finalizers are not run in the correct order anyway, and there are situations where running them in the wrong order might be worse than not running them at all. And, most of all, solution #2 is easy to implement. Can somebody suggest a third solution, or shall I go for #2 for the time being? Cheers, Wolfgang

2 1

FFI & C++ & Cygwin
by Koen Claessen 11 Jan '03

11 Jan '03

Dear GHC users, I have the following problem and I wonder if anyone can help. I am using the FFI to talk to a library of functions written in C++. On Unixes (Solaris, Linux) this works just fine if one adds the right -ldstdc++ here and there. However, I am using Cygwin now and that is where all the problems start. The C++ stuff compiles fine (using Cygwin's g++). The Haskell stuff compiles just fine (using Win Ghc). However, at linking time I get the following error: - undefined reference to '_impure_ptr' - undefined reference to 'operator delete(void*)' - undefined reference to 'vtable for ___cxxabiv1::__blahblah' These are all things that C++ uses internally. I think the problem is that I used Cygwin's g++ compiler and that Ghc uses Mingwin's gcc compiler to compile and link. However, I have tried to recompile the C++ libraries using the Mingwin C++ compiler but it starts throwing pages of error messages at me. The other way around: using a Cygwin specific GHC, seems more appropriate, but where does one get one of those? (I have never managed to compile one myself.) Any ideas? /Koen.

3 3

Re: signal masks and garbage collection.
by Wolfgang Thaller 10 Jan '03

10 Jan '03

Keean Schupke wrote: > I am trying to block the SIGPIPE signal, I have used the Posix > sigprocmask > call to set the signal to blocked. However the program sill bails out > if the > client closes its socket. The exception handler appears to be called > then > the program terminates. When I run the program in gdb, it gives a > SIGPIPE > signal just after the thread swap happens... Heres the report from gdb: I think I know what's going on: The runtime system is using sigprocmask for it's own purposes and accidentally overwrites your signal mask. In short: stay away from sigProcMask and friends, they don't work. Instead, try to use: installHandler sigPIPE Ignore Nothing I hope that works, I haven't tried it. Cheers, Wolfgang Thaller

1 0

RE: openFile and threads
by Peter Thiemann 10 Jan '03

10 Jan '03

Hi, one thing that I gleaned from Matthias's strace output is the fcntl system calls to obtain the locks. They are not really needed for my application and could be avoided using the POSIX library. However, this does not seem to be a big issue just from the cost of the system calls, because there is no noticeable difference between Matthias's C programs. > > But it sounds like in your case you need to open lots of (small?) files. > What do you do with the contents of the files? Yes, the files are small. They typically contain less than 10 words. These words are key words and the Select program selects file names based on boolean expressions formed from the key words. What I'm actually doing is implementing a data base for email messages, where these file names are the primary keys for the messages. Each message is represented by two files of the same name (but in different directories), the data file containing the raw message, and the meta data file that just contains a list of key words. Keeping the meta data in this way allows for smooth interaction with file synchronization across several computers. So it's necessary that each set of key words resides in its own file. I have created a web page with a little more argumentation about it: http://www.informatik.uni-freiburg.de/~thiemann/MailStore The downloadables may be a bit out of date, but you get the idea. Hope that helps. -Peter

3 2

RE: Native Threads in the RTS
by Simon Peyton-Jones 10 Jan '03

10 Jan '03

| I've postponed writing up a new proposal again... | | But I'm going to sum up some requirements that I would like to see | fulfilled - to make it clearer to others why I'm proposing such strange | things... I've been watching the discussion about native threads, and getting thoroughly confused. In an attempt to get a handle on what is going on, I have (with Simon M) written a sort of operational semantics for Concurrent Haskell with foreign threads, that attempts to abstract away from everything except the issues that gave rise to these thread proposals. You can find the document in haskell-report/ffi/threads.tex. The style files are in haskell-report/styles/*.sty. There's a Makefile in haskell-report/ffi. It's very much a first cut, and it would clearly be good to merge the threads.txt document with this new Latex one, and in the end have a final spec. But before investing effort in fiddling with it, I thought it'd be good to see whether anyone finds it helpful. It's almost certainly inconsistent in minor ways, and may need adjustment to accurately reflect the proposals on the table, but I hope it may help to make the debate more precise. Feel free to modify it. E.g. add inline comments, alternative rules, and whatever. Simon |

2 1

RE: openFile and threads
by Peter Thiemann 10 Jan '03

10 Jan '03

Hi Simon, > > If the openFile isn't on the critical path, then it can help to do it in > another thread, but only if the openFile is blocking (not usually the > case if you're opening a normal file). Actually, we tried that using mergeIO, but there was no real improvement. > > You might consider bypassing the Handle interface and going to the bare > metal using the Posix library, which will cut down on the overhead in > openFile. That's what I was fearing. Is the conversion from Haskell Strings to C strings a performance problem? > > The best solution is to avoid the open altogether if possible (eg. with > caching), but I don't know about your particular application so this > might not be a possibility. No, that's not possible. The program reads every file at most once and then terminates. Although one might contemplate writing a separate server that keeps all the information in memory and refreshes it regularly. Thanks -Peter

1 0

RE: readping fd's and flushing buffers
by Simon Marlow 10 Jan '03

10 Jan '03

> A related problem... connections are refused when using accept if the > hostname doesn't resolve. Maybe something like this would > help, unless there > is a better way? > > accept sock = do > ~(sock', (SockAddrInet port haddr)) <- Socket.accept sock > (HostEntry peer _ _ _) <- ((getHostByAddr AF_INET haddr) > `Control.Exception.catch` (\_ -> > return (HostEntry ((showHex ((haddr `shiftR` 24) .&. 0xff) > . showChar '.' > . showHex ((haddr `shiftR` 16) .&. 0xff) > . showChar '.' . showHex ((haddr `shiftR` 8) .&. 0xff) > . showChar '.' > . showHex (haddr .&. 0xff)) "") [] AF_INET []))) > handle <- socketToHandle sock' ReadWriteMode > return (handle, peer, port) Yes, except that inet_ntoa is the right way to get the string representation of an IP address. I'll make this change. Cheers, Simon

1 0