Re: [ANNOUNCE] GHC 7.10.3 release candidate 1

I'd be keen to see Mac support. How can I help out to test that for 8.0? On Tuesday, November 17, 2015, Ben Gamari wrote: > Richard Eisenberg > writes: > > > On Nov 4, 2015, at 11:12 AM, Peter Trommler < > peter.tromm...@th-nuernberg.de > wrote: > > > >> It looks like a bug to me. > > > > I'm t

Re: Remote GHCi

Hi Simon, While this is an interesting proposal, Haskell for Mac strongly relies on running interpreted code in the same process. I’m using ’dynCompileExpr’ as well as ’hscStmtWithLocation’ and some other stuff. This is quite crucial for some of the interactive functionality. Imagine a game whe

Re: Remote GHCi

I like it. Let me make sure that I've understand this correctly: - While GHC doesn't need to be built with profiling if you want to use profiling in the interpeter, you will need multiple versions of the "server binary" for each way you want to implement. This should be pre

RE: Window build broken

Well the error is correct, it’s just checking against the machine type in the PE spec: IMAGE_FILE_MACHINE_AMD64 0x8664 x64 So somewhere along the line an invalid PE file was generated (or for the wrong architecture). From: Ryan Scott Sent: Wednesday, November 18, 2015 00:44 To: ghc-devs@haskell

Re: Window build broken

Wow, I happened to try building GHC on Windows for the first time ever today, and I also experienced this error :) Interestingly, someone reported a very similar error to this on Trac, but for GHC 7.8.3 [1]. Here's where the error message comes from [2] in Linker.c: static int verifyCOFFHeade

RE: Window build broken

Hi Simon, I’m wondering what environment you’re coming in, is it msys2? The prompt you showed earlier /cygdrive/c/code/HEAD-1$ Looks like cygwin. Tamar From: Simon Peyton Jones Sent: Wednesday, November 18, 2015 00:25 To: David Macek;ghc-devs@haskell.org Subject: RE: Window build broken It sa

RE: Window build broken

I have two builds failing in the same way. One is a branch that is not fully up to date, and doesn’t have acce37f38bc3. So it seems independent of whether that's there or not Simon | -Original Message- | From: Ben Gamari [mailto:b...@well-typed.com] | Sent: 17 November 2015 23:03 | To

RE: Window build broken

It says this: bash$ file libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.0.0.o libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.0.0.o: PE Unknown PE signature 0x742e x86-64 (stripped to external PDB), for MS Windows | -Original Message- | From: David Macek [mailto:david.mace...

Re: Window build broken

Simon Peyton Jones writes: > Sigh. My Windows build is broken. See below. Any ideas? The stage2 > complier in non-interactive mode works ok. It’s just ghci fails. What > does “Not x86_64 PEi386” mean? What can I do to fix? > > I should say that my laptop broke so this is a new Windows machine, >

Re: Window build broken

On 17. 11. 2015 23:31, Simon Peyton Jones wrote: > Sigh. My Windows build is broken. See below. Any ideas? The stage2 > complier in non-interactive mode works ok. It’s just ghci fails. What does > “Not x86_64 PEi386” mean? What can I do to fix? Maybe it's obvious and you already checked, b

Window build broken

Sigh. My Windows build is broken. See below. Any ideas? The stage2 complier in non-interactive mode works ok. It’s just ghci fails. What does “Not x86_64 PEi386” mean? What can I do to fix? I should say that my laptop broke so this is a new Windows machine, presumably with a slightly diffe

Re: Remote GHCi

I've been thinking of these applications before, in the context of cross compilers, and of how to deal with these things as dependencies. Custom error message formatting could be done in the same way as Template Haskell I think, since there appears to be a reasonably well-defined place where these

RE: [commit: ghc] master: Remove PatSynBuilderId (2208011)

I will do it if Matthew doesn't get to it Simon | -Original Message- | From: Ben Gamari [mailto:b...@well-typed.com] | Sent: 17 November 2015 16:41 | To: Simon Peyton Jones; Matthew Pickering | Cc: ghc-devs@haskell.org | Subject: RE: [commit: ghc] master: Remove PatSynBuilderId (220

Re: Remote GHCi

The use-case which I've worked on deals with widget messages. Widgets are stored inside the kernel, and can recieve signals from user code, frontend events etc. To capture messages sent by the user code, the messages are queued in a TChan inside the interpreter environment. Messages from this TCha

Re: Remote GHCi

Simon, As Sumit said, we use dynCompileExpr for core functionality of IHaskell. I am not really sure how the change you are proposing affects that, though. We use dynCompileExpr in several places for evaluation inside the interpreter context: 1. Evaluating a Haskell expression in the interpreter

RE: [commit: ghc] master: Remove PatSynBuilderId (2208011)

Simon Peyton Jones writes: > | I don't think this would work in the case where there are no fields > | initialised? > > Oh yes, silly me. I was thinking that then we wouldn’t need to look at > 'labels' at all, but that's not true. > > Well, at least then I'd replace [PostTc id [FieldLabel] with

Re: Implementation idea for unboxed polymorphic types

At the moment, GHC does not support type families over kind #, but if it did, would this code do the trick https://gist.github.com/vagarenko/077c6dd73cd610269aa9 ? 2015-11-16 22:32 GMT+05:00 Ömer Sinan Ağacan : > > But I don't see why you'd need quoting at constructor calls. Couldn't you > > just

Re: [ANNOUNCE] GHC 7.10.3 release candidate 1

Richard Eisenberg writes: > On Nov 4, 2015, at 11:12 AM, Peter Trommler > wrote: > >> It looks like a bug to me. > > I'm taking your "it" here to mean the fact that GHC is looking for > readelf on a Mac OS platform. I tend to agree -- I was surprised to > see this, but I'm almost-totally cluele

Feature status for GHC 8.0

tldr. Please let us know the status of your patches for GHC 8.0. Hello everyone! You are receiving this message because you responsible for one of the in-flight items on the GHC 8.0 roadmap [1]. As you may know, the release is quickly approaching and we'd like to have final patches up for revi

Re: too many lines too long

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 17/11/15 15:15, Richard Eisenberg wrote: > We have such a thing: > https://ghc.haskell.org/trac/ghc/wiki/Commentary/CodingStyle > > I don't think its widely consulted or respected, though. There are several issues here. (Get rid of tabs v. spaces

Re: Remote GHCi

How does this interact with typechecker plugins? I assume they would still happen in GHC's process. I've also been thinking about designing and implementing a mechanisms where programmers could specify custom pretty-printers for their types, and GHC would use these pretty-printers in error mess

Re: too many lines too long

We have such a thing: https://ghc.haskell.org/trac/ghc/wiki/Commentary/CodingStyle I don't think its widely consulted or respected, though. Richard On Nov 17, 2015, at 5:19 AM, Simon Marlow wrote: > On 13/11/2015 15:01, Jan Stolarek wrote: >> My view on this is: >> >> Firstly, I hate explain

Re: Remote GHCi

CC Daniel Corin, maintainer of hint. On 17/11/2015 11:49, Luite Stegeman wrote: I like this idea, and it overlaps very much with the work that still needs to be done for GHCJSi. I think that for Template Haskell, the restriction that everything has to be marshalled via Binary is not too problema

Re: Further custom type error questions

FWIW: I didn't realise that this kind of example was the point of TypeError being kind-polymorphic, thanks for the clarification.I don't see an easy way of encoding this using the simpler alternative I suggested, so my question is answered. In hindsight, the wiki does already show an example l

Re: Remote GHCi

I like this idea, and it overlaps very much with the work that still needs to be done for GHCJSi. I think that for Template Haskell, the restriction that everything has to be marshalled via Binary is not too problematic, although it'd require a bit of care if Richard's pre-proposal to expose more G

Re: Further custom type error questions

Iavor, Ben, et al.: How about much simpler type family Head (a :: [k]) :: k where Head (x ': xs) = x Head '[] = Error "Empty list" Can this be expressed through Error-as-constraint? On 11/17/2015 02:09 AM, Iavor Diatchki wrote: > Hello, > > I imagine people wanting to do things as in the e

RE: Further custom type error questions

So perhaps you can update the wiki page to give an example like this, and thereby explain the design choice? Or have a FAQ: “why not give TypeErorr the kind String -> Constraint?”. The thought will be lost in email! Simon From: Iavor Diatchki [mailto:iavor.diatc...@gmail.com] Sent: 17 Novembe

Re: Remote GHCi

So the remote GHCi server I had in mind would be too dumb to support this - it would be at a much lower level, with support for linking object code and bytecode and evaluation only. What you probably want for this is a remote interface to the GHC API, similar to what ide-backend provides. Ch

Re: Remote GHCi

I think there will be ways to do what you want in the context of a remote interpreter, but I'll need to understand more about the way in which you use dynCompileExpr. What do you do with the result of dynCompileExpr? Can you run that code in the context of the interpreter instead? Cheers Si

Re: Remote GHCi

Hi Simon, IHaskell makes use of dynCompileExpr to evaluate code provided by the user, so that the result can be sent to the frontend to be displayed. I don't think we can make it work without using dynCompileExpr, Andrew would have more to say about this.

Re: Remote GHCi

This fits in directly with what I am trying to do for the haskell-ide-engine, where the intention is to expose ghci via an asynchronous process with communication via message passing. A bonus would be to have two separate interfaces, one for REPL interaction for the user, the other to be able to q

Re: too many lines too long

On 13/11/2015 15:01, Jan Stolarek wrote: My view on this is: Firstly, I hate explaining myself to Arcanist. When prompted to explain the reason for too long lines I typically enter "wontfix" without thinking too much. Secondly, I really don't like how warnings clutter code reviews. I have my

Remote GHCi

Hi folks - I've been thinking about changing the way we run interpreted code so that it would be run in a separate process. It turns out this has quite a few benefits, and would let us kill some of the really awkward hacks we have in GHC to work around problems that arise because we're running