RE: Multiple imports on single line

you can do it today: import Foo; import Bar; import Baz you do have to repeat the ‘import’ though S From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of eng. Vassil Ognyanov Keremidchiev Sent: 31 July 2014 23:25 To: ghc-devs@haskell.org Subject: Multiple imports on single line H

Multiple imports on single line

Hello, dear GHC developers! Is it possible to add such constructions in next GHCs: import Data.List, Data.Array, Data.Aeson, Network.HTTP.Conduit on a single line. This will simplify source code and clear the space before the actual code. Best regards, Vassil Keremidchiev

Re: pthread.h missing

Not strange at all as pthread isn't included in the mingw toolchain (it is on Win64, but it doesn't know to link in pthread there). There's no easy fix. Other than setting it to expected failure, of course. Niklas 2014-07-31 22:56 GMT+02:00 Simon Peyton Jones : > On Windows rts/T8124 is faili

pthread.h missing

On Windows rts/T8124 is failing thus: T8124_c.c:4:21: fatal error: pthread.h: No such file or directory compilation terminated. *** unexpected failure for T8124(threaded1) Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/m

Haskell Platform 2014.2.0.0 Release Candidate 3

Small update to the Haskell Platfrom 2014.2.0.0 release: We have new Release Candidate 3 versions of the source tarball... and a new generic-linux bindist of the platform! - source tarball: haskell-platform-2014.2.0.0-srcdist-RC3.tar.gz

Re: Forcing apps to collect GC stats?

Right, so if you look in ./includes/rts/Flags.h, you'll see a set of different options for the GC stats: #define NO_GC_STATS 0 #define COLLECT_GC_STATS 1 #define ONELINE_GC_STATS 2 #define SUMMARY_GC_STATS 3 #define VERBOSE_GC_STATS 4 By default the RTS sets the stats flag to NO_GC_STATS, wh

Re: Forcing apps to collect GC stats?

On Thu, Jul 31, 2014 at 6:55 PM, Austin Seipp wrote: > And also, take note the conditional is very specific; you want > COLLECT_GC_STATS only when NO_GC_STATS is the current setting - if you > unconditionally force COLLECT_GC_STATS, then things like `+RTS > -sstderr -RTS` will no longer work. I me

Re: Forcing apps to collect GC stats?

We already have GHC.Stats. It would be nice if it was put there. On Thu, Jul 31, 2014 at 6:55 PM, Austin Seipp wrote: > The 'safe' mark was just an oversight from me - I don't really think > it matters, considering it's only called once at startup anyway. > Similarly I imagine the oversight is ne

Re: Forcing apps to collect GC stats?

The 'safe' mark was just an oversight from me - I don't really think it matters, considering it's only called once at startup anyway. Similarly I imagine the oversight is negligible in the Criterion or ekg case. And also, take note the conditional is very specific; you want COLLECT_GC_STATS only w

Re: Forcing apps to collect GC stats?

Indeed. I filed a bug earlier today to make use of this. On Thu, Jul 31, 2014 at 6:15 PM, Edward Kmett wrote: > Interesting. > > I suppose ekg could also (ab)use this. > > Johan? > > -Edward > > > On Thu, Jul 31, 2014 at 5:51 AM, Simon Marlow wrote: >> >> Hey Bryan, >> >> Sorry for the delay. >>

Re: Forcing apps to collect GC stats?

Interesting. I suppose ekg could also (ab)use this. Johan? -Edward On Thu, Jul 31, 2014 at 5:51 AM, Simon Marlow wrote: > Hey Bryan, > > Sorry for the delay. > > > On 15/07/14 01:57, Bryan O'Sullivan wrote: > >> I spent a bit of time over the weekend trying to figure out how to force >> the

Re: Changing the -package dependency resolution algorithm

> We need to rethink the shadowing behaviour. It is designed to handle > the case where we have the same PackageId (name + version) in two > different DBs (e.g. global and local). Shadowing takes the topmost one > of these (e.g. local, or rightmost -package-db flag). We can relax this > requ

RE: A couple of GHC-API questions

| 1. The docs say that annotations can only be applied to top-level | binders/declarations. We’ve found it *very* helpful to annotate nested | binders in some cases to reduce the inference burden (it’s also | extremely helpful for debugging the code/spec). Is this restriction in | place because of

The build is broken: docs/users_guide/users_guide.xml

Hi there, I have dblatex installed on my builders that makes them failing for the last few days, e.g. [1]. The cause of the failure is this: "/usr/local/bin/dblatex" -P 'filename.as.url=0' docs/users_guide/users_guide.xml --ps -o docs/users_guide/users_guide.ps [..] Build users_guide.ps latex fa

Re: [commit: ghc] master: rts: add Emacs 'Local Variables' to every .c file (39b5c1c)

On Thu, Jul 31, 2014 at 01:03:47PM +0200, Alexander Berntsen wrote: > for those of us who use the improved editor of the beast: > This only seems to work if you're starting a new vim instance inside of the directory, the vimrc in the directo

RE: Overlapping and incoherent instances

| My proposal is to have just one pragma, e.g. OVERLAP, that allows | overlap in either direction. But if you have examples whether the | extra sophistication introduced by a separation into OVERLAPPABLE and | OVERLAPPING is needed, I am happy to go along... Great! As you'll see the proposal, "O

Re: [commit: ghc] master: rts: add Emacs 'Local Variables' to every .c file (39b5c1c)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 31/07/14 11:37, Herbert Valerio Riedel wrote: > https://www.gnu.org/software/emacs/manual/html_node/emacs/Directory-Variables.html And > for those of us who use the improved editor of the beast:

Re: Forcing apps to collect GC stats?

Hey Bryan, Sorry for the delay. On 15/07/14 01:57, Bryan O'Sullivan wrote: I spent a bit of time over the weekend trying to figure out how to force the RTS to collect GC statistics, but was unable to do so. I'm currently working on enriching criterion's ability to gather data, among which I'd

Re: [commit: ghc] master: rts: add Emacs 'Local Variables' to every .c file (39b5c1c)

On 31/07/14 10:37, Herbert Valerio Riedel wrote: Hello Simon, On 2014-07-31 at 10:53:20 +0200, Simon Marlow wrote: [...] rts: add Emacs 'Local Variables' to every .c file This will hopefully help ensure some basic consistency in the forward by overriding buffer variables. I

Re: [commit: ghc] master: rts: add Emacs 'Local Variables' to every .c file (39b5c1c)

Hello Simon, On 2014-07-31 at 10:53:20 +0200, Simon Marlow wrote: [...] >> rts: add Emacs 'Local Variables' to every .c file >> >> This will hopefully help ensure some basic consistency in the forward by >> overriding buffer variables. In particular, it sets the wrap length, the >

Re: [commit: ghc] master: rts: add Emacs 'Local Variables' to every .c file (39b5c1c)

On 28/07/14 15:37, g...@git.haskell.org wrote: Repository : ssh://g...@git.haskell.org/ghc On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/39b5c1cbd8950755de400933cecca7b8deb4ffcd/ghc --- commit 39b5c1cbd

Re: Overlapping and incoherent instances

Now if only we could somehow find a way to do the same thing for AllowAmbiguousTypes. :) I have a 2500 line file that I'm forced to turn on AllowAmbiguousTypes in for 3 definitions, and checking that I didn't accidentally make something else ambiguous to GHC's eyes is a rather brutal affair. (I ca

RE: Overlapping and incoherent instances

Andreas, remember that GHC 7.8 already implements (essentially) the same algorithm. The difference is that 7.8 offers only the brutal -XOverlappingInstances to control it. In your example of the decision you make when writing instance Bla a => Bla [a] vs instance {-# OVERLAPPABLE #-} Bl

Re: Changing the -package dependency resolution algorithm

Sorry for not replying to this earlier. I think after our meeting the other day we agreed to keep the existing algorithm but document it better. Here's a stab at describing the spec: 1. compute the set of valid packages, where a package is valid if - all its dependencies are valid - it is

RE: Overlapping and incoherent instances

Friends, in sending my message below, I should also have sent a link to https://ghc.haskell.org/trac/ghc/ticket/9242#comment:25 Comment 25 describes the semantics of OVERLAPPING/OVERLAPPABLE etc, which I signally failed to do in my message below, leading to confusion in the follow up