February 2015 - ghc-devs

ANNOUNCE: GHC 7.10.1 Release Candidate 2
by Austin Seipp 17 Feb '15

17 Feb '15

We are pleased to announce the second release candidate for GHC 7.10.1: https://downloads.haskell.org/~ghc/7.10.1-rc2/ This includes the source tarball and bindists for 64bit/32bit Linux and Windows. Binary builds for other platforms will be available shortly. (CentOS 6.5 binaries are not available at this time like they were for 7.8.x). These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x3B58D86F). We plan to make the 7.10.1 release sometime in February of 2015. Please test as much as possible; bugs are much cheaper if we find them before the release! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

11 17

Resolving Windows 64-bit linker issues
by Darren Grant 17 Feb '15

17 Feb '15

Hi all, I notice there are a series of related long-standing issues subject to particular cygwin64 quirks, and I'd like to offer time to help resolve these if possible At this point I've had some exposure to the GHC build process (7.8.3), and have poked around the GHC linker to gain some low level insight. Would anyone be available to fill me in on the current state of affairs with mingw64 GHCi linking? For instance, is there ongoing work, or perhaps a preferred direction but no available developer bandwidth to proceed? Thank you. Cheers, Darren

5 8

RE: Resolving Windows 64-bit linker issues
by Tamar Christina 17 Feb '15

17 Feb '15

Hi Darren, I'm afraid I don't off the top of my head. I've never had to look at that file yet. On my way to work this morning I was reading up on what mingw64 uses .refptr for. So now I understand at least that part. But I'm afraid I can't offer any advice on how to tackle it in GHC at the moment. Regards, Tamar Sent from my Windows Phone ------------------------------ From: Darren Grant <dedgrant(a)gmail.com> Sent: ‎17/‎02/‎2015 06:57 To: Tamar Christina <lonetiger(a)gmail.com> Cc: Mikolaj Konarski <mikolaj(a)well-typed.com>; Roman Kuznetsov <kuznero(a)gmail.com>; ghc-devs(a)haskell.org; Simon Peyton Jones <simonpj(a)microsoft.com>; David Macek <david.macek.0(a)gmail.com>; kyra <kyrab(a)mail.ru>; Gintautas Miliauskas <gintautas(a)miliauskas.lt>; Martin Foster <martin.e.foster(a)gmail.com> Subject: Re: Resolving Windows 64-bit linker issues Hi Tamar, Thank you for the offer. Do you have any thoughts or advice on approaching changes to the existing PE code in Linker.c? I'm wondering if this was destined to be extended into support for PE+ given the absence of .refptr and $. Cheers, Darren On Mon, Feb 16, 2015 at 9:10 PM, Tamar Christina <lonetiger(a)gmail.com> wrote: > Hi Darren, > > I don’t actually know what the status of these issues are. I think one of > the tasks we had set out to do was actually checking on these tickets and > their progress. > > Gintautas was doing most of the mingw64 build stuff. I don’t know if the > cygwin64 link stuff has been looked at by anyone since I think we’re all > mostly using mingw64. > > I have two issues I’m working on atm, both related to the RTS. But if > there’s anything I can do to help then just let me know. > > Cheers, > Tamar > > *From:* Darren Grant <dedgrant(a)gmail.com> > *Sent:* ‎Tuesday‎, ‎February‎ ‎17‎, ‎2015 ‎06‎:‎02 > *To:* Mikolaj Konarski <mikolaj(a)well-typed.com> > *Cc:* Phyx <lonetiger(a)gmail.com>, Roman Kuznetsov <kuznero(a)gmail.com>, > ghc-devs(a)haskell.org, Simon Peyton Jones <simonpj(a)microsoft.com>, David > Macek <david.macek.0(a)gmail.com>, kyra <kyrab(a)mail.ru>, Gintautas > Miliauskas <gintautas(a)miliauskas.lt>, Martin Foster > <martin.e.foster(a)gmail.com> > > To expand on that (let's see if I can do this without accidentally sending > again, oops!): > > Roman, I will get in touch with you on a separate email thread to see if > we can find an optimal way to coordinate, something that satisfies our > schedules and needs. Others please feel free to bug me any time by email ( > dedgrant(a)gmail.com) or on freenode #ghc as dedgrant, PST hours. > > In the meantime I'll be auditing some of the related backlogged tickets on > trac. If there's something I can do to help further the goal of a Windows > Task Force page, please let me know. > > > Pleased to meet everyone! > > Cheers, > Darren > > > On Mon, Feb 16, 2015 at 8:48 PM, Darren Grant <dedgrant(a)gmail.com> wrote: > >> Thank you kindly for the great introduction. I hope I can be helpful here. >> >> >> On Feb 16, 2015 7:47 AM, "Mikolaj Konarski" <mikolaj(a)well-typed.com> >> wrote: >> >>> Resending, since Roman's and Kyril's email addresses were >>> mangled/missing. >>> >>> On Mon, Feb 16, 2015 at 3:43 PM, Simon Peyton Jones >>> <simonpj(a)microsoft.com> wrote: >>> > Darren >>> > >>> > >>> > >>> > Excellent! We have a Windows Task Force, consisting roughly of the >>> folk in >>> > cc. So they would be the first group to ask. >>> > >>> > >>> > >>> > (I think it would be very helpful to have a Windows Task Force home >>> page, so >>> > that it’s easier to find the group.) >>> > >>> > >>> > >>> > thanks for helping with Windows. >>> > >>> > >>> > >>> > Simon >>> > >>> > >>> > >>> > From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of >>> Darren >>> > Grant >>> > Sent: 15 February 2015 07:36 >>> > To: ghc-devs(a)haskell.org >>> > Subject: Resolving Windows 64-bit linker issues >>> > >>> > >>> > >>> > Hi all, >>> > >>> > >>> > >>> > I notice there are a series of related long-standing issues subject to >>> > particular cygwin64 quirks, and I'd like to offer time to help resolve >>> these >>> > if possible >>> > >>> > At this point I've had some exposure to the GHC build process (7.8.3), >>> and >>> > have poked around the GHC linker to gain some low level insight. >>> > >>> > >>> > >>> > Would anyone be available to fill me in on the current state of >>> affairs with >>> > mingw64 GHCi linking? For instance, is there ongoing work, or perhaps a >>> > preferred direction but no available developer bandwidth to proceed? >>> > >>> > >>> > >>> > Thank you. >>> > >>> > >>> > >>> > Cheers, >>> > >>> > Darren >>> > >>> > >>> >> >

1 0

Anonymous FFI calls
by Francesco Mazzoli 13 Feb '15

13 Feb '15

Hi, I am in a situation where it would be very useful to call C functions without an explicit FFI import. For example, I'd like to be able to do (foreign import ccall "cadd" :: CInt -> CInt -> CInt) 1 2 instead of declaring the foreign import explicitely at the top level. Is there a way to do this or to achieve similar results in some other way? If not, I imagine it would be easy to implement such a facility in GHC, given that the code implementing calling to C functions must already be present to implement "proper" FFI imports. I think such an addition would be useful in many cases. Thanks, Francesco

6 16

What `reify` sees in Template Haskell
by Francesco Mazzoli 13 Feb '15

13 Feb '15

Hi, I recently stumbled upon the issue of `reify` not being able to give information about local variables, as of GHC 7.8. For example, this won't work: foo x = $(do {xInfo <- reify 'x; ...}) The motivation for this change is described here: <https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/BlogPostChanges#PartC…>. While I agree that getting the type of local variables is going to be brittle, I also think that offering that functionality is extremely useful in certain cases, such as in the case of the language-c-inline library, that used this facility to avoid having to type verbose type annotations -- see <https://github.com/mchakravarty/language-c-inline/issues/25>. My two part question is: 1. would it be possible to revert to the old behavior easily, or is doing that difficult or impossible now given the overall changes to the Template Haskell code? 2. if 1, wouldn't it make more sense to allow reifying all names if the user really wants, maybe with a specific `unsafeReify` function or similar? It should be made clear in the docs that by using `unsafeReify` the user is relying on GHC internals (specifically the internals of type checking). Also, I think that post should at least be referenced in the manual, for lack of better documentation. This behavior is not mentioned anywhere else. Thanks, Francesco

3 3

Newcomer question
by Hengchu Zhang 12 Feb '15

12 Feb '15

Hi GHC Devs, I just joined the community and wanted to start contributing/hacking on GHC. I was going through Newcomer's Info tab, and this https://ghc.haskell.org/trac/ghc/ticket/8811 seemed like a good first thing for me to try. A few questions related to git: from the ticket it looks like this bug happens in 7.6.3. From the repo I checked out, there is a tag ghc-7.6.3-release. But I guess I'm not really supposed to checkout the tag and modify the code from there? But running git branch only shows the master branch. So should I run ./sync-all checkout ghc-7.6 and modify the code from that branch? Thank you very much! Best, Hengchu

2 1

GHC Haddock URL
by Andrew Farmer 12 Feb '15

12 Feb '15

Can someone with The Power please symlink (or otherwise redirect) this: https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc to https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc-7.8.4 ... so I can Hoogle with greater ease? Thanks much! Andrew

2 1

Phabricator question
by Iavor Diatchki 12 Feb '15

12 Feb '15

Hello, I followed the instruction on the GHC wiki, and published an `arc` revision for my work on the typeable-with-kinds branch. The result was called D652. After I did this, I noticed a bug, and some redundant code; so I fixed my branch. How can I update D652, so that it will diff using the most current version of my branch? -Iavor

3 2

Re: [Haskell-cafe] Anonymous FFI calls
by Michael Sloan 11 Feb '15

11 Feb '15

It works, cool! So at least this ought to address Francesco's use-case. Is there anything wrong with my code? It definitely looks like a GHC bug. Yes, I've successfully generated instance declarations from the top-level. I may as well describe the usecase: pretty printing a value of any type in GHCI. While this feature list isn't the main point here, it'd be very cool to do things like: * Look up the value of mutable references such as IORefs * Print out functions as just their type * Be able to evaluate particular subtrees of the pretty print output (like present [1]) * Select a subportion of the output and get a variable out of it Usage would look like "$(pretty 'x)". This would reify the type of x and transitively generate `Pretty` instances for things, by using my th-reify-many package [2]. It then generates an expression which invokes `pretty` on `x`, using these new instances. This instance generation can do clever things like check if a type has a "Data" instance, and use it if available. In this way, we can construct a pretty printer for ghci which will work for any type. Certainly, this is still possible without instance generation, but it'd be quite clever to not need to re-generate the pretty printing code for every invocation. -Michael [1] https://github.com/chrisdone/present [2] https://github.com/mgsloan/th-reify-many On Wed, Feb 11, 2015 at 6:51 PM, Geoffrey Mainland <mainland(a)cs.drexel.edu> wrote: > Hi Michael, > > Try this out: > > https://gist.github.com/mainland/f18cf3827c4b0b64b835 > > Have you had success generating instance declarations from top-level > splices? > > Geoff > > On 02/11/2015 07:41 PM, Michael Sloan wrote: >> Hi! >> >> I don't mean to be accusatory with the whole documentation thing - I >> totally understand that most folks have a lot going on! In this >> particular case, I got very excited when I initially saw addTopDecls, >> because it says it allows you to "Add additional top-level >> declarations". After implementing something to use it, I got rather >> disappointed as it couldn't add instances. >> >> So, when I say "not implemented", it's just that the docs say it >> allows you to add additional top-level decls, when you can really only >> add functions, variable bindings, and foreign import decls. >> >> I didn't realize that not re-exporting these functions is due to their >> experimental status. That makes sense! I'm glad it was a conscious >> decision. I just tried writing a demo of addTopDecls, but >> unfortunately using it to add a function and referencing this function >> causes a GHC internal error: >> https://gist.github.com/mgsloan/53d7fa50338c696e5c80 . I haven't >> tried it with a foreign import yet. >> >> -Michael >> >> On Wed, Feb 11, 2015 at 3:51 PM, Geoffrey Mainland >> <mainland(a)cs.drexel.edu> wrote: >>> Typed Template Haskell happened at the end of my tenure at MSR, and >>> there was a mad rush to get it in to the compiler in time for 7.8.3 at >>> the same time I was starting a new job. I'm afraid the documentation is >>> indeed wanting, but the alternative was no typed Template Haskell. >>> >>> One side-effect was that the functions you note as present only in >>> Language.Haskell.TH.Syntax were not thoroughly vetted, so we didn't >>> re-export them from Language.Haskell.TH. >>> >>> I am willing to help with documentation if people want to use this >>> functionality. Has anyone attempted to use addTopDecls? Michael, when >>> you say "it's not implemented," what do you mean? What, exactly, is not >>> implemented? >>> >>> Cheers, >>> Geoff >>> >>> On 2/11/15 6:32 PM, Michael Sloan wrote: >>>> I'd love for the implementation to be as powerful as the documentation >>>> suggests it is :D >>>> >>>> However, yes, in the meantime, fixing the documentation would be great! >>>> >>>> Also, I meant to say that addTopDecls is only exported by >>>> "Language.Haskell.TH.Syntax". While this is a digression, there are a >>>> few other handy functions that are oddly left out of >>>> "Language.Haskell.TH": addDependentFile, addModFinalizer, and possibly >>>> more. >>>> >>>> -Michael >>>> >>>> On Wed, Feb 11, 2015 at 3:25 PM, Simon Peyton Jones >>>> <simonpj(a)microsoft.com> wrote: >>>>> I would LOVE someone to improve the documentation for addTopDecls. Manuel Chakravarty and Geoff Mainland were responsible for the implementation. >>>>> >>>>> Simon >>>>> >>>>> | -----Original Message----- >>>>> | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Michael >>>>> | Sloan >>>>> | Sent: 11 February 2015 23:19 >>>>> | To: Francesco Mazzoli >>>>> | Cc: ghc-devs(a)haskell.org; haskell >>>>> | Subject: Re: [Haskell-cafe] Anonymous FFI calls >>>>> | >>>>> | It seems like addTopDecls[1] will able to help here. Unfortunately, >>>>> | the function is not well documented and not very discoverable because >>>>> | it's only exported by Language.Haskell.TH. >>>>> | >>>>> | The documentation doesn't mention that it can only be used to create >>>>> | new top level functions and FFI imports[2]. I think that adding FFI >>>>> | imports was the main motivation for implementing it. In the past >>>>> | I've wanted to generate instances via this function, but unfortunately >>>>> | it's not implemented.. >>>>> | >>>>> | Hope that helps! >>>>> | -Michael >>>>> | >>>>> | [1] http://hackage.haskell.org/package/template-haskell- >>>>> | 2.9.0.0/docs/Language-Haskell-TH-Syntax.html#v:addTopDecls >>>>> | >>>>> | [2] >>>>> | https://github.com/ghc/ghc/blob/1d982ba10f590828b78eba992e73315dee33f78a/ >>>>> | compiler/typecheck/TcSplice.hs#L818 >>>>> | >>>>> | On Wed, Feb 11, 2015 at 2:26 AM, Francesco Mazzoli <f(a)mazzo.li> wrote: >>>>> | > Hi, >>>>> | > >>>>> | > I am in a situation where it would be very useful to call C functions >>>>> | > without an explicit FFI import. For example, I'd like to be able to do >>>>> | > >>>>> | > (foreign import ccall "cadd" :: CInt -> CInt -> CInt) 1 2 >>>>> | > >>>>> | > instead of declaring the foreign import explicitely at the top level. >>>>> | > >>>>> | > Is there a way to do this or to achieve similar results in some other >>>>> | > way? >>>>> | > >>>>> | > If not, I imagine it would be easy to implement such a facility in GHC, >>>>> | > given that the code implementing calling to C functions must already be >>>>> | > present to implement "proper" FFI imports. I think such an addition >>>>> | > would be useful in many cases. >>>>> | > >>>>> | > Thanks, >>>>> | > Francesco >>>>> | > _______________________________________________ >>>>> | > Haskell-Cafe mailing list >>>>> | > Haskell-Cafe(a)haskell.org >>>>> | > http://www.haskell.org/mailman/listinfo/haskell-cafe >>>>> | _______________________________________________ >>>>> | ghc-devs mailing list >>>>> | ghc-devs(a)haskell.org >>>>> | http://www.haskell.org/mailman/listinfo/ghc-devs >

1 0

Re: [Haskell-cafe] Anonymous FFI calls
by Michael Sloan 11 Feb '15

11 Feb '15

Hi! I don't mean to be accusatory with the whole documentation thing - I totally understand that most folks have a lot going on! In this particular case, I got very excited when I initially saw addTopDecls, because it says it allows you to "Add additional top-level declarations". After implementing something to use it, I got rather disappointed as it couldn't add instances. So, when I say "not implemented", it's just that the docs say it allows you to add additional top-level decls, when you can really only add functions, variable bindings, and foreign import decls. I didn't realize that not re-exporting these functions is due to their experimental status. That makes sense! I'm glad it was a conscious decision. I just tried writing a demo of addTopDecls, but unfortunately using it to add a function and referencing this function causes a GHC internal error: https://gist.github.com/mgsloan/53d7fa50338c696e5c80 . I haven't tried it with a foreign import yet. -Michael On Wed, Feb 11, 2015 at 3:51 PM, Geoffrey Mainland <mainland(a)cs.drexel.edu> wrote: > Typed Template Haskell happened at the end of my tenure at MSR, and > there was a mad rush to get it in to the compiler in time for 7.8.3 at > the same time I was starting a new job. I'm afraid the documentation is > indeed wanting, but the alternative was no typed Template Haskell. > > One side-effect was that the functions you note as present only in > Language.Haskell.TH.Syntax were not thoroughly vetted, so we didn't > re-export them from Language.Haskell.TH. > > I am willing to help with documentation if people want to use this > functionality. Has anyone attempted to use addTopDecls? Michael, when > you say "it's not implemented," what do you mean? What, exactly, is not > implemented? > > Cheers, > Geoff > > On 2/11/15 6:32 PM, Michael Sloan wrote: >> I'd love for the implementation to be as powerful as the documentation >> suggests it is :D >> >> However, yes, in the meantime, fixing the documentation would be great! >> >> Also, I meant to say that addTopDecls is only exported by >> "Language.Haskell.TH.Syntax". While this is a digression, there are a >> few other handy functions that are oddly left out of >> "Language.Haskell.TH": addDependentFile, addModFinalizer, and possibly >> more. >> >> -Michael >> >> On Wed, Feb 11, 2015 at 3:25 PM, Simon Peyton Jones >> <simonpj(a)microsoft.com> wrote: >>> I would LOVE someone to improve the documentation for addTopDecls. Manuel Chakravarty and Geoff Mainland were responsible for the implementation. >>> >>> Simon >>> >>> | -----Original Message----- >>> | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Michael >>> | Sloan >>> | Sent: 11 February 2015 23:19 >>> | To: Francesco Mazzoli >>> | Cc: ghc-devs(a)haskell.org; haskell >>> | Subject: Re: [Haskell-cafe] Anonymous FFI calls >>> | >>> | It seems like addTopDecls[1] will able to help here. Unfortunately, >>> | the function is not well documented and not very discoverable because >>> | it's only exported by Language.Haskell.TH. >>> | >>> | The documentation doesn't mention that it can only be used to create >>> | new top level functions and FFI imports[2]. I think that adding FFI >>> | imports was the main motivation for implementing it. In the past >>> | I've wanted to generate instances via this function, but unfortunately >>> | it's not implemented.. >>> | >>> | Hope that helps! >>> | -Michael >>> | >>> | [1] http://hackage.haskell.org/package/template-haskell- >>> | 2.9.0.0/docs/Language-Haskell-TH-Syntax.html#v:addTopDecls >>> | >>> | [2] >>> | https://github.com/ghc/ghc/blob/1d982ba10f590828b78eba992e73315dee33f78a/ >>> | compiler/typecheck/TcSplice.hs#L818 >>> | >>> | On Wed, Feb 11, 2015 at 2:26 AM, Francesco Mazzoli <f(a)mazzo.li> wrote: >>> | > Hi, >>> | > >>> | > I am in a situation where it would be very useful to call C functions >>> | > without an explicit FFI import. For example, I'd like to be able to do >>> | > >>> | > (foreign import ccall "cadd" :: CInt -> CInt -> CInt) 1 2 >>> | > >>> | > instead of declaring the foreign import explicitely at the top level. >>> | > >>> | > Is there a way to do this or to achieve similar results in some other >>> | > way? >>> | > >>> | > If not, I imagine it would be easy to implement such a facility in GHC, >>> | > given that the code implementing calling to C functions must already be >>> | > present to implement "proper" FFI imports. I think such an addition >>> | > would be useful in many cases. >>> | > >>> | > Thanks, >>> | > Francesco >>> | > _______________________________________________ >>> | > Haskell-Cafe mailing list >>> | > Haskell-Cafe(a)haskell.org >>> | > http://www.haskell.org/mailman/listinfo/haskell-cafe >>> | _______________________________________________ >>> | ghc-devs mailing list >>> | ghc-devs(a)haskell.org >>> | http://www.haskell.org/mailman/listinfo/ghc-devs >

1 0