Re: How does GHC implement layout?

The history here: several people independently noticed that it might be better to implement the "parse error" part of layout by doing something simpler than full parsing. For example, if we just count brackets in the lexer, then we can handle things like f (case x of y -> z) and if we treat

ApplicativeDo needs a bit of love

Folks, ApplicativeDo does what it does quite well, indeed it's in heavy use doing what we built it for, and I was pleasantly surprised to see that 12% of people would even like it to be enabled by default . But a number of issues have

Re: Recompilation avoidance questions

he places that used it, which David listed in that comment. Cheers Simon > > Ömer > > Simon Marlow , 22 Nis 2020 Çar, 12:02 tarihinde şunu > yazdı: > > > > On Tue, 21 Apr 2020 at 11:38, Ömer Sinan Ağacan > wrote: > >> > >> Hi all, > >> > >

Re: Recompilation avoidance questions

On Tue, 21 Apr 2020 at 11:38, Ömer Sinan Ağacan wrote: > Hi all, > > I'm currently reading the "recompilation avoidance" wiki page [1], and I > have a > few questions about the current design. > > The wiki page says (in the paragraph "Suppose the change to D ...") if a > module > B re-exports x

Re: Object unloading confusion

Hi Omer The point of the heap scan is to find *info pointers* into objects that we want to unload, since we can't unload those. What about static object pointers? Well, those would be found by traversing the static_objects list, which we also do in checkUnload. Except that static_objects doesn't

Re: Confused about PAP object layout

b 2020 Pzt, 13:45 > tarihinde şunu yazdı: > > > > I’m not following this in detail, but do please make sure that the > results of this discussion end up in a suitable Note. Obviously it’s not > transparently clear as-is, and I can see clarity emerging > > > >

Re: Confused about PAP object layout

On Thu, 20 Feb 2020 at 09:21, Ömer Sinan Ağacan wrote: > > I'm not sure what you mean by "garbage". The bitmap merely determines > whether > > a field is a pointer, > > I think the bitmap is for liveness, not for whether a field is pointer or > not. > Relevant code for building an info table for

Re: Confused about PAP object layout

On Fri, 14 Feb 2020 at 11:49, Ömer Sinan Ağacan wrote: > Hi Simon, > > In this code: (slightly simplified) > > StgPtr > scavenge_PAP (StgPAP *pap) > { > evacuate(>fun); > return scavenge_PAP_payload (pap->fun, pap->payload, pap->n_args); > } > > StgPtr >

Re: Feasibility of native RTS support for continuations?

On Mon, 10 Feb 2020 at 08:17, Simon Marlow wrote: > On Mon, 10 Feb 2020 at 08:10, Alexis King wrote: > >> On Feb 6, 2020, at 02:28, Simon Marlow wrote: >> >> The issue here is that raiseAsync is destructive - it *moves* the stack >> to the heap, rather t

Re: Feasibility of native RTS support for continuations?

On Mon, 10 Feb 2020 at 08:10, Alexis King wrote: > On Feb 6, 2020, at 02:28, Simon Marlow wrote: > > The issue here is that raiseAsync is destructive - it *moves* the stack to > the heap, rather than copying it. So if you want to continue execution > where you left off, for sh

Re: Feasibility of native RTS support for continuations?

On Sun, 2 Feb 2020 at 04:26, Alexis King wrote: > I took a stab at implementing this today, using the “continuation is a > stack” implementation strategy I described in my previous email. I > haven’t tried very hard to break it yet, but this tiny test program > works: > > {-# LANGUAGE

Re: Feasibility of native RTS support for continuations?

On Sat, 1 Feb 2020 at 00:23, Alexis King wrote: > > On Jan 30, 2020, at 02:35, Simon Marlow wrote: > > > Also you might want to optimise the implementation so that it doesn't > actually tear down the stack as it copies it into the heap, so that you > could avoid the need

Re: Feasibility of native RTS support for continuations?

My guess is you can almost do what you want with asynchronous exceptions but some changes to the RTS would be needed. There's a bit of code in the IO library that literally looks like this ( https://gitlab.haskell.org/ghc/ghc/blob/master/libraries%2Fbase%2FGHC%2FIO%2FHandle%2FInternals.hs#L175 ):

Re: Bug in SRT generation for procs in .cmm files?

Yes, I think my assumption was that we wouldn't be referring to any CAFs from .cmm source code so we didn't need to track the CAFyness of labels. It would be quite a pain to support this I think - in .cmm you can refer to anything by its raw label, so we would have to either declare whether

Re: Code generation/SRT question

But if so, can you cast your > question more precisely in terms of which lines of the wiki page or Note > are you asking about? And let’s make sure that the appropriate bit gets > updated when you’ve nailed the answer > > > > > > > > Simon > > > > &

Re: Code generation/SRT question

gt; its SRT. > > ·If f is top level, and calls itself, there is no need to include > a pointer to f’s closure in f’s own SRT. > > I think this last point is the one you are asking, but I’m not certain. > > All this should be written down somewhere, and perhaps is. But

Re: Code generation/SRT question

There's no need to set the srt field of f_info if f_closure is the SRT, since any reference to f_info in the code will give rise to a reference to f_closure in the SRT corresponding to that code fragment. Does that make sense? The use of a closure as an SRT is really quite a nice optimisation

Re: Parser performance: 10% regression in 8.8

/happy/pull/134 > 2. Release a new ‘happy’ > 3. (Optional) Specify in GHC’s build system that it builds only with the > latest 'happy' release > 4. Restore the --coerce option in GHC’s build system ‘happy’ configuration > 5. Backport it to the ghc-8.8 branch > > I have no access to do

Re: Why not short out IND_STATICs in the GC?

On Sat, 27 Apr 2019 at 07:44, Ömer Sinan Ağacan wrote: > Hi Simon, > > I'm wondering why in the GC we don't short out IND_STATICs like we do in > INDs > and BLACKHOLEs. Is there a reason for that? In this code in evacuate(): > > case IND_STATIC: >

Re: Proposal: Don't read environment files by default

On Sun, 7 Apr 2019 at 16:57, Oleg Grenrus wrote: > > On 7.4.2019 17.21, Simon Marlow wrote: > > As I understand it, the aim is to support workflows like "cabal > > install $pkg; ghci" (amongst other things). This currently works with > > 'cabal install' b

Re: Proposal: Don't read environment files by default

I've also been surprised (not in a good way) by environment files. But I haven't followed all the discussion so I still have some questions. As I understand it, the aim is to support workflows like "cabal install $pkg; ghci" (amongst other things). This currently works with 'cabal install'

Re: How do I find out which info table a continuation belongs to?

I believe this is due to https://phabricator.haskell.org/D4722 (cc Sergei Azovskov) I'm a bit surprised that gdb isn't showing anything though, it should know that the address corresponds to a temporary symbol like `.L1234`. Perhaps you need to compile with -g to make this work, I'm not sure.

Re: [GHC DevOps Group] Welcome to GitLab!

Congrats Ben and co! This is a huge step forwards. On Thu, 27 Dec 2018 at 06:27, Ben Gamari wrote: > > git remote set-url origin https://gitlab.haskell.org/ghc/ghc.git > git remote set-url --push origin g...@gitlab.haskell.org:ghc/ghc > > This is all that should be necessary; a quick

Re: [GHC DevOps Group] GitLab migration status

Hi Ben - this sounds good, a couple of questions: - What about the performance issue we noticed last week? - What will happen to Phabricator diffs that are still mid-review? It would be a shame to have to move them to gitlab and interrupt the review trail. Can't we just shut Phabricator to new

Re: Residency profiles

https://phabricator.haskell.org/D5428 On Sun, 9 Dec 2018 at 10:12, Sebastian Graf wrote: > Ah, I was only looking at `+RTS --help`, not the users guide. Silly me. > > Am Do., 6. Dez. 2018 um 20:53 Uhr schrieb Simon Marlow >: > >> It is documented! >> https://downlo

Re: Cmm Memory Model (Understanding #15449)

FWIW, my main reference at the time when this stuff was implemented was this page by Doug Lea: http://gee.cs.oswego.edu/dl/jmm/cookbook.html As Ben says, things have evolved a lot since then. I'm not an expert at all, but I know from experience that getting this stuff right is really hard. Even

Re: Residency profiles

It is documented! https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/runtime_control.html#rts-flag--F%20%E2%9F%A8factor%E2%9F%A9 On Thu, 6 Dec 2018 at 16:21, Sebastian Graf wrote: > Hey, > > thanks, all! Measuring with `-A1M -F1` delivers much more reliable > residency numbers. >

Re: [GHC DevOps Group] The future of Phabricator

Nov 2018 at 16:35, Ben Gamari wrote: > Simon Marlow writes: > > > On Fri, 2 Nov 2018 at 08:59, Herbert Valerio Riedel > > wrote: > > > >> On 2018-11-02 at 08:13:37 +, Simon Marlow wrote: > >> > >> > I suppose we can do a squash-

Re: [GHC DevOps Group] The future of Phabricator

On Fri, 2 Nov 2018 at 08:59, Herbert Valerio Riedel wrote: > On 2018-11-02 at 08:13:37 +0000, Simon Marlow wrote: > > > I suppose we can do a squash-merge when committing to keep the history > > clean, but then contributors have a choice - either do GitHub-style > > where

Re: [GHC DevOps Group] The future of Phabricator

: > Simon Marlow writes: > > > I'm entirely happy to move, provided (1) whatever we move to provides the > > functionality we need, and (2) it's clearly what the community wants > > (considering both current and future contributors). In the past when > moving &

Re: Hitting RTS bug on GHC 8.0.2

Looking at the code I can't see how that assertion could possibly fail. Is it reproducible? On Tue, 30 Oct 2018 at 08:38, Harendra Kumar wrote: > Hi, > > I got the following crash in one of my CI tests ( > https://travis-ci.org/composewell/streamly/jobs/448112763): > > test: internal error:

Re: [GHC DevOps Group] The future of Phabricator

I'm entirely happy to move, provided (1) whatever we move to provides the functionality we need, and (2) it's clearly what the community wants (considering both current and future contributors). In the past when moving to GitHub was brought up, there were a handful of core contributors who argued

Re: Treatment of unknown pragmas

What pragma syntax should other Haskell compilers use? I don't think it's fair for GHC to have exclusive rights to the pragma syntax form the report, and other compilers should not be relegated to using {-# X-FOOHC ... #-}. But now we have all the same issues again. Cheers Simon On Thu, 25 Oct

Re: Shall we make -dsuppress-uniques default?

For what it's worth, I put this in my .zshrc cleancore=(-ddump-simpl -dsuppress-coercions -dsuppress-var-kinds -dsuppress-idinfo -dsuppress-type-signatures -dsuppress-type-applications) and then ghc $cleancore -c Foo.hs but this is mainly for the use case of "I wonder if this thing is getting

Re: Why align all pinned array payloads on 16 bytes?

o the given > byte). Is there a use case for this or people mostly use alignment on word > boundaries? > > Ömer > > Sven Panne , 17 Eki 2018 Çar, 10:29 tarihinde şunu > yazdı: > > > > Am Di., 16. Okt. 2018 um 23:18 Uhr schrieb Simon Marlow < > marlo...@gmail.com&g

Re: Treatment of unknown pragmas

On Wed, 17 Oct 2018 at 15:02, Ben Gamari wrote: > Simon Marlow writes: > > > Simon - GHC provides some protection against mistyped pragma names, in > the > > form of the -Wunrecognised-pragmas warning, but only for {-# ... #-} > > pragmas. If tools decide to

Re: Treatment of unknown pragmas

; {- HLINT blah blah -} > > > > GHC will ignore it. HLint can look at it. Simple. > > > > I must be missing something obvious. > > > > Simon > > > > *From:* ghc-devs *On Behalf Of *Simon > Marlow > *Sent:* 16 October 2018 21:44 > *To:

Re: Why align all pinned array payloads on 16 bytes?

I vaguely recall that this was because 16 byte alignment is the minimum you need for certain foreign types, and it's what malloc() does. Perhaps check the FFI spec and the guarantees that mallocForeignPtrBytes and friends provide? Cheers Simon On Thu, 11 Oct 2018 at 18:44, Ömer Sinan Ağacan

Re: Parser.y rewrite with parser combinators

I personally love to hack things up with parser combinators, but for anything longer term where I want a degree of confidence that changes aren't going to introduce new problems I'd still use Happy. Yes it's a total pain sometimes, and LALR(1) is very restrictive, but I wouldn't want to lose the

Re: Treatment of unknown pragmas

I suggested to Neil that he add the {-# HLINT #-} pragma to GHC. It seemed like the least worst option taking into account the various issues that have already been described in this thread. I'm OK with adding HLINT; after all we already ignore OPTIONS_HADDOCK, OPTIONS_NHC98, a bunch of other

Re: Phabricator workflow vs. GitHub

On Fri, 5 Oct 2018 at 15:22, Niklas Hambüchen wrote: > > I think the article is assuming the base for `arc diff` is always the > parent revision, i.e. `arc diff HEAD^`, which is how the workflow works > best. Strangely I don't think the open source Phabricator is set up to do > this by default

Re: Phabricator workflow vs. GitHub

I think the article is assuming the base for `arc diff` is always the parent revision, i.e. `arc diff HEAD^`, which is how the workflow works best. Strangely I don't think the open source Phabricator is set up to do this by default so you have to actually type `arc diff HEAD^` (there's probably

Re: nofib oldest GHC to support?

Typically I never remove any support for older compilers in nofib and the nofib-analyze tool, I just add support for new things. I realise we don't continuously test any of those old versions and thus they can bitrot, but in my experience so far it doesn't happen very often, and it's sometimes

Phabricator workflow vs. GitHub

Here's an interesting blog post relevant to previous discussions about Phabricator / GitHub: https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/?fbclid=IwAR3JyQP5uCn6ENiHOTWd41y5D-U0_CCJ55_23nzKeUYTjgLASHu2dq5QCc0 Yes it's a decidedly pro-Phabricator rant, but it does go into a lot of

Re: Stable name allocation

This looks cleanest > > to me if it can be done easily. > > > > 2. First run the GC if we're low on memory (how?). Then if we need to > > allocate a StableName#, we'll be sure to have room. > > > > > > On Tue, Sep 25, 2018 at 6:25 AM, Simon Marlow >

Re: isAlive() too conservative -- does it cause leaks?

On 19 July 2018 at 11:09, Ömer Sinan Ağacan wrote: > Hi Simon, > > Currently isAlive considers all static closures as being alive. The code: > > // ignore static closures > // > // ToDo: This means we never look through IND_STATIC, which means > // isRetainer needs to handle the

Re: Write barrier for stack updates?

Hi Ömer, The write barrier is the function `dirty_STACK()` here: https://phabricator.haskell.org/diffusion/GHC/browse/master/rts%2Fsm%2FStorage.c$1133-1140 If you grep for `dirty_STACK` you'll see it being called everywhere we mutate a STACK, in particular in the scheduler just before running a

Re: Scavenging SRTs in scavenge_one

> call printClosure(0x4200ec9000) > > 0x4200ec9000: STACK > > > > >>> call checkClosure(0x4200ec9000) > > $3 = 4096 -- makes sense, larger than 3277 bytes > > > > So I have a large STACK object, and STACKs can refer to static objects. &g

Re: Loading GHC into GHCi (and ghcid)

On 8 June 2018 at 19:18, Evan Laforge wrote: > On Fri, Jun 8, 2018 at 12:29 AM, Simon Marlow wrote: > > heap profiler for a while. However, I imagine at some point loading > > everything into GHCi will become unsustainable and we'll have to explore > > other strategie

Re: Loading GHC into GHCi (and ghcid)

On 7 June 2018 at 22:25, Evan Laforge wrote: > On Thu, Jun 7, 2018 at 1:47 PM, Simon Marlow wrote: > > For loading large amounts of code into GHCi, you want to add -j +RTS > > -A128m where is the number of cores on your machine. We've found that > > parallel compilat

Re: Loading GHC into GHCi (and ghcid)

On 8 June 2018 at 00:33, Evan Laforge wrote: > On Thu, Jun 7, 2018 at 2:48 PM, Bartosz Nitka wrote: > > What version of GHC are you using? > > There have been some significant improvements like > > https://phabricator.haskell.org/rGHCb8fec6950ad99cbf11cd22698b > 8d5ab35afb828f, > > that only

Re: Why do we prevent static archives from being loaded when DYNAMIC_GHC_PROGRAMS=YES?

There's a technical restriction. The static code would be compiled with the small memory model, so it would have 32-bit relocations for external references, assuming that those references would resolve to something in the low 2GB of the address space. But we would be trying to link it against

Re: Loading GHC into GHCi (and ghcid)

For loading large amounts of code into GHCi, you want to add -j +RTS -A128m where is the number of cores on your machine. We've found that parallel compilation works really well in GHCi provided you use a nice large allocation area for the GC. This dramatically speeds up working with large

Re: revertCAFs and -fexternal-interpreter

Yes, very probably this is a bug. Please file a ticket and assign to me (or better still send a diff!). Cheers Simon On 6 June 2018 at 08:58, Rahul Muttineni wrote: > Hello devs, > > I noticed that in ghc/GHCi/UI.hs, the calls to 'revertCAFs' are made in > the compiler's RTS instead of the

Re: -fghci-leak-check apparently causes many tests to fail

Sorry, only just saw this. -fghci-leak-check is a new flag I added to prevent regressions of the space leak that was fixed in https://phabricator.haskell.org/D4659 If you're seeing errors from this, then we should fix them. Could you open a ticket and assign to me please? Cheers Simon On 1

Re: Scavenging SRTs in scavenge_one

Your explanation is basically right. scavenge_one() is only used for a non-major collection, where we aren't traversing SRTs. Admittedly this is a subtle point that could almost certainly be documented better, I probably just overlooked it. More inline: On 1 May 2018 at 10:26, Ömer Sinan Ağacan

Re: Question about indirectees of BLACKHOLE closures

>> blocked > >> threads. Did I get this right? > >> > >> Secondly, can a BLACKHOLE point to a THUNK? I'd expect no, because we > >> BLACKHOLE > >> a closure when we're done evaluating it (assuming no eager blackholing), > >> and &g

Re: Question about indirectees of BLACKHOLE closures

Added comments: https://phabricator.haskell.org/D4517 On 20 March 2018 at 14:58, Simon Marlow <marlo...@gmail.com> wrote: > Hi Omer, > > On 20 March 2018 at 13:05, Ömer Sinan Ağacan <omeraga...@gmail.com> wrote: > >> Hi, >> >> I've been looking at BLACK

Re: Question about indirectees of BLACKHOLE closures

Hi Omer, On 20 March 2018 at 13:05, Ömer Sinan Ağacan wrote: > Hi, > > I've been looking at BLACKHOLE closures and how the indirectee field is > used > and I have a few questions: > > Looking at evacuate for BLACKHOLE closures: > > case BLACKHOLE: > { >

Re: What does "return" keyword mean in INFO_TABLE_RET declarations?

On 19 March 2018 at 00:53, Rahul Muttineni wrote: > Hi Omer, > > An INFO_TABLE_RET is a frame that "can be returned to" and the return > keyword allows you to provide a name for the value(s) that was(were) > returned to this frame and do something with it if you wish. If you

Re: GHCi recompilation avoidance UI

determine whether the module > will actually be loaded interpreted or compiled. Can someone give me a > clue? > > On Thursday, November 2, 2017 10:21:07 AM EST Simon Marlow wrote: > > On 31 October 2017 at 15:42, David Feuer <da...@well-typed.com> wrote: > > > > &

Re: Bringing some observable sharing to GHCi

Not being able to :print an exception would be quite annoying. Do TypeReps need to be cyclic? Observable sharing can be done with StableName, but that would be a bit pile of hassle in the printer. Maybe exceptions warrant a special case. Cheers Simon On 29 October 2017 at 20:40, David Feuer

Re: GHCi recompilation avoidance UI

On 31 October 2017 at 15:42, David Feuer wrote: > Changes in GHC 8.2.1 lead to a lot of recompilation, because GHCi now > refuses to load optimized > code unless -fobject-code (and optimization flags) are enabled. I propose > the following slight > modification to

Re: Phab: conditional approval

On 19 August 2017 at 03:56, Richard Eisenberg wrote: > Hi devs, > > When reviewing a diff on Phab, I can "accept" or "request changes". > Sometimes, though, I want to do both: I suggest very minor (e.g., typo) > changes, but then when these changes are made, I accept. I'm

Re: GHC Threads affinity

On 10 September 2017 at 04:03, Michael Baikov wrote: > Greetings > > > Currently GHC supports two kinds of threads - pinned to a specific > capability (bound threads) and those it can migrate between any > capabilities (unbound threads). For purposes of achieving lower

Re: GHC staus

One thing for 8.4: there have been a series of performance improvements in ghc --make and GHCi, with some quite dramatic improvements on very large programs (1K+ modules). Bartosz can supply more details. On 3 September 2017 at 14:15, Simon Peyton Jones wrote: > Ben,

Re: GHC staus

I have a vested interest in the cross-compilation story because it's very related to Remote GHCi, so I'd love to join in if you have a discussion about that :) On 4 September 2017 at 11:16, Manuel M T Chakravarty wrote: > +1 for a lighting talk on that! (You can tell the

Re: WordX/IntX wrap Word#/Int#?

On 11 June 2017 at 22:44, Joachim Breitner wrote: > Hi, > > Am Sonntag, den 11.06.2017, 10:44 -0400 schrieb Ben Gamari: > > This is certainly one consideration. Another is that you would also > > need to teach the garbage collector to understand closures with sub- > >

Re: external interpreter failing on Mac

No idea what this is, but just to point out that the continuous build succeeded on OS X at the same revision that you have: https://phabricator.haskell.org/B16186, so this is at least not a universal failure. Something specific to the version of GMP, or some other external tool/library? On 14

Re: Where do I start if I would like help improve GHC compilation times?

Pretty-printing the asm is a likely contender for optimisation, however the problem is not the pretty-printing per se. We don't actually use any of the backtracking stuff when printing asm, since there's no point nicely indenting things or wrapping lines. The overhead is probably all in the

Re: Lazy ST vs concurrency

ks currently under evaluation. But this is a messy solution, I don't like it either. Cheers Simon > Of course this does not guarantee safety. But I think it’d give a > per-thunk way to specify it. > > > > Simon > > > > *From:* Simon Marlow [mailto:marlo...@gmail.c

Re: Lazy ST vs concurrency

at > this is the wrong solution, and pointing to a new ticket to fix it, then OK. > Arguably this isn't all that urgent, given that it's been broken for 8 years or so. > > > Simon > > > > *From:* Simon Marlow [mailto:marlo...@gmail.com] > *Sent:* 31 January 2017

Re: Lazy ST vs concurrency

lease notes etc. to note that the implementation got slower). I think -fatomic-eager-blackholing might "fix" it with less overhead, though. Ben's suggestion: > eagerlyBlackhole :: a -> a is likely to be unreliable I think. We lack the control in the source language to tie it to a

Re: Lazy ST vs concurrency

On 30 January 2017 at 16:18, David Feuer wrote: > I forgot to CC ghc-devs the first time, so here's another copy. > > I was working on #11760 this weekend, which has to do with concurrency > breaking lazy ST. I came up with what I thought was a pretty decent > solution ( >

Re: Next steps of the trac-to-maniphest migration?

On 24 January 2017 at 14:09, Matthew Pickering <matthewtpicker...@gmail.com> wrote: > On Tue, Jan 24, 2017 at 1:26 PM, Simon Marlow <marlo...@gmail.com> wrote: > > > Can we have custom fields with Maniphest? I like the rich metadata we > have > > with OS / A

Re: Next steps of the trac-to-maniphest migration?

ve the wiki, correct? > It is a bit more heavyweight to setup but much easier to get right due > to the structured editing interface which trac doesn't provide for > these kinds of queries. > > Matt > > On Tue, Jan 24, 2017 at 9:41 AM, Simon Marlow <marlo...@gmail.com>

Re: Next steps of the trac-to-maniphest migration?

On 21 January 2017 at 22:21, Matthew Pickering wrote: > Hello devs, > > Thanks to everyone so far who has looked at and commented on the > prototype. It seems that the response is generally positive so I would > like to drive the process forwards. > > In order for

Re: StablePtr / StableName ?

StableNames do use the RTS hash table implementation, but StablePtr does *not*, the ticket is incorrect. But to be clear, nothing has changed - StableName has always used this hash table implementation. No doubt it could be faster if we used a better hash table, but whether it matters to you or

Re: Including remote-iserv upstream?

Absolutely, let's get this code upstream. Just put it up on Phabricator and I'll be happy to review. I recall that we wanted to split up the ghci lib into modules that are compiled with stage0 (the client) and modules compiled with stage1 (the server). Is that a part of your plans? I think it

Re: Navigating GHC proposals

button in your browser. > > > > Seriously? But the rendered proposal is the useful link to send to > people. There _*must_ *be a way, even if its indirect. > > > > Simon > > > > *From:* Simon Marlow [mailto:marlo...@gmail.com] > *Sent:* 09 January 2017 16:03 >

Re: Debugging GHC with GHCi

On 9 January 2017 at 04:51, Ben Gamari wrote: > Thomas Jakway writes: > > > I want to be able to load certain GHC modules in interpreted mode in > > ghci so I can set breakpoints in them. I have tests in the testsuite > > that are compiled by

Re: Navigating GHC proposals

I don't think there is a way to go from the rendered proposal to the pull request, other than the "back" button in your browser. The constraint-vs-type proposal seems a little bit weird in that it actually has a branch in the ghc-proposals repository itself, rather than being a pull request from

Compile GHC with -prof to get a stack trace on panic

I think this has been mentioned before but it's probably not widely known: if you compile GHC profiled (that is, enable GhcProfiled=YES in your mk/ build.mk), then every panic comes with a stack trace. Here's one I just saw: ghc-stage2: panic! (the 'impossible' happened) (GHC version

Re: Making (useful subsets of) bytecode portable between targets

; >>>> > >>>> E.g. Start the runner app on an iPhone plugged in into a USB power > source and leave it there? > >>>> > >>>> Sent from my iPhone > >>>> > >>>>> On 24 Nov 2016, at 12:42 PM, Manuel M T Chakrav

Re: DWARF patches for 8.2

Awesome stuff Ben. I'll try to find some time to review these. On 22 November 2016 at 06:18, Ben Gamari wrote: > Hello fellow DWARF enthusiasts, > > Tonight I finally made something of a breakthrough on the DWARF front; > after finding a small logic error in one of my

Re: T12041 failing?

t; > > *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Simon > Marlow > *Sent:* 09 November 2016 13:03 > *To:* ghc-devs@haskell.org > *Subject:* T12041 failing? > > > > I just saw the error below in a validate with -DDEBUG. Anyone know about > this? >

T12041 failing?

I just saw the error below in a validate with -DDEBUG. Anyone know about this? --- /tmp/ghctest-uhJ8rt/test spaces/./indexed-types/should_fail/T12041.run/T12041.stderr.normalised 2016-11-09 12:13:38.206501840 + +++ /tmp/ghctest-uhJ8rt/test

Re: setnumcapabilities001 failure

> values that are not read from memory after the changes have been made, not > memory effects or data races. > > On Fri, Oct 28, 2016 at 3:02 AM, Simon Marlow <marlo...@gmail.com> wrote: > >> Hi Ryan, I don't think that's the issue. Those variables can only be >> modified

Re: setnumcapabilities001 failure

oop. A failed > requestSync in that loop would not get updated values for those global > pointers. That particular loop isn't doing that optimization for me, but I > think it could happen without volatile. > > Ryan > > On Thu, Oct 27, 2016 at 9:18 AM, Ben Gamari <b.

Re: Linker reorganization

On 28 October 2016 at 02:33, Ben Gamari wrote: > Hello RTS people, > > Today I finally grew frustrated enough with my constant battle with the > 7000 line tangle of CPP that is rts/Linker.c to do something about it. > The result is D2643 through D2650. In short, I took the

Re: Default options for -threaded

On 8 October 2016 at 17:55, Ben Gamari wrote: > loneti...@gmail.com writes: > > > Hi All, > > > > A user on https://ghc.haskell.org/trac/ghc/ticket/11054 has asked why > > -N -qa isn’t the default for -threaded. > > > I'm not sure that scheduling on all of the cores on the

Re: Better X87

I believe that comment goes even further back - it was probably Julian Seward who worked on the x86 code generator around 1999, if I recall correctly. ​ ___ ghc-devs mailing list ghc-devs@haskell.org

Re: Compact regions in users guide

Yes we need some docs. But I expect the API to change before we're done with the implementation (it isn't really usable in its current state), so I'm deferring the docs until things settle down. Cheers Simon On 17 October 2016 at 18:32, Ben Gamari wrote: > Hello Compact

Re: Dataflow analysis for Cmm

On 16 October 2016 at 14:03, Michal Terepeta wrote: > Hi, > > I was looking at cleaning up a bit the situation with dataflow analysis > for Cmm. > In particular, I was experimenting with rewriting the current > `cmm.Hoopl.Dataflow` module: > - To only include the

Re: Master recently broke on OS X

It appears to be passing now. I did commit a sequence of 3 patches, 2 of which should have been squashed together (my bad) and the intermediate builds were broken, but the final state was OK except for a failure in setnumcapabilities001. I'll try to reproduce that one today. Cheers Simon On 18

Re: Improving GHC GC for latency-sensitive networked services

Chris, There are a few things here. - There are different levels of latency-sensitivity. The system I work on at Facebook is latency sensitive and we have no problem with the GC (after we implemented a few optimisations and did some tuning). But we're ok with pauses up to 100ms or so, and our

Re: qualified module export

On 11 October 2016 at 18:04, Iavor Diatchki wrote: > Hello, > > There may be some more thinking to be done on the design of this feature. > In particular, if a module `M` has en export declaration `module T`, this > is not at all the same as adding `import T` in modules

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

a lot simpler. On 1 October 2016 at 21:49, Brandon Allbery <allber...@gmail.com> wrote: > On Sat, Oct 1, 2016 at 4:47 PM, Simon Marlow <marlo...@gmail.com> wrote: > >> A nice trick for dealing with stacked diffs in Phabricator is to use "git >> rebas

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

A nice trick for dealing with stacked diffs in Phabricator is to use "git rebase -i" to modify diffs in the middle of the stack. You can also insert "x arc diff" between lines to automatically update later diffs on Phabricator after a rebase lower down the stack. You only need a single branch

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

Well, let's be careful here. I like the idea, but it's not a complete solution for people who don't want to use arc, because you can't revise a patch after submission in response to reviews, you would have to open a new PR. Perhaps you could build something that would allow revisions to PRs

  1   2   3   4   5   >