- Glasgow-haskell-users

Dynamic linking in Windows GHC 7.0.3
by Hussain Sobhy 27 May '11

27 May '11

When using dynamic linking on windows, shared libraries seem to be stored in same folders where the packages where installed i.e each library in a different folder. And these folders aren't visible to the system (by the PATH variable). Is it possible to specify the folder to which the libraries (libHSrts-ghc8.03.dll etc.) will be stored ? for example C:\Windows\System32 Because currently when I try to run any executable which is dynamically linked it complains about missing dlls. Thanks

1 0

Exported modules in the GHC API
by David Waern 27 May '11

27 May '11

Hi, When encountering an IEModuleContents ModuleName export item, I'd like a simple way to get its original Module (with the original module name and package ID). It seems a bit complicated to have to go through the import items to figure this out. My question is: is there a simpler way, and if not, do you agree that the API should provide a simpler way? Thanks, David

2 4

Completely reproducible Haskell builds
by Greg Steuck 27 May '11

27 May '11

I am trying to get ghc-7.0.3 build procedure down to a byte-identical rebuild on Linux-amd64. I solved one source of variability: ar embedding timestamps into .a files (HOWTO at the end) Now I am looking to eliminate variations in ELF64 executables. To make things easy, I am going to demonstrate with unlit binary. I start at a point where make leaves off. % cp utils/unlit/dist/build/tmp/unlit{,.1} % "/usr/bin/ghc" -o utils/unlit/dist/build/tmp/unlit -O -H64m -package-conf libraries/bootstrapping.conf -i -iutils/unlit/. -iutils/unlit/dist/build -iutils/unlit/dist/build/autogen -Iutils/unlit/dist/build -Iutils/unlit/dist/build/autogen -no-user-package-conf -rtsopts -odir utils/unlit/dist/build -hidir utils/unlit/dist/build -stubdir utils/unlit/dist/build -hisuf hi -osuf o -hcsuf hc -no-auto-link-packages -no-hs-main utils/unlit/dist/build/unlit.o % sha1sum utils/unlit/dist/build/tmp/unlit{,.1} 6f679d9dd9a9ea84a68be99369c9f1dc72ba41f0 utils/unlit/dist/build/tmp/unlit beed059e09c9429c3b74ea613d5be30c6c17ac3c utils/unlit/dist/build/tmp/unlit.1 % ls -l utils/unlit/dist/build/tmp/unlit{,.1} -rwxr-x--- 1 gnezdo eng 15112 May 25 21:53 utils/unlit/dist/build/tmp/unlit -rwxr-x--- 1 gnezdo eng 15112 May 25 21:53 utils/unlit/dist/build/tmp/unlit.1 % for i in utils/unlit/dist/build/tmp/unlit{,.1}; do readelf -a $i > $i.elf; done % diff utils/unlit/dist/build/tmp/unlit{,.1}.elf 250c250 < 27: 0000000000000000 0 FILE LOCAL DEFAULT ABS ghc27965_0.c --- > 27: 0000000000000000 0 FILE LOCAL DEFAULT ABS ghc20499_0.c Looks like there is a temporary file name baked into the ELF file. Indeed, running with -v reveals: *** C Compiler: /usr/bin/gcc -c /tmp/ghc28016_0/ghc28016_0.c -o /tmp/ghc28016_0/ghc28016_0.o -I/usr/lib/ghc-7.0.3/include -fno-stack-protector *** Linker: /usr/bin/gcc -v -o utils/unlit/dist/build/tmp/unlit -fno-stack-protector utils/unlit/dist/build/unlit.o /tmp/ghc28016_0/ghc28016_0.o Digging a bit into the sources reveals mkExtraCObj in DriverPipeline.hs which calls newTempName. The best option for dealing with this seems to be using gcc ability to accept input from a pipe. I know I could make this work on a Posix system. Yet I suspect getting it to work on Windows would be overly onerous. Next best idea is to make GHC use repeatable temporary .c & .o file names for each invocation. There is already a unique temporary directory where all the the temporary files are created. This suggests I do not need to worry about adversarial races. So GHC just need to avoid racing with itself. I see a couple of options: 1) newTempName should create a new subdirectory for each call and the return a fixed name inside of this (so /tmp/ghc28016_0/ghc28016_0.c above would become /tmp/ghc28016_0/0/dummy.c) 2) mkExtraCObj could compute some hash function of its xs argument (C program text) and then create a file named, e.g. /tmp/ghc28016_0/38eb8d8eb0abe9c828ba60983e2a97f7a069ec41.c Which of these two looks better? Other ideas? Would people be open to accepting a patch along these lines if I were to write one? The steps to make ar not include the timestamps were 1) Add "AR_OPTS = qD" to build.mk. This takes care of most .a files. 2) Set AR_FLAGS=qD in the evironment and dummy out ranlib (create a no-op script called ranlib on your PATH prior to real ranlib). This takes care of libffi build. Thanks Greg -- nest.cx is Gmail hosted, use PGP for anything private. Key: http://tinyurl.com/ho8qg Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0

3 3

Re: Type of an HsExpr
by Sven Urbanski 26 May '11

26 May '11

Hello everyone, On Thu, May 19, 2011 at 09:17, Simon Peyton-Jones <simonpj(a)microsoft.com> wrote: > Maybe you want > > tcRnExpr :: HscEnv > -> InteractiveContext > -> LHsExpr RdrName > -> IO (Messages, Maybe Type) > > from TcRnDriver? This is pretty close to what I need. Unfortunately, I have LhsExpr Id not RdrName. A little detail: I am traversing the LHsExprs inside a "TypecheckedSource". Since I mostly only need the HsExprs, I could also use a "ParsedModule". I have tried switching to ParsedModule. But whenever I use the PostTcType from a MatchGroup (within a FunBind) I get: panic! (the 'impossible' happened) (GHC version 6.12.3 for i386-unknown-linux): Evaluated the place holder for a PostTcType So, I guess the PostTcType is just not well defined within a ParsedModule. Thats why I use TypecheckedSource. On Thu, May 19, 2011 at 17:06, Ranjit Jhala <jhala(a)cs.ucsd.edu> wrote: > dsExpr :: HsExpr Id -> DsM CoreExpr > > which "desugars" the source-level HsExpr into the CoreExpr. Again, pretty close to what I need. The Monad is a little unexpected. I wrote a simple function: hsExpr2TypeDo :: HsExpr Id -> DsM Type hsExpr2TypeDo hsexpr = do let ioCoreE = dsExpr hsexpr x <- ioCoreE return (exprType x) (One could write that a little shorter, but that's not the point) My problem was, that I eventually need the Type from the DsMonad. Obviously, I cant just get the value out of a monad (that's against the idea of monads). So I was looking for a function that transforms: DsM a -> IO a. I found: initDs :: HscEnv -> Module -> GlobalRdrEnv -> TypeEnv -> DsM a -> IO (Messages, Maybe a) 1) For the HscEnv I use the result of getSession 2) Module is the result of ms_mod (getModSummary m)) However for the other parameters, I use empty values: 3) emptyGlobalRdrEnv 4) emptyTypeEnv This actually works (at least for the simple cases I have tested). But it seems wrong to me to pass two empty environments. Can I somehow obtain valid environments? Another question: Why is dsExpr monadic? What side effects could there possibly be? Thanks for all the answers, I'm sorry that I answer so late, I wanted to try everything out before responding. Thanks, Sven

3 2

Re: Type of an HsExpr
by Sven Urbanski 25 May '11

25 May '11

On Mon, May 23, 2011 at 17:30, Ranjit Jhala <jhala(a)cs.ucsd.edu> wrote: > Btw, I don't know what application you have in mind, but if you are > happy with just the types of identifiers then those are easy enough > to get > > idType :: Id -> Kind No, I really need the type for any expression. (My application is a haskell to java compiler, btw; I need the type for the proper use of generics in java.) Thanks again, Sven

2 1

operations with handles hang
by Artem Chuprina 24 May '11

24 May '11

Hello. Searching for example of TCP server in Haskell, I found an example close to my problem. While most of examples of TCP servers do very simple handling of TCP requests, in one thread, this one does in a simplified manner what I need - routes messages between connected clients. But trying it, I encountered a very strange (for me) behavior. The example can be found at http://sequence.complete.org/node/258, and a slightly cleaned code is below. An author writes that the code was tested on ghc 6.6 under Linux/x86. I have ghc 6.12.1 on Debian GNU/Linux. My compiler asked me to add type signatures in second arguments of catch (original code does not have them). The code works well while no one of the clients is disconnected. But as one of the clients disconnects, the server hangs trying to write to its handle, consuming processor (and it seems that it slowly consumes memory too). My investigation showed that disconnect is detected by hGetLine, which throws an exception, and clientLoop in finally closes the handle. After that hPutStrLn to its handle in mainLoop hangs. To me this is a very strange behavior. I expected that hPutStrLn to closed handle should throw an exception. The original author, it seems, too. I tried to comment the final hClose in clientLoop. After that hPutStrLn stopped to hang, but, strangely, the fact that the client has disconnected is detected only on the second write (hFlush) after disconnect, not on the first. And more, when I insert, say, hIsClosed h before hPutStrLn h in mainLoop, the server hangs on it, now even not waiting for disconnect, just on first call to hIsClosed. Could anyone tell me what is wrong with the code: module Main where import Prelude hiding (catch) import Network (listenOn, accept, sClose, Socket, withSocketsDo, PortID(..)) import System.IO import System.Environment (getArgs) import Control.Exception (finally, catch) import Control.Concurrent import Control.Concurrent.STM import Control.Monad (forM, filterM, liftM, when) main = withSocketsDo $ do [portStr] <- getArgs let port = fromIntegral (read portStr :: Int) servSock <- listenOn $ PortNumber port putStrLn $ "listening on: " ++ show port start servSock `finally` sClose servSock start servSock = do acceptChan <- atomically newTChan forkIO $ acceptLoop servSock acceptChan mainLoop servSock acceptChan [] type Client = (TChan String, Handle) acceptLoop :: Socket -> TChan Client -> IO () acceptLoop servSock chan = do (cHandle, host, port) <- accept servSock cChan <- atomically newTChan cTID <- forkIO $ clientLoop cHandle cChan atomically $ writeTChan chan (cChan, cHandle) acceptLoop servSock chan clientLoop :: Handle -> TChan String -> IO () clientLoop handle chan = listenLoop (hGetLine handle) chan `catch` (const $ return () :: IOError -> IO ()) `finally` hClose handle listenLoop :: IO a -> TChan a -> IO () listenLoop act chan = sequence_ (repeat (act >>= atomically . writeTChan chan)) mainLoop :: Socket -> TChan Client -> [Client] -> IO () mainLoop servSock acceptChan clients = do r <- atomically $ (Left `fmap` readTChan acceptChan) `orElse` (Right `fmap` tselect clients) case r of Left (ch,h) -> do putStrLn "new client" mainLoop servSock acceptChan $ (ch,h):clients Right (line,_) -> do putStrLn $ "data: " ++ line clients' <- forM clients $ \(ch,h) -> do hPutStrLn h line hFlush h return [(ch,h)] `catch` (const (hClose h >> return []) :: IOError -> IO [a]) let dropped = length $ filter null clients' when (dropped > 0) $ putStrLn ("clients lost: " ++ show dropped) mainLoop servSock acceptChan $ concat clients' tselect :: [(TChan a, t)] -> STM (a, t) tselect = foldl orElse retry . map (\(ch, ty) -> (flip (,) ty) `fmap` readTChan ch)

3 2

hsc2hs on Mac
by Kazu Yamamoto 23 May '11

23 May '11

Hello, I'm using Haskell Platform 2011.2.0.1 on MacOS (Snow Leapard). hsc2hs converts (#const sizeof(struct stat)) (#peek struct stat, st_mtimespec) to 108 36 but the correct values are 144 32. Is this a bug of hsc2hs? gcc-4.0 says sizeof (struct stat) is 108 while gcc-4.2 (default) says that is 144. --Kazu

3 4

Re: repa: fromVector
by Christian Höner zu Siederdissen 20 May '11

20 May '11

Hi, there is a ticket for 'vector' available with what I need: http://trac.haskell.org/vector/ticket/15 basically, I need a generalised scan that makes available a partially initialized vector for each new element. gen_scan :: Vector v a => Int -> (v a -> a) -> v a Only that 'a' tends to be a 5-tuple ;-) A function along those lines is extremely useful in a number of cases. I hope to have some time to actually dig through the repa sources and see what is possible. Gruss, Christian * Ben Lippmeier <benl(a)ouroborus.net> [20.05.2011 04:14]: > > On 19/05/2011, at 8:27 PM, Christian Höner zu Siederdissen wrote: > > > I'd like to use repa in a rather perverted mode, I guess: > > > > for my programs I need to be able to update arrays in place and > > repeatedly perform operations on them. > > Right now, it basically works like this (in ST): > > > > - create unboxed space using "primitive" (same as unboxed vectors) > > - unsafefreeze unboxed space > > - perform calculations on frozen, immutable space > > - write result into mutable space (which is shared with the unsafefrozen > > space) > > If you care deeply about inplace update, then you could use the parallel array filling functions directly. The ones in D.A.Repa.Internals.Eval*.hs. For 2D images, use the fillVectorBlockwiseP [1] or fillCursoredBlock2P. > > > fillVectorBlockwiseP > :: Elt a > => IOVector a -- ^ vector to write elements into > -> (Int -> a) -- ^ fn to evaluate an element at the given index > -> Int -- ^ width of image. > -> IO () > > > -- | Fill a block in a 2D image, in parallel. > -- Coordinates given are of the filled edges of the block. > -- We divide the block into columns, and give one column to each thread. > fillCursoredBlock2P > :: Elt a > => IOVector a -- ^ vector to write elements into > -> (DIM2 -> cursor) -- ^ make a cursor to a particular element > -> (DIM2 -> cursor -> cursor) -- ^ shift the cursor by an offset > -> (cursor -> a) -- ^ fn to evaluate an element at the given index. > -> Int -- ^ width of whole image > -> Int -- ^ x0 lower left corner of block to fill > -> Int -- ^ y0 (low x and y value) > -> Int -- ^ x1 upper right corner of block to fill > -> Int -- ^ y1 (high x and y value, index of last elem to fill) > -> IO () > > > Actually, it might be worthwhile exporting these in the API anyway. > > [1] http://code.ouroborus.net/repa/repa-head/repa/Data/Array/Repa/Internals/Eva… > [2] http://code.ouroborus.net/repa/repa-head/repa/Data/Array/Repa/Internals/Eva… > >

1 0

repa: fromVector
by Christian Höner zu Siederdissen 20 May '11

20 May '11

Hi, I'd like to use repa in a rather perverted mode, I guess: for my programs I need to be able to update arrays in place and repeatedly perform operations on them. Right now, it basically works like this (in ST): - create unboxed space using "primitive" (same as unboxed vectors) - unsafefreeze unboxed space - perform calculations on frozen, immutable space - write result into mutable space (which is shared with the unsafefrozen space) - In principle, this should work with repa as well, I think. The question is: does "Repa.Internals.Base.fromVector" any copying, or does it just use the unboxed vector as-is internally? should I expect any problems? ;-) Gruss, Christian

3 2

Type of a HsExpr
by Sven Urbanski 19 May '11

19 May '11

Hi all, I'm having a problem similar to Ranjit in the mail "parsing types". However, I want to get the type of an HsExpr: getType :: HsExpr -> Type or something similar. This should basically do what :t does in ghci, but for any given HsExpr (also it should not work on Strings). Looking at the ghc sources, I found exprType :: CoreExpr -> Type which is pretty close to what i need. Another way of solving this, would be a function lik this: hsExpr2CoreExpr :: HsExpr -> CoreExpr Than I could combine them like: exprType . hsExpr2CoreExpr Any hints are very much appreciated, Sven

2 1