- Glasgow-haskell-users

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

build ghc package from repo ?
by Ranjit Jhala 19 May '11

19 May '11

Dear ghc-users, I'm having a rather tricky time building a fresh copy of ghc from the git repository (let me call it git-ghc) and then getting my-own-client-code to compile with the modules from git-ghc. The catch is that my-client-code also depends on other cabal-installed libraries which break once git-ghc is installed as _the_ ghc in my system... Is there a way I can just build git-ghc but ONLY install the packages (i.e. add them to the ghc-pkg database) so that my-own-client-code can then be compiled (by platform-ghc) against the modules from git-ghc? Thanks!, Ranjit.

1 0

Linking in Dead Code
by Guy 16 May '11

16 May '11

If only 1% of an imported module is used, GHC will link in the entire module. Are there any plans, or at least some ideas, to rectify this? One severe example of this is qtHaskell, where importing the top-level module causes glacial compile (actually link) times and huge executables. Strip can fix the executable size (why does GHC not do this automatically?), but linking remains a problem.

5 9

testsuite results
by Daniel Fischer 16 May '11

16 May '11

Running the testsuite with today's HEAD (perf build, but without profiling to keep time bearable) resulted in: ==================== OVERALL SUMMARY for test run started at Do 12. Mai 13:34:13 CEST 2011 2765 total tests, which gave rise to 9300 test cases, of which 0 caused framework failures 1587 were skipped 7467 expected passes 229 expected failures 9 unexpected passes 8 unexpected failures ==================== Pretty cool, I can't remember having so few unexpected failures before. ==================== Unexpected failures: T5084(normal) That's the compiler not complaining about an INLINE-pragma on a class method without default implementation. Patch is in ghc-generics branch, not yet in master, according to #5084. Anyway it's nothing serious (was a feature request, not a bug). dph-diophantine-opt(normal,threaded1,threaded2) These are due to a missing Show instance for [:Int:], a library issue. dph-words-opt(normal) Fails with "dph-words-opt: libraries/vector/Data/Vector/Generic.hs:369 (slice): invalid slice (1,2,2)". No idea whether that's a library or a compiler issue. hpc_markup_multi_001(normal) hpc_markup_multi_002(normal) hpc_markup_multi_003(normal) Those are due to hpc looking in the wrong directory for the tix files, patch exists, but is not yet in the master branch, according to #5069. So, of the eight unexpected failures, six are due to trivia (they *might* fail for other causes when the trivia are fixed, but there's no reason to expect that), one is a feature request whose test reached testsuite/master before the implementation reached ghc/master and only one may (but need not) indicate a compiler bug at present, that's rather awesome. ==================== Unexpected passes: mc01(hpc,ghci) mc06(hpc,ghci) mc08(hpc,ghci) mc11(hpc) mc16(hpc) mc18(hpc) All these involve the new MonadComprehensions extension, they're expected to work and do so for the normal and optasm ways, maybe they should also be expected to work for hpc and ghci. Additionally, sometimes conc016(threaded2) passes unexpectedly; which thread first gets its exception to the other one is impossible to predict: -- NB. this test is delicate since 6.14, because throwTo is now always -- interruptible, so the main thread's killThread can be legitimately -- interrupted by the child thread's killThread, rather than the other -- way around. This happens because the child thread is running on -- another processor, so the main thread's throwTo is blocked waiting -- for a response, and while waiting it is interruptible. Summing up: Yay!

3 4