Re: Should GHC default to -O1 ?

On 08/11/2011 14:31, Daniel Fischer wrote: On the haskell-cafe as well as the beginners mailing lists, there frequently (for some value of frequent) are posts where the author inquires about a badly performing programme, in the form of stack overflows, space leaks or slowness. Often this is beca

Re: behaviour change in getDirectoryContents in GHC 7.2?

On 09/11/2011 10:39, Max Bolingbroke wrote: On 8 November 2011 11:43, Simon Marlow wrote: Don't you mean 1 is what we have? Yes, sorry! Failing to roundtrip in some cases, and doing so silently, seems highly suboptimal to me. I'm sorry I didn't pick up on this at the tim

Re: behaviour change in getDirectoryContents in GHC 7.2?

On 08/11/2011 15:42, John Millikin wrote: On Tue, Nov 8, 2011 at 03:04, Simon Marlow wrote: I really think we should provide the native APIs. The problem is that the System.Posix.Directory API is all in terms of FilePath (=String), and if we gave that a different meaning from the

Re: behaviour change in getDirectoryContents in GHC 7.2?

On 09/11/2011 13:11, Ian Lynagh wrote: > On Wed, Nov 09, 2011 at 11:02:54AM +0000, Simon Marlow wrote: >> >> I would be happy with the surrogate approach I think. Arguable if >> you try to treat a string with lone surrogates as Unicode and it >> fails, then that is a f

Re: behaviour change in getDirectoryContents in GHC 7.2?

On 09/11/2011 15:58, Max Bolingbroke wrote: (Note that the above outlined problems are problems in the current implementation too -- but the current implementation doesn't even pretend to support U+EFxx characters. Its correctness is entirely dependent on them never showing up, which is why we c

Re: behaviour change in getDirectoryContents in GHC 7.2?

On 09/11/2011 16:42, John Millikin wrote: On Wed, Nov 9, 2011 at 08:04, Simon Marlow wrote: Ok, I spent most of today adding ByteString alternatives for all of the functions in System.Posix that use FilePath or environment strings. The Haddocks for my augmented unix package are here: http

Re: behaviour change in getDirectoryContents in GHC 7.2?

On 10/11/2011 09:28, Max Bolingbroke wrote: Is there any consensus about what to do here? My take is that we should move back to lone surrogates. This: 1. Recovers the roundtrip property, which we appear to believe is essential 2. Removes all the weird problems I outlined earlier that can

Re: GHC 7.2.2 RC 1

Sorry, no. That one has a workaround: define your own fixIO: fixIO :: (a -> IO a) -> IO a fixIO k = do m <- newEmptyMVar ans <- unsafeInterleaveIO (takeMVar m) result <- k ans putMVar m result return result Cheers, Simon On 11/11/2011 06:16, Nathan Howell wrote: An

Re: encoding and paths, again

On 13/11/2011 19:41, Ganesh Sittampalam wrote: Hi, I'm not entirely clear on what the overall situation will be once Simon M's patch to add .ByteString versions to unix is added in GHC 7.4.1. In particular the original problem darcs ran into was with getDirectoryContents in the directory packag

Re: source/build separation

On 15/11/2011 10:21, Rustom Mody wrote: I am building ghc from source. The building page http://hackage.haskell.org/trac/ghc/wiki/Building/Using#Sourcetreesandbuildtrees mentions lndir for separating source trees from build trees. Given how much detail is generally given for individual commands

Re: encoding and paths, again

On 16/11/2011 08:09, Ganesh Sittampalam wrote: On 14/11/2011 14:47, Simon Marlow wrote: (1) Does Win32 need similar additions? I can't spot any substantial changes to it for Max's PEP383, but I'm not sure if any lower-level library changes might have affected it. No - Win32 fi

Re: Way to expose BLACKHOLES through an API?

On 16/11/2011 10:20, Jean-Marie Gaillourdet wrote: Hi, On 16.11.2011, at 10:43, Duncan Coutts wrote: On Tue, 2011-11-08 at 15:43 +, Simon Marlow wrote: Hmm, but there is something you could do. Suppose a thread could be in a mode in which instead of blocking on a BLACKHOLE it would

Re: ANNOUNCE: GHC version 7.2.1

you make them known in the next release? sorry for causing this bug. Simon Marlow fixed this in: commit f0191c559d683b5bac12243c0db3b780b684799e Author: Simon Marlow Date: Wed Aug 10 10:02:55 2011 +0100 default to using @note for saving the linker opts (someone mentioned that it w

Re: What makes GHC's GC good for purely functional workloads?

On 23/11/2011 04:09, Edward Z. Yang wrote: Apologies if this has been asked before. In some ways GHC's garbage collectors are very traditional, so I was wondering what magic dust makes it do better in Haskelly workloads (e.g. whereas you'd need to do a bit more work in the JVM to make some alloc

Re: Stable names and type constraints

On 23/11/2011 04:56, Lee Pike wrote: Hi Everybody, This is a question about System.Mem.StableName ---let me know if this isn't the right forum, but my understanding is that stable names are GHC-specifi

Fwd: [commit: ghc] master: Relax the restriction on using abstract newtypes in FFI declarations. (c6b0fd6)

. Cheers, Simon Original Message Subject: [commit: ghc] master: Relax the restriction on using abstract newtypes in FFI declarations. (c6b0fd6) Date: Thu, 24 Nov 2011 06:57:21 -0800 From: Simon Marlow To: cvs-...@haskell.org Repository : ssh://darcs.haskell.org//srv/dar

Re: Revert a CAF?

On 06/12/2011 17:48, wren ng thornton wrote: So, I have an optimization/internals question. Does the GHC API have any hooks for being able to revert a CAF to the original expression, thus discarding the previously computed result? The reason I'm wanting this is that I have a particular CAF which

Re: Revert a CAF?

On 07/12/11 15:16, Twan van Laarhoven wrote: On 06/12/11 18:48, wren ng thornton wrote: So, I have an optimization/internals question. Does the GHC API have any hooks for being able to revert a CAF to the original expression, thus discarding the previously computed result? ... I could hack som

Re: ghc-7.4.1-rc1 recompilation checking

On 27/12/2011 13:07, Christian Maeder wrote: Hi, full recompilation with ghc-7.4.1-rc1 is already triggered by a changed "-o" option, which is inconvenient when creating different binaries with shared modules. (see below) It is no problem if I always omit the -o option and get binaries named li

Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1

On 21/12/2011 22:36, Roman Cheplyaka wrote: * Ian Lynagh [2011-12-21 18:29:21+] * The profiling and hpc implementations have been merged and overhauled. Visible changes include renaming of profiling flags: http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/flag-ref

Re: filename corruption with -osuf in ghc-7.0.3

On 24/12/2011 06:23, Evan Laforge wrote: I've noticed a strange behaviour with ghc's -osuf flag: % cat>Test.hs {-# LANGUAGE ForeignFunctionInterface #-} module Test where import Foreign foreign import ccall "wrapper" c_callback :: Int -> IO (FunPtr Int) % ghc-7.0.3 -v -c -osuf .hs.o Test.hs % l

Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1

On 03/01/2012 16:54, Tristan Ravitch wrote: This might be the expected behavior but I'll ask anyway. I have what seems to be a legitimate stack overflow (due to excessive recursion and not the evaluation of a big thunk). The stack trace from -xc only shows about 13 calls on the stack (with eac

Re: renamed GMP symbols in GHC

On 22/12/2011 22:58, Michal Konečný wrote: Several issues related to the way GMP is included in GHC were publicly discussed in the past with the goal of replacing GMP. As summarised in this wiki by Peter Tanski , the main issues were:

Re: renamed GMP symbols in GHC

On 04/01/2012 21:00, Joachim Breitner wrote: Hi, Am Mittwoch, den 04.01.2012, 20:50 +0100 schrieb Axel Simon: On 04.01.2012, at 17:50, Joachim Breitner wrote: BTW, Is there a way to get the linker to create two independent copies of a library in one program space? Maybe if it is compiled as PI

Re: Test suite quality

On 07/01/2012 17:52, Joachim Breitner wrote: Dear GHC-Team, to improve the quality of Haskell on Debian started to package the GHC testsuite in a package of its own, and will upload it to Debian so that it runs on all architectures and catches possible architecture-dependent bugs there. Using t

Re: Unit unboxed tuples

On 09/01/2012 04:46, wren ng thornton wrote: On 12/23/11 8:34 AM, Simon Peyton-Jones wrote: More uniform! If you the singleton-unboxed-tuple data constructor in source code, as a function, you'd write (\x -> (# x #)). In a pattern, or applied, you'd write (# x #). Shouldn't (# T #) be identica

Re: Unregistered builds broken?

On 10/01/2012 10:58, Joachim Breitner wrote: Dear GHC team (esp. Simon and Ian), thanks for fixing the exotic-architecture-build-errors in time for 7.4.1, everything compiles smoothly now: https://buildd.debian.org/status/package.php?p=ghc&suite=experimental (Well, arm* and mips* are not done ye

Re: Unit unboxed tuples

On 10/01/2012 16:18, Dan Doel wrote: Copying the list, sorry. I have a lot of trouble replying correctly with gmail's interface for some reason. :) On Tue, Jan 10, 2012 at 11:14 AM, Dan Doel wrote: On Tue, Jan 10, 2012 at 5:01 AM, Simon Marlow wrote: On 09/01/2012 04:46, wren ng tho

Re: Easiest way to extend CAS (casMutVar#) to boxed/unboxed Vector elements?

On 10/01/2012 17:19, Ryan Newton wrote: Hello there, I was wondering what the recommendations would be for getting CAS on [mutable] vector elements? I thought that as a first step I might create an a library that does the trick only for unboxed vectors, by using bits-atomic (i.e. FFI + GCC intr

Re: Unboxed mutable variables (was: Easiest way to extend CAS (casMutVar#) to boxed/unboxed Vector elements?)

On 12/01/2012 17:55, Johan Tibell wrote: On Thu, Jan 12, 2012 at 12:54 AM, Simon Marlow wrote: For boxed arrays you need a PrimOp of course (like catMutVar#). For unboxed arrays you could get away with FFI, but a PrimOp would be better because it could be inline. But to get it inline would

Re: Unboxed mutable variables

On 12/01/2012 18:37, Johan Tibell wrote: On Thu, Jan 12, 2012 at 10:25 AM, Simon Marlow wrote: I think by (1) you mean mutable variables containing unboxed values, right? Yes. I normally use an unboxed array of length 1 for these. There's not much overhead - only an extra word in the

Re: Profiling semantics

On 17/01/2012 09:30, Roman Cheplyaka wrote: * Simon Marlow [2012-01-03 11:00:58+] I'd be interested in hearing feedback, particularly if you find a case where costs are attributed somewhere that you didn't expect, or the stack looks wrong. What I often find counter-intuitive

Re: Runtime performance degradation for multi-threaded C FFI callback

On 21/01/2012 15:35, Sanket Agrawal wrote: Hi Edward, I was just going to get back to you about it. I did find out that the issue was indeed one GHC thread dealing with 5 C threads for callback (1:5 mapping) - so, the C threads were blocking on callback waiting for the only GHC thread to be avai

Re: Straight-line single assignment in C--

On 21/01/2012 20:39, Edward Z. Yang wrote: Excerpts from Edward Z. Yang's message of Fri Jan 20 23:44:02 -0500 2012: If multiple assignment is rare enough in straight line code, I might be able to take the conservative approach and just say a -> used multiple times Which I don't think wi

Re: Runtime performance degradation for multi-threaded C FFI callback

d this with GHC-7.2.1, however Daniel Fischer reported that, with ghc-7.2.2, he observed different behavior (which matches your explanation AFAICT). Is it possible that the scheduling of callbacks into Haskell changed between those versions? Thanks, John L. From: Simon Marlow Subject: Re: Runti

Re: Runtime performance degradation for multi-threaded C FFI callback

ther (ignoring bound threads and the like)? Callbacks always create bound threads. There are no restrictions on which capabilities can handle either forkIO or bound threads. Cheers, Simon Thank you, John L. On Mon, Jan 23, 2012 at 1:26 PM, Simon Marlow wrote: I'll need to a

Re: Is it true that an exception is always terminates the thread?

On 24/01/2012 15:59, Edward Z. Yang wrote: Excerpts from Ryan Newton's message of Tue Jan 24 10:25:37 -0500 2012: This is related but somewhat tangential -- *Why isn't there a tryReadChan?* It looks like it would be implementable with the current Chan representation in terms of tryTakeMVar.

Re: FW: A Garbage Collection Question

On 25/01/2012 07:16, Andres Löh wrote: You seem to assume that old strategies use a different GC policy than new strategies. My understanding is that this is not true. The WEAK policy is used in general now. So old strategies shouldn't be used with more recent GHCs, or you'll lose parallelism.

Re: parallelizing ghc

On 24/01/2012 03:53, Evan Laforge wrote: > I recently switched from ghc --make to a parallelized build system. I > was looking forward to faster builds, and while they are much faster > at figuring out what has to be rebuilt (which is most of the time for > a small rebuild, since ld dominates), c

Re: parallelizing ghc

On 26/01/2012 23:37, Evan Laforge wrote: I'm slightly surprised by this - in my experience parallel builds beat --make as long as the parallelism is a factor of 2 or more. Is your dependency graph very narrow, or do you have lots of very small modules? I get full parallelism, 4 threads at once

Re: ghc-7.4.1-rc1 recompilation checking

On 30/01/2012 09:45, Christian Maeder wrote: This seems not to be fixed in Release Candidate 2 Thanks for letting us know. Ian, please merge this patch: commit f283c39119b333e4249420fa96b93652e0fbaec1 Author: Simon Marlow Date: Tue Jan 3 10:28:39 2012 + Don't record outputFi

Re: ghc -C in 7.4.1

On 05/02/2012 18:06, Brandon Allbery wrote: On Sun, Feb 5, 2012 at 12:11, Serge D. Mechveliani mailto:mech...@botik.ru>> wrote: I needed to look into the C code made by ghc-7.4.1 GHC doesn't write C source any more. Warning: The -fvia-C flag does nothing; it will be removed in

Re: parallelizing ghc

On 10/02/2012 08:01, Evan Laforge wrote: I like the idea! And it should be possible to build this without modifying GHC at all, on top of the GHC API. As you say, you'll need a server process, which accepts command lines, executes them, and sends back the results. A local socket should be fine

Re: Changes to Typeable

On 10/02/2012 16:03, Simon Peyton-Jones wrote: Friends The page describes an improved implementation of the Typeable class, making use of polymorphic kinds. Technically it is straightforward, but it represents a non-backward-compatible change to a widely used library, so we need to make a pla

Re: Changes to Typeable

(your version is clearer, though) I'm assuming there's no significance behind your renaming of 'typeRep' to 'typeOfProxy'? Cheers, Simon On Mon, Feb 13, 2012 at 8:33 AM, Simon Marlow mailto:marlo...@gmail.com>> wrote: On 10/02/2012 16:03, Simon Pe

Re: recompilation on --main-is

Will be fixed in 7.4.2: http://hackage.haskell.org/trac/ghc/ticket/5878 Cheers, Simon On 16/02/2012 05:10, Evan Laforge wrote: Thanks for bringing this up. I've been having the same problem and was thinking there was something wrong with my system. I have 3 main files and one util that

Re: Removal of #include from template-hsc.h breaks largefile support on 32bit Linux

On 15/02/2012 12:31, Eugene Crosser wrote: Hello all, I am new here, but I want to report what I suspect may be a problem. I ran into it while using some third-party package from hackage on a 32bit Linux with ghc 7.4.1. I discovered that off_t fields in the .hsc files in the package where inter

Re: recent changes to hsc2hs break wrapping c++

On 15/02/2012 19:51, Evan Laforge wrote: On Wed, Feb 15, 2012 at 11:17 AM, Eugene Crosser wrote: On 02/15/2012 09:59 PM, Evan Laforge wrote: Unfortunately, the result is I (apparently) can't use it now. Here's how that happens: The change was to remove the dependency on HsFFI.h. Evan, *if

Re: parallelizing ghc

On 17/02/2012 01:59, Evan Laforge wrote: However, the GHC API doesn't provide a way to do this directly (I hadn't really thought about this when I suggested the idea before, sorry). The GHC API provides support for compiling multiple modules in the way that GHCi and --make work; each module is a

Re: Removal of #include from template-hsc.h breaks largefile support on 32bit Linux

On 16/02/2012 13:25, Eugene Crosser wrote: Hello Simon, thanks for your attention :) On 02/16/2012 04:25 PM, Simon Marlow wrote: I found that earlier versions of hsc2hs included HsFFI.h into the [...] As I understand, this situation means that while the ghc itself and haskell programs

Re: Help me grok addFinalizer

On 16/02/2012 22:20, Michael Craig wrote: > I haven't checked, but ... I checked, and your solution works. In the context of a larger program, getting NOLINE pragmas in all the right places would be challenging, wouldn't it? I found a bug report on the GHC Trac [1] in which Simon explains the

Re: Unpack primitive types by default in data

On 17/02/2012 00:25, Johan Tibell wrote: Hi all, I've been thinking about this some more and I think we should definitely unpack primitive types (e.g. Int, Word, Float, Double, Char) by default. Why only primitive types? I think you probably want to do it for any type that unpacks to a singl

Re: Removal of #include from template-hsc.h breaks largefile support on 32bit Linux

or something to "blow up", the typechecker will catch any discrepancies. Perhaps I don't understand what problem you're thinking of - can you give more detail? Cheers, Simon John On Fri, Feb 17, 2012 at 4:23 AM, Simon Marlow wrote: On 16/02/2012 13:25,

Re: Understanding the -A and the -H flags

On 25/02/2012 16:51, Johan Tibell wrote: Hi! I'm trying to understand the interaction between the -A and -H RTS flags. The documentation at http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/runtime-control.html says that if you use -H (with or without an argument) it implicitly implies

Re: Removal of #include from template-hsc.h breaks largefile support on 32bit Linux

On 17/02/2012 22:51, John Meacham wrote: On Fri, Feb 17, 2012 at 2:12 PM, Simon Marlow wrote: On 17/02/12 19:36, John Meacham wrote: It isn't local to a file though because it changes the ABI, for instance void foo(off_t *x); it will blow up if called from a file with a differently

Re: Unpack primitive types by default in data

On 17/02/2012 20:10, Johan Tibell wrote: nofib probably has, to a first approximation, zero strictness annotations. Because most of the programs in there predate the addition of strictness annotations to Haskell. That's good for us. In what way? The nofib programs have no strictness annot

Re: parallelizing ghc

On 17/02/2012 18:12, Evan Laforge wrote: Sure, except that if the server is to be used by multiple clients, you will get clashes in the PIT when say two clients both try to compile a module with the same name. The PIT is indexed by Module, which is basically the pair (package,modulename), and th

Re: Understanding the -A and the -H flags

On 27/02/2012 17:34, Johan Tibell wrote: Hi Simon, On Mon, Feb 27, 2012 at 12:25 AM, Simon Marlow wrote: "Think of -Hsize as a variable -A option. It says: I want to use at least size bytes, so use whatever is left over to increase the -A value." Doesn't that describe exactl

Re: Unpack primitive types by default in data

On 17/02/2012 18:34, Johan Tibell wrote: On Fri, Feb 17, 2012 at 3:13 AM, Roman Leshchinskiy wrote: True, I didn't phrase that right at all. AFAIK, in Java, there is a one-to-one correspondence between a primitive type and its boxed version. So you can say that boxed integers will be unboxed w

Re: ghci 7.4.1 no longer loading .o files?

On 21/02/2012 04:57, Evan Laforge wrote: On Mon, Feb 20, 2012 at 8:33 PM, Evan Laforge wrote: On Mon, Feb 20, 2012 at 1:14 AM, Eugene Crosser wrote: On 02/20/2012 10:46 AM, Evan Laforge wrote: Is there something that changed in 7.4.1 that would cause it to decide to interpret .hs files inste

Re: ghci 7.4.1 no longer loading .o files?

On 27/02/2012 05:08, Evan Laforge wrote: Indeed it was, I initially thought it wasn't because I wasn't using flags for either, but then I remember ghci also picks up flags from ~/.ghci. Turns out I was using -fno-monomorphism-restriction because that's convenient for ghci, but not compiling with

Re: New STM?

On 17/02/2012 18:36, wren ng thornton wrote: Hello all, I had some patches committed to STM a while back[1], and for some reason I was expecting them in the new GHC release. Does STM only ship with the Platform? If not, then any idea when the next version of STM will be released? Thanks for th

Re: recent changes to hsc2hs break wrapping c++

On 18/02/2012 05:22, Evan Laforge wrote: On Thu, Feb 16, 2012 at 4:27 AM, Simon Marlow wrote: I'm not sure why you're using the C++ compiler from hsc2hs, and I don't think that is guaranteed to work. But maybe we can fix it if there's a legitimate reason to want it. Well

Re: Installing binary tarball fails on Linux

On 23/02/2012 21:24, Johan Tibell wrote: Hi, I tried to install the GHC 7.4.1 32-bit binary tarball today and ran into the error below. Are 32-bit GHC's not supported on 64-bit Linuxes? The error: Installing library in /usr/local/lib/ghc-7.4.1/ghc-prim-0.2.0.0 ghc-cabal: Bad interface file: di

Re: parallel build fixes for 7.4.2

On 24/02/2012 08:16, Conrad Parker wrote: Hi, recently we've been tweaking our internal build system at Tsuru to handle parallel builds of both cabal packages via 'cabal-sort --makefile' and our local code tree via 'ghc -M'. In addition to the recompilation checker fixes of #5878, the following

Re: Increasing number of worker tasks in RTS (GHC 7.4.1) - how to debug?

On 26/02/2012 02:23, Sanket Agrawal wrote: I have to take back what I said about the increase in worker tasks being related to some Mac OS pthread bug. I can now reproduce the issue on Linux (Redhat x86_64) too (and cause a segmentation fault once in a while). So, now, it seems the issue might be

Re: Enormous FFI speedup observed

On 27/02/2012 10:46, Joachim Breitner wrote: Hi, as I wrote on http://www.joachim-breitner.de/blog/archives/546-GHC-7.4.1-speeds-up-arbtt-by-a-factor-of-22.html I observe an enormous speed up (22×) in arbtt, and it seems to be related to FFI function calls. The release notes do not give a hint w

Re: Understanding the -A and the -H flags

On 28/02/2012 15:59, Johan Tibell wrote: On Tue, Feb 28, 2012 at 12:57 AM, Simon Marlow wrote: Ah, so I see where your confusion arises - this assumption is not true in general. Just discard the assumption, and I think everything will make more sense. Picking a size for -A around the L2

Re: Unpack primitive types by default in data

On 28/02/2012 15:56, Johan Tibell wrote: On Tue, Feb 28, 2012 at 1:11 AM, Simon Marlow wrote: I think there are some in GHC - I've been surprised occasionally when adding an UNPACK makes things worse. I just realized that there is a failure mode I didn't quite consider: havin

Re: Unpack primitive types by default in data

On 29/02/2012 16:17, Johan Tibell wrote: On Wed, Feb 29, 2012 at 2:08 AM, Simon Marlow mailto:marlo...@gmail.com>> wrote: (I think you meant "record", not "field" in the last sentence, right?) I did mean record, but I wasn't being very clear. Let me try aga

Re: ghci 7.4.1 no longer loading .o files?

work with older versions of GHC. (does anyone have some .ghci magic for doing conditional compilation?) Furthermore, I'm shortly going to push a patch that will add an indication of why modules are being recompiled. Here's the log message: commit 27d7d930ff8741f980245da1b895ceaa529

Re: ghci 7.4.1 no longer loading .o files?

On 02/03/2012 04:21, Evan Laforge wrote: On Tue, Feb 28, 2012 at 1:53 AM, Simon Marlow wrote: I don't see how we could avoid including -D, since it might really affect the source of the module that GHC eventually sees. We've never taken -D into account before, and that was incorrect

Re: Do something with TypecheckedSource during build?

On 02/03/2012 10:48, JP Moresmau wrote: Hello, I know that in 7.4 I can add a Core transformation plugin, but I didn't find in the doc if there was a way to do what I'd like to. I don't really want to go as far as Core, I think. What I do at the moment is that I use the GHC API to get to the poin

Re: Why I Want Global Field Names (By Default)

On 05/03/2012 11:06, AntC wrote: Gershom Bazerman gmail.com> writes: ... If everyone finds this agreeable (and I can imagine no reason they wouldn't!) ... That's a misleading remark: you're asking people to agree to a half-baked and sketchy proposal. I wonder if we might all st

Re: Glasgow-haskell-users Digest, Vol 103, Issue 4

On 02/03/12 23:03, Iain Alexander wrote: On 1 Mar 2012 at 14:15, Simon Marlow wrote: does anyone have some .ghci magic for doing conditional compilation? Do you mean something like the attached? Yes! Cheers, Simon HTH, Iain. The following section of this message contains a

Re: How unsafe are unsafeThawArray# and unsafeFreezeArray#

On 09/03/2012 01:13, Johan Tibell wrote: Hi, I just ran across some code that calls unsafeThawArray#, writeArray#, and unsafeFreezeArray#, in that order. How unsafe is that? * Is it unsafe in the sense that if someone has a reference to the original Array# they will see the value of that pure

Re: How unsafe are unsafeThawArray# and unsafeFreezeArray#

On 09/03/2012 11:44, John Meacham wrote: Out of curiosity, Is the reason you keep track of mutable vs not mutable heap allocations in order to optimize the generational garbage collector? as in, if a non-mutable value is placed in an older generation you don't need to worry about it being updated

Re: Boxed foreign prim

On 09/03/2012 04:12, Edward Kmett wrote: I'm currently working with a lot of very short arrays of fixed length and as a thought experiment I thought I would try to play with fast numeric field accessors In particular, I'd like to use something like foreign prim to do something like > foreign i

Re: Getting the file descriptor of a handle, without closing it

On 11/03/2012 01:31, Volker Wysk wrote: Hi This is an addition to my previous post. This modified version of main seems to work: main = do fd<- unsafeWithHandleFd stdin return putStrLn ("stdin: fd = " ++ show fd) fd<- unsafeWithHandleFd stdout return putStrLn ("stdout: fd =

Re: Boxed foreign prim

On 12/03/2012 14:22, Edward Kmett wrote: On Mon, Mar 12, 2012 at 6:45 AM, Simon Marlow mailto:marlo...@gmail.com>> wrote: But I can only pass unboxed types to foreign prim. Is this an intrinsic limitation or just an artifact of the use cases that have pre

Re: profiling and backtracing blues

On 13/03/2012 21:25, Ranjit Jhala wrote: Hi all, I'm trying to use the nifty backtracing mechanism in GHC 74. AFAICT, this requires everything be built with profiling on), but as a consequence, I hit this: "You can't call hscCompileCoreExpr in a profiled compiler" Any hints on whether

Re: profiling and backtracing blues

the bit that doesn't work with profiling). Cheers, Simon On Mar 14, 2012, at 3:59 AM, Simon Marlow wrote: On 13/03/2012 21:25, Ranjit Jhala wrote: Hi all, I'm trying to use the nifty backtracing mechanism in GHC 74. AFAICT, this requires everything be built with pr

Re: GHCi and line numbers (with ghc-7.4.1)

On 20/03/2012 20:12, Simon Hengel wrote: Hi, ghc --interactive now behaves different in regards to line numbers in error messages than previous versions. They are now incremented with each evaluated expression. $ ghc --interactive -ignore-dot-ghci Prelude> foo :2:1: Not in scop

Re: GHCi and line numbers (with ghc-7.4.1)

On 22/03/2012 11:36, Christopher Done wrote: On 22 March 2012 12:13, Simon Marlow wrote: On 20/03/2012 20:12, Simon Hengel wrote: They are now incremented with each evaluated expression. Why *are* they incremented with each evaluation? Surely the only use for line numbers would be in multi

Re: [saj...@gmail.com: Google Summer of Code: a NUMA wishlist!]

On 26/03/2012 04:25, Sajith T S wrote: Date: Sun, 25 Mar 2012 22:49:52 -0400 From: Sajith T S To: The Haskell Cafe Subject: Google Summer of Code: a NUMA wishlist! Dear Cafe, It's last minute-ish to bring this up (in my part of the world it's still March 25), but graduate students are famously

Re: [saj...@gmail.com: Google Summer of Code: a NUMA wishlist!]

On 27/03/2012 01:14, Sajith T S wrote: Hi Simon, Thanks for the reply. It seems that forwarding the message here was a very good idea! Simon Marlow wrote: -- From a very recent discussion on parallel-haskell [4], we learn that RTS' NUMA support could be improved. The hypothes

Re: [saj...@gmail.com: Google Summer of Code: a NUMA wishlist!]

On 28/03/2012 16:57, Tyson Whitehead wrote: On March 28, 2012 04:41:16 Simon Marlow wrote: Sure. Do you have a NUMA machine to test on? My understanding is non-NUMA machines went away when the AMD and Intel moved away from frontside buses (FSB) and integrated the memory controllers on die

Re: Code review for new primop's CMM code.

On 29/03/2012 05:56, Ryan Newton wrote: Hi all, In preparation for students working on concurrent data structures GSOC(s), I wanted to make sure they could count on CAS for array elements as well as IORefs. The following patch represents my first attempt: https://github.com/rrnewton/ghc/commit

Re: Potential GSoC proposal: Reduce the speed gap between 'ghc -c' and 'ghc --make'

On 02/04/2012 07:37, Mikhail Glushenkov wrote: Hi all, [Hoping it's not too late.] During my work on parallelising 'ghc --make' [1] I encountered a stumbling block: running 'ghc --make' can be often much faster than using separate compile ('ghc -c') and link stages, which means that any paralle

Re: What do the following numbers mean?

On 03/04/2012 00:46, Ben Lippmeier wrote: On 02/04/2012, at 10:10 PM, Jurriaan Hage wrote: Can anyone tell me what the exact difference is between 1,842,979,344 bytes maximum residency (219 sample(s)) and 4451 MB total memory in use (0 MB lost due to fragmentation) I could not find this inform

Re: Invariants for GHC.Event ensureIOManagerIsRunning

On 14/04/2012 04:53, Edward Z. Yang wrote: Hello all, I recently ran into a rather reproduceable bug where I would get this error from the event manager: /dev/null: hClose: user error (Pattern match failure in do expression at libraries/base/System/Event/Thread.hs:83:3-10) The program wa

Re: Another profiling question.

On 17/04/2012 16:22, Herbert Valerio Riedel wrote: Jurriaan Hage writes: from the RTS option -s I get : INIT time0.00s ( 0.00s elapsed) MUT time 329.99s (940.55s elapsed) GCtime 745.91s (751.51s elapsed) RPtime 765.76s (767.76s elapsed) PROF time 359.95

Re: "containing" memory-consuming computations

On 19/04/2012 11:45, Herbert Valerio Riedel wrote: > For the time-dimension, I'm already using functions such as > System.Timeout.timeout which I can use to make sure that even a (forced) > pure computation doesn't require (significantly) more wall-clock time > than I expect it to. Note that tim

Re: default instance for IsString

On 24/04/2012 11:08, Erik Hesselink wrote: On Tue, Apr 24, 2012 at 10:55, Michael Snoyman wrote: On Tue, Apr 24, 2012 at 11:36 AM, Erik Hesselink wrote: On Tue, Apr 24, 2012 at 08:32, Michael Snoyman wrote: Here's a theoretically simple solution to the problem. How about adding a new method

Re: default instance for IsString

On 24/04/2012 14:14, Daniel Peebles wrote: Why are potentially partial literals scarier than the fact that every value in the language could lead to an exception when forced? My thoughts exactly. In this thread people are using the term "safe" to mean "total". We already overload "safe" too

Re: default instance for IsString

On 24/04/2012 15:19, Yitzchak Gale wrote: Simon Marlow wrote: In this thread people are using the term "safe" to mean "total". We already overload "safe" too much, might it be a better idea to use "total" instead? I'm not sure what you'

Re: Potential GSoC proposal: Reduce the speed gap between 'ghc -c' and 'ghc --make'

On 25/04/2012 03:17, Mikhail Glushenkov wrote: Hello Simon, Sorry for the delay. On Tue, Apr 10, 2012 at 1:03 PM, Simon Marlow wrote: Questions: Would implementing this optimisation be a worthwhile/realistic GSoC project? What are other potential ways to bring 'ghc -c' perform

Re: Potential GSoC proposal: Reduce the speed gap between 'ghc -c' and 'ghc --make'

On 25/04/2012 08:57, Simon Marlow wrote: On 25/04/2012 03:17, Mikhail Glushenkov wrote: Hello Simon, Sorry for the delay. On Tue, Apr 10, 2012 at 1:03 PM, Simon Marlow wrote: Questions: Would implementing this optimisation be a worthwhile/realistic GSoC project? What are other potential

Re: Potential GSoC proposal: Reduce the speed gap between 'ghc -c' and 'ghc --make'

On 26/04/2012 23:32, Johan Tibell wrote: On Thu, Apr 26, 2012 at 2:34 PM, Mikhail Glushenkov wrote: Thanks. I'll look into how to optimise .hi loading by more traditional means, then. Lennart is working on speeding up the binary package (which I believe is used to decode the .hi files.) His

Re: Weird behavior of the NonTermination exception

On 03/05/2012 17:14, Bas van Dijk wrote: On 3 May 2012 17:31, Edward Z. Yang wrote: Excerpts from Bas van Dijk's message of Thu May 03 11:10:38 -0400 2012: As can be seen, the putMVar is executed successfully. So why do I get the message: "thread blocked indefinitely in an MVar operation"? G

<    1   2   3   4   5   6   7   8   9   10   >