Michael Snoyman wrote:
I think I have a misunderstanding of how forkProcess should be working.
Ultimately this relates to some bugs in the development version of keter, but
I've found some behavior in a simple test program which I wouldn't have
expected either, which may or may not be related.
Just following up to my problem, I was seeing lots of hangs in various
places in my program when it was built with the threaded runtime.
I eventually tracked every single hang back to calls to MissingH's
System.Cmd.Utils, including pipeFrom, pipeTo, pipeBoth, and pOpen.
I was at this point
Joey Adams wrote:
Off the top of my head, I'm not aware of any (non-Windows-related)
gotchas with using -threaded. However, some functions in MissingH
(e.g. in System.Cmd.Utils) call forkProcess. To quote the
documentation of forkProcess [1]:
---
forkProcess comes with a giant warning:
I've found a minimal test case that seems to demonstrate a bug in either
MissingH or ghc's threaded runtime. Or I'm doing something stupid in
fewer lines of code than usual. ;)
When built with the threaded runtime, after a short while it hangs in
hGetContents.
import System.Cmd
import System.IO
Antoine Latter wrote:
Well, hPipeFrom does indeed call forkProcess internally. I don't fully
understand when it is and is not safe to use 'forkProcess' with the
threaded runtime of GHC.
Which version of GHC are you using?
I've reproduced the problem with 7.4.2, and 7.4.1.
Just tried
I've isolated the hang further to hPipeFrom's use of System.Log.Logger.
Commenting out calls to logging functions makes it reliably run ok. See
the LINE OF DEATH in the attached updated test case.
... And it turns out that System.Log.Logger uses a MVar to hold the
logger information. So I think
I have a rather large program that works fine with ghc's default
runtime, but now I'd like to build it with -threaded, and this
causes it to hang in a way I have not been able to pin down to anything
specific. It hangs at different points each time it's run; running
it in strace will consistently
I found myself writing the code below today, and thought I'd write to see if
there's a better way, perhaps one that doesn't use unsafePerformIO.
A sample use case for this is a program that reads a FilePath from a Handle,
and then operates on that file on disk. GHC uses a special encoding for
Joachim Breitner wrote:
Most of these architectures do not have a native code generator (so they
are compiled via C) and are unregisterized, i.e. GHC knows nothing about
their registers. Both cause a performance penalty; I don’t know numbers.
I assume this is what Joey refers to. But maybe
Thomas DuBuisson wrote:
On Sun, Apr 8, 2012 at 4:03 PM, Francesco Mazzoli f...@mazzo.li wrote:
No, it is not possible to build GHC without GHC. Building GHC on ARM is
going to be extremely tricky (I'm not sure anyone has ever done it).
I used to use an unregistered build of GHC built by
Jason Dusek wrote:
:info System.Posix.Env.getEnvironment
System.Posix.Env.getEnvironment :: IO [(String, String)]
-- Defined in System.Posix.Env
But there is no law that environment variables must be made of
characters:
The recent ghc release provides
John Millikin wrote:
That was my understanding also, then QuickCheck found a
counter-example. It turns out that there are cases where a valid path
cannot be roundtripped in the GHC 7.2 encoding.
The issue is that [238,189,178] decodes to 0xEF72, which is within
the 0xEF00-0xEFFF range that
John Millikin wrote:
That was my understanding also, then QuickCheck found a
counter-example. It turns out that there are cases where a valid path
cannot be roundtripped in the GHC 7.2 encoding.
The issue is that [238,189,178] decodes to 0xEF72, which is within
the 0xEF00-0xEFFF range that
John Millikin wrote:
Perhaps I'm misunderstanding, but the definition of 'withFilePath' you
provided is definitely locale-dependent. Unless getFileSystemEncoding
is constant?
I think/hope it's locale dependent, but undecodable bytes are remapped,
so as long as the system's locale doesn't
John Millikin wrote:
In GHC 7.2 and later, file path handling in the platform libraries
was changed to treat all paths as text (encoded according to locale).
This does not work well on POSIX systems, because POSIX paths are byte
sequences. There is no guarantee that any particular path will
John Millikin wrote:
In GHC 7.2 and later, file path handling in the platform libraries
was changed to treat all paths as text (encoded according to locale).
This does not work well on POSIX systems, because POSIX paths are byte
sequences. There is no guarantee that any particular path will
Yves Parès wrote:
Have you tried to compile your code with optimisations? I guess GHC's
strictness analysis would find strict evaluation is better here.
The original code I saw this happen to the wild was built with -O2.
I didn't try building the test case with optimisations.
--
see shy jo
The attached test case quickly chews up hundreds of MB of memory.
If modified to call work' instead, it runs in constant space.
Somehow the value repeatedly read in from the file and stored in
the state is leaking. Can anyone help me understand why?
(ghc 7.0.4)
--
see shy jo
{-# LANGUAGE
Claude Heiland-Allen wrote:
Control.Monad.State.Strict is strict in the actions, but the state
itself is still lazy, so you end up building a huge thunk in the
state containing all the updates that ever took place to the initial
state.
Using this should fix it:
modify' :: MonadState s m
David Fox wrote:
I try to create a workflow for this sort of thing. I create a package
with a name like set-extra, with one module Data.Set.Extra and an
alternative Data.Set module that exports both the old Data.Set and the
symbols in Data.Set.Extra. Then I email the maintainers of the
I'm finding a rather unusual problem as I write haskell..
Unlike every other language I've used, large portions of my haskell code
are turning out to be general-purpose, reusable code. Fully 20% of the
haskell code I've written for git-annex is general purpose. Now, I came out
of a decade of perl
Bas van Dijk wrote:
You can use the following:
{-# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies, MultiParamTypeClasses
#-}
import Control.Applicative
import Control.Monad
import Control.Monad.Base
import Control.Monad.Trans.Class
import Control.Monad.Trans.Control
import
Bas van Dijk wrote:
On 6 December 2011 09:12, Bas van Dijk v.dijk@gmail.com wrote:
instance MonadBaseControl IO Annex where
newtype StM Annex a = StAnnex (StM (StateT AnnexState IO) a)
liftBaseWith f = Annex $ liftBaseWith $ \runInIO -
f $ liftM StAnnex .
I'm trying to convert from 0.2 to 0.3, but in way over my head.
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
newtype Annex a = Annex { runAnnex :: StateT AnnexState IO a }
deriving (
Monad,
MonadIO,
-- MonadControlIO
Michael Snoyman wrote:
I just spent a fair amount of time yesterday upgrading packages to
monad-control 0.3. What I had to do was add in the MonadTransControl
and MonadBaseControl instances manually. It's actually not too
difficult; just copy out the instance for StateT and make a few
Yitzchak Gale wrote:
The API for parsing and rendering time in Data.Time is
based on the standard API for that in C - like the libraries
in most languages. It's pretty standard stuff.
I'm sure it can be improved upon though. If you have a useful
alternative time parsing library, please
I've been trying to deal with how my haskell program handles unicode
filenames. Been dealing with problems like those described here:
http://hackage.haskell.org/trac/ghc/ticket/3307
Or, simply demonstrated by feeding unicode to getLine = readFile
My approach currently is to carefully identify
Suppose I'm playing with HUnit for nearly the first time. I might write
a test program like this, to see what a test failure looks like in practice:
import Test.HUnit
import Test.HUnit.Tools
main = runVerboseTests $ TestList
[ TestCase $ assertBool should fail False
, TestCase $
28 matches
Mail list logo
