Re: A bug of multicore IO manager
Hi Andi, > What sort of workload was the mighty server under during those 1 or 2 days > while you waited for it to become unresponsive. I.e. was this a production > web server? Or were you generating requests at some frequency or leaving it > mostly idle? I ran Mighty on http://mew.org. This is my private domain which provides my free programs and articles. It's not so busy but not so dull. I did not generate requests from measurement tools. --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: A bug of multicore IO manager
Hi Kazu, What sort of workload was the mighty server under during those 1 or 2 days while you waited for it to become unresponsive. I.e. was this a production web server? Or were you generating requests at some frequency or leaving it mostly idle? -Andi On Tue, Sep 3, 2013 at 6:29 PM, Andreas Voellmy wrote: > Kazu, thanks for noticing this! I will try to recreate it on my server as > well. > > -Andi > > > On Tue, Sep 3, 2013 at 5:57 PM, Johan Tibell wrote: > >> Hi Kazu, >> >> On Tue, Sep 3, 2013 at 2:52 PM, Kazu Yamamoto wrote: >> >>> Hi, >>> >>> As I said before, I started running HTTP server using Mio in the real >>> world. Unfortunately, the daemon is not stable. >>> >>> After one day or so, the server cannot accept any HTTP requests. No >>> error messages from the server. >>> >>> The server is alive. To terminate the server (running in a "screen" >>> terminal), single Ctrl-c is not enough. Typing Ctrl-c again terminates >>> the server. >>> >> >> Could you run an strace on the process in this state so we can get an >> idea what it's doing? >> >> >>> After several tests, I'm getting convinced that this occurs only when >>> +RTS -N is specified (where >= 2). The server runs well if +RTS >>> -N is not specified. >>> >> >> That indicates that the problem is with the threaded RTS and perhaps with >> the IO manager. >> >> >>> My question: if the program complied with GHC needs double Ctrl-c to >>> terminate, what is the situation of the program? >>> >> >> If Ctrl+C generates an exception (does it?) there could be an overzealous >> exception catcher somewhere that catches all exceptions, including your >> Ctrl+C. >> >> >>> >>> P.S. >>> >>> It seems to me that the server also is leaking space. The server is >>> getting fatter gradually. >> >> >> Could you use the profiler to see what type of objects are leaking? >> >> >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: A bug of multicore IO manager
Hi Kazu, On Tue, Sep 3, 2013 at 2:52 PM, Kazu Yamamoto wrote: > Hi, > > As I said before, I started running HTTP server using Mio in the real > world. Unfortunately, the daemon is not stable. > > After one day or so, the server cannot accept any HTTP requests. No > error messages from the server. > > The server is alive. To terminate the server (running in a "screen" > terminal), single Ctrl-c is not enough. Typing Ctrl-c again terminates > the server. > Could you run an strace on the process in this state so we can get an idea what it's doing? > After several tests, I'm getting convinced that this occurs only when > +RTS -N is specified (where >= 2). The server runs well if +RTS > -N is not specified. > That indicates that the problem is with the threaded RTS and perhaps with the IO manager. > My question: if the program complied with GHC needs double Ctrl-c to > terminate, what is the situation of the program? > If Ctrl+C generates an exception (does it?) there could be an overzealous exception catcher somewhere that catches all exceptions, including your Ctrl+C. > > P.S. > > It seems to me that the server also is leaking space. The server is > getting fatter gradually. Could you use the profiler to see what type of objects are leaking? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: A bug of multicore IO manager
Kazu, thanks for noticing this! I will try to recreate it on my server as well. -Andi On Tue, Sep 3, 2013 at 5:57 PM, Johan Tibell wrote: > Hi Kazu, > > On Tue, Sep 3, 2013 at 2:52 PM, Kazu Yamamoto wrote: > >> Hi, >> >> As I said before, I started running HTTP server using Mio in the real >> world. Unfortunately, the daemon is not stable. >> >> After one day or so, the server cannot accept any HTTP requests. No >> error messages from the server. >> >> The server is alive. To terminate the server (running in a "screen" >> terminal), single Ctrl-c is not enough. Typing Ctrl-c again terminates >> the server. >> > > Could you run an strace on the process in this state so we can get an idea > what it's doing? > > >> After several tests, I'm getting convinced that this occurs only when >> +RTS -N is specified (where >= 2). The server runs well if +RTS >> -N is not specified. >> > > That indicates that the problem is with the threaded RTS and perhaps with > the IO manager. > > >> My question: if the program complied with GHC needs double Ctrl-c to >> terminate, what is the situation of the program? >> > > If Ctrl+C generates an exception (does it?) there could be an overzealous > exception catcher somewhere that catches all exceptions, including your > Ctrl+C. > > >> >> P.S. >> >> It seems to me that the server also is leaking space. The server is >> getting fatter gradually. > > > Could you use the profiler to see what type of objects are leaking? > > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
A bug of multicore IO manager
Hi, As I said before, I started running HTTP server using Mio in the real world. Unfortunately, the daemon is not stable. After one day or so, the server cannot accept any HTTP requests. No error messages from the server. The server is alive. To terminate the server (running in a "screen" terminal), single Ctrl-c is not enough. Typing Ctrl-c again terminates the server. After several tests, I'm getting convinced that this occurs only when +RTS -N is specified (where >= 2). The server runs well if +RTS -N is not specified. My question: if the program complied with GHC needs double Ctrl-c to terminate, what is the situation of the program? P.S. It seems to me that the server also is leaking space. The server is getting fatter gradually. --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: RE: More windows woe
From: Simon Peyton-Jones
To: "Edward Z. Yang" , Simon Marlow
Cc: "ghc-devs@haskell.org"
Subject: RE: More windows woe
Message-ID:
<59543203684b2244980d7e4057d5fbc1485bb...@db3ex14mbxc308.europe.corp.microsoft.com>
Content-Type: text/plain; charset="utf-8"
Simon Marlow: please help!
At the moment windows builds are hosed, which is a Bad Situation.
Actually it turns out that what want is
debugBelch("Checking whether to unload %S\n", oc->fileName));
That is, use "%S" rather than "%s" as format specifier for wide chars.
Sadly, this works on Windows, but not on Linux:
rts/CheckUnload.c:260:13:
error: format ?%S? expects argument of type ?wchar_t *?, but argument 2
has type ?pathchar *? [-Werror=format]
So what I need guidance on, please!, is what the approved way to deal with this
is. I suppose that I could identify each use of %s on a filepath and say
#ifdef mingw32_HOST_OS
debugBelch("Checking whether to unload %S\n", oc->fileName));
#else
debugBelch("Checking whether to unload %s\n", oc->fileName));
#endif
But that seems deeply unsatisfactory doesn't it?
If not that, then what?
Simon
Similar code is in place to distinguish between 32-bit and 64-bit StgWords:
> grep -r -e FMT_Word includes/
includes/stg/Types.h:#define FMT_Word32"u"
includes/stg/Types.h:#define FMT_Word32"lu"
includes/stg/Types.h:#define FMT_Word64"lu"
includes/stg/Types.h:#define FMT_Word64"llu"
includes/stg/Types.h:#define FMT_Word FMT_Word64
includes/stg/Types.h:#define FMT_Word FMT_Word32
and format strings like "blabla " FMT_Word " ..blabla" are used inside
rts/. One could do the same for FMT_Path and introduce it where required.
Maybe this would be acceptable?
/ Jost
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: New official language extension tokens for GHC 7.8.1
On Mon, Sep 02, 2013 at 07:48:58AM +, Simon Peyton-Jones wrote: > | Which of the language extensions listed in `expectedGhcOnlyExtensions` > | are deemed ready for public consumption in GHC 7.8.1, > > Good question. Here's the list with my comments. We need input from Ian. on > > RelaxedLayout > AlternativeLayoutRule > AlternativeLayoutRuleTransitional > I have no idea about these three. AlternativeLayoutRule* aren't ready. I'm afraid I can't even remember what RelaxedLayout does OTTOMH. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: AMP (#8004) almost finished, review would be nice
Excerpts from David Luposchainsky's message of Tue Sep 03 07:40:38 -0700 2013: > > I don't see any documentation. > > In what sense? More comments, longer function headers? I thought the > names used were clear, with comments giving an overview over longer > sections. (If you're talking about Haddock: the AMP functions are not > exported, hence no HTML docs. tcAmpWarn is called from inside > tcTopSrcDecls in the same module.) It's a command line flag, so the manual needs to be updated to describe it. It also needs to be added to the changelog. Cheers, Edward ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Anyone else failing to validate on 'linker_unload'?
> Ryan, can you do one final thing? When you run that program, be sure > to specify `+RTS -Dl` (must be linked with -debug.) This will enable > all the debug output where the linker is concerned. There will be a > few hundred lines just for initialization (based on my machine.) If my > theory is correct, you'll probably see stuff like 'Unloading object > file ...' right as the invalid read/segfault occurs. Hi Austin, I did this, and it produced a 97MB text file of debug output, the tail end of which was: *initLinker: idempotent return* *lookupSymbol: value of stg_gc_unpt_r1 is 0x485570* *`stg_gc_unpt_r1' resolves to 0x485570Reloc: P = 0x40b510f3 S = 0x485570 A = 0xfffc* *relocations for section 3 using symtab 8* *Rel entry 0 is raw( (nil) 0x80001 (nil)) lookupSymbol: looking up base_ControlziApplicative_zdfApplicativeIO3_info* *initLinker: start* *initLinker: idempotent return* *lookupSymbol: value of base_ControlziApplicative_zdfApplicativeIO3_info is 0x40b51058* *`base_ControlziApplicative_zdfApplicativeIO3_info' resolves to 0x40b51058Reloc: P = 0x40b51100 S = 0x40b51058 A = (nil)* *resolveObjs: done* *lookupSymbol: looking up f* *initLinker: start* *initLinker: idempotent return* *lookupSymbol: value of f is 0x440330c0* *initLinker: start* *initLinker: idempotent return* *unloadObj: Test.o* *Checking whether to unload Test.o* *Unloading object file Test.o* And that's when it segfaulted (notusing valgrind). If it is of any use, here is the full output, which fortunately compresses down to 4.4MB: http://www.cs.indiana.edu/~rrnewton/temp/linker_unload_debug_output.txt.bz2 Best, -Ryan P.S. Here is the equivalent output from the same thing being run under valgrind: initLinker: idempotent return lookupSymbol: value of base_ControlziApplicative_zdfApplicativeIO3_info is 0x4c15058 `base_ControlziApplicative_zdfApplicativeIO3_info' resolves to 0x4c15058Reloc: P = 0x4c15100 S = 0x4c15058 A = (nil) resolveObjs: done lookupSymbol: looking up f initLinker: start initLinker: idempotent return lookupSymbol: value of f is 0x4c0f0c0 initLinker: start initLinker: idempotent return unloadObj: Test.o Checking whether to unload Test.o Unloading object file Test.o ==9030== Invalid read of size 8 ==9030==at 0x492502: checkUnload (CheckUnload.c:286) ==9030==by 0x476580: GarbageCollect (GC.c:666) ==9030==by 0x46ADCD: scheduleDoGC (Schedule.c:1652) ==9030==by 0x46B976: performGC_ (Schedule.c:2551) ==9030==by 0x46B9AE: performMajorGC (Schedule.c:2565) ==9030==by 0x4043E1: main (in /home/beehive/ryan_scratch/ghc-working/testsuite/tests/rts/linker_unload2) ==9030== Address 0x95c4580 is 80 bytes inside a block of size 120 free'd ==9030==at 0x4A063F0: free (vg_replace_malloc.c:446) ==9030==by 0x4656D5: stgFree (RtsUtils.c:107) ==9030==by 0x45DDF4: freeObjectCode (Linker.c:2087) ==9030==by 0x4924CF: checkUnload (CheckUnload.c:295) ==9030==by 0x476580: GarbageCollect (GC.c:666) ==9030==by 0x46ADCD: scheduleDoGC (Schedule.c:1652) ==9030==by 0x46B976: performGC_ (Schedule.c:2551) ==9030==by 0x46B9AE: performMajorGC (Schedule.c:2565) ==9030==by 0x4043E1: main (in /home/beehive/ryan_scratch/ghc-working/testsuite/tests/rts/linker_unload2) ==9030== ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: newtype coercion wrapping status
On Sep 2, 2013, at 5:33 PM, Joachim Breitner wrote: > >> - The changes in Coercion are correct -- the use of Nominal that you >> removed harkened to the days when all CoVars were Nominal. > > Would you prefer to apply these changes to HEAD independently of the > coercion feature? It would keep my patch cleaner. > Done, and pushed. Thanks for bringing this to my attention. Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: AMP (#8004) almost finished, review would be nice
On 2013-09-03 16:19, Simon Peyton-Jones wrote: > Some comments on the code. > Use warnTc or addWarnTc, rather than fiddling with mkPlainWarnMsg > etc. Ditto in checkShouldInst, instead of returning a (Maybe > WarnMsg), just use warnTc inside checkShouldInst. > Why not just getInstEnvs and lookupInstEnv in checkShouldInst, much > as in TcInteract.matchClassInst? Instead you are passing parameters > around that are readily available in the Tc monad. Still getting used to the API, will refactor :-) > Don't use tryTc in tcLookupClassMaybe -- it's a sledgehammer to crack > a nut. The only classes you are looking up are monad, applicative, > alternative, and they will always be found -- or at least if not we > have a problem, and tcLookupClass will rightly report an error. So I > see no need for this tryTc and matching on maybes. The use of tryTc there fixed the problem we (me and Dan) discussed recently on ghc-devs: the testsuite errors with GHC/Base.lhs:1:1: GHC internal error: ‛GHC.Base.Monad’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [] (and the full build errored with "missing interfaces for GHC.Base"). The maybe business fixed this. (Subject of the discussion: "Cannot make ghc: Failed to load interface for GHC.Base") Also note that the Prelude is not necessarily imported, so I think the lookups here can fail regardless of the issue mentioned before. > I don't see any documentation. In what sense? More comments, longer function headers? I thought the names used were clear, with comments giving an overview over longer sections. (If you're talking about Haddock: the AMP functions are not exported, hence no HTML docs. tcAmpWarn is called from inside tcTopSrcDecls in the same module.) > I don't know about this validation stuff; maybe others can help. > Why not *not* add -fno-warn-amp to GcStage1HcOpts? The flag is mysteriously passed to the existing GHC, i.e. it appears when building phase 1. However, the current compiler doesn't know about the flag and fails. (This was my initial attempt.) Thanks for the advice, David/quchen ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: More windows woe
Simon Marlow: please help!
At the moment windows builds are hosed, which is a Bad Situation.
Actually it turns out that what want is
debugBelch("Checking whether to unload %S\n", oc->fileName));
That is, use "%S" rather than "%s" as format specifier for wide chars.
Sadly, this works on Windows, but not on Linux:
rts/CheckUnload.c:260:13:
error: format ‘%S’ expects argument of type ‘wchar_t *’, but argument 2
has type ‘pathchar *’ [-Werror=format]
So what I need guidance on, please!, is what the approved way to deal with this
is. I suppose that I could identify each use of %s on a filepath and say
#ifdef mingw32_HOST_OS
debugBelch("Checking whether to unload %S\n", oc->fileName));
#else
debugBelch("Checking whether to unload %s\n", oc->fileName));
#endif
But that seems deeply unsatisfactory doesn't it?
If not that, then what?
Simon
| -Original Message-
| From: Edward Z. Yang [mailto:ezy...@mit.edu]
| Sent: 28 August 2013 20:59
| To: Simon Peyton-Jones
| Cc: ghc-devs@haskell.org
| Subject: Re: More windows woe
|
| My guess is the printf's need to be replaced with swprintf's.
|
| Edward
|
| Excerpts from Simon Peyton-Jones's message of Wed Aug 28 01:25:26 -0700
| 2013:
| > OK, so now my windows build is getting further, but it now falls over
| here. This one looks more straightforward! Can anyone help?
| >
| > Simon
| >
| > "inplace/bin/ghc-stage1.exe" -optc-Werror -optc-Wall -optc-Wall -optc-
| Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-
| Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-
| Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-
| Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-
| Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-
| ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-
| DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -
| optc-fomit-frame-pointer -optc-fno-omit-frame-pointer -optc-g -optc-O0 -
| optc-DRtsWay=\"rts_debug\" -static -optc-DDEBUG -ticky -DTICKY_TICKY -
| H32m -O -Werror -Wall -H64m -O0 -Iincludes -Iincludes/dist -
| Iincludes/dist-derivedconstants/header -Iincludes/dist-
| ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name
| rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -
| Irts/dist/build -Irts/dist/build/autogen -O2 -O0-c
| rts/CheckUnload.c -o rts/dist/build/CheckUnload.debug_o
| > cc1.exe: warnings being treated as errors
| > rts\CheckUnload.c: In function 'checkUnload':
| >
| > rts\CheckUnload.c:257:7:
| > error: format '%s' expects type 'char *', but argument 2 has type
| 'pathchar *'
| >
| > rts\CheckUnload.c:293:11:
| > error: format '%s' expects type 'char *', but argument 2 has type
| 'pathchar *'
| >
| > rts\CheckUnload.c:297:11:
| > error: format '%s' expects type 'char *', but argument 2 has type
| 'pathchar *'
| > bash-3.1$
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
RE: AMP (#8004) almost finished, review would be nice
David Thanks for doing this. Some comments on the code. * Use warnTc or addWarnTc, rather than fiddling with mkPlainWarnMsg etc. * Ditto in checkShouldInst, instead of returning a (Maybe WarnMsg), just use warnTc inside checkShouldInst. * Don't use tryTc in tcLookupClassMaybe -- it's a sledgehammer to crack a nut. The only classes you are looking up are monad, applicative, alternative, and they will always be found -- or at least if not we have a problem, and tcLookupClass will rightly report an error. So I see no need for this tryTc and matching on maybes. * Why not just getInstEnvs and lookupInstEnv in checkShouldInst, much as in TcInteract.matchClassInst? Instead you are passing parameters around that are readily available in the Tc monad. * I don't see any documentation. I don't know about this validation stuff; maybe others can help. Why not *not* add -fno-warn-amp to GcStage1HcOpts? Simon | 1. Validation does not work due to the warnings issued. Since "sh | validate" uses -Werror, an AMP warning will stop the compilation before | tests can even be run. Unfortunately, the build system seems to use the | variables 'GhcStage1HcOpts' in the build process of phase 1, which is of | course done with the current (7.6.3 or whatever is installed) compiler. | When adding "-fno-warn-amp" to that variable phase 1 won't build because | the parameter is unknown to the old compiler. Is there some sort of | -"ignore next parameter if unknown" hack, or is there a smart solution? | | 2. Temporarily removing the -Werror constraint from validate-settings.mk | (or by using custom-settings.mk) makes the validation build go through. | However, the testsuite defines a couple of violating modules, therefore | there is unexpected STDERR output, hence a handful of tests fail. Should | a fix for this be included in the AMP patch, or be done as a separate | instance? | | 3. Similarly, GHC defines around 50 offending modules, creating warnings | in the standard build process. Again, should this be included, or can we | push that to after the feature freeze and regard it as bugfixing? | | Greetings, | David/quchen | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: extending GHC plugins with Hooks
just a quick heads-up: After discussing with Thomas at ZuriHac I now have a review-ready patch (and a demo program that uses all the hooks) that should do everything Thomas, Edsko and I need, and is extensible if new things come up. I'm still in Switzerland though, and my internet connection is spotty, I'll try to submit it tonight or tomorrow morning luite On Tue, Aug 27, 2013 at 6:18 PM, Thomas Schilling wrote: > I think there are a couple of things that are worth exposing. Looking > at Luite's patch, for example, there are a few that a basic high-level > platform wouldn't solve. A few things an API might reasonably want to > customise: > > - Parse custom flags (when wrapping GHC) > > - Hook into GHC's compilation manager or use one-shot mode and use > Shake as a more flexible compilation manager > > - Foreign function calling conventions (e.g., for GHCJS) > > - Compilation ways (can't think of a good example here) > > - The location of built-in / hardcoded identifiers (i.e., the PrelNames > stuff) > > - How modules are found (Finder) and where they are stored (e.g., > network-backed store, in-memory only) > > - Wrap/Adapt various stages of the > renamer/typechecker/optimiser/codegen. Mostly for IDE tools > (including tools to examine compiler transformations), but custom > backends also need to replace the codegen bits > > - Run custom stages in DriverPipeline or adapt existing ones > (including not running them) > > - Both Lambdachine and GHCJS implement a custom code generator. I > think GHCJS is translating from STG. Lambdachine used to start from > CorePrep, but due to the weird "unarise" stuff I had to switch to > using STG which isn't too bad as it also seems more stable. A custom > code generator requires disabling the "Asm" pass and all subsequent > passes from DriverPipeline > > - I'm not so sure about syntactic extensions. They might be better > implemented using haskell-src-exts and then translated into plain > Haskell > > If we can get these things integrated nicely then it would be > worthwhile to wait another year. > > On 27 August 2013 09:17, Simon Peyton-Jones wrote: > > I’m sympathetic to supporting GHCJS. But, as described in my email, > there > > seems to be several different proposals for extending plugins swirling > > around, and I’m not sure how they relate to each other. > > > > > > > > My suggestion (for you guys to lead J): > > > > · Identify the minimum necessary for GHCJS in 7.8 > > > > · Debate the remaining proposals under less time pressure > > > > > > > > Simon > > > > > > > > From: Carter Schonwald [mailto:carter.schonw...@gmail.com] > > Sent: 23 August 2013 19:36 > > To: Daniel F > > Cc: Simon Peyton-Jones; ghc-devs > > Subject: Re: extending GHC plugins with Hooks > > > > > > > > indeed, ghcjs is one of the things i'm most looking forward to! > > > > That the hooks machinery needed to nicely support GHCJS will enable many > > other use cases is also something i'm excited about too... would be a > shame > > for neither to work with 7.8 > > > > > > > > -Carter > > > > > > > > On Fri, Aug 23, 2013 at 2:09 PM, Daniel F wrote: > > > > Hello > > > > > > > > On Thu, Aug 22, 2013 at 8:13 PM, Simon Peyton-Jones < > simo...@microsoft.com> > > wrote: > > > > Luite, Edsko, Thomas, Nicolas > > > > > > > > You have all variously proposed improvements to the GHC API and/or the > > plug-in mechanism. I have been so swamped in the last few months that I > > have not had a chance to look carefully at your proposals, nor how they > > relate to each other. > > > > > > > > We are now only three weeks away from wanting to do a feature freeze on > GHC > > 7.8, and there are a lot of other things that we want to complete > > > > http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8 > > > > (Mostly they have gestating for some time.) > > > > > > > > So I’m hoping you’ll be ok with not putting these plugin-related changes > > into 7.8. I have the sense that they’d benefit from more discussion > among > > the folk interested in plugins. Perhaps some of the ideas could be > combined > > nicely; I don’t know. And the people who are going to write plugins are > > also probably up for building HEAD anyhow. > > > > > > > > (Exception: Luite, I think you have some fairly narrow, specific changes > > that would help GHCJS, and I’m probably fine with those if you care to > send > > patches.) > > > > > > > > Does this mean that GHCJS patches will be accepted, but it has to use > some > > other mechanism (not Hooks)? > > > > It would be really nice to see ghcjs support in the upcoming GHC. > > > > > > > > > > > > > > Please say if you think there’s a really strong reason for putting stuff > in > > the 7.8. > > > > > > > > Thanks > > > > > > > > Simon > > > > > > > > From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Luite > > Stegeman > > Sent: 21 August 2013 03:51 > > To: ghc-devs > > Subject: extending GHC plugins wit
