From brandon_m_moore at yahoo.com Wed Jul 2 08:19:37 2014 From: brandon_m_moore at yahoo.com (Brandon Moore) Date: Wed, 2 Jul 2014 01:19:37 -0700 Subject: Closed type families, apartness, and occurs check Message-ID: <1404289177.94748.YahooMailNeo@web122105.mail.ne1.yahoo.com> >From the user manual, it sounds like a clause of a closed type family should be rejected once no subsitution of the type could make it unify with the clause. If so, it doesn't seem to do an occurs check: type family IsEq a b :: Bool where ? IsEq a a = True ? IsEq a b = False > :kind! forall a . IsEq a a forall a . IsEq a a :: Bool = forall (a :: k). 'True > :kind! forall a . IsEq a [a] forall a . IsEq a [a] :: Bool = forall a. IsEq a [a] I came across this while trying to using Generics to find the immediate children of a term - this sort of non-reduction happens while comparing a type like (Term var) with a constructor argument of type var. Brandon -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Wed Jul 2 12:11:06 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 2 Jul 2014 08:11:06 -0400 Subject: Closed type families, apartness, and occurs check In-Reply-To: <1404289177.94748.YahooMailNeo@web122105.mail.ne1.yahoo.com> References: <1404289177.94748.YahooMailNeo@web122105.mail.ne1.yahoo.com> Message-ID: <4A7CAE03-A485-4136-A0E2-23A756136A6C@cis.upenn.edu> Hi Brandon, Yes, this is a dark corner of GHC wherein a proper dragon lurks. In your second example, you're suggesting that, for all types `a`, `a` is never equal to `[a]`. The problem is: that's not true! Consider: > type family G x where > G x = [G x] This is a well-formed, although pathological, type family. What should the behavior of `IsEq (G Int) [G Int]` be? The only possible consistent answer is `True`. This is why `IsEq a [a]` correctly does not reduce. For further information, see section 6 of [1] and for a practical example of how this can cause a program error (with open type families) see [2]. [1]: http://www.cis.upenn.edu/~eir/papers/2014/axioms/axioms.pdf [2]: https://ghc.haskell.org/trac/ghc/ticket/8162 It is conceivable that some restrictions around UndecidableInstances (short of banning it in a whole program, including all importing modules) can mitigate this problem, but no one I know has gotten to the bottom of it. Richard On Jul 2, 2014, at 4:19 AM, Brandon Moore wrote: > From the user manual, it sounds like a clause of a closed type family should be rejected once no subsitution of the type could make it unify with the clause. If so, it doesn't seem to do an occurs check: > > type family IsEq a b :: Bool where > IsEq a a = True > IsEq a b = False > > > :kind! forall a . IsEq a a > forall a . IsEq a a :: Bool > = forall (a :: k). 'True > > :kind! forall a . IsEq a [a] > forall a . IsEq a [a] :: Bool > = forall a. IsEq a [a] > > I came across this while trying to using Generics to find the immediate children of a term - this sort of non-reduction happens while comparing a type like (Term var) with a constructor argument of type var. > > Brandon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From brandon_m_moore at yahoo.com Wed Jul 2 13:58:50 2014 From: brandon_m_moore at yahoo.com (Brandon Moore) Date: Wed, 2 Jul 2014 06:58:50 -0700 Subject: Closed type families, apartness, and occurs check In-Reply-To: <4A7CAE03-A485-4136-A0E2-23A756136A6C@cis.upenn.edu> References: <1404289177.94748.YahooMailNeo@web122105.mail.ne1.yahoo.com> <4A7CAE03-A485-4136-A0E2-23A756136A6C@cis.upenn.edu> Message-ID: <1404309530.68322.YahooMailNeo@web122106.mail.ne1.yahoo.com> That was the only thing I worried about, but any examples I tried with families like that ended up with infinite type errors. Infinite types are not meant to be supported, which perhaps gives a solution - the other sensible answer is bottom, i.e. a type checker error or perhaps an infinite loop in the compiler. For instantating with a type family to solve an equation that fails the occurs check, the type family has to be able to already reduce (even if there are some variables), so just adopting the policy that type families be fully expanded before the check would seem to prevent IsEq (G a) [G a] from ever evaulating to true. Brandon On Wednesday, July 2, 2014 7:11 AM, Richard Eisenberg wrote: > > >Hi Brandon, > > >Yes, this is a dark corner of GHC wherein a proper dragon lurks. > > >In your second example, you're suggesting that, for all types `a`, `a` is never equal to `[a]`. The problem is: that's not true! Consider: > > >> type family G x where >> ? G x = [G x] > > >This is a well-formed, although pathological, type family. What should the behavior of `IsEq (G Int) [G Int]` be? The only possible consistent answer is `True`. This is why `IsEq a [a]` correctly does not reduce. > > >For further information, see section 6 of [1] and for a practical example of how this can cause a program error (with open type families) see [2]. > > >[1]:?http://www.cis.upenn.edu/~eir/papers/2014/axioms/axioms.pdf >[2]:?https://ghc.haskell.org/trac/ghc/ticket/8162 > > >It is conceivable that some restrictions around UndecidableInstances (short of banning it in a whole program, including all importing modules) can mitigate this problem, but no one I know has gotten to the bottom of it. > > >Richard > >On Jul 2, 2014, at 4:19 AM, Brandon Moore wrote: > >From the user manual, it sounds like a clause of a closed type family should be rejected once no subsitution of the type could make it unify with the clause. If so, it doesn't seem to do an occurs check: >> >> >>type family IsEq a b :: Bool where >>? IsEq a a = True >>? IsEq a b = False >> >> >> >>> :kind! forall a . IsEq a a >>forall a . IsEq a a :: Bool >>= forall (a :: k). 'True >>> :kind! forall a . IsEq a [a] >>forall a . IsEq a [a] :: Bool >>= forall a. IsEq a [a] >> >> >> >>I came across this while trying to using Generics to find the immediate children of a term - this sort of non-reduction happens while comparing a type like (Term var) with a constructor argument of type var. >> >> >> >>Brandon >>_______________________________________________ >>Glasgow-haskell-users mailing list >>Glasgow-haskell-users at haskell.org >>http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Wed Jul 2 14:01:39 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 2 Jul 2014 10:01:39 -0400 Subject: Closed type families, apartness, and occurs check In-Reply-To: <1404309530.68322.YahooMailNeo@web122106.mail.ne1.yahoo.com> References: <1404289177.94748.YahooMailNeo@web122105.mail.ne1.yahoo.com> <4A7CAE03-A485-4136-A0E2-23A756136A6C@cis.upenn.edu> <1404309530.68322.YahooMailNeo@web122106.mail.ne1.yahoo.com> Message-ID: <12426EB9-F34F-4BDC-AC4F-AC9E8D9B1944@cis.upenn.edu> But that would mean that `IsEq (F a) (F a)` (for some irreducible-for-now `F a`) is stuck, even when we're sure that it will eventually become True. Your approach is perhaps right, but it has negative consequences, too. Richard On Jul 2, 2014, at 9:58 AM, Brandon Moore wrote: > That was the only thing I worried about, but any examples I tried with families like that ended up with infinite type errors. > Infinite types are not meant to be supported, which perhaps gives a solution - the other sensible answer is bottom, i.e. a type checker error or perhaps an infinite loop in the compiler. For instantating with a type family to solve an equation that fails the occurs check, the type family has to be able to already reduce (even if there are some variables), so just adopting the policy that type families be fully expanded before the check would seem to prevent IsEq (G a) [G a] from ever evaulating to true. > > Brandon > > > On Wednesday, July 2, 2014 7:11 AM, Richard Eisenberg wrote: > > > Hi Brandon, > > Yes, this is a dark corner of GHC wherein a proper dragon lurks. > > In your second example, you're suggesting that, for all types `a`, `a` is never equal to `[a]`. The problem is: that's not true! Consider: > > > type family G x where > > G x = [G x] > > This is a well-formed, although pathological, type family. What should the behavior of `IsEq (G Int) [G Int]` be? The only possible consistent answer is `True`. This is why `IsEq a [a]` correctly does not reduce. > > For further information, see section 6 of [1] and for a practical example of how this can cause a program error (with open type families) see [2]. > > [1]: http://www.cis.upenn.edu/~eir/papers/2014/axioms/axioms.pdf > [2]: https://ghc.haskell.org/trac/ghc/ticket/8162 > > It is conceivable that some restrictions around UndecidableInstances (short of banning it in a whole program, including all importing modules) can mitigate this problem, but no one I know has gotten to the bottom of it. > > Richard > > On Jul 2, 2014, at 4:19 AM, Brandon Moore wrote: > >> From the user manual, it sounds like a clause of a closed type family should be rejected once no subsitution of the type could make it unify with the clause. If so, it doesn't seem to do an occurs check: >> >> type family IsEq a b :: Bool where >> IsEq a a = True >> IsEq a b = False >> >> > :kind! forall a . IsEq a a >> forall a . IsEq a a :: Bool >> = forall (a :: k). 'True >> > :kind! forall a . IsEq a [a] >> forall a . IsEq a [a] :: Bool >> = forall a. IsEq a [a] >> >> I came across this while trying to using Generics to find the immediate children of a term - this sort of non-reduction happens while comparing a type like (Term var) with a constructor argument of type var. >> >> Brandon >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stegeman at gmail.com Wed Jul 2 16:14:09 2014 From: stegeman at gmail.com (Luite Stegeman) Date: Wed, 2 Jul 2014 18:14:09 +0200 Subject: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation? Message-ID: hi all, I've added some code [1] [2] to GHCJS to make it run Template Haskell code on node.js, rather than using the GHC linker. GHCJS has supported TH for a long time now, but so far always relied on native (host) code for it. This is the main reason that GHCJS always builds native and JavaScript code for everything (another is that Cabal Setup.hs scripts need to be compiled to some host-runnable form, but that can also be JavaScript if you have node.js) Now besides the compiler having to do twice the work, this has some other disadvantages: - Our JavaScript code has the same dependencies (packages) as native code, which means packages like unix or Win32 show up somewhere, depending on the host environment. This also limits our options in choosing JS-specific packages. - The Template Haskell code runs on the host environment, which might be slightly different from the target, for example in integer size or operating system specific constants. Moreover, building native code made the GHCJS installation procedure more tricky, making end users think about libgmp or libiconv locations, since it basically required the same preparation as building GHC from source. This change will make installing much easier and more reliable (we still have to update the build scripts). How it works is pretty simple: - When any code needs to be run on the target (hscCompileCoreExpr, through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with the thrunner.js [3] script, - GHCJS sends its RTS and the Template Haskell server code [1] to node.js, the script starts a Haskell thread running the server, - for every splice, GHCJS compiles it to JavaScript and links it using its incremental linking functionality. The code for the splice, including dependencies that have not yet been sent to the runner (for earlier splices), is then sent in a RunTH [4] message, - the runner loads and runs the code in the Q monad, can send queries to GHCJS for reification, - the runner sends back the result as a serialized Template Haskell AST (using GHC.Generics for the Binary instances). All Template Haskell functionality is supported, including recent additions for reifying modules and annotations. I still need to clean up and push the patches for the directory and process packages, but after that, the TH code can read/write files, run processes and interact with them and make network connections, all through node.js. Now since this approach is in no way specific to JavaScript, I was wondering if there's any interest in getting this functionality into GHC 7.10 for general cross compilation. The runner would be a native (target) program with dynamic libraries (or object files) being sent over to the target machine (or emulator) for the splices. Thanks to Andras Slemmer from Prezi who helped build the initial proof of concept (without reification) at BudHac. cheers, Luite [1] https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs [2] https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs [3] https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js [4] https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29 -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed Jul 2 18:20:53 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 2 Jul 2014 14:20:53 -0400 Subject: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation? In-Reply-To: References: Message-ID: wow, this is great work! If theres a clear path to getting the generic tooling into 7.10, i'm all for it :) (and willing to help on concrete mechanical subtasks) On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman wrote: > hi all, > > I've added some code [1] [2] to GHCJS to make it run Template Haskell code > on node.js, rather than using the GHC linker. GHCJS has supported TH for a > long time now, but so far always relied on native (host) code for it. This > is the main reason that GHCJS always builds native and JavaScript code for > everything (another is that Cabal Setup.hs scripts need to be compiled to > some host-runnable form, but that can also be JavaScript if you have > node.js) > > Now besides the compiler having to do twice the work, this has some other > disadvantages: > > - Our JavaScript code has the same dependencies (packages) as native code, > which means packages like unix or Win32 show up somewhere, depending on the > host environment. This also limits our options in choosing JS-specific > packages. > - The Template Haskell code runs on the host environment, which might be > slightly different from the target, for example in integer size or > operating system specific constants. > > Moreover, building native code made the GHCJS installation procedure more > tricky, making end users think about libgmp or libiconv locations, since it > basically required the same preparation as building GHC from source. This > change will make installing much easier and more reliable (we still have to > update the build scripts). > > How it works is pretty simple: > > - When any code needs to be run on the target (hscCompileCoreExpr, through > the Hooks API new in GHC 7.8), GHCJS starts a node.js process with the > thrunner.js [3] script, > - GHCJS sends its RTS and the Template Haskell server code [1] to node.js, > the script starts a Haskell thread running the server, > - for every splice, GHCJS compiles it to JavaScript and links it using its > incremental linking functionality. The code for the splice, including > dependencies that have not yet been sent to the runner (for earlier > splices), is then sent in a RunTH [4] message, > - the runner loads and runs the code in the Q monad, can send queries to > GHCJS for reification, > - the runner sends back the result as a serialized Template Haskell AST > (using GHC.Generics for the Binary instances). > > All Template Haskell functionality is supported, including recent > additions for reifying modules and annotations. I still need to clean up > and push the patches for the directory and process packages, but after > that, the TH code can read/write files, run processes and interact with > them and make network connections, all through node.js. > > Now since this approach is in no way specific to JavaScript, I was > wondering if there's any interest in getting this functionality into GHC > 7.10 for general cross compilation. The runner would be a native (target) > program with dynamic libraries (or object files) being sent over to the > target machine (or emulator) for the splices. > > Thanks to Andras Slemmer from Prezi who helped build the initial proof of > concept (without reification) at BudHac. > > cheers, > > Luite > > [1] > https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs > [2] > https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs > [3] > https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js > [4] > https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29 > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Jul 3 00:54:20 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 2 Jul 2014 20:54:20 -0400 Subject: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation? In-Reply-To: References: Message-ID: This would probably be a great boon for those trying to use haskell for Android and IOS right? how might the emulation setup work for those? On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald wrote: > wow, this is great work! > > If theres a clear path to getting the generic tooling into 7.10, i'm all > for it :) (and willing to help on concrete mechanical subtasks) > > > On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman > wrote: > >> hi all, >> >> I've added some code [1] [2] to GHCJS to make it run Template Haskell >> code on node.js, rather than using the GHC linker. GHCJS has supported TH >> for a long time now, but so far always relied on native (host) code for it. >> This is the main reason that GHCJS always builds native and JavaScript code >> for everything (another is that Cabal Setup.hs scripts need to be compiled >> to some host-runnable form, but that can also be JavaScript if you have >> node.js) >> >> Now besides the compiler having to do twice the work, this has some other >> disadvantages: >> >> - Our JavaScript code has the same dependencies (packages) as native >> code, which means packages like unix or Win32 show up somewhere, depending >> on the host environment. This also limits our options in choosing >> JS-specific packages. >> - The Template Haskell code runs on the host environment, which might be >> slightly different from the target, for example in integer size or >> operating system specific constants. >> >> Moreover, building native code made the GHCJS installation procedure more >> tricky, making end users think about libgmp or libiconv locations, since it >> basically required the same preparation as building GHC from source. This >> change will make installing much easier and more reliable (we still have to >> update the build scripts). >> >> How it works is pretty simple: >> >> - When any code needs to be run on the target (hscCompileCoreExpr, >> through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with >> the thrunner.js [3] script, >> - GHCJS sends its RTS and the Template Haskell server code [1] to >> node.js, the script starts a Haskell thread running the server, >> - for every splice, GHCJS compiles it to JavaScript and links it using >> its incremental linking functionality. The code for the splice, including >> dependencies that have not yet been sent to the runner (for earlier >> splices), is then sent in a RunTH [4] message, >> - the runner loads and runs the code in the Q monad, can send queries to >> GHCJS for reification, >> - the runner sends back the result as a serialized Template Haskell AST >> (using GHC.Generics for the Binary instances). >> >> All Template Haskell functionality is supported, including recent >> additions for reifying modules and annotations. I still need to clean up >> and push the patches for the directory and process packages, but after >> that, the TH code can read/write files, run processes and interact with >> them and make network connections, all through node.js. >> >> Now since this approach is in no way specific to JavaScript, I was >> wondering if there's any interest in getting this functionality into GHC >> 7.10 for general cross compilation. The runner would be a native (target) >> program with dynamic libraries (or object files) being sent over to the >> target machine (or emulator) for the splices. >> >> Thanks to Andras Slemmer from Prezi who helped build the initial proof of >> concept (without reification) at BudHac. >> >> cheers, >> >> Luite >> >> [1] >> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs >> [2] >> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs >> [3] >> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js >> [4] >> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29 >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cj at vdbonline.com Thu Jul 3 12:25:46 2014 From: cj at vdbonline.com (CJ van den Berg) Date: Thu, 03 Jul 2014 14:25:46 +0200 Subject: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation? In-Reply-To: References: Message-ID: <53B54BCA.5060301@vdbonline.com> Yes! This would definitely be of great interest to users of the Android cross compilers. It should be quite feasible to drive a TH runner process on a development device or emulator. Having genuine TH support would be a huge improvement to the usefulness of GHC in a cross compiling scenario. I would love to start work on integrating TH runner support into ghc-android. On 2014-07-02 18:14, Luite Stegeman wrote: > Now since this approach is in no way specific to JavaScript, I was > wondering if there's any interest in getting this functionality into GHC > 7.10 for general cross compilation. The runner would be a native > (target) program with dynamic libraries (or object files) being sent > over to the target machine (or emulator) for the splices. > -- CJ van den Berg mailto:cj at vdbonline.com xmpp:neurocyte at gmail.com From stegeman at gmail.com Thu Jul 3 12:51:11 2014 From: stegeman at gmail.com (Luite Stegeman) Date: Thu, 3 Jul 2014 14:51:11 +0200 Subject: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation? In-Reply-To: References: Message-ID: I think GHC could use more or less the same communication method as GHCJS now does: Start some user-specifiied process and send messages through pipes (GHCJS uses stdin/stderr of the node process), with the difference that it would get dynamic libraries for the target rather than blobs of JS code. That user process is then responsible for setting up the actual communication with the runner on the emulator or development device. A requirement for complete TH support is that more code can be loaded at runtime, so that multiple splices can be run by the same runner (because of the persistent map, qGetQ / qPutQ), I'm not sure if this is problematic on iOS. On Thu, Jul 3, 2014 at 2:54 AM, Carter Schonwald wrote: > This would probably be a great boon for those trying to use haskell for > Android and IOS right? how might the emulation setup work for those? > > > > > On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> wow, this is great work! >> >> If theres a clear path to getting the generic tooling into 7.10, i'm all >> for it :) (and willing to help on concrete mechanical subtasks) >> >> >> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman >> wrote: >> >>> hi all, >>> >>> I've added some code [1] [2] to GHCJS to make it run Template Haskell >>> code on node.js, rather than using the GHC linker. GHCJS has supported TH >>> for a long time now, but so far always relied on native (host) code for it. >>> This is the main reason that GHCJS always builds native and JavaScript code >>> for everything (another is that Cabal Setup.hs scripts need to be compiled >>> to some host-runnable form, but that can also be JavaScript if you have >>> node.js) >>> >>> Now besides the compiler having to do twice the work, this has some >>> other disadvantages: >>> >>> - Our JavaScript code has the same dependencies (packages) as native >>> code, which means packages like unix or Win32 show up somewhere, depending >>> on the host environment. This also limits our options in choosing >>> JS-specific packages. >>> - The Template Haskell code runs on the host environment, which might be >>> slightly different from the target, for example in integer size or >>> operating system specific constants. >>> >>> Moreover, building native code made the GHCJS installation procedure >>> more tricky, making end users think about libgmp or libiconv locations, >>> since it basically required the same preparation as building GHC from >>> source. This change will make installing much easier and more reliable (we >>> still have to update the build scripts). >>> >>> How it works is pretty simple: >>> >>> - When any code needs to be run on the target (hscCompileCoreExpr, >>> through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with >>> the thrunner.js [3] script, >>> - GHCJS sends its RTS and the Template Haskell server code [1] to >>> node.js, the script starts a Haskell thread running the server, >>> - for every splice, GHCJS compiles it to JavaScript and links it using >>> its incremental linking functionality. The code for the splice, including >>> dependencies that have not yet been sent to the runner (for earlier >>> splices), is then sent in a RunTH [4] message, >>> - the runner loads and runs the code in the Q monad, can send queries to >>> GHCJS for reification, >>> - the runner sends back the result as a serialized Template Haskell AST >>> (using GHC.Generics for the Binary instances). >>> >>> All Template Haskell functionality is supported, including recent >>> additions for reifying modules and annotations. I still need to clean up >>> and push the patches for the directory and process packages, but after >>> that, the TH code can read/write files, run processes and interact with >>> them and make network connections, all through node.js. >>> >>> Now since this approach is in no way specific to JavaScript, I was >>> wondering if there's any interest in getting this functionality into GHC >>> 7.10 for general cross compilation. The runner would be a native (target) >>> program with dynamic libraries (or object files) being sent over to the >>> target machine (or emulator) for the splices. >>> >>> Thanks to Andras Slemmer from Prezi who helped build the initial proof >>> of concept (without reification) at BudHac. >>> >>> cheers, >>> >>> Luite >>> >>> [1] >>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs >>> [2] >>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs >>> [3] >>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js >>> [4] >>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29 >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at repetae.net Thu Jul 3 20:47:51 2014 From: john at repetae.net (John Meacham) Date: Thu, 3 Jul 2014 13:47:51 -0700 Subject: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation? In-Reply-To: References: Message-ID: In case anyone wanted to start writing haskell android code now, jhc fully supports android as a target. here is an app made with it https://play.google.com/store/apps/details?id=org.metasepi.ajhc.android.cube this was made with Kiwamu's ajhc branch but code has been merged back into the main tree. On Wed, Jul 2, 2014 at 5:54 PM, Carter Schonwald wrote: > This would probably be a great boon for those trying to use haskell for > Android and IOS right? how might the emulation setup work for those? > > > > > On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald > wrote: >> >> wow, this is great work! >> >> If theres a clear path to getting the generic tooling into 7.10, i'm all >> for it :) (and willing to help on concrete mechanical subtasks) >> >> >> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman >> wrote: >>> >>> hi all, >>> >>> I've added some code [1] [2] to GHCJS to make it run Template Haskell >>> code on node.js, rather than using the GHC linker. GHCJS has supported TH >>> for a long time now, but so far always relied on native (host) code for it. >>> This is the main reason that GHCJS always builds native and JavaScript code >>> for everything (another is that Cabal Setup.hs scripts need to be compiled >>> to some host-runnable form, but that can also be JavaScript if you have >>> node.js) >>> >>> Now besides the compiler having to do twice the work, this has some other >>> disadvantages: >>> >>> - Our JavaScript code has the same dependencies (packages) as native >>> code, which means packages like unix or Win32 show up somewhere, depending >>> on the host environment. This also limits our options in choosing >>> JS-specific packages. >>> - The Template Haskell code runs on the host environment, which might be >>> slightly different from the target, for example in integer size or operating >>> system specific constants. >>> >>> Moreover, building native code made the GHCJS installation procedure more >>> tricky, making end users think about libgmp or libiconv locations, since it >>> basically required the same preparation as building GHC from source. This >>> change will make installing much easier and more reliable (we still have to >>> update the build scripts). >>> >>> How it works is pretty simple: >>> >>> - When any code needs to be run on the target (hscCompileCoreExpr, >>> through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with >>> the thrunner.js [3] script, >>> - GHCJS sends its RTS and the Template Haskell server code [1] to >>> node.js, the script starts a Haskell thread running the server, >>> - for every splice, GHCJS compiles it to JavaScript and links it using >>> its incremental linking functionality. The code for the splice, including >>> dependencies that have not yet been sent to the runner (for earlier >>> splices), is then sent in a RunTH [4] message, >>> - the runner loads and runs the code in the Q monad, can send queries to >>> GHCJS for reification, >>> - the runner sends back the result as a serialized Template Haskell AST >>> (using GHC.Generics for the Binary instances). >>> >>> All Template Haskell functionality is supported, including recent >>> additions for reifying modules and annotations. I still need to clean up and >>> push the patches for the directory and process packages, but after that, the >>> TH code can read/write files, run processes and interact with them and make >>> network connections, all through node.js. >>> >>> Now since this approach is in no way specific to JavaScript, I was >>> wondering if there's any interest in getting this functionality into GHC >>> 7.10 for general cross compilation. The runner would be a native (target) >>> program with dynamic libraries (or object files) being sent over to the >>> target machine (or emulator) for the splices. >>> >>> Thanks to Andras Slemmer from Prezi who helped build the initial proof of >>> concept (without reification) at BudHac. >>> >>> cheers, >>> >>> Luite >>> >>> [1] >>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs >>> [2] >>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs >>> [3] >>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js >>> [4] >>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29 >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >> > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- John Meacham - http://notanumber.net/ From djsamperi at gmail.com Fri Jul 4 04:43:24 2014 From: djsamperi at gmail.com (Dominick Samperi) Date: Fri, 4 Jul 2014 00:43:24 -0400 Subject: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation? In-Reply-To: References: Message-ID: Hello John, I tried to install the Haskell demo Cube on my Nexus 7 and got: Error: package file was not signed correctly. D On Thu, Jul 3, 2014 at 4:47 PM, John Meacham wrote: > In case anyone wanted to start writing haskell android code now, jhc > fully supports android as a target. here is an app made with it > > https://play.google.com/store/apps/details?id=org.metasepi.ajhc.android.cube > > this was made with Kiwamu's ajhc branch but code has been merged back > into the main tree. > > On Wed, Jul 2, 2014 at 5:54 PM, Carter Schonwald > wrote: >> This would probably be a great boon for those trying to use haskell for >> Android and IOS right? how might the emulation setup work for those? >> >> >> >> >> On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald >> wrote: >>> >>> wow, this is great work! >>> >>> If theres a clear path to getting the generic tooling into 7.10, i'm all >>> for it :) (and willing to help on concrete mechanical subtasks) >>> >>> >>> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman >>> wrote: >>>> >>>> hi all, >>>> >>>> I've added some code [1] [2] to GHCJS to make it run Template Haskell >>>> code on node.js, rather than using the GHC linker. GHCJS has supported TH >>>> for a long time now, but so far always relied on native (host) code for it. >>>> This is the main reason that GHCJS always builds native and JavaScript code >>>> for everything (another is that Cabal Setup.hs scripts need to be compiled >>>> to some host-runnable form, but that can also be JavaScript if you have >>>> node.js) >>>> >>>> Now besides the compiler having to do twice the work, this has some other >>>> disadvantages: >>>> >>>> - Our JavaScript code has the same dependencies (packages) as native >>>> code, which means packages like unix or Win32 show up somewhere, depending >>>> on the host environment. This also limits our options in choosing >>>> JS-specific packages. >>>> - The Template Haskell code runs on the host environment, which might be >>>> slightly different from the target, for example in integer size or operating >>>> system specific constants. >>>> >>>> Moreover, building native code made the GHCJS installation procedure more >>>> tricky, making end users think about libgmp or libiconv locations, since it >>>> basically required the same preparation as building GHC from source. This >>>> change will make installing much easier and more reliable (we still have to >>>> update the build scripts). >>>> >>>> How it works is pretty simple: >>>> >>>> - When any code needs to be run on the target (hscCompileCoreExpr, >>>> through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with >>>> the thrunner.js [3] script, >>>> - GHCJS sends its RTS and the Template Haskell server code [1] to >>>> node.js, the script starts a Haskell thread running the server, >>>> - for every splice, GHCJS compiles it to JavaScript and links it using >>>> its incremental linking functionality. The code for the splice, including >>>> dependencies that have not yet been sent to the runner (for earlier >>>> splices), is then sent in a RunTH [4] message, >>>> - the runner loads and runs the code in the Q monad, can send queries to >>>> GHCJS for reification, >>>> - the runner sends back the result as a serialized Template Haskell AST >>>> (using GHC.Generics for the Binary instances). >>>> >>>> All Template Haskell functionality is supported, including recent >>>> additions for reifying modules and annotations. I still need to clean up and >>>> push the patches for the directory and process packages, but after that, the >>>> TH code can read/write files, run processes and interact with them and make >>>> network connections, all through node.js. >>>> >>>> Now since this approach is in no way specific to JavaScript, I was >>>> wondering if there's any interest in getting this functionality into GHC >>>> 7.10 for general cross compilation. The runner would be a native (target) >>>> program with dynamic libraries (or object files) being sent over to the >>>> target machine (or emulator) for the splices. >>>> >>>> Thanks to Andras Slemmer from Prezi who helped build the initial proof of >>>> concept (without reification) at BudHac. >>>> >>>> cheers, >>>> >>>> Luite >>>> >>>> [1] >>>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs >>>> [2] >>>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs >>>> [3] >>>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js >>>> [4] >>>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29 >>>> >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users at haskell.org >>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>>> >>> >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > > > > -- > John Meacham - http://notanumber.net/ > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From stegeman at gmail.com Fri Jul 4 11:03:35 2014 From: stegeman at gmail.com (Luite Stegeman) Date: Fri, 4 Jul 2014 13:03:35 +0200 Subject: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation? In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF10422771@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF10422771@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: On Thu, Jul 3, 2014 at 6:18 PM, Simon Peyton Jones wrote: > Luite > > > > I lack the bandwidth to respond at any technical depth, but I?d like to > make encouraging noises. If you can figure out a way to make GHC do these > things without making the compiler terribly complicated and making > maintaining it harder, then I?m open to your proposals. > > > I think most of the communication code could go into a separate executable that can be built by the user for the target-specific communication. The GHC API facing part of the implementation in GHCJS is under 300 lines and that includes some non-exported code duplicated from GHC, so I'm reasonably optimistic that it can be done without too much impact. Unfortunately I won't have much time in the near future, since a GHCJS release is well overdue (mostly because I keep adding features like this...) and I want to focus on that first, but getting it ready before 7.10 should be doable (especially if other people want to help!) luite -------------- next part -------------- An HTML attachment was scrubbed... URL: From kili at outback.escape.de Fri Jul 4 21:50:24 2014 From: kili at outback.escape.de (Matthias Kilian) Date: Fri, 4 Jul 2014 23:50:24 +0200 Subject: GHC and Haskell-Platform on OpenBSD Message-ID: <20140704215024.GA28172@nutty.outback.escape.de> Hi, I'd like to know wether anyone here is using GHC on OpenBSD *and* relying on the Haskell-Platform meta package for OpenBSD. If there's no need for the HP meta package, I could just start to update GHC and all related packages for OpenBSD, but if there are a lot of people who prefer to stick to the HP, I'd to wait until the official update of the HP. So, if you love running pkg_add haskell-platform on OpenBSD, please speak up. And if you don't care an just run pkg_add ghc please speak up too ;-) Ciao, Kili From john at repetae.net Fri Jul 4 23:58:07 2014 From: john at repetae.net (John Meacham) Date: Fri, 4 Jul 2014 16:58:07 -0700 Subject: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation? In-Reply-To: References: Message-ID: Hmm.. It works on my nexus 4. Kiwamu of the metasepi http://ajhc.metasepi.org/ is the one that uploaded the demo. Perhaps he needs to update the key or something. On Thu, Jul 3, 2014 at 9:43 PM, Dominick Samperi wrote: > Hello John, > I tried to install the Haskell demo Cube on my Nexus 7 > and got: Error: package file was not signed correctly. > D > > On Thu, Jul 3, 2014 at 4:47 PM, John Meacham wrote: >> In case anyone wanted to start writing haskell android code now, jhc >> fully supports android as a target. here is an app made with it >> >> https://play.google.com/store/apps/details?id=org.metasepi.ajhc.android.cube >> >> this was made with Kiwamu's ajhc branch but code has been merged back >> into the main tree. >> >> On Wed, Jul 2, 2014 at 5:54 PM, Carter Schonwald >> wrote: >>> This would probably be a great boon for those trying to use haskell for >>> Android and IOS right? how might the emulation setup work for those? >>> >>> >>> >>> >>> On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald >>> wrote: >>>> >>>> wow, this is great work! >>>> >>>> If theres a clear path to getting the generic tooling into 7.10, i'm all >>>> for it :) (and willing to help on concrete mechanical subtasks) >>>> >>>> >>>> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman >>>> wrote: >>>>> >>>>> hi all, >>>>> >>>>> I've added some code [1] [2] to GHCJS to make it run Template Haskell >>>>> code on node.js, rather than using the GHC linker. GHCJS has supported TH >>>>> for a long time now, but so far always relied on native (host) code for it. >>>>> This is the main reason that GHCJS always builds native and JavaScript code >>>>> for everything (another is that Cabal Setup.hs scripts need to be compiled >>>>> to some host-runnable form, but that can also be JavaScript if you have >>>>> node.js) >>>>> >>>>> Now besides the compiler having to do twice the work, this has some other >>>>> disadvantages: >>>>> >>>>> - Our JavaScript code has the same dependencies (packages) as native >>>>> code, which means packages like unix or Win32 show up somewhere, depending >>>>> on the host environment. This also limits our options in choosing >>>>> JS-specific packages. >>>>> - The Template Haskell code runs on the host environment, which might be >>>>> slightly different from the target, for example in integer size or operating >>>>> system specific constants. >>>>> >>>>> Moreover, building native code made the GHCJS installation procedure more >>>>> tricky, making end users think about libgmp or libiconv locations, since it >>>>> basically required the same preparation as building GHC from source. This >>>>> change will make installing much easier and more reliable (we still have to >>>>> update the build scripts). >>>>> >>>>> How it works is pretty simple: >>>>> >>>>> - When any code needs to be run on the target (hscCompileCoreExpr, >>>>> through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with >>>>> the thrunner.js [3] script, >>>>> - GHCJS sends its RTS and the Template Haskell server code [1] to >>>>> node.js, the script starts a Haskell thread running the server, >>>>> - for every splice, GHCJS compiles it to JavaScript and links it using >>>>> its incremental linking functionality. The code for the splice, including >>>>> dependencies that have not yet been sent to the runner (for earlier >>>>> splices), is then sent in a RunTH [4] message, >>>>> - the runner loads and runs the code in the Q monad, can send queries to >>>>> GHCJS for reification, >>>>> - the runner sends back the result as a serialized Template Haskell AST >>>>> (using GHC.Generics for the Binary instances). >>>>> >>>>> All Template Haskell functionality is supported, including recent >>>>> additions for reifying modules and annotations. I still need to clean up and >>>>> push the patches for the directory and process packages, but after that, the >>>>> TH code can read/write files, run processes and interact with them and make >>>>> network connections, all through node.js. >>>>> >>>>> Now since this approach is in no way specific to JavaScript, I was >>>>> wondering if there's any interest in getting this functionality into GHC >>>>> 7.10 for general cross compilation. The runner would be a native (target) >>>>> program with dynamic libraries (or object files) being sent over to the >>>>> target machine (or emulator) for the splices. >>>>> >>>>> Thanks to Andras Slemmer from Prezi who helped build the initial proof of >>>>> concept (without reification) at BudHac. >>>>> >>>>> cheers, >>>>> >>>>> Luite >>>>> >>>>> [1] >>>>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs >>>>> [2] >>>>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs >>>>> [3] >>>>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js >>>>> [4] >>>>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29 >>>>> >>>>> _______________________________________________ >>>>> Glasgow-haskell-users mailing list >>>>> Glasgow-haskell-users at haskell.org >>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >> >> >> >> -- >> John Meacham - http://notanumber.net/ >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- John Meacham - http://notanumber.net/ From 2haskell at pkturner.org Sat Jul 5 16:02:40 2014 From: 2haskell at pkturner.org (Scott Turner) Date: Sat, 05 Jul 2014 12:02:40 -0400 Subject: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation? In-Reply-To: References: Message-ID: <53B821A0.70508@pkturner.org> It installed and worked on my Nexus 5. On 2014-07-04 00:43, Dominick Samperi wrote: > Hello John, > I tried to install the Haskell demo Cube on my Nexus 7 > and got: Error: package file was not signed correctly. > D > > On Thu, Jul 3, 2014 at 4:47 PM, John Meacham wrote: >> In case anyone wanted to start writing haskell android code now, jhc >> fully supports android as a target. here is an app made with it >> >> https://play.google.com/store/apps/details?id=org.metasepi.ajhc.android.cube >> >> this was made with Kiwamu's ajhc branch but code has been merged back >> into the main tree. >> >> On Wed, Jul 2, 2014 at 5:54 PM, Carter Schonwald >> wrote: >>> This would probably be a great boon for those trying to use haskell for >>> Android and IOS right? how might the emulation setup work for those? >>> >>> >>> >>> >>> On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald >>> wrote: >>>> wow, this is great work! >>>> >>>> If theres a clear path to getting the generic tooling into 7.10, i'm all >>>> for it :) (and willing to help on concrete mechanical subtasks) >>>> >>>> >>>> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman >>>> wrote: >>>>> hi all, >>>>> >>>>> I've added some code [1] [2] to GHCJS to make it run Template Haskell >>>>> code on node.js, rather than using the GHC linker. GHCJS has supported TH >>>>> for a long time now, but so far always relied on native (host) code for it. >>>>> This is the main reason that GHCJS always builds native and JavaScript code >>>>> for everything (another is that Cabal Setup.hs scripts need to be compiled >>>>> to some host-runnable form, but that can also be JavaScript if you have >>>>> node.js) >>>>> >>>>> Now besides the compiler having to do twice the work, this has some other >>>>> disadvantages: >>>>> >>>>> - Our JavaScript code has the same dependencies (packages) as native >>>>> code, which means packages like unix or Win32 show up somewhere, depending >>>>> on the host environment. This also limits our options in choosing >>>>> JS-specific packages. >>>>> - The Template Haskell code runs on the host environment, which might be >>>>> slightly different from the target, for example in integer size or operating >>>>> system specific constants. >>>>> >>>>> Moreover, building native code made the GHCJS installation procedure more >>>>> tricky, making end users think about libgmp or libiconv locations, since it >>>>> basically required the same preparation as building GHC from source. This >>>>> change will make installing much easier and more reliable (we still have to >>>>> update the build scripts). >>>>> >>>>> How it works is pretty simple: >>>>> >>>>> - When any code needs to be run on the target (hscCompileCoreExpr, >>>>> through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with >>>>> the thrunner.js [3] script, >>>>> - GHCJS sends its RTS and the Template Haskell server code [1] to >>>>> node.js, the script starts a Haskell thread running the server, >>>>> - for every splice, GHCJS compiles it to JavaScript and links it using >>>>> its incremental linking functionality. The code for the splice, including >>>>> dependencies that have not yet been sent to the runner (for earlier >>>>> splices), is then sent in a RunTH [4] message, >>>>> - the runner loads and runs the code in the Q monad, can send queries to >>>>> GHCJS for reification, >>>>> - the runner sends back the result as a serialized Template Haskell AST >>>>> (using GHC.Generics for the Binary instances). >>>>> >>>>> All Template Haskell functionality is supported, including recent >>>>> additions for reifying modules and annotations. I still need to clean up and >>>>> push the patches for the directory and process packages, but after that, the >>>>> TH code can read/write files, run processes and interact with them and make >>>>> network connections, all through node.js. >>>>> >>>>> Now since this approach is in no way specific to JavaScript, I was >>>>> wondering if there's any interest in getting this functionality into GHC >>>>> 7.10 for general cross compilation. The runner would be a native (target) >>>>> program with dynamic libraries (or object files) being sent over to the >>>>> target machine (or emulator) for the splices. >>>>> >>>>> Thanks to Andras Slemmer from Prezi who helped build the initial proof of >>>>> concept (without reification) at BudHac. >>>>> >>>>> cheers, >>>>> >>>>> Luite >>>>> >>>>> [1] >>>>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs >>>>> [2] >>>>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs >>>>> [3] >>>>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js >>>>> [4] >>>>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29 >>>>> >>>>> _______________________________________________ >>>>> Glasgow-haskell-users mailing list >>>>> Glasgow-haskell-users at haskell.org >>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>>>> >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >> >> >> -- >> John Meacham - http://notanumber.net/ >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From carter.schonwald at gmail.com Sat Jul 5 17:34:19 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 5 Jul 2014 13:34:19 -0400 Subject: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation? In-Reply-To: <53B821A0.70508@pkturner.org> References: <53B821A0.70508@pkturner.org> Message-ID: does JHC support template haskell? On Sat, Jul 5, 2014 at 12:02 PM, Scott Turner <2haskell at pkturner.org> wrote: > It installed and worked on my Nexus 5. > > On 2014-07-04 00:43, Dominick Samperi wrote: > > Hello John, > > I tried to install the Haskell demo Cube on my Nexus 7 > > and got: Error: package file was not signed correctly. > > D > > > > On Thu, Jul 3, 2014 at 4:47 PM, John Meacham wrote: > >> In case anyone wanted to start writing haskell android code now, jhc > >> fully supports android as a target. here is an app made with it > >> > >> > https://play.google.com/store/apps/details?id=org.metasepi.ajhc.android.cube > >> > >> this was made with Kiwamu's ajhc branch but code has been merged back > >> into the main tree. > >> > >> On Wed, Jul 2, 2014 at 5:54 PM, Carter Schonwald > >> wrote: > >>> This would probably be a great boon for those trying to use haskell for > >>> Android and IOS right? how might the emulation setup work for those? > >>> > >>> > >>> > >>> > >>> On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald > >>> wrote: > >>>> wow, this is great work! > >>>> > >>>> If theres a clear path to getting the generic tooling into 7.10, i'm > all > >>>> for it :) (and willing to help on concrete mechanical subtasks) > >>>> > >>>> > >>>> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman > >>>> wrote: > >>>>> hi all, > >>>>> > >>>>> I've added some code [1] [2] to GHCJS to make it run Template Haskell > >>>>> code on node.js, rather than using the GHC linker. GHCJS has > supported TH > >>>>> for a long time now, but so far always relied on native (host) code > for it. > >>>>> This is the main reason that GHCJS always builds native and > JavaScript code > >>>>> for everything (another is that Cabal Setup.hs scripts need to be > compiled > >>>>> to some host-runnable form, but that can also be JavaScript if you > have > >>>>> node.js) > >>>>> > >>>>> Now besides the compiler having to do twice the work, this has some > other > >>>>> disadvantages: > >>>>> > >>>>> - Our JavaScript code has the same dependencies (packages) as native > >>>>> code, which means packages like unix or Win32 show up somewhere, > depending > >>>>> on the host environment. This also limits our options in choosing > >>>>> JS-specific packages. > >>>>> - The Template Haskell code runs on the host environment, which > might be > >>>>> slightly different from the target, for example in integer size or > operating > >>>>> system specific constants. > >>>>> > >>>>> Moreover, building native code made the GHCJS installation procedure > more > >>>>> tricky, making end users think about libgmp or libiconv locations, > since it > >>>>> basically required the same preparation as building GHC from source. > This > >>>>> change will make installing much easier and more reliable (we still > have to > >>>>> update the build scripts). > >>>>> > >>>>> How it works is pretty simple: > >>>>> > >>>>> - When any code needs to be run on the target (hscCompileCoreExpr, > >>>>> through the Hooks API new in GHC 7.8), GHCJS starts a node.js > process with > >>>>> the thrunner.js [3] script, > >>>>> - GHCJS sends its RTS and the Template Haskell server code [1] to > >>>>> node.js, the script starts a Haskell thread running the server, > >>>>> - for every splice, GHCJS compiles it to JavaScript and links it > using > >>>>> its incremental linking functionality. The code for the splice, > including > >>>>> dependencies that have not yet been sent to the runner (for earlier > >>>>> splices), is then sent in a RunTH [4] message, > >>>>> - the runner loads and runs the code in the Q monad, can send > queries to > >>>>> GHCJS for reification, > >>>>> - the runner sends back the result as a serialized Template Haskell > AST > >>>>> (using GHC.Generics for the Binary instances). > >>>>> > >>>>> All Template Haskell functionality is supported, including recent > >>>>> additions for reifying modules and annotations. I still need to > clean up and > >>>>> push the patches for the directory and process packages, but after > that, the > >>>>> TH code can read/write files, run processes and interact with them > and make > >>>>> network connections, all through node.js. > >>>>> > >>>>> Now since this approach is in no way specific to JavaScript, I was > >>>>> wondering if there's any interest in getting this functionality into > GHC > >>>>> 7.10 for general cross compilation. The runner would be a native > (target) > >>>>> program with dynamic libraries (or object files) being sent over to > the > >>>>> target machine (or emulator) for the splices. > >>>>> > >>>>> Thanks to Andras Slemmer from Prezi who helped build the initial > proof of > >>>>> concept (without reification) at BudHac. > >>>>> > >>>>> cheers, > >>>>> > >>>>> Luite > >>>>> > >>>>> [1] > >>>>> > https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/src/Gen2/TH.hs > >>>>> [2] > >>>>> > https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Eval.hs > >>>>> [3] > >>>>> > https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261a/lib/etc/thrunner.js > >>>>> [4] > >>>>> > https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812d4f9a4/GHCJS/Prim/TH/Types.hs#L29 > >>>>> > >>>>> _______________________________________________ > >>>>> Glasgow-haskell-users mailing list > >>>>> Glasgow-haskell-users at haskell.org > >>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > >>>>> > >>> > >>> _______________________________________________ > >>> Glasgow-haskell-users mailing list > >>> Glasgow-haskell-users at haskell.org > >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > >>> > >> > >> > >> -- > >> John Meacham - http://notanumber.net/ > >> _______________________________________________ > >> Glasgow-haskell-users mailing list > >> Glasgow-haskell-users at haskell.org > >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sat Jul 5 17:38:13 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 5 Jul 2014 13:38:13 -0400 Subject: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation? In-Reply-To: References: <53B821A0.70508@pkturner.org> Message-ID: On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald wrote: > does JHC support template haskell? Pretty sure TH is too closely tied to ghc. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at repetae.net Sat Jul 5 19:59:27 2014 From: john at repetae.net (John Meacham) Date: Sat, 5 Jul 2014 12:59:27 -0700 Subject: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation? In-Reply-To: References: <53B821A0.70508@pkturner.org> Message-ID: Actually, I was looking into it a little, and template haskell could effectively be implemented by a pre-processor and a portable library that is compiler independent. If one could get ghc to spit out the template haskell source after it expands it then that can be fed to jhc as a quick first pass, but ideally the pre-processor TH would create programs that can be run under the target compiler. that would bring TH to every haskell compiler. John On Sat, Jul 5, 2014 at 10:38 AM, Brandon Allbery wrote: > On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald > wrote: >> >> does JHC support template haskell? > > > Pretty sure TH is too closely tied to ghc. > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b at gmail.com ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -- John Meacham - http://notanumber.net/ From stegeman at gmail.com Sat Jul 5 20:09:08 2014 From: stegeman at gmail.com (Luite Stegeman) Date: Sat, 5 Jul 2014 22:09:08 +0200 Subject: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation? In-Reply-To: References: <53B821A0.70508@pkturner.org> Message-ID: How would you do reification with that approach? On Sat, Jul 5, 2014 at 9:59 PM, John Meacham wrote: > Actually, I was looking into it a little, and template haskell could > effectively be implemented by a pre-processor and a portable library > that is compiler independent. If one could get ghc to spit out the > template haskell source after it expands it then that can be fed to > jhc as a quick first pass, but ideally the pre-processor TH would > create programs that can be run under the target compiler. that would > bring TH to every haskell compiler. > > John > > On Sat, Jul 5, 2014 at 10:38 AM, Brandon Allbery > wrote: > > On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald > > wrote: > >> > >> does JHC support template haskell? > > > > > > Pretty sure TH is too closely tied to ghc. > > > > -- > > brandon s allbery kf8nh sine nomine > associates > > allbery.b at gmail.com > ballbery at sinenomine.net > > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > > > -- > John Meacham - http://notanumber.net/ > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at repetae.net Sat Jul 5 20:39:22 2014 From: john at repetae.net (John Meacham) Date: Sat, 5 Jul 2014 13:39:22 -0700 Subject: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation? In-Reply-To: References: <53B821A0.70508@pkturner.org> Message-ID: The target compiler would have the TH libraries, which could be made to be portable. The external program would just extract the TH bits and turn them into a program that spits the TH expanded output to a new file to compile, and repeat the process til no TH expansions exist and finally that is the result you pass to the compiler. John On Sat, Jul 5, 2014 at 1:09 PM, Luite Stegeman wrote: > How would you do reification with that approach? > > > On Sat, Jul 5, 2014 at 9:59 PM, John Meacham wrote: >> >> Actually, I was looking into it a little, and template haskell could >> effectively be implemented by a pre-processor and a portable library >> that is compiler independent. If one could get ghc to spit out the >> template haskell source after it expands it then that can be fed to >> jhc as a quick first pass, but ideally the pre-processor TH would >> create programs that can be run under the target compiler. that would >> bring TH to every haskell compiler. >> >> John >> >> On Sat, Jul 5, 2014 at 10:38 AM, Brandon Allbery >> wrote: >> > On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald >> > wrote: >> >> >> >> does JHC support template haskell? >> > >> > >> > Pretty sure TH is too closely tied to ghc. >> > >> > -- >> > brandon s allbery kf8nh sine nomine >> > associates >> > allbery.b at gmail.com >> > ballbery at sinenomine.net >> > unix, openafs, kerberos, infrastructure, xmonad >> > http://sinenomine.net >> >> >> >> -- >> John Meacham - http://notanumber.net/ >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -- John Meacham - http://notanumber.net/ From stegeman at gmail.com Sat Jul 5 20:56:40 2014 From: stegeman at gmail.com (Luite Stegeman) Date: Sat, 5 Jul 2014 22:56:40 +0200 Subject: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation? In-Reply-To: References: <53B821A0.70508@pkturner.org> Message-ID: I'm not sure I correctly understand your approach, but to have the template haskell reification work without any runtime communication with the compiler you'd have to include the entire typechecker state, at least for all names reachable from the splice (see http://hackage.haskell.org/package/template-haskell-2.9.0.0/docs/Language-Haskell-TH-Syntax.html , the Quasi class for the required functionality). This would mean serializing all names with types modules, annotations, instances. I briefly looked into this for GHCJS but decided that just querying the compiler would be better. On Sat, Jul 5, 2014 at 10:39 PM, John Meacham wrote: > The target compiler would have the TH libraries, which could be made > to be portable. The external program would just extract the TH bits > and turn them into a program that spits the TH expanded output to a > new file to compile, and repeat the process til no TH expansions exist > and finally that is the result you pass to the compiler. > > John > > On Sat, Jul 5, 2014 at 1:09 PM, Luite Stegeman wrote: > > How would you do reification with that approach? > > > > > > On Sat, Jul 5, 2014 at 9:59 PM, John Meacham wrote: > >> > >> Actually, I was looking into it a little, and template haskell could > >> effectively be implemented by a pre-processor and a portable library > >> that is compiler independent. If one could get ghc to spit out the > >> template haskell source after it expands it then that can be fed to > >> jhc as a quick first pass, but ideally the pre-processor TH would > >> create programs that can be run under the target compiler. that would > >> bring TH to every haskell compiler. > >> > >> John > >> > >> On Sat, Jul 5, 2014 at 10:38 AM, Brandon Allbery > >> wrote: > >> > On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald > >> > wrote: > >> >> > >> >> does JHC support template haskell? > >> > > >> > > >> > Pretty sure TH is too closely tied to ghc. > >> > > >> > -- > >> > brandon s allbery kf8nh sine nomine > >> > associates > >> > allbery.b at gmail.com > >> > ballbery at sinenomine.net > >> > unix, openafs, kerberos, infrastructure, xmonad > >> > http://sinenomine.net > >> > >> > >> > >> -- > >> John Meacham - http://notanumber.net/ > >> _______________________________________________ > >> Glasgow-haskell-users mailing list > >> Glasgow-haskell-users at haskell.org > >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > > > > > -- > John Meacham - http://notanumber.net/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nomeata at debian.org Sat Jul 5 21:04:23 2014 From: nomeata at debian.org (Joachim Breitner) Date: Sat, 05 Jul 2014 23:04:23 +0200 Subject: ghc, tls, gmp Message-ID: <1404594263.5548.18.camel@kirk> Hi, in Debian, we have the (well-known) problem of linking against libraries using libgmp, in this case haskell-curl, which links against libcurl, which links against gnutls, which uses libgmp since the latest release: https://lists.debian.org/debian-haskell/2014/07/msg00000.html Are there any viable solutions to this problem that I might not be aware of? Are there any solutions to be expected in the near future? (My best idea so far is to use libcurl linked against openssl, but this causes licensing issues.) Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata at debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nomeata at joachim-breitner.de | http://people.debian.org/~nomeata -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From vogt.adam at gmail.com Sun Jul 6 03:18:51 2014 From: vogt.adam at gmail.com (adam vogt) Date: Sat, 5 Jul 2014 23:18:51 -0400 Subject: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation? In-Reply-To: References: <53B821A0.70508@pkturner.org> Message-ID: Zeroth takes the first approach. It only supports a subset of TH (DecsQ splices) however. http://hackage.haskell.org/package/zeroth https://github.com/aavogt/zeroth is a fork that works with more recent haskell-src-exts and ghc On Sat, Jul 5, 2014 at 3:59 PM, John Meacham wrote: > Actually, I was looking into it a little, and template haskell could > effectively be implemented by a pre-processor and a portable library > that is compiler independent. If one could get ghc to spit out the > template haskell source after it expands it then that can be fed to > jhc as a quick first pass, but ideally the pre-processor TH would > create programs that can be run under the target compiler. that would > bring TH to every haskell compiler. > > John > > On Sat, Jul 5, 2014 at 10:38 AM, Brandon Allbery wrote: >> On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald >> wrote: >>> >>> does JHC support template haskell? >> >> >> Pretty sure TH is too closely tied to ghc. >> >> -- >> brandon s allbery kf8nh sine nomine associates >> allbery.b at gmail.com ballbery at sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net > > > > -- > John Meacham - http://notanumber.net/ > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From greg at gregweber.info Sun Jul 6 18:32:06 2014 From: greg at gregweber.info (Greg Weber) Date: Sun, 6 Jul 2014 11:32:06 -0700 Subject: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation? In-Reply-To: References: <53B821A0.70508@pkturner.org> Message-ID: I created a GHC patch that spits out the generated Template Haskell code to a file with -dump-to-file -ddump-splices https://ghc.haskell.org/trac/ghc/ticket/9126 On Sat, Jul 5, 2014 at 8:18 PM, adam vogt wrote: > Zeroth takes the first approach. It only supports a subset of TH > (DecsQ splices) however. > > http://hackage.haskell.org/package/zeroth > > https://github.com/aavogt/zeroth is a fork that works with more recent > haskell-src-exts and ghc > > On Sat, Jul 5, 2014 at 3:59 PM, John Meacham wrote: > > Actually, I was looking into it a little, and template haskell could > > effectively be implemented by a pre-processor and a portable library > > that is compiler independent. If one could get ghc to spit out the > > template haskell source after it expands it then that can be fed to > > jhc as a quick first pass, but ideally the pre-processor TH would > > create programs that can be run under the target compiler. that would > > bring TH to every haskell compiler. > > > > John > > > > On Sat, Jul 5, 2014 at 10:38 AM, Brandon Allbery > wrote: > >> On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald > >> wrote: > >>> > >>> does JHC support template haskell? > >> > >> > >> Pretty sure TH is too closely tied to ghc. > >> > >> -- > >> brandon s allbery kf8nh sine nomine > associates > >> allbery.b at gmail.com > ballbery at sinenomine.net > >> unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > > > > > > > -- > > John Meacham - http://notanumber.net/ > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at proclivis.com Tue Jul 8 04:10:15 2014 From: mike at proclivis.com (Michael Jones) Date: Mon, 7 Jul 2014 22:10:15 -0600 Subject: Cross compiling for Cortex A9 Message-ID: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> I am having problems building a GHC cross compiler for Linux (Yocto on a Wandboard) running on a Cortex A9, and need some advice on how to debug it. The cross compiler produces an executable that runs on the Target, but fails to print. So I need help coming up with a strategy to narrow down the root cause. Some details: The application: main = do putStrLn "Haskell start" The command line options work. The program runs, and I can step through assembly. Debug data is printed to the console. But putStrLn fails, and program enters an infinite loop. I compile my app as follows: arm-unknown-linux-gnueabi-ghc -debug -static Main.hs Using -threaded does not fix the problem. Let me compare debug data from a run on my HOST, with a run on my TARGET. First, a run from my HOST: created capset 0 of type 2 created capset 1 of type 3 cap 0: initialised assigned cap 0 to capset 0 assigned cap 0 to capset 1 cap 0: created thread 1 cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (suspended while making a foreign call) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (finished) cap 0: created thread 2 cap 0: running thread 2 (ThreadRunGHC) cap 0: thread 2 stopped (finished) cap 0: starting GC cap 0: GC working cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: all caps stopped for GC cap 0: finished GC removed cap 0 from capset 0 removed cap 0 from capset 1 cap 0: shutting down deleted capset 0 deleted capset 1 And, it prints properly. So this is my referenced for what it should do on the TARGET. When I run on my TARGET, I get: created capset 0 of type 2 created capset 1 of type 3 cap 0: initialised assigned cap 0 to capset 0 assigned cap 0 to capset 1 cap 0: created thread 1 cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (heap overflow) cap 0: starting GC cap 0: GC working cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: all caps stopped for GC cap 0: finished GC cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) ... And the debug data goes on forever, just as debugging assembly demonstrated an infinite loop. Clearly, the following does not occur: cap 0: thread 1 stopped (suspended while making a foreign call) And there are overflows. If I had to guess, it is possible that some code is in a loop retrying to foreign call, and failing. Certainly, it is in some kind of a loop, because I found a place I can put a break point and and telling GDB to continue will cause the break over and over at the same place. So somewhere there is a loop. I can step through the application with GDB and see names of files and offsets in assembly. But without a true source code debug, that is a bit rough, especially for someone that does not know the RTS code. If there was a way to compile such that C source code was available and a place to break, that would help. However, I suspect since it never makes a foreign call, there is no place in C to place the breakpoint anyway. So I am also assuming there is no direct way to debug with GDB. But, I can see debug output printed to the console. My hope is there is a way to enable more printing, or a place I can add more print functions to help find the problem. So I think I need one of the following: - A solution from someone that has seen this before, perhaps on the iPhone - How to enable more debug logging - Where in the source code to add debug statements to narrow down the problem Thanks for any help you can give. Mike From carter.schonwald at gmail.com Tue Jul 8 04:42:58 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 8 Jul 2014 00:42:58 -0400 Subject: Cross compiling for Cortex A9 In-Reply-To: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> References: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> Message-ID: could you share the output of ghc --info? On Tue, Jul 8, 2014 at 12:10 AM, Michael Jones wrote: > I am having problems building a GHC cross compiler for Linux (Yocto on a > Wandboard) running on a Cortex A9, and need some advice on how to debug it. > > The cross compiler produces an executable that runs on the Target, but > fails to print. So I need help coming up with a strategy to narrow down the > root cause. > > Some details: > > The application: > > main = do > putStrLn "Haskell start" > > > The command line options work. The program runs, and I can step through > assembly. Debug data is printed to the console. But putStrLn fails, and > program enters an infinite loop. > > I compile my app as follows: > > arm-unknown-linux-gnueabi-ghc -debug -static Main.hs > > Using -threaded does not fix the problem. > > Let me compare debug data from a run on my HOST, with a run on my TARGET. > First, a run from my HOST: > > created capset 0 of type 2 > created capset 1 of type 3 > cap 0: initialised > assigned cap 0 to capset 0 > assigned cap 0 to capset 1 > cap 0: created thread 1 > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (suspended while making a foreign call) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (finished) > cap 0: created thread 2 > cap 0: running thread 2 (ThreadRunGHC) > cap 0: thread 2 stopped (finished) > cap 0: starting GC > cap 0: GC working > cap 0: GC idle > cap 0: GC done > cap 0: GC idle > cap 0: GC done > cap 0: GC idle > cap 0: GC done > cap 0: GC idle > cap 0: GC done > cap 0: all caps stopped for GC > cap 0: finished GC > removed cap 0 from capset 0 > removed cap 0 from capset 1 > cap 0: shutting down > deleted capset 0 > deleted capset 1 > > And, it prints properly. So this is my referenced for what it should do on > the TARGET. > > When I run on my TARGET, I get: > > created capset 0 of type 2 > created capset 1 of type 3 > cap 0: initialised > assigned cap 0 to capset 0 > assigned cap 0 to capset 1 > cap 0: created thread 1 > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (yielding) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (yielding) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (yielding) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (yielding) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (yielding) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (yielding) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (stack overflow) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (stack overflow) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (stack overflow) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (yielding) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (stack overflow) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (stack overflow) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (stack overflow) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (yielding) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (stack overflow) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (heap overflow) > cap 0: starting GC > cap 0: GC working > cap 0: GC idle > cap 0: GC done > cap 0: GC idle > cap 0: GC done > cap 0: GC idle > cap 0: GC done > cap 0: all caps stopped for GC > cap 0: finished GC > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (yielding) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (stack overflow) > ... > > And the debug data goes on forever, just as debugging assembly > demonstrated an infinite loop. > > Clearly, the following does not occur: > > cap 0: thread 1 stopped (suspended while making a foreign call) > > And there are overflows. > > If I had to guess, it is possible that some code is in a loop retrying to > foreign call, and failing. Certainly, it is in some kind of a loop, because > I found a place I can put a break point and and telling GDB to continue > will cause the break over and over at the same place. So somewhere there is > a loop. > > I can step through the application with GDB and see names of files and > offsets in assembly. But without a true source code debug, that is a bit > rough, especially for someone that does not know the RTS code. If there was > a way to compile such that C source code was available and a place to > break, that would help. However, I suspect since it never makes a foreign > call, there is no place in C to place the breakpoint anyway. So I am also > assuming there is no direct way to debug with GDB. > > But, I can see debug output printed to the console. My hope is there is a > way to enable more printing, or a place I can add more print functions to > help find the problem. > > So I think I need one of the following: > > - A solution from someone that has seen this before, perhaps on the iPhone > - How to enable more debug logging > - Where in the source code to add debug statements to narrow down the > problem > > Thanks for any help you can give. > > Mike > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at proclivis.com Tue Jul 8 05:51:51 2014 From: mike at proclivis.com (Michael Jones) Date: Mon, 7 Jul 2014 23:51:51 -0600 Subject: Cross compiling for Cortex A9 In-Reply-To: References: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> Message-ID: I am pasting both the info from the HOST and TARGET compilers: HOST ==== [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -fno-stack-protector -Wl,--hash-size=31 -Wl,--reduce-memory-overheads") ,("ar command","/usr/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("perl command","/usr/bin/perl") ,("target os","OSLinux") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.6.3") ,("Booter version","7.6.3") ,("Stage","2") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","x86_64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Unregisterised","NO") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn thr_debug_p") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/lib/ghc") ,("Global Package DB","/usr/lib/ghc/package.conf.d") ,("Gcc Linker flags","[\"-Wl,--hash-size=31\",\"-Wl,--reduce-memory-overheads\"]") ,("Ld Linker flags","[\"--hash-size=31\",\"--reduce-memory-overheads\"]") ] TARGET ======= [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","arm-poky-linux-gnueabi-gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags","") ,("ld command","arm-poky-linux-gnueabi-ld") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","/usr/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSLinux") ,("target arch","ArchARM {armISA = ARMv5, armISAExt = [], armABI = HARD}") ,("target word size","4") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.8.2") ,("Booter version","7.6.3") ,("Stage","1") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","arm-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","NO") ,("Have native code generator","NO") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l ") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","NO") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/local/lib/arm-unknown-linux-gnueabi-ghc-7.8.2") ,("Global Package DB","/usr/local/lib/arm-unknown-linux-gnueabi-ghc-7.8.2/package.conf.d") ] On Jul 7, 2014, at 10:42 PM, Carter Schonwald wrote: > could you share the output of ghc --info? > > > On Tue, Jul 8, 2014 at 12:10 AM, Michael Jones wrote: > I am having problems building a GHC cross compiler for Linux (Yocto on a Wandboard) running on a Cortex A9, and need some advice on how to debug it. > > The cross compiler produces an executable that runs on the Target, but fails to print. So I need help coming up with a strategy to narrow down the root cause. > > Some details: > > The application: > > main = do > putStrLn "Haskell start" > > > The command line options work. The program runs, and I can step through assembly. Debug data is printed to the console. But putStrLn fails, and program enters an infinite loop. > > I compile my app as follows: > > arm-unknown-linux-gnueabi-ghc -debug -static Main.hs > > Using -threaded does not fix the problem. > > Let me compare debug data from a run on my HOST, with a run on my TARGET. First, a run from my HOST: > > created capset 0 of type 2 > created capset 1 of type 3 > cap 0: initialised > assigned cap 0 to capset 0 > assigned cap 0 to capset 1 > cap 0: created thread 1 > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (suspended while making a foreign call) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (finished) > cap 0: created thread 2 > cap 0: running thread 2 (ThreadRunGHC) > cap 0: thread 2 stopped (finished) > cap 0: starting GC > cap 0: GC working > cap 0: GC idle > cap 0: GC done > cap 0: GC idle > cap 0: GC done > cap 0: GC idle > cap 0: GC done > cap 0: GC idle > cap 0: GC done > cap 0: all caps stopped for GC > cap 0: finished GC > removed cap 0 from capset 0 > removed cap 0 from capset 1 > cap 0: shutting down > deleted capset 0 > deleted capset 1 > > And, it prints properly. So this is my referenced for what it should do on the TARGET. > > When I run on my TARGET, I get: > > created capset 0 of type 2 > created capset 1 of type 3 > cap 0: initialised > assigned cap 0 to capset 0 > assigned cap 0 to capset 1 > cap 0: created thread 1 > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (yielding) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (yielding) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (yielding) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (yielding) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (yielding) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (yielding) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (stack overflow) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (stack overflow) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (stack overflow) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (yielding) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (stack overflow) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (stack overflow) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (stack overflow) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (yielding) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (stack overflow) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (heap overflow) > cap 0: starting GC > cap 0: GC working > cap 0: GC idle > cap 0: GC done > cap 0: GC idle > cap 0: GC done > cap 0: GC idle > cap 0: GC done > cap 0: all caps stopped for GC > cap 0: finished GC > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (yielding) > cap 0: running thread 1 (ThreadRunGHC) > cap 0: thread 1 stopped (stack overflow) > ... > > And the debug data goes on forever, just as debugging assembly demonstrated an infinite loop. > > Clearly, the following does not occur: > > cap 0: thread 1 stopped (suspended while making a foreign call) > > And there are overflows. > > If I had to guess, it is possible that some code is in a loop retrying to foreign call, and failing. Certainly, it is in some kind of a loop, because I found a place I can put a break point and and telling GDB to continue will cause the break over and over at the same place. So somewhere there is a loop. > > I can step through the application with GDB and see names of files and offsets in assembly. But without a true source code debug, that is a bit rough, especially for someone that does not know the RTS code. If there was a way to compile such that C source code was available and a place to break, that would help. However, I suspect since it never makes a foreign call, there is no place in C to place the breakpoint anyway. So I am also assuming there is no direct way to debug with GDB. > > But, I can see debug output printed to the console. My hope is there is a way to enable more printing, or a place I can add more print functions to help find the problem. > > So I think I need one of the following: > > - A solution from someone that has seen this before, perhaps on the iPhone > - How to enable more debug logging > - Where in the source code to add debug statements to narrow down the problem > > Thanks for any help you can give. > > Mike > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Jul 8 06:03:41 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 8 Jul 2014 02:03:41 -0400 Subject: Cross compiling for Cortex A9 In-Reply-To: References: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> Message-ID: hrmmm, i seem to recall it being said that you need to use the GOLD linker on ARM. (i think some of this is detailed in http://bgamari.github.io/posts/2014-03-06-compiling-ghc-7.8-on-arm.html ) ,("ld command","arm-poky-linux-gnueabi-ld") is that GOLD? On Tue, Jul 8, 2014 at 1:51 AM, Michael Jones wrote: > I am pasting both the info from the HOST and TARGET compilers: > > HOST > ==== > > [("Project name","The Glorious Glasgow Haskell Compilation System") > ,("GCC extra via C opts"," -fwrapv") > ,("C compiler command","/usr/bin/gcc") > ,("C compiler flags"," -fno-stack-protector -Wl,--hash-size=31 > -Wl,--reduce-memory-overheads") > ,("ar command","/usr/bin/ar") > ,("ar flags","q") > ,("ar supports at file","YES") > ,("touch command","touch") > ,("dllwrap command","/bin/false") > ,("windres command","/bin/false") > ,("perl command","/usr/bin/perl") > ,("target os","OSLinux") > ,("target arch","ArchX86_64") > ,("target word size","8") > ,("target has GNU nonexec stack","True") > ,("target has .ident directive","True") > ,("target has subsections via symbols","False") > ,("LLVM llc command","llc") > ,("LLVM opt command","opt") > ,("Project version","7.6.3") > ,("Booter version","7.6.3") > ,("Stage","2") > ,("Build platform","x86_64-unknown-linux") > ,("Host platform","x86_64-unknown-linux") > ,("Target platform","x86_64-unknown-linux") > ,("Have interpreter","YES") > ,("Object splitting supported","YES") > ,("Have native code generator","YES") > ,("Support SMP","YES") > ,("Unregisterised","NO") > ,("Tables next to code","YES") > ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn > thr_debug_dyn thr_debug_p") > ,("Leading underscore","NO") > ,("Debug on","False") > ,("LibDir","/usr/lib/ghc") > ,("Global Package DB","/usr/lib/ghc/package.conf.d") > ,("Gcc Linker > flags","[\"-Wl,--hash-size=31\",\"-Wl,--reduce-memory-overheads\"]") > ,("Ld Linker flags","[\"--hash-size=31\",\"--reduce-memory-overheads\"]") > ] > > > TARGET > ======= > > [("Project name","The Glorious Glasgow Haskell Compilation System") > ,("GCC extra via C opts"," -fwrapv") > ,("C compiler command","arm-poky-linux-gnueabi-gcc") > ,("C compiler flags"," -fno-stack-protector") > ,("C compiler link flags","") > ,("ld command","arm-poky-linux-gnueabi-ld") > ,("ld flags","") > ,("ld supports compact unwind","YES") > ,("ld supports build-id","YES") > ,("ld supports filelist","NO") > ,("ld is GNU ld","YES") > ,("ar command","/usr/bin/ar") > ,("ar flags","q") > ,("ar supports at file","YES") > ,("touch command","touch") > ,("dllwrap command","/bin/false") > ,("windres command","/bin/false") > ,("libtool command","libtool") > ,("perl command","/usr/bin/perl") > ,("target os","OSLinux") > ,("target arch","ArchARM {armISA = ARMv5, armISAExt = [], armABI = HARD}") > ,("target word size","4") > ,("target has GNU nonexec stack","False") > ,("target has .ident directive","True") > ,("target has subsections via symbols","False") > ,("Unregisterised","NO") > ,("LLVM llc command","llc") > ,("LLVM opt command","opt") > ,("Project version","7.8.2") > ,("Booter version","7.6.3") > ,("Stage","1") > ,("Build platform","x86_64-unknown-linux") > ,("Host platform","x86_64-unknown-linux") > ,("Target platform","arm-unknown-linux") > ,("Have interpreter","YES") > ,("Object splitting supported","NO") > ,("Have native code generator","NO") > ,("Support SMP","YES") > ,("Tables next to code","YES") > ,("RTS ways","l debug thr thr_debug thr_l ") > ,("Support dynamic-too","YES") > ,("Support parallel --make","YES") > ,("Dynamic by default","NO") > ,("GHC Dynamic","NO") > ,("Leading underscore","NO") > ,("Debug on","False") > ,("LibDir","/usr/local/lib/arm-unknown-linux-gnueabi-ghc-7.8.2") > ,("Global Package > DB","/usr/local/lib/arm-unknown-linux-gnueabi-ghc-7.8.2/package.conf.d") > ] > > > > > On Jul 7, 2014, at 10:42 PM, Carter Schonwald > wrote: > > could you share the output of ghc --info? > > > On Tue, Jul 8, 2014 at 12:10 AM, Michael Jones wrote: > >> I am having problems building a GHC cross compiler for Linux (Yocto on a >> Wandboard) running on a Cortex A9, and need some advice on how to debug it. >> >> The cross compiler produces an executable that runs on the Target, but >> fails to print. So I need help coming up with a strategy to narrow down the >> root cause. >> >> Some details: >> >> The application: >> >> main = do >> putStrLn "Haskell start" >> >> >> The command line options work. The program runs, and I can step through >> assembly. Debug data is printed to the console. But putStrLn fails, and >> program enters an infinite loop. >> >> I compile my app as follows: >> >> arm-unknown-linux-gnueabi-ghc -debug -static Main.hs >> >> Using -threaded does not fix the problem. >> >> Let me compare debug data from a run on my HOST, with a run on my TARGET. >> First, a run from my HOST: >> >> created capset 0 of type 2 >> created capset 1 of type 3 >> cap 0: initialised >> assigned cap 0 to capset 0 >> assigned cap 0 to capset 1 >> cap 0: created thread 1 >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (suspended while making a foreign call) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (finished) >> cap 0: created thread 2 >> cap 0: running thread 2 (ThreadRunGHC) >> cap 0: thread 2 stopped (finished) >> cap 0: starting GC >> cap 0: GC working >> cap 0: GC idle >> cap 0: GC done >> cap 0: GC idle >> cap 0: GC done >> cap 0: GC idle >> cap 0: GC done >> cap 0: GC idle >> cap 0: GC done >> cap 0: all caps stopped for GC >> cap 0: finished GC >> removed cap 0 from capset 0 >> removed cap 0 from capset 1 >> cap 0: shutting down >> deleted capset 0 >> deleted capset 1 >> >> And, it prints properly. So this is my referenced for what it should do >> on the TARGET. >> >> When I run on my TARGET, I get: >> >> created capset 0 of type 2 >> created capset 1 of type 3 >> cap 0: initialised >> assigned cap 0 to capset 0 >> assigned cap 0 to capset 1 >> cap 0: created thread 1 >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (yielding) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (yielding) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (yielding) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (yielding) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (yielding) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (yielding) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (stack overflow) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (stack overflow) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (stack overflow) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (yielding) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (stack overflow) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (stack overflow) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (stack overflow) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (yielding) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (stack overflow) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (heap overflow) >> cap 0: starting GC >> cap 0: GC working >> cap 0: GC idle >> cap 0: GC done >> cap 0: GC idle >> cap 0: GC done >> cap 0: GC idle >> cap 0: GC done >> cap 0: all caps stopped for GC >> cap 0: finished GC >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (yielding) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (stack overflow) >> ... >> >> And the debug data goes on forever, just as debugging assembly >> demonstrated an infinite loop. >> >> Clearly, the following does not occur: >> >> cap 0: thread 1 stopped (suspended while making a foreign call) >> >> And there are overflows. >> >> If I had to guess, it is possible that some code is in a loop retrying to >> foreign call, and failing. Certainly, it is in some kind of a loop, because >> I found a place I can put a break point and and telling GDB to continue >> will cause the break over and over at the same place. So somewhere there is >> a loop. >> >> I can step through the application with GDB and see names of files and >> offsets in assembly. But without a true source code debug, that is a bit >> rough, especially for someone that does not know the RTS code. If there was >> a way to compile such that C source code was available and a place to >> break, that would help. However, I suspect since it never makes a foreign >> call, there is no place in C to place the breakpoint anyway. So I am also >> assuming there is no direct way to debug with GDB. >> >> But, I can see debug output printed to the console. My hope is there is a >> way to enable more printing, or a place I can add more print functions to >> help find the problem. >> >> So I think I need one of the following: >> >> - A solution from someone that has seen this before, perhaps on the iPhone >> - How to enable more debug logging >> - Where in the source code to add debug statements to narrow down the >> problem >> >> Thanks for any help you can give. >> >> Mike >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukexipd at gmail.com Tue Jul 8 06:06:12 2014 From: lukexipd at gmail.com (Luke Iannini) Date: Mon, 7 Jul 2014 23:06:12 -0700 Subject: ARM64 Task Force Message-ID: Howdy all, Would anyone like to team up on getting ARM64 support into GHC? Cheers Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at proclivis.com Tue Jul 8 13:25:12 2014 From: mike at proclivis.com (Michael Jones) Date: Tue, 8 Jul 2014 07:25:12 -0600 Subject: Cross compiling for Cortex A9 In-Reply-To: References: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> Message-ID: <26E11031-CBF2-4D30-A043-85097FEE8CF1@proclivis.com> That doc says: ...This will usually manifest itself as a failure of dll-split during the build process with internal error: evacuate(static): strange closure type 0. Which does not happen when I build. Until this is fixed, the newer gold linker will be the only supported linker with GHC on ARM (at least when tables-next-to-code is enabled). GHC now checks that the linker being used isn?t affected by the bug in question, so hopefully users won?t be affected beyond needing to switch linkers. And I don't get an error indicating this bug unless it is a warning missed in the massive build output. So I assumed all was fixed. Nonetheless, I'll dig into the linker notes a bit more. Perhaps I should just try the gold linker if Ben does not respond to this enquiry. Mike Sent from my iPad > On Jul 8, 2014, at 12:03 AM, Carter Schonwald wrote: > > hrmmm, i seem to recall it being said that you need to use the GOLD linker on ARM. (i think some of this is detailed in http://bgamari.github.io/posts/2014-03-06-compiling-ghc-7.8-on-arm.html ) > > ,("ld command","arm-poky-linux-gnueabi-ld") > is that GOLD? > > >> On Tue, Jul 8, 2014 at 1:51 AM, Michael Jones wrote: >> I am pasting both the info from the HOST and TARGET compilers: >> >> HOST >> ==== >> >> [("Project name","The Glorious Glasgow Haskell Compilation System") >> ,("GCC extra via C opts"," -fwrapv") >> ,("C compiler command","/usr/bin/gcc") >> ,("C compiler flags"," -fno-stack-protector -Wl,--hash-size=31 -Wl,--reduce-memory-overheads") >> ,("ar command","/usr/bin/ar") >> ,("ar flags","q") >> ,("ar supports at file","YES") >> ,("touch command","touch") >> ,("dllwrap command","/bin/false") >> ,("windres command","/bin/false") >> ,("perl command","/usr/bin/perl") >> ,("target os","OSLinux") >> ,("target arch","ArchX86_64") >> ,("target word size","8") >> ,("target has GNU nonexec stack","True") >> ,("target has .ident directive","True") >> ,("target has subsections via symbols","False") >> ,("LLVM llc command","llc") >> ,("LLVM opt command","opt") >> ,("Project version","7.6.3") >> ,("Booter version","7.6.3") >> ,("Stage","2") >> ,("Build platform","x86_64-unknown-linux") >> ,("Host platform","x86_64-unknown-linux") >> ,("Target platform","x86_64-unknown-linux") >> ,("Have interpreter","YES") >> ,("Object splitting supported","YES") >> ,("Have native code generator","YES") >> ,("Support SMP","YES") >> ,("Unregisterised","NO") >> ,("Tables next to code","YES") >> ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn thr_debug_p") >> ,("Leading underscore","NO") >> ,("Debug on","False") >> ,("LibDir","/usr/lib/ghc") >> ,("Global Package DB","/usr/lib/ghc/package.conf.d") >> ,("Gcc Linker flags","[\"-Wl,--hash-size=31\",\"-Wl,--reduce-memory-overheads\"]") >> ,("Ld Linker flags","[\"--hash-size=31\",\"--reduce-memory-overheads\"]") >> ] >> >> >> TARGET >> ======= >> >> [("Project name","The Glorious Glasgow Haskell Compilation System") >> ,("GCC extra via C opts"," -fwrapv") >> ,("C compiler command","arm-poky-linux-gnueabi-gcc") >> ,("C compiler flags"," -fno-stack-protector") >> ,("C compiler link flags","") >> ,("ld command","arm-poky-linux-gnueabi-ld") >> ,("ld flags","") >> ,("ld supports compact unwind","YES") >> ,("ld supports build-id","YES") >> ,("ld supports filelist","NO") >> ,("ld is GNU ld","YES") >> ,("ar command","/usr/bin/ar") >> ,("ar flags","q") >> ,("ar supports at file","YES") >> ,("touch command","touch") >> ,("dllwrap command","/bin/false") >> ,("windres command","/bin/false") >> ,("libtool command","libtool") >> ,("perl command","/usr/bin/perl") >> ,("target os","OSLinux") >> ,("target arch","ArchARM {armISA = ARMv5, armISAExt = [], armABI = HARD}") >> ,("target word size","4") >> ,("target has GNU nonexec stack","False") >> ,("target has .ident directive","True") >> ,("target has subsections via symbols","False") >> ,("Unregisterised","NO") >> ,("LLVM llc command","llc") >> ,("LLVM opt command","opt") >> ,("Project version","7.8.2") >> ,("Booter version","7.6.3") >> ,("Stage","1") >> ,("Build platform","x86_64-unknown-linux") >> ,("Host platform","x86_64-unknown-linux") >> ,("Target platform","arm-unknown-linux") >> ,("Have interpreter","YES") >> ,("Object splitting supported","NO") >> ,("Have native code generator","NO") >> ,("Support SMP","YES") >> ,("Tables next to code","YES") >> ,("RTS ways","l debug thr thr_debug thr_l ") >> ,("Support dynamic-too","YES") >> ,("Support parallel --make","YES") >> ,("Dynamic by default","NO") >> ,("GHC Dynamic","NO") >> ,("Leading underscore","NO") >> ,("Debug on","False") >> ,("LibDir","/usr/local/lib/arm-unknown-linux-gnueabi-ghc-7.8.2") >> ,("Global Package DB","/usr/local/lib/arm-unknown-linux-gnueabi-ghc-7.8.2/package.conf.d") >> ] >> >> >> >> >>> On Jul 7, 2014, at 10:42 PM, Carter Schonwald wrote: >>> >>> could you share the output of ghc --info? >>> >>> >>>> On Tue, Jul 8, 2014 at 12:10 AM, Michael Jones wrote: >>>> I am having problems building a GHC cross compiler for Linux (Yocto on a Wandboard) running on a Cortex A9, and need some advice on how to debug it. >>>> >>>> The cross compiler produces an executable that runs on the Target, but fails to print. So I need help coming up with a strategy to narrow down the root cause. >>>> >>>> Some details: >>>> >>>> The application: >>>> >>>> main = do >>>> putStrLn "Haskell start" >>>> >>>> >>>> The command line options work. The program runs, and I can step through assembly. Debug data is printed to the console. But putStrLn fails, and program enters an infinite loop. >>>> >>>> I compile my app as follows: >>>> >>>> arm-unknown-linux-gnueabi-ghc -debug -static Main.hs >>>> >>>> Using -threaded does not fix the problem. >>>> >>>> Let me compare debug data from a run on my HOST, with a run on my TARGET. First, a run from my HOST: >>>> >>>> created capset 0 of type 2 >>>> created capset 1 of type 3 >>>> cap 0: initialised >>>> assigned cap 0 to capset 0 >>>> assigned cap 0 to capset 1 >>>> cap 0: created thread 1 >>>> cap 0: running thread 1 (ThreadRunGHC) >>>> cap 0: thread 1 stopped (suspended while making a foreign call) >>>> cap 0: running thread 1 (ThreadRunGHC) >>>> cap 0: thread 1 stopped (finished) >>>> cap 0: created thread 2 >>>> cap 0: running thread 2 (ThreadRunGHC) >>>> cap 0: thread 2 stopped (finished) >>>> cap 0: starting GC >>>> cap 0: GC working >>>> cap 0: GC idle >>>> cap 0: GC done >>>> cap 0: GC idle >>>> cap 0: GC done >>>> cap 0: GC idle >>>> cap 0: GC done >>>> cap 0: GC idle >>>> cap 0: GC done >>>> cap 0: all caps stopped for GC >>>> cap 0: finished GC >>>> removed cap 0 from capset 0 >>>> removed cap 0 from capset 1 >>>> cap 0: shutting down >>>> deleted capset 0 >>>> deleted capset 1 >>>> >>>> And, it prints properly. So this is my referenced for what it should do on the TARGET. >>>> >>>> When I run on my TARGET, I get: >>>> >>>> created capset 0 of type 2 >>>> created capset 1 of type 3 >>>> cap 0: initialised >>>> assigned cap 0 to capset 0 >>>> assigned cap 0 to capset 1 >>>> cap 0: created thread 1 >>>> cap 0: running thread 1 (ThreadRunGHC) >>>> cap 0: thread 1 stopped (yielding) >>>> cap 0: running thread 1 (ThreadRunGHC) >>>> cap 0: thread 1 stopped (yielding) >>>> cap 0: running thread 1 (ThreadRunGHC) >>>> cap 0: thread 1 stopped (yielding) >>>> cap 0: running thread 1 (ThreadRunGHC) >>>> cap 0: thread 1 stopped (yielding) >>>> cap 0: running thread 1 (ThreadRunGHC) >>>> cap 0: thread 1 stopped (yielding) >>>> cap 0: running thread 1 (ThreadRunGHC) >>>> cap 0: thread 1 stopped (yielding) >>>> cap 0: running thread 1 (ThreadRunGHC) >>>> cap 0: thread 1 stopped (stack overflow) >>>> cap 0: running thread 1 (ThreadRunGHC) >>>> cap 0: thread 1 stopped (stack overflow) >>>> cap 0: running thread 1 (ThreadRunGHC) >>>> cap 0: thread 1 stopped (stack overflow) >>>> cap 0: running thread 1 (ThreadRunGHC) >>>> cap 0: thread 1 stopped (yielding) >>>> cap 0: running thread 1 (ThreadRunGHC) >>>> cap 0: thread 1 stopped (stack overflow) >>>> cap 0: running thread 1 (ThreadRunGHC) >>>> cap 0: thread 1 stopped (stack overflow) >>>> cap 0: running thread 1 (ThreadRunGHC) >>>> cap 0: thread 1 stopped (stack overflow) >>>> cap 0: running thread 1 (ThreadRunGHC) >>>> cap 0: thread 1 stopped (yielding) >>>> cap 0: running thread 1 (ThreadRunGHC) >>>> cap 0: thread 1 stopped (stack overflow) >>>> cap 0: running thread 1 (ThreadRunGHC) >>>> cap 0: thread 1 stopped (heap overflow) >>>> cap 0: starting GC >>>> cap 0: GC working >>>> cap 0: GC idle >>>> cap 0: GC done >>>> cap 0: GC idle >>>> cap 0: GC done >>>> cap 0: GC idle >>>> cap 0: GC done >>>> cap 0: all caps stopped for GC >>>> cap 0: finished GC >>>> cap 0: running thread 1 (ThreadRunGHC) >>>> cap 0: thread 1 stopped (yielding) >>>> cap 0: running thread 1 (ThreadRunGHC) >>>> cap 0: thread 1 stopped (stack overflow) >>>> ... >>>> >>>> And the debug data goes on forever, just as debugging assembly demonstrated an infinite loop. >>>> >>>> Clearly, the following does not occur: >>>> >>>> cap 0: thread 1 stopped (suspended while making a foreign call) >>>> >>>> And there are overflows. >>>> >>>> If I had to guess, it is possible that some code is in a loop retrying to foreign call, and failing. Certainly, it is in some kind of a loop, because I found a place I can put a break point and and telling GDB to continue will cause the break over and over at the same place. So somewhere there is a loop. >>>> >>>> I can step through the application with GDB and see names of files and offsets in assembly. But without a true source code debug, that is a bit rough, especially for someone that does not know the RTS code. If there was a way to compile such that C source code was available and a place to break, that would help. However, I suspect since it never makes a foreign call, there is no place in C to place the breakpoint anyway. So I am also assuming there is no direct way to debug with GDB. >>>> >>>> But, I can see debug output printed to the console. My hope is there is a way to enable more printing, or a place I can add more print functions to help find the problem. >>>> >>>> So I think I need one of the following: >>>> >>>> - A solution from someone that has seen this before, perhaps on the iPhone >>>> - How to enable more debug logging >>>> - Where in the source code to add debug statements to narrow down the problem >>>> >>>> Thanks for any help you can give. >>>> >>>> Mike >>>> >>>> >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users at haskell.org >>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christian.Maeder at dfki.de Wed Jul 9 11:03:50 2014 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed, 09 Jul 2014 13:03:50 +0200 Subject: ghc -M In-Reply-To: <5357787F.4070002@dfki.de> References: <5357787F.4070002@dfki.de> Message-ID: <53BD2196.1000404@dfki.de> I've created a ticket for the changed makefile dependencies! https://ghc.haskell.org/trac/ghc/ticket/9287 C. Am 23.04.2014 10:23, schrieb Christian Maeder: > Hi, > > using "ghc -M" with ghc-7.8.2 under linux. I got a message: > > You must specify at least one -dep-suffix > > (and a failure). > > http://www.haskell.org/ghc/docs/7.8.1/html/users_guide/separate-compilation.html#makefile-dependencies > > > I've stopped using "ghc -M" now, but I think it should be documented > better. > > Maybe dynamic linking complicated matters. > > Cheers Christian > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From bgamari.foss at gmail.com Wed Jul 9 20:27:30 2014 From: bgamari.foss at gmail.com (Ben Gamari) Date: Wed, 09 Jul 2014 16:27:30 -0400 Subject: Cross compiling for Cortex A9 In-Reply-To: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> References: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> Message-ID: <871ttuwa4t.fsf@gmail.com> Michael Jones writes: > I am having problems building a GHC cross compiler for Linux (Yocto on > a Wandboard) running on a Cortex A9, and need some advice on how to > debug it. > Sorry for the delay, almost overlooked this one! > The cross compiler produces an executable that runs on the Target, but > fails to print. So I need help coming up with a strategy to narrow > down the root cause. > > Some details: > > The application: > > main = do > putStrLn "Haskell start" > > > The command line options work. The program runs, and I can step > through assembly. Debug data is printed to the console. But putStrLn > fails, and program enters an infinite loop. > Hmmm, very peculiar. I would probably begin by compiling with `-auto-all -caf-all -prof` and run the resulting executable with `+RTS -xc`. SIGINT the process after a second or so and see what the backtrace looks like. While worth trying, this probably won't help too much as your problem is likely RTS-related. You might try stracing the executable and see if it is ever even trying a syscall. Unfortunately, I doubt it is as the program appears to be hitting heap and stack overflows. This is quite perplexing. I'm going to try to reproduce the issue on my end. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From mike at proclivis.com Thu Jul 10 05:23:58 2014 From: mike at proclivis.com (Michael Jones) Date: Wed, 9 Jul 2014 23:23:58 -0600 Subject: Cross compiling for Cortex A9 In-Reply-To: <871ttuwa4t.fsf@gmail.com> References: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> <871ttuwa4t.fsf@gmail.com> Message-ID: Ben, I ran into a snag trying to use the options you suggested. First, I was not sure where to use the flags, so I pasted a piece of my build.mk. You can correct it if I have it wrong. I also get a compile error that I pasted after the build.mk text. I have not made any changes except in aclocal.m4 so that my configure can recognize the target. It can?t figure out the tools, so I add options for all of them. The tools are for the target. That was my interpretation of the wiki. It finds the host tools on its own. add eabi support in aclocal.m4... autoreconf ./configure --target=arm-linux-gnueabi --with-gcc=arm-poky-linux-gnueabi-gcc --with-ld=arm-poky-linux-gnueabi-ld --with-nm=arm-poky-linux-gnueabi-nm --with-ar=arm-poky-linux-gnueabi-ar --with-ranlib=arm-poky-linux-gnueabi-ranlib # -------- A Fast build configured for cross-compilation ---------------------- ifeq "$(BuildFlavour)" "quick-cross" SRC_HC_OPTS = -H64m -O0 -auto-all -caf-all -prof GhcStage1HcOpts = -O -fllvm -auto-all -caf-all -prof GhcStage2HcOpts = -O0 -fllvm GhcLibHcOpts = -O -fllvm -auto-all -caf-all -prof SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO INTEGER_LIBRARY = integer-simple Stage1Only = YES DYNAMIC_BY_DEFAULT = NO DYNAMIC_GHC_PROGRAMS = NO endif echo "compiler_stage1_depfile_haskell_EXISTS = YES" >> compiler/stage1/build/.depend-v.haskell.tmp for dir in compiler/stage1/build/./ compiler/stage1/build/CodeGen/ compiler/stage1/build/CodeGen/Platform/ compiler/stage1/build/Hoopl/ compiler/stage1/build/Llvm/ compiler/stage1/build/LlvmCodeGen/ compiler/stage1/build/PPC/ compiler/stage1/build/RegAlloc/ compiler/stage1/build/RegAlloc/Graph/ compiler/stage1/build/RegAlloc/Linear/ compiler/stage1/build/RegAlloc/Linear/PPC/ compiler/stage1/build/RegAlloc/Linear/SPARC/ compiler/stage1/build/RegAlloc/Linear/X86/ compiler/stage1/build/RegAlloc/Linear/X86_64/ compiler/stage1/build/SPARC/ compiler/stage1/build/SPARC/CodeGen/ compiler/stage1/build/Vectorise/ compiler/stage1/build/Vectorise/Builtins/ compiler/stage1/build/Vectorise/Generic/ compiler/stage1/build/Vectorise/Monad/ compiler/stage1/build/Vectorise/Type/ compiler/stage1/build/Vectorise/Utils/ compiler/stage1/build/X86/; do if test ! -d $dir; then mkdir -p $dir; fi done grep -v ' : [a-zA-Z]:/' compiler/stage1/build/.depend-v.haskell.tmp > compiler/stage1/build/.depend-v.haskell.tmp2 sed -e '/hs$/ p' -e '/hs$/ s/o /hi /g' -e '/hs$/ s/:/ : %hi: %o /' -e '/hs$/ s/^/$(eval $(call hi-rule,/' -e '/hs$/ s/$/))/' -e '/hs-boot$/ p' -e '/hs-boot$/ s/o-boot /hi-boot /g' -e '/hs-boot$/ s/:/ : %hi-boot: %o-boot /' -e '/hs-boot$/ s/^/$(eval $(call hi-rule,/' -e '/hs-boot$/ s/$/))/' compiler/stage1/build/.depend-v.haskell.tmp2 > compiler/stage1/build/.depend-v.haskell utils/ghc-pkg/ghc.mk:46: warning: overriding commands for target `install_utils/ghc-pkg_dist_wrapper' utils/ghc-pkg/ghc.mk:37: warning: ignoring old commands for target `install_utils/ghc-pkg_dist_wrapper' make[1]: *** No rule to make target `libraries/terminfo/dist-boot/build/System/Console/Terminfo.p_hi', needed by `utils/ghc-pkg/dist/build/Main.o'. Stop. On Jul 9, 2014, at 2:27 PM, Ben Gamari wrote: > Michael Jones writes: > >> I am having problems building a GHC cross compiler for Linux (Yocto on >> a Wandboard) running on a Cortex A9, and need some advice on how to >> debug it. >> > Sorry for the delay, almost overlooked this one! > >> The cross compiler produces an executable that runs on the Target, but >> fails to print. So I need help coming up with a strategy to narrow >> down the root cause. >> >> Some details: >> >> The application: >> >> main = do >> putStrLn "Haskell start" >> >> >> The command line options work. The program runs, and I can step >> through assembly. Debug data is printed to the console. But putStrLn >> fails, and program enters an infinite loop. >> > Hmmm, very peculiar. I would probably begin by compiling with `-auto-all > -caf-all -prof` and run the resulting executable with `+RTS -xc`. SIGINT > the process after a second or so and see what the backtrace looks like. > > While worth trying, this probably won't help too much as your problem is > likely RTS-related. You might try stracing the executable and see if it > is ever even trying a syscall. > > Unfortunately, I doubt it is as the program appears to be hitting heap > and stack overflows. This is quite perplexing. I'm going to try to > reproduce the issue on my end. > > Cheers, > > - Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From karel.gardas at centrum.cz Fri Jul 11 10:35:10 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Fri, 11 Jul 2014 12:35:10 +0200 Subject: Cross compiling for Cortex A9 In-Reply-To: References: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> Message-ID: <53BFBDDE.1040509@centrum.cz> I'm not sure if this is already solved, but if you cross-compile to A9, why do you use ARMv5 platform OS? ("target arch","ArchARM {armISA = ARMv5, armISAExt = [], armABI = HARD}") this looks really strange. armABI HARD, that means FP data in FP regs, still no VFP in armISAExt and even armISA set to ARMv5. For example on my ubuntu 12.04 I do have: ("target arch", "ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}"), which is right for pandaboard which is dual Cortex-A9. So, shortly I really do not know if you do not hit some corner case in LLVM here. I would certainly suggest especially considering your Cortex-A9 target to update your OS to get to what I do have here: ARMv7+VFPv3/NEON+ABI HARD. BTW: Another issue may be that GHC misconfigures on your platform and they you will need to tell us more about your target OS... Cheers, Karel On 07/ 8/14 07:51 AM, Michael Jones wrote: > I am pasting both the info from the HOST and TARGET compilers: > > HOST > ==== > > [("Project name","The Glorious Glasgow Haskell Compilation System") > ,("GCC extra via C opts"," -fwrapv") > ,("C compiler command","/usr/bin/gcc") > ,("C compiler flags"," -fno-stack-protector -Wl,--hash-size=31 > -Wl,--reduce-memory-overheads") > ,("ar command","/usr/bin/ar") > ,("ar flags","q") > ,("ar supports at file","YES") > ,("touch command","touch") > ,("dllwrap command","/bin/false") > ,("windres command","/bin/false") > ,("perl command","/usr/bin/perl") > ,("target os","OSLinux") > ,("target arch","ArchX86_64") > ,("target word size","8") > ,("target has GNU nonexec stack","True") > ,("target has .ident directive","True") > ,("target has subsections via symbols","False") > ,("LLVM llc command","llc") > ,("LLVM opt command","opt") > ,("Project version","7.6.3") > ,("Booter version","7.6.3") > ,("Stage","2") > ,("Build platform","x86_64-unknown-linux") > ,("Host platform","x86_64-unknown-linux") > ,("Target platform","x86_64-unknown-linux") > ,("Have interpreter","YES") > ,("Object splitting supported","YES") > ,("Have native code generator","YES") > ,("Support SMP","YES") > ,("Unregisterised","NO") > ,("Tables next to code","YES") > ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn > thr_debug_dyn thr_debug_p") > ,("Leading underscore","NO") > ,("Debug on","False") > ,("LibDir","/usr/lib/ghc") > ,("Global Package DB","/usr/lib/ghc/package.conf.d") > ,("Gcc Linker > flags","[\"-Wl,--hash-size=31\",\"-Wl,--reduce-memory-overheads\"]") > ,("Ld Linker flags","[\"--hash-size=31\",\"--reduce-memory-overheads\"]") > ] > > > TARGET > ======= > > [("Project name","The Glorious Glasgow Haskell Compilation System") > ,("GCC extra via C opts"," -fwrapv") > ,("C compiler command","arm-poky-linux-gnueabi-gcc") > ,("C compiler flags"," -fno-stack-protector") > ,("C compiler link flags","") > ,("ld command","arm-poky-linux-gnueabi-ld") > ,("ld flags","") > ,("ld supports compact unwind","YES") > ,("ld supports build-id","YES") > ,("ld supports filelist","NO") > ,("ld is GNU ld","YES") > ,("ar command","/usr/bin/ar") > ,("ar flags","q") > ,("ar supports at file","YES") > ,("touch command","touch") > ,("dllwrap command","/bin/false") > ,("windres command","/bin/false") > ,("libtool command","libtool") > ,("perl command","/usr/bin/perl") > ,("target os","OSLinux") > ,("target arch","ArchARM {armISA = ARMv5, armISAExt = [], armABI = HARD}") > ,("target word size","4") > ,("target has GNU nonexec stack","False") > ,("target has .ident directive","True") > ,("target has subsections via symbols","False") > ,("Unregisterised","NO") > ,("LLVM llc command","llc") > ,("LLVM opt command","opt") > ,("Project version","7.8.2") > ,("Booter version","7.6.3") > ,("Stage","1") > ,("Build platform","x86_64-unknown-linux") > ,("Host platform","x86_64-unknown-linux") > ,("Target platform","arm-unknown-linux") > ,("Have interpreter","YES") > ,("Object splitting supported","NO") > ,("Have native code generator","NO") > ,("Support SMP","YES") > ,("Tables next to code","YES") > ,("RTS ways","l debug thr thr_debug thr_l ") > ,("Support dynamic-too","YES") > ,("Support parallel --make","YES") > ,("Dynamic by default","NO") > ,("GHC Dynamic","NO") > ,("Leading underscore","NO") > ,("Debug on","False") > ,("LibDir","/usr/local/lib/arm-unknown-linux-gnueabi-ghc-7.8.2") > ,("Global Package > DB","/usr/local/lib/arm-unknown-linux-gnueabi-ghc-7.8.2/package.conf.d") > ] > > > > > On Jul 7, 2014, at 10:42 PM, Carter Schonwald > > wrote: > >> could you share the output of ghc --info? >> >> >> On Tue, Jul 8, 2014 at 12:10 AM, Michael Jones > > wrote: >> >> I am having problems building a GHC cross compiler for Linux >> (Yocto on a Wandboard) running on a Cortex A9, and need some >> advice on how to debug it. >> >> The cross compiler produces an executable that runs on the Target, >> but fails to print. So I need help coming up with a strategy to >> narrow down the root cause. >> >> Some details: >> >> The application: >> >> main = do >> putStrLn "Haskell start" >> >> >> The command line options work. The program runs, and I can step >> through assembly. Debug data is printed to the console. But >> putStrLn fails, and program enters an infinite loop. >> >> I compile my app as follows: >> >> arm-unknown-linux-gnueabi-ghc -debug -static Main.hs >> >> Using -threaded does not fix the problem. >> >> Let me compare debug data from a run on my HOST, with a run on my >> TARGET. First, a run from my HOST: >> >> created capset 0 of type 2 >> created capset 1 of type 3 >> cap 0: initialised >> assigned cap 0 to capset 0 >> assigned cap 0 to capset 1 >> cap 0: created thread 1 >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (suspended while making a foreign call) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (finished) >> cap 0: created thread 2 >> cap 0: running thread 2 (ThreadRunGHC) >> cap 0: thread 2 stopped (finished) >> cap 0: starting GC >> cap 0: GC working >> cap 0: GC idle >> cap 0: GC done >> cap 0: GC idle >> cap 0: GC done >> cap 0: GC idle >> cap 0: GC done >> cap 0: GC idle >> cap 0: GC done >> cap 0: all caps stopped for GC >> cap 0: finished GC >> removed cap 0 from capset 0 >> removed cap 0 from capset 1 >> cap 0: shutting down >> deleted capset 0 >> deleted capset 1 >> >> And, it prints properly. So this is my referenced for what it >> should do on the TARGET. >> >> When I run on my TARGET, I get: >> >> created capset 0 of type 2 >> created capset 1 of type 3 >> cap 0: initialised >> assigned cap 0 to capset 0 >> assigned cap 0 to capset 1 >> cap 0: created thread 1 >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (yielding) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (yielding) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (yielding) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (yielding) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (yielding) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (yielding) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (stack overflow) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (stack overflow) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (stack overflow) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (yielding) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (stack overflow) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (stack overflow) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (stack overflow) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (yielding) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (stack overflow) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (heap overflow) >> cap 0: starting GC >> cap 0: GC working >> cap 0: GC idle >> cap 0: GC done >> cap 0: GC idle >> cap 0: GC done >> cap 0: GC idle >> cap 0: GC done >> cap 0: all caps stopped for GC >> cap 0: finished GC >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (yielding) >> cap 0: running thread 1 (ThreadRunGHC) >> cap 0: thread 1 stopped (stack overflow) >> ... >> >> And the debug data goes on forever, just as debugging assembly >> demonstrated an infinite loop. >> >> Clearly, the following does not occur: >> >> cap 0: thread 1 stopped (suspended while making a foreign call) >> >> And there are overflows. >> >> If I had to guess, it is possible that some code is in a loop >> retrying to foreign call, and failing. Certainly, it is in some >> kind of a loop, because I found a place I can put a break point >> and and telling GDB to continue will cause the break over and over >> at the same place. So somewhere there is a loop. >> >> I can step through the application with GDB and see names of files >> and offsets in assembly. But without a true source code debug, >> that is a bit rough, especially for someone that does not know the >> RTS code. If there was a way to compile such that C source code >> was available and a place to break, that would help. However, I >> suspect since it never makes a foreign call, there is no place in >> C to place the breakpoint anyway. So I am also assuming there is >> no direct way to debug with GDB. >> >> But, I can see debug output printed to the console. My hope is >> there is a way to enable more printing, or a place I can add more >> print functions to help find the problem. >> >> So I think I need one of the following: >> >> - A solution from someone that has seen this before, perhaps on >> the iPhone >> - How to enable more debug logging >> - Where in the source code to add debug statements to narrow down >> the problem >> >> Thanks for any help you can give. >> >> Mike >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From mike at proclivis.com Fri Jul 11 11:56:33 2014 From: mike at proclivis.com (Michael Jones) Date: Fri, 11 Jul 2014 05:56:33 -0600 Subject: Cross compiling for Cortex A9 In-Reply-To: <53BFBDDE.1040509@centrum.cz> References: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> <53BFBDDE.1040509@centrum.cz> Message-ID: <7D6EC01E-9CB9-44C5-950A-D39B7BA8731A@proclivis.com> Karel, Not solved yet, but I did not notice the target problem. It is obvious once pointed out. I?ll try to fix that and try again and report back. Thanks, Mike On Jul 11, 2014, at 4:35 AM, Karel Gardas wrote: > > I'm not sure if this is already solved, but if you cross-compile to A9, why do you use ARMv5 platform OS? > > ("target arch","ArchARM {armISA = ARMv5, armISAExt = [], armABI = HARD}") > > this looks really strange. armABI HARD, that means FP data in FP regs, still no VFP in armISAExt and even armISA set to ARMv5. > > For example on my ubuntu 12.04 I do have: > > ("target arch", "ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}"), > > which is right for pandaboard which is dual Cortex-A9. > > So, shortly I really do not know if you do not hit some corner case in LLVM here. I would certainly suggest especially considering your Cortex-A9 target to update your OS to get to what I do have here: ARMv7+VFPv3/NEON+ABI HARD. > > BTW: Another issue may be that GHC misconfigures on your platform and they you will need to tell us more about your target OS... > > Cheers, > Karel > > On 07/ 8/14 07:51 AM, Michael Jones wrote: >> I am pasting both the info from the HOST and TARGET compilers: >> >> HOST >> ==== >> >> [("Project name","The Glorious Glasgow Haskell Compilation System") >> ,("GCC extra via C opts"," -fwrapv") >> ,("C compiler command","/usr/bin/gcc") >> ,("C compiler flags"," -fno-stack-protector -Wl,--hash-size=31 >> -Wl,--reduce-memory-overheads") >> ,("ar command","/usr/bin/ar") >> ,("ar flags","q") >> ,("ar supports at file","YES") >> ,("touch command","touch") >> ,("dllwrap command","/bin/false") >> ,("windres command","/bin/false") >> ,("perl command","/usr/bin/perl") >> ,("target os","OSLinux") >> ,("target arch","ArchX86_64") >> ,("target word size","8") >> ,("target has GNU nonexec stack","True") >> ,("target has .ident directive","True") >> ,("target has subsections via symbols","False") >> ,("LLVM llc command","llc") >> ,("LLVM opt command","opt") >> ,("Project version","7.6.3") >> ,("Booter version","7.6.3") >> ,("Stage","2") >> ,("Build platform","x86_64-unknown-linux") >> ,("Host platform","x86_64-unknown-linux") >> ,("Target platform","x86_64-unknown-linux") >> ,("Have interpreter","YES") >> ,("Object splitting supported","YES") >> ,("Have native code generator","YES") >> ,("Support SMP","YES") >> ,("Unregisterised","NO") >> ,("Tables next to code","YES") >> ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn >> thr_debug_dyn thr_debug_p") >> ,("Leading underscore","NO") >> ,("Debug on","False") >> ,("LibDir","/usr/lib/ghc") >> ,("Global Package DB","/usr/lib/ghc/package.conf.d") >> ,("Gcc Linker >> flags","[\"-Wl,--hash-size=31\",\"-Wl,--reduce-memory-overheads\"]") >> ,("Ld Linker flags","[\"--hash-size=31\",\"--reduce-memory-overheads\"]") >> ] >> >> >> TARGET >> ======= >> >> [("Project name","The Glorious Glasgow Haskell Compilation System") >> ,("GCC extra via C opts"," -fwrapv") >> ,("C compiler command","arm-poky-linux-gnueabi-gcc") >> ,("C compiler flags"," -fno-stack-protector") >> ,("C compiler link flags","") >> ,("ld command","arm-poky-linux-gnueabi-ld") >> ,("ld flags","") >> ,("ld supports compact unwind","YES") >> ,("ld supports build-id","YES") >> ,("ld supports filelist","NO") >> ,("ld is GNU ld","YES") >> ,("ar command","/usr/bin/ar") >> ,("ar flags","q") >> ,("ar supports at file","YES") >> ,("touch command","touch") >> ,("dllwrap command","/bin/false") >> ,("windres command","/bin/false") >> ,("libtool command","libtool") >> ,("perl command","/usr/bin/perl") >> ,("target os","OSLinux") >> ,("target arch","ArchARM {armISA = ARMv5, armISAExt = [], armABI = HARD}") >> ,("target word size","4") >> ,("target has GNU nonexec stack","False") >> ,("target has .ident directive","True") >> ,("target has subsections via symbols","False") >> ,("Unregisterised","NO") >> ,("LLVM llc command","llc") >> ,("LLVM opt command","opt") >> ,("Project version","7.8.2") >> ,("Booter version","7.6.3") >> ,("Stage","1") >> ,("Build platform","x86_64-unknown-linux") >> ,("Host platform","x86_64-unknown-linux") >> ,("Target platform","arm-unknown-linux") >> ,("Have interpreter","YES") >> ,("Object splitting supported","NO") >> ,("Have native code generator","NO") >> ,("Support SMP","YES") >> ,("Tables next to code","YES") >> ,("RTS ways","l debug thr thr_debug thr_l ") >> ,("Support dynamic-too","YES") >> ,("Support parallel --make","YES") >> ,("Dynamic by default","NO") >> ,("GHC Dynamic","NO") >> ,("Leading underscore","NO") >> ,("Debug on","False") >> ,("LibDir","/usr/local/lib/arm-unknown-linux-gnueabi-ghc-7.8.2") >> ,("Global Package >> DB","/usr/local/lib/arm-unknown-linux-gnueabi-ghc-7.8.2/package.conf.d") >> ] >> >> >> >> >> On Jul 7, 2014, at 10:42 PM, Carter Schonwald >> > wrote: >> >>> could you share the output of ghc --info? >>> >>> >>> On Tue, Jul 8, 2014 at 12:10 AM, Michael Jones >> > wrote: >>> >>> I am having problems building a GHC cross compiler for Linux >>> (Yocto on a Wandboard) running on a Cortex A9, and need some >>> advice on how to debug it. >>> >>> The cross compiler produces an executable that runs on the Target, >>> but fails to print. So I need help coming up with a strategy to >>> narrow down the root cause. >>> >>> Some details: >>> >>> The application: >>> >>> main = do >>> putStrLn "Haskell start" >>> >>> >>> The command line options work. The program runs, and I can step >>> through assembly. Debug data is printed to the console. But >>> putStrLn fails, and program enters an infinite loop. >>> >>> I compile my app as follows: >>> >>> arm-unknown-linux-gnueabi-ghc -debug -static Main.hs >>> >>> Using -threaded does not fix the problem. >>> >>> Let me compare debug data from a run on my HOST, with a run on my >>> TARGET. First, a run from my HOST: >>> >>> created capset 0 of type 2 >>> created capset 1 of type 3 >>> cap 0: initialised >>> assigned cap 0 to capset 0 >>> assigned cap 0 to capset 1 >>> cap 0: created thread 1 >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (suspended while making a foreign call) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (finished) >>> cap 0: created thread 2 >>> cap 0: running thread 2 (ThreadRunGHC) >>> cap 0: thread 2 stopped (finished) >>> cap 0: starting GC >>> cap 0: GC working >>> cap 0: GC idle >>> cap 0: GC done >>> cap 0: GC idle >>> cap 0: GC done >>> cap 0: GC idle >>> cap 0: GC done >>> cap 0: GC idle >>> cap 0: GC done >>> cap 0: all caps stopped for GC >>> cap 0: finished GC >>> removed cap 0 from capset 0 >>> removed cap 0 from capset 1 >>> cap 0: shutting down >>> deleted capset 0 >>> deleted capset 1 >>> >>> And, it prints properly. So this is my referenced for what it >>> should do on the TARGET. >>> >>> When I run on my TARGET, I get: >>> >>> created capset 0 of type 2 >>> created capset 1 of type 3 >>> cap 0: initialised >>> assigned cap 0 to capset 0 >>> assigned cap 0 to capset 1 >>> cap 0: created thread 1 >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (yielding) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (yielding) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (yielding) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (yielding) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (yielding) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (yielding) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (stack overflow) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (stack overflow) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (stack overflow) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (yielding) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (stack overflow) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (stack overflow) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (stack overflow) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (yielding) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (stack overflow) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (heap overflow) >>> cap 0: starting GC >>> cap 0: GC working >>> cap 0: GC idle >>> cap 0: GC done >>> cap 0: GC idle >>> cap 0: GC done >>> cap 0: GC idle >>> cap 0: GC done >>> cap 0: all caps stopped for GC >>> cap 0: finished GC >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (yielding) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (stack overflow) >>> ... >>> >>> And the debug data goes on forever, just as debugging assembly >>> demonstrated an infinite loop. >>> >>> Clearly, the following does not occur: >>> >>> cap 0: thread 1 stopped (suspended while making a foreign call) >>> >>> And there are overflows. >>> >>> If I had to guess, it is possible that some code is in a loop >>> retrying to foreign call, and failing. Certainly, it is in some >>> kind of a loop, because I found a place I can put a break point >>> and and telling GDB to continue will cause the break over and over >>> at the same place. So somewhere there is a loop. >>> >>> I can step through the application with GDB and see names of files >>> and offsets in assembly. But without a true source code debug, >>> that is a bit rough, especially for someone that does not know the >>> RTS code. If there was a way to compile such that C source code >>> was available and a place to break, that would help. However, I >>> suspect since it never makes a foreign call, there is no place in >>> C to place the breakpoint anyway. So I am also assuming there is >>> no direct way to debug with GDB. >>> >>> But, I can see debug output printed to the console. My hope is >>> there is a way to enable more printing, or a place I can add more >>> print functions to help find the problem. >>> >>> So I think I need one of the following: >>> >>> - A solution from someone that has seen this before, perhaps on >>> the iPhone >>> - How to enable more debug logging >>> - Where in the source code to add debug statements to narrow down >>> the problem >>> >>> Thanks for any help you can give. >>> >>> Mike >>> >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >>> >> >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Fri Jul 11 13:40:54 2014 From: austin at well-typed.com (Austin Seipp) Date: Fri, 11 Jul 2014 08:40:54 -0500 Subject: ANNOUNCE: GHC version 7.8.3 Message-ID: ============================================================== The (Interactive) Glasgow Haskell Compiler -- version 7.8.3 ============================================================== The GHC Team is pleased to announce a new patchlevel release of GHC, 7.8.3. This is an important bugfix release relative to 7.8.2 (with over 50 defects fixed), so we highly recommend upgrading from the previous 7.8 releases. The full release notes are here: https://www.haskell.org/ghc/docs/7.8.3/html/users_guide/release-7-8-3.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://ghc.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://ghc.haskell.org/trac/ghc/wiki/Platforms http://ghc.haskell.org/trac/ghc/wiki/CodeOwners Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug Hashes & Signatures ~~~~~~~~~~~~~~~~~ Included in this email is a signed copy of the SHA256 hashes for the tarballs, using my GPG key (keyid 0x3B58D86F). -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: SHA256SUMS Type: application/octet-stream Size: 2934 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SHA256SUMS.sig Type: application/octet-stream Size: 836 bytes Desc: not available URL: From mike at proclivis.com Sat Jul 12 05:27:06 2014 From: mike at proclivis.com (Michael Jones) Date: Fri, 11 Jul 2014 23:27:06 -0600 Subject: Cross compiling for Cortex A9 In-Reply-To: <53BFBDDE.1040509@centrum.cz> References: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> <53BFBDDE.1040509@centrum.cz> Message-ID: <1515908B-FC78-4DD8-AB57-287C4B99065C@proclivis.com> Karel, I have failed to figure out how to make this happen: ("target arch", "ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}?) I have added poky to the list of vendors in aclocal.m4 then configured like this: /configure --target=arm-poky-linux-gnueabi --with-gcc=arm-poky-linux-gnueabi-gcc But I end up with ARMv5. I am new to Autotools and the Haskell build system, so I am not sure what controls this. I assume the idea is that the gcc cross-compiler compiles some code that checks for versions when it evaluates stuff like: AC_COMPILE_IFELSE([ AC_LANG_PROGRAM( [], [#if defined(__ARM_ARCH_2__) || \ defined(__ARM_ARCH_3__) || \ defined(__ARM_ARCH_3M__) || \ defined(__ARM_ARCH_4__) || \ defined(__ARM_ARCH_4T__) || \ So I then suspect the compiler needs options like -mcpu=cortex-a9 -mfpu=neon to make the proper version defined, so that the code can check the architecture. But if all these assumptions are true, it is not clear where to put these options. But that is a big if. Can you explain or point to a doc that explains how this works? The Haskell Developer Wiki does not get into the details at this level. Or, if you have tweaked files for the Panda, I can difference them with mine and figure it out. Thanks, Mike On Jul 11, 2014, at 4:35 AM, Karel Gardas wrote: > > I'm not sure if this is already solved, but if you cross-compile to A9, why do you use ARMv5 platform OS? > > ("target arch","ArchARM {armISA = ARMv5, armISAExt = [], armABI = HARD}") > > this looks really strange. armABI HARD, that means FP data in FP regs, still no VFP in armISAExt and even armISA set to ARMv5. > > For example on my ubuntu 12.04 I do have: > > ("target arch", "ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}"), > > which is right for pandaboard which is dual Cortex-A9. > > So, shortly I really do not know if you do not hit some corner case in LLVM here. I would certainly suggest especially considering your Cortex-A9 target to update your OS to get to what I do have here: ARMv7+VFPv3/NEON+ABI HARD. > > BTW: Another issue may be that GHC misconfigures on your platform and they you will need to tell us more about your target OS... > > Cheers, > Karel > > On 07/ 8/14 07:51 AM, Michael Jones wrote: >> I am pasting both the info from the HOST and TARGET compilers: >> >> HOST >> ==== >> >> [("Project name","The Glorious Glasgow Haskell Compilation System") >> ,("GCC extra via C opts"," -fwrapv") >> ,("C compiler command","/usr/bin/gcc") >> ,("C compiler flags"," -fno-stack-protector -Wl,--hash-size=31 >> -Wl,--reduce-memory-overheads") >> ,("ar command","/usr/bin/ar") >> ,("ar flags","q") >> ,("ar supports at file","YES") >> ,("touch command","touch") >> ,("dllwrap command","/bin/false") >> ,("windres command","/bin/false") >> ,("perl command","/usr/bin/perl") >> ,("target os","OSLinux") >> ,("target arch","ArchX86_64") >> ,("target word size","8") >> ,("target has GNU nonexec stack","True") >> ,("target has .ident directive","True") >> ,("target has subsections via symbols","False") >> ,("LLVM llc command","llc") >> ,("LLVM opt command","opt") >> ,("Project version","7.6.3") >> ,("Booter version","7.6.3") >> ,("Stage","2") >> ,("Build platform","x86_64-unknown-linux") >> ,("Host platform","x86_64-unknown-linux") >> ,("Target platform","x86_64-unknown-linux") >> ,("Have interpreter","YES") >> ,("Object splitting supported","YES") >> ,("Have native code generator","YES") >> ,("Support SMP","YES") >> ,("Unregisterised","NO") >> ,("Tables next to code","YES") >> ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn >> thr_debug_dyn thr_debug_p") >> ,("Leading underscore","NO") >> ,("Debug on","False") >> ,("LibDir","/usr/lib/ghc") >> ,("Global Package DB","/usr/lib/ghc/package.conf.d") >> ,("Gcc Linker >> flags","[\"-Wl,--hash-size=31\",\"-Wl,--reduce-memory-overheads\"]") >> ,("Ld Linker flags","[\"--hash-size=31\",\"--reduce-memory-overheads\"]") >> ] >> >> >> TARGET >> ======= >> >> [("Project name","The Glorious Glasgow Haskell Compilation System") >> ,("GCC extra via C opts"," -fwrapv") >> ,("C compiler command","arm-poky-linux-gnueabi-gcc") >> ,("C compiler flags"," -fno-stack-protector") >> ,("C compiler link flags","") >> ,("ld command","arm-poky-linux-gnueabi-ld") >> ,("ld flags","") >> ,("ld supports compact unwind","YES") >> ,("ld supports build-id","YES") >> ,("ld supports filelist","NO") >> ,("ld is GNU ld","YES") >> ,("ar command","/usr/bin/ar") >> ,("ar flags","q") >> ,("ar supports at file","YES") >> ,("touch command","touch") >> ,("dllwrap command","/bin/false") >> ,("windres command","/bin/false") >> ,("libtool command","libtool") >> ,("perl command","/usr/bin/perl") >> ,("target os","OSLinux") >> ,("target arch","ArchARM {armISA = ARMv5, armISAExt = [], armABI = HARD}") >> ,("target word size","4") >> ,("target has GNU nonexec stack","False") >> ,("target has .ident directive","True") >> ,("target has subsections via symbols","False") >> ,("Unregisterised","NO") >> ,("LLVM llc command","llc") >> ,("LLVM opt command","opt") >> ,("Project version","7.8.2") >> ,("Booter version","7.6.3") >> ,("Stage","1") >> ,("Build platform","x86_64-unknown-linux") >> ,("Host platform","x86_64-unknown-linux") >> ,("Target platform","arm-unknown-linux") >> ,("Have interpreter","YES") >> ,("Object splitting supported","NO") >> ,("Have native code generator","NO") >> ,("Support SMP","YES") >> ,("Tables next to code","YES") >> ,("RTS ways","l debug thr thr_debug thr_l ") >> ,("Support dynamic-too","YES") >> ,("Support parallel --make","YES") >> ,("Dynamic by default","NO") >> ,("GHC Dynamic","NO") >> ,("Leading underscore","NO") >> ,("Debug on","False") >> ,("LibDir","/usr/local/lib/arm-unknown-linux-gnueabi-ghc-7.8.2") >> ,("Global Package >> DB","/usr/local/lib/arm-unknown-linux-gnueabi-ghc-7.8.2/package.conf.d") >> ] >> >> >> >> >> On Jul 7, 2014, at 10:42 PM, Carter Schonwald >> > wrote: >> >>> could you share the output of ghc --info? >>> >>> >>> On Tue, Jul 8, 2014 at 12:10 AM, Michael Jones >> > wrote: >>> >>> I am having problems building a GHC cross compiler for Linux >>> (Yocto on a Wandboard) running on a Cortex A9, and need some >>> advice on how to debug it. >>> >>> The cross compiler produces an executable that runs on the Target, >>> but fails to print. So I need help coming up with a strategy to >>> narrow down the root cause. >>> >>> Some details: >>> >>> The application: >>> >>> main = do >>> putStrLn "Haskell start" >>> >>> >>> The command line options work. The program runs, and I can step >>> through assembly. Debug data is printed to the console. But >>> putStrLn fails, and program enters an infinite loop. >>> >>> I compile my app as follows: >>> >>> arm-unknown-linux-gnueabi-ghc -debug -static Main.hs >>> >>> Using -threaded does not fix the problem. >>> >>> Let me compare debug data from a run on my HOST, with a run on my >>> TARGET. First, a run from my HOST: >>> >>> created capset 0 of type 2 >>> created capset 1 of type 3 >>> cap 0: initialised >>> assigned cap 0 to capset 0 >>> assigned cap 0 to capset 1 >>> cap 0: created thread 1 >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (suspended while making a foreign call) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (finished) >>> cap 0: created thread 2 >>> cap 0: running thread 2 (ThreadRunGHC) >>> cap 0: thread 2 stopped (finished) >>> cap 0: starting GC >>> cap 0: GC working >>> cap 0: GC idle >>> cap 0: GC done >>> cap 0: GC idle >>> cap 0: GC done >>> cap 0: GC idle >>> cap 0: GC done >>> cap 0: GC idle >>> cap 0: GC done >>> cap 0: all caps stopped for GC >>> cap 0: finished GC >>> removed cap 0 from capset 0 >>> removed cap 0 from capset 1 >>> cap 0: shutting down >>> deleted capset 0 >>> deleted capset 1 >>> >>> And, it prints properly. So this is my referenced for what it >>> should do on the TARGET. >>> >>> When I run on my TARGET, I get: >>> >>> created capset 0 of type 2 >>> created capset 1 of type 3 >>> cap 0: initialised >>> assigned cap 0 to capset 0 >>> assigned cap 0 to capset 1 >>> cap 0: created thread 1 >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (yielding) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (yielding) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (yielding) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (yielding) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (yielding) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (yielding) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (stack overflow) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (stack overflow) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (stack overflow) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (yielding) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (stack overflow) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (stack overflow) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (stack overflow) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (yielding) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (stack overflow) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (heap overflow) >>> cap 0: starting GC >>> cap 0: GC working >>> cap 0: GC idle >>> cap 0: GC done >>> cap 0: GC idle >>> cap 0: GC done >>> cap 0: GC idle >>> cap 0: GC done >>> cap 0: all caps stopped for GC >>> cap 0: finished GC >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (yielding) >>> cap 0: running thread 1 (ThreadRunGHC) >>> cap 0: thread 1 stopped (stack overflow) >>> ... >>> >>> And the debug data goes on forever, just as debugging assembly >>> demonstrated an infinite loop. >>> >>> Clearly, the following does not occur: >>> >>> cap 0: thread 1 stopped (suspended while making a foreign call) >>> >>> And there are overflows. >>> >>> If I had to guess, it is possible that some code is in a loop >>> retrying to foreign call, and failing. Certainly, it is in some >>> kind of a loop, because I found a place I can put a break point >>> and and telling GDB to continue will cause the break over and over >>> at the same place. So somewhere there is a loop. >>> >>> I can step through the application with GDB and see names of files >>> and offsets in assembly. But without a true source code debug, >>> that is a bit rough, especially for someone that does not know the >>> RTS code. If there was a way to compile such that C source code >>> was available and a place to break, that would help. However, I >>> suspect since it never makes a foreign call, there is no place in >>> C to place the breakpoint anyway. So I am also assuming there is >>> no direct way to debug with GDB. >>> >>> But, I can see debug output printed to the console. My hope is >>> there is a way to enable more printing, or a place I can add more >>> print functions to help find the problem. >>> >>> So I think I need one of the following: >>> >>> - A solution from someone that has seen this before, perhaps on >>> the iPhone >>> - How to enable more debug logging >>> - Where in the source code to add debug statements to narrow down >>> the problem >>> >>> Thanks for any help you can give. >>> >>> Mike >>> >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >>> >> >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From gabriel439 at gmail.com Mon Jul 14 02:30:18 2014 From: gabriel439 at gmail.com (Gabriel Gonzalez) Date: Sun, 13 Jul 2014 19:30:18 -0700 Subject: Avoiding BlockedIndefinitelyOnSTM exceptions Message-ID: <53C340BA.7000209@gmail.com> I have what may sound like an unusual request: I would like to automatically avoid `BlockedIndefinitelyOnSTM` exceptions with a primitive that looks something like this: safe :: STM a -> STM (Maybe a) This hypothetical `safe` primitive would attempt a transaction, and if `ghc` detects that this transaction would fail because of an `BlockedIndefinitelyOnSTM` exception it will return `Nothing` instead of throwing an uncatchable exception. I originally simulated a limited form of this behavior using `pipes-concurrency`. I instrumented the garbage collector (using weak references) to detect when an STM variable was garbage collected and to safely cancel any transactions that depended on those variables. You can see the implementation here: https://github.com/Gabriel439/Haskell-Pipes-Concurrency-Library/blob/23e7e2dab472b7e4cde7bea31227a917ce5d5375/src/Pipes/Concurrent.hs#L170 The original purpose behind this was to easily read and write to a channel without having to count references to the channel. I reasoned that the garbage collector *already knew* how many open references there were to channel, so I thought "why not use the garbage collector to gracefully cancel transactions that would block just before they would trigger the exception?" This worked really well up until ghc-7.8 changed something and the above trick no longer works. To be honest, I'm surprised that it ever worked at all, which is why I'm not requesting restoring the original behavior. Instead, I think providing something like the above `safe` primitive would be nicer, if possible. Would it be possible to implement something like `safe`? Alternatively, is it possible to make the `BlockedIndefinitelyOnSTM` exception catchable? P.S. I'm also interested in learning more about what may have caused the change in behavior in the transition from ghc-7.6 to ghc-7.8. What changes were made to the interaction between STM and weak references that may have triggered this? From semanticphilosopher at gmail.com Mon Jul 14 07:19:46 2014 From: semanticphilosopher at gmail.com (Neil Davies) Date: Mon, 14 Jul 2014 08:19:46 +0100 Subject: Avoiding BlockedIndefinitelyOnSTM exceptions In-Reply-To: <53C340BA.7000209@gmail.com> References: <53C340BA.7000209@gmail.com> Message-ID: <932501F0-0348-4939-B930-CE92C3F878E3@gmail.com> Gabriel Is the underlying issue one of ?scope? - STM variables have global scope, would a batter approach to be to create scope of such things and then some overall recovery mechanism could handle such an exception within that scope? Neil On 14 Jul 2014, at 03:30, Gabriel Gonzalez wrote: > I have what may sound like an unusual request: I would like to automatically avoid `BlockedIndefinitelyOnSTM` exceptions with a primitive that looks something like this: > > safe :: STM a -> STM (Maybe a) > > This hypothetical `safe` primitive would attempt a transaction, and if `ghc` detects that this transaction would fail because of an `BlockedIndefinitelyOnSTM` exception it will return `Nothing` instead of throwing an uncatchable exception. > > I originally simulated a limited form of this behavior using `pipes-concurrency`. I instrumented the garbage collector (using weak references) to detect when an STM variable was garbage collected and to safely cancel any transactions that depended on those variables. You can see the implementation here: > > https://github.com/Gabriel439/Haskell-Pipes-Concurrency-Library/blob/23e7e2dab472b7e4cde7bea31227a917ce5d5375/src/Pipes/Concurrent.hs#L170 > > The original purpose behind this was to easily read and write to a channel without having to count references to the channel. I reasoned that the garbage collector *already knew* how many open references there were to channel, so I thought "why not use the garbage collector to gracefully cancel transactions that would block just before they would trigger the exception?" > > This worked really well up until ghc-7.8 changed something and the above trick no longer works. To be honest, I'm surprised that it ever worked at all, which is why I'm not requesting restoring the original behavior. Instead, I think providing something like the above `safe` primitive would be nicer, if possible. > > Would it be possible to implement something like `safe`? > > Alternatively, is it possible to make the `BlockedIndefinitelyOnSTM` exception catchable? > > P.S. I'm also interested in learning more about what may have caused the change in behavior in the transition from ghc-7.6 to ghc-7.8. What changes were made to the interaction between STM and weak references that may have triggered this? > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From karel.gardas at centrum.cz Mon Jul 14 08:28:30 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Mon, 14 Jul 2014 10:28:30 +0200 Subject: Cross compiling for Cortex A9 In-Reply-To: <1515908B-FC78-4DD8-AB57-287C4B99065C@proclivis.com> References: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> <53BFBDDE.1040509@centrum.cz> <1515908B-FC78-4DD8-AB57-287C4B99065C@proclivis.com> Message-ID: <53C394AE.4020303@centrum.cz> On 07/12/14 07:27 AM, Michael Jones wrote: > Karel, > > I have failed to figure out how to make this happen: > > ("target arch", "ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}?) > This is result of running ./configure on arm/ubuntu12.04 -- so I don't cross-compile, but rather compile natively. This is still preferred way to be able to run testsuite AFAIK... > I have added poky to the list of vendors in aclocal.m4 then configured like this: > > /configure --target=arm-poky-linux-gnueabi --with-gcc=arm-poky-linux-gnueabi-gcc > > But I end up with ARMv5. > > I am new to Autotools and the Haskell build system, so I am not sure what controls this. I assume the idea is that the gcc cross-compiler compiles some code that checks for versions when it evaluates stuff like: > > AC_COMPILE_IFELSE([ > AC_LANG_PROGRAM( > [], > [#if defined(__ARM_ARCH_2__) || \ > defined(__ARM_ARCH_3__) || \ > defined(__ARM_ARCH_3M__) || \ > defined(__ARM_ARCH_4__) || \ > defined(__ARM_ARCH_4T__) || \ > You arm-poky-linux-gnueabi-gcc -v tells what? Also arm-poky-linux-gnueabi-gcc -dM -E - < /dev/null may tell you something. > So I then suspect the compiler needs options like -mcpu=cortex-a9 -mfpu=neon to make the proper version defined, so that the code can check the architecture. It depends on how the compiler is configured. -v will tell you. Mine looks like: karel at panda:~$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper Target: arm-linux-gnueabi Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi Thread model: posix gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) Please note --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb -- I'm sure you will also be able to build a cross-compiler using those option, so it'll generate ARMv7A code by default, use just half of VFPv3 regs (VFPv3-D16) and generate Thumbs isns by default (not ARM). Karel From christiaan.baaij at gmail.com Mon Jul 14 08:53:17 2014 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Mon, 14 Jul 2014 10:53:17 +0200 Subject: Installing ghc-7.8.3 OS X bindist fails on Xcode 4 CLI-only machine Message-ID: Hi, I'm having problems installing the OS X bindist of GHC 7.8.3 on my machine. Here are the specs for my machine: Hardware: MacBook Pro, 13-inch, Mid 2009 Operating System: OS X 10.8.5 gcc: i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Note that I only have the Xcode 4 CLI tools installed, not Xcode 4 itself. The line that fails is: > /usr/bin/gcc -E -m64 -undef -traditional -Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs -P -DINSTALLING -DLIB_DIR='"/opt/ghc/7.8.3/lib/ghc-7.8.3"' -DINCLUDE_DIR='"/opt/ghc/7.8.3/lib/ghc-7.8.3/include"' -DPAPI_INCLUDE_DIR="" -DPAPI_LIB_DIR="" -DFFI_INCLUDE_DIR= -DFFI_LIB_DIR= '-DFFI_LIB="Cffi"' -x c -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header rts/package.conf.in -o rts/dist/package.conf.install.raw > cc1: error: unrecognized command line option "-Wno-invalid-pp-token" > cc1: error: unrecognized command line option "-Wno-unicode" > make[2]: *** [rts/dist/package.conf.install] Error 1 > make[1]: *** [install] Error 2 > make: *** [install] Error 2 Earlier in the configuration process I see: > checking XCode version... xcode-select: Error: No Xcode is selected. Use xcode-select -switch , or see the xcode-select manpage (man xcode-select) for further information. > not found (too old?) Could that be the culprit? The entire installation log can be found here: https://gist.github.com/christiaanb/ec06e93fa16fdfdb5fa3 -- Christiaan From allbery.b at gmail.com Mon Jul 14 14:41:52 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 14 Jul 2014 10:41:52 -0400 Subject: Installing ghc-7.8.3 OS X bindist fails on Xcode 4 CLI-only machine In-Reply-To: References: Message-ID: On Mon, Jul 14, 2014 at 4:53 AM, Christiaan Baaij < christiaan.baaij at gmail.com> wrote: > > cc1: error: unrecognized command line option "-Wno-invalid-pp-token" > > cc1: error: unrecognized command line option "-Wno-unicode" > Those are clang options, for what it's worth. It seems to be defaulting to Xcode 5 / clang if xcode-select fails; it should probably test against /usr/bin/gcc directly for that case. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at proclivis.com Mon Jul 14 14:58:37 2014 From: mike at proclivis.com (Michael Jones) Date: Mon, 14 Jul 2014 08:58:37 -0600 Subject: Cross compiling for Cortex A9 In-Reply-To: <53C394AE.4020303@centrum.cz> References: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> <53BFBDDE.1040509@centrum.cz> <1515908B-FC78-4DD8-AB57-287C4B99065C@proclivis.com> <53C394AE.4020303@centrum.cz> Message-ID: <67CEBBAE-CC1F-47CC-9A21-AA94C4A25149@proclivis.com> Karel, Thanks. This helps. If I understand, you have Linux running on a Panda, and on that Panda system you have gcc, and you compile GHC on the Panda itself, rather than build a cross compiler. I can see the advantage of building this way. As far as cross compilers, I have a reason for trying to build a cross compiler, other than the ability to keep the image of the target small. That is, eventually, I want to be able to compile for an RTOS and/or bare iron system. I decided that learning to cross compile for Linux first would be a good approach. Learn the build system on something known to work. So I probably will not give up on that. I got a book on Autoconfig. I?ll just have to dig a level deeper into the whole build system. Mainly it means learning the M4 system. I have never used it. Below are the defines from the command you suggested. Thanks for that, got me over an ignorance hump. At least this define, __ARM_ARCH_5T__, is in the aclocal.m4 file. So I will have to study the macros until I figure out what controls the gcc options passed to the gcc cross compiler. I guess my question is what actually controls this result ("target arch", "ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}?)? Are these controlled by the defines below, or are they controlled by passing gcc arguments to the gcc compiler when the Haskell compiler calls gcc? Mike #define __ARM_SIZEOF_WCHAR_T 32 #define __ARM_ARCH_ISA_ARM 1 #define __ARM_FP 12 #define __ARM_NEON_FP 4 #define __ARM_SIZEOF_MINIMAL_ENUM 4 #define __ARM_PCS_VFP 1 #define __ARM_ARCH_5T__ 1 #define __ARM_FEATURE_CLZ 1 #define __ARM_ARCH_ISA_THUMB 1 #define __ARM_ARCH 5 #define __arm__ 1 #define __ARM_EABI__ 1 mike at ubuntu:~/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/bin/cortexa9hf-vfp-neon-poky-linux-gnueabi$ ./arm-poky-linux-gnueabi-gcc -v Using built-in specs. COLLECT_GCC=./arm-poky-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/libexec/cortexa9hf-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.8.2/lto-wrapper Target: arm-poky-linux-gnueabi Configured with: /home/mike/fsl-community-bsp/build/tmp/work-shared/gcc-4.8.2-r0/gcc-4.8.2/configure --build=x86_64-linux --host=x86_64-linux --target=arm-poky-linux-gnueabi --prefix=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr --exec_prefix=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr --bindir=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/bin/cortexa9hf-vfp-neon-poky-linux-gnueabi --sbindir=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/bin/cortexa9hf-vfp-neon-poky-linux-gnueabi --libexecdir=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/libexec/cortexa9hf-vfp-neon-poky-linux-gnueabi --datadir=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/share --sysconfdir=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/etc --sharedstatedir=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/com --localstatedir=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/var --libdir=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/lib/cortexa9hf-vfp-neon-poky-linux-gnueabi --includedir=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/include --oldincludedir=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/include --infodir=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/share/info --mandir=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux --enable-clocale=generic --with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix --disable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=arm-poky-linux-gnueabi- --without-local-prefix --enable-target-optspace --enable-lto --enable-libssp --disable-bootstrap --disable-libmudflap --with-system-zlib --with-linker-hash-style=gnu --enable-linker-build-id --with-ppl=no --with-cloog=no --enable-checking=release --enable-cheaders=c_global --with-float=hard --with-gxx-include-dir=/home/mike/fsl-community-bsp/build/tmp/sysroots/wandboard-quad/usr/include/c++ --with-sysroot=/home/mike/fsl-community-bsp/build/tmp/sysroots/wandboard-quad --with-build-sysroot=/home/mike/fsl-community-bsp/build/tmp/sysroots/wandboard-quad --enable-poison-system-directories --disable-libunwind-exceptions --with-mpfr=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr --with-system-zlib --disable-nls Thread model: posix gcc version 4.8.2 (GCC) mike at ubuntu:~/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/bin/cortexa9hf-vfp-neon-poky-linux-gnueabi$ #define __DBL_MIN_EXP__ (-1021) #define __HQ_FBIT__ 15 #define __UINT_LEAST16_MAX__ 65535 #define __ARM_SIZEOF_WCHAR_T 32 #define __ATOMIC_ACQUIRE 2 #define __SFRACT_IBIT__ 0 #define __FLT_MIN__ 1.1754943508222875e-38F #define __UFRACT_MAX__ 0XFFFFP-16UR #define __UINT_LEAST8_TYPE__ unsigned char #define __DQ_FBIT__ 63 #define __INTMAX_C(c) c ## LL #define __ULFRACT_FBIT__ 32 #define __SACCUM_EPSILON__ 0x1P-7HK #define __CHAR_BIT__ 8 #define __USQ_IBIT__ 0 #define __UINT8_MAX__ 255 #define __ACCUM_FBIT__ 15 #define __WINT_MAX__ 4294967295U #define __USFRACT_FBIT__ 8 #define __ORDER_LITTLE_ENDIAN__ 1234 #define __SIZE_MAX__ 4294967295U #define __ARM_ARCH_ISA_ARM 1 #define __WCHAR_MAX__ 4294967295U #define __LACCUM_IBIT__ 32 #define __DBL_DENORM_MIN__ ((double)4.9406564584124654e-324L) #define __GCC_ATOMIC_CHAR_LOCK_FREE 1 #define __FLT_EVAL_METHOD__ 0 #define __unix__ 1 #define __LLACCUM_MAX__ 0X7FFFFFFFFFFFFFFFP-31LLK #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1 #define __FRACT_FBIT__ 15 #define __UINT_FAST64_MAX__ 18446744073709551615ULL #define __SIG_ATOMIC_TYPE__ int #define __UACCUM_FBIT__ 16 #define __DBL_MIN_10_EXP__ (-307) #define __FINITE_MATH_ONLY__ 0 #define __ARMEL__ 1 #define __LFRACT_IBIT__ 0 #define __GNUC_PATCHLEVEL__ 2 #define __LFRACT_MAX__ 0X7FFFFFFFP-31LR #define __UINT_FAST8_MAX__ 255 #define __DEC64_MAX_EXP__ 385 #define __INT8_C(c) c #define __UINT_LEAST64_MAX__ 18446744073709551615ULL #define __SA_FBIT__ 15 #define __SHRT_MAX__ 32767 #define __LDBL_MAX__ 1.7976931348623157e+308L #define __FRACT_MAX__ 0X7FFFP-15R #define __UFRACT_FBIT__ 16 #define __ARM_FP 12 #define __UFRACT_MIN__ 0.0UR #define __UINT_LEAST8_MAX__ 255 #define __GCC_ATOMIC_BOOL_LOCK_FREE 1 #define __UINTMAX_TYPE__ long long unsigned int #define __LLFRACT_EPSILON__ 0x1P-63LLR #define __linux 1 #define __DEC32_EPSILON__ 1E-6DF #define __CHAR_UNSIGNED__ 1 #define __UINT32_MAX__ 4294967295U #define __ULFRACT_MAX__ 0XFFFFFFFFP-32ULR #define __TA_IBIT__ 64 #define __LDBL_MAX_EXP__ 1024 #define __WINT_MIN__ 0U #define __linux__ 1 #define __ULLFRACT_MIN__ 0.0ULLR #define __SCHAR_MAX__ 127 #define __WCHAR_MIN__ 0U #define __INT64_C(c) c ## LL #define __DBL_DIG__ 15 #define __ARM_NEON_FP 4 #define __GCC_ATOMIC_POINTER_LOCK_FREE 1 #define __LLACCUM_MIN__ (-0X1P31LLK-0X1P31LLK) #define __SIZEOF_INT__ 4 #define __SIZEOF_POINTER__ 4 #define __USACCUM_IBIT__ 8 #define __USER_LABEL_PREFIX__ #define __STDC_HOSTED__ 1 #define __LDBL_HAS_INFINITY__ 1 #define __LFRACT_MIN__ (-0.5LR-0.5LR) #define __HA_IBIT__ 8 #define __TQ_IBIT__ 0 #define __FLT_EPSILON__ 1.1920928955078125e-7F #define __APCS_32__ 1 #define __USFRACT_IBIT__ 0 #define __LDBL_MIN__ 2.2250738585072014e-308L #define __FRACT_MIN__ (-0.5R-0.5R) #define __DEC32_MAX__ 9.999999E96DF #define __DA_IBIT__ 32 #define __ARM_SIZEOF_MINIMAL_ENUM 4 #define __INT32_MAX__ 2147483647 #define __UQQ_FBIT__ 8 #define __SIZEOF_LONG__ 4 #define __UACCUM_MAX__ 0XFFFFFFFFP-16UK #define __STDC_IEC_559__ 1 #define __STDC_ISO_10646__ 201103L #define __UINT16_C(c) c #define __DECIMAL_DIG__ 17 #define __LFRACT_EPSILON__ 0x1P-31LR #define __ULFRACT_MIN__ 0.0ULR #define __gnu_linux__ 1 #define __ARM_PCS_VFP 1 #define __LDBL_HAS_QUIET_NAN__ 1 #define __ULACCUM_IBIT__ 32 #define __UACCUM_EPSILON__ 0x1P-16UK #define __GNUC__ 4 #define __ULLACCUM_MAX__ 0XFFFFFFFFFFFFFFFFP-32ULLK #define __HQ_IBIT__ 0 #define __FLT_HAS_DENORM__ 1 #define __SIZEOF_LONG_DOUBLE__ 8 #define __ARM_ARCH_5T__ 1 #define __BIGGEST_ALIGNMENT__ 8 #define __DQ_IBIT__ 0 #define __DBL_MAX__ ((double)1.7976931348623157e+308L) #define __ULFRACT_IBIT__ 0 #define __INT_FAST32_MAX__ 2147483647 #define __DBL_HAS_INFINITY__ 1 #define __ACCUM_IBIT__ 16 #define __DEC32_MIN_EXP__ (-94) #define __THUMB_INTERWORK__ 1 #define __LACCUM_MAX__ 0X7FFFFFFFFFFFFFFFP-31LK #define __INT_FAST16_TYPE__ int #define __LDBL_HAS_DENORM__ 1 #define __DEC128_MAX__ 9.999999999999999999999999999999999E6144DL #define __INT_LEAST32_MAX__ 2147483647 #define __DEC32_MIN__ 1E-95DF #define __ACCUM_MAX__ 0X7FFFFFFFP-15K #define __DBL_MAX_EXP__ 1024 #define __USACCUM_EPSILON__ 0x1P-8UHK #define __DEC128_EPSILON__ 1E-33DL #define __SFRACT_MAX__ 0X7FP-7HR #define __FRACT_IBIT__ 0 #define __PTRDIFF_MAX__ 2147483647 #define __UACCUM_MIN__ 0.0UK #define __STDC_NO_THREADS__ 1 #define __UACCUM_IBIT__ 16 #define __LONG_LONG_MAX__ 9223372036854775807LL #define __SIZEOF_SIZE_T__ 4 #define __ULACCUM_MAX__ 0XFFFFFFFFFFFFFFFFP-32ULK #define __SIZEOF_WINT_T__ 4 #define __SA_IBIT__ 16 #define __ULLACCUM_MIN__ 0.0ULLK #define __GXX_ABI_VERSION 1002 #define __UTA_FBIT__ 64 #define __FLT_MIN_EXP__ (-125) #define __USFRACT_MAX__ 0XFFP-8UHR #define __UFRACT_IBIT__ 0 #define __INT_FAST64_TYPE__ long long int #define __DBL_MIN__ ((double)2.2250738585072014e-308L) #define __LACCUM_MIN__ (-0X1P31LK-0X1P31LK) #define __ULLACCUM_FBIT__ 32 #define __GXX_TYPEINFO_EQUALITY_INLINE 0 #define __ULLFRACT_EPSILON__ 0x1P-64ULLR #define __DEC128_MIN__ 1E-6143DL #define __REGISTER_PREFIX__ #define __UINT16_MAX__ 65535 #define __DBL_HAS_DENORM__ 1 #define __ACCUM_MIN__ (-0X1P15K-0X1P15K) #define __SQ_IBIT__ 0 #define __UINT8_TYPE__ unsigned char #define __UHA_FBIT__ 8 #define __NO_INLINE__ 1 #define __SFRACT_MIN__ (-0.5HR-0.5HR) #define __UTQ_FBIT__ 128 #define __FLT_MANT_DIG__ 24 #define __VERSION__ "4.8.2" #define __UINT64_C(c) c ## ULL #define __ULLFRACT_FBIT__ 64 #define __FRACT_EPSILON__ 0x1P-15R #define __ULACCUM_MIN__ 0.0ULK #define _STDC_PREDEF_H 1 #define __UDA_FBIT__ 32 #define __LLACCUM_EPSILON__ 0x1P-31LLK #define __GCC_ATOMIC_INT_LOCK_FREE 1 #define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__ #define __USFRACT_MIN__ 0.0UHR #define __UQQ_IBIT__ 0 #define __STDC_IEC_559_COMPLEX__ 1 #define __INT32_C(c) c #define __DEC64_EPSILON__ 1E-15DD #define __ORDER_PDP_ENDIAN__ 3412 #define __DEC128_MIN_EXP__ (-6142) #define __UHQ_FBIT__ 16 #define __LLACCUM_FBIT__ 31 #define __INT_FAST32_TYPE__ int #define __UINT_LEAST16_TYPE__ short unsigned int #define unix 1 #define __INT16_MAX__ 32767 #define __SIZE_TYPE__ unsigned int #define __UINT64_MAX__ 18446744073709551615ULL #define __UDQ_FBIT__ 64 #define __INT8_TYPE__ signed char #define __ELF__ 1 #define __ULFRACT_EPSILON__ 0x1P-32ULR #define __LLFRACT_FBIT__ 63 #define __FLT_RADIX__ 2 #define __INT_LEAST16_TYPE__ short int #define __LDBL_EPSILON__ 2.2204460492503131e-16L #define __UINTMAX_C(c) c ## ULL #define __SACCUM_MAX__ 0X7FFFP-7HK #define __SIG_ATOMIC_MAX__ 2147483647 #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 1 #define __VFP_FP__ 1 #define __SIZEOF_PTRDIFF_T__ 4 #define __LACCUM_EPSILON__ 0x1P-31LK #define __DEC32_SUBNORMAL_MIN__ 0.000001E-95DF #define __INT_FAST16_MAX__ 2147483647 #define __UINT_FAST32_MAX__ 4294967295U #define __UINT_LEAST64_TYPE__ long long unsigned int #define __USACCUM_MAX__ 0XFFFFP-8UHK #define __SFRACT_EPSILON__ 0x1P-7HR #define __FLT_HAS_QUIET_NAN__ 1 #define __FLT_MAX_10_EXP__ 38 #define __LONG_MAX__ 2147483647L #define __DEC128_SUBNORMAL_MIN__ 0.000000000000000000000000000000001E-6143DL #define __FLT_HAS_INFINITY__ 1 #define __unix 1 #define __USA_FBIT__ 16 #define __UINT_FAST16_TYPE__ unsigned int #define __DEC64_MAX__ 9.999999999999999E384DD #define __CHAR16_TYPE__ short unsigned int #define __PRAGMA_REDEFINE_EXTNAME 1 #define __INT_LEAST16_MAX__ 32767 #define __DEC64_MANT_DIG__ 16 #define __INT64_MAX__ 9223372036854775807LL #define __UINT_LEAST32_MAX__ 4294967295U #define __SACCUM_FBIT__ 7 #define __GCC_ATOMIC_LONG_LOCK_FREE 1 #define __INT_LEAST64_TYPE__ long long int #define __ARM_FEATURE_CLZ 1 #define __INT16_TYPE__ short int #define __INT_LEAST8_TYPE__ signed char #define __SQ_FBIT__ 31 #define __DEC32_MAX_EXP__ 97 #define __ARM_ARCH_ISA_THUMB 1 #define __INT_FAST8_MAX__ 127 #define __ARM_ARCH 5 #define __INTPTR_MAX__ 2147483647 #define __QQ_FBIT__ 7 #define linux 1 #define __UTA_IBIT__ 64 #define __LDBL_MANT_DIG__ 53 #define __SFRACT_FBIT__ 7 #define __SACCUM_MIN__ (-0X1P7HK-0X1P7HK) #define __DBL_HAS_QUIET_NAN__ 1 #define __SIG_ATOMIC_MIN__ (-__SIG_ATOMIC_MAX__ - 1) #define __INTPTR_TYPE__ int #define __UINT16_TYPE__ short unsigned int #define __WCHAR_TYPE__ unsigned int #define __SIZEOF_FLOAT__ 4 #define __USQ_FBIT__ 32 #define __UINTPTR_MAX__ 4294967295U #define __DEC64_MIN_EXP__ (-382) #define __ULLACCUM_IBIT__ 32 #define __INT_FAST64_MAX__ 9223372036854775807LL #define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1 #define __FLT_DIG__ 6 #define __UINT_FAST64_TYPE__ long long unsigned int #define __INT_MAX__ 2147483647 #define __LACCUM_FBIT__ 31 #define __USACCUM_MIN__ 0.0UHK #define __UHA_IBIT__ 8 #define __INT64_TYPE__ long long int #define __FLT_MAX_EXP__ 128 #define __UTQ_IBIT__ 0 #define __DBL_MANT_DIG__ 53 #define __INT_LEAST64_MAX__ 9223372036854775807LL #define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1 #define __DEC64_MIN__ 1E-383DD #define __WINT_TYPE__ unsigned int #define __UINT_LEAST32_TYPE__ unsigned int #define __SIZEOF_SHORT__ 2 #define __ULLFRACT_IBIT__ 0 #define __LDBL_MIN_EXP__ (-1021) #define __arm__ 1 #define __UDA_IBIT__ 32 #define __INT_LEAST8_MAX__ 127 #define __LFRACT_FBIT__ 31 #define __LDBL_MAX_10_EXP__ 308 #define __ATOMIC_RELAXED 0 #define __DBL_EPSILON__ ((double)2.2204460492503131e-16L) #define __UINT8_C(c) c #define __INT_LEAST32_TYPE__ int #define __SIZEOF_WCHAR_T__ 4 #define __UINT64_TYPE__ long long unsigned int #define __LLFRACT_MAX__ 0X7FFFFFFFFFFFFFFFP-63LLR #define __TQ_FBIT__ 127 #define __INT_FAST8_TYPE__ signed char #define __ULLACCUM_EPSILON__ 0x1P-32ULLK #define __UHQ_IBIT__ 0 #define __LLACCUM_IBIT__ 32 #define __DBL_DECIMAL_DIG__ 17 #define __DEC_EVAL_METHOD__ 2 #define __TA_FBIT__ 63 #define __UDQ_IBIT__ 0 #define __ORDER_BIG_ENDIAN__ 4321 #define __ACCUM_EPSILON__ 0x1P-15K #define __UINT32_C(c) c ## U #define __INTMAX_MAX__ 9223372036854775807LL #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ #define __FLT_DENORM_MIN__ 1.4012984643248171e-45F #define __LLFRACT_IBIT__ 0 #define __INT8_MAX__ 127 #define __UINT_FAST32_TYPE__ unsigned int #define __CHAR32_TYPE__ unsigned int #define __FLT_MAX__ 3.4028234663852886e+38F #define __USACCUM_FBIT__ 8 #define __INT32_TYPE__ int #define __SIZEOF_DOUBLE__ 8 #define __FLT_MIN_10_EXP__ (-37) #define __UFRACT_EPSILON__ 0x1P-16UR #define __INTMAX_TYPE__ long long int #define __DEC128_MAX_EXP__ 6145 #define __ATOMIC_CONSUME 1 #define __GNUC_MINOR__ 8 #define __UINTMAX_MAX__ 18446744073709551615ULL #define __DEC32_MANT_DIG__ 7 #define __HA_FBIT__ 7 #define __DBL_MAX_10_EXP__ 308 #define __LDBL_DENORM_MIN__ 4.9406564584124654e-324L #define __INT16_C(c) c #define __STDC__ 1 #define __PTRDIFF_TYPE__ int #define __LLFRACT_MIN__ (-0.5LLR-0.5LLR) #define __ATOMIC_SEQ_CST 5 #define __DA_FBIT__ 31 #define __UINT32_TYPE__ unsigned int #define __UINTPTR_TYPE__ unsigned int #define __USA_IBIT__ 16 #define __DEC64_SUBNORMAL_MIN__ 0.000000000000001E-383DD #define __ARM_EABI__ 1 #define __DEC128_MANT_DIG__ 34 #define __LDBL_MIN_10_EXP__ (-307) #define __SIZEOF_LONG_LONG__ 8 #define __ULACCUM_EPSILON__ 0x1P-32ULK #define __SACCUM_IBIT__ 8 #define __GCC_ATOMIC_LLONG_LOCK_FREE 1 #define __LDBL_DIG__ 15 #define __FLT_DECIMAL_DIG__ 9 #define __UINT_FAST16_MAX__ 4294967295U #define __GNUC_GNU_INLINE__ 1 #define __GCC_ATOMIC_SHORT_LOCK_FREE 1 #define __ULLFRACT_MAX__ 0XFFFFFFFFFFFFFFFFP-64ULLR #define __UINT_FAST8_TYPE__ unsigned char #define __USFRACT_EPSILON__ 0x1P-8UHR #define __ULACCUM_FBIT__ 32 #define __QQ_IBIT__ 0 #define __ATOMIC_ACQ_REL 4 #define __ATOMIC_RELEASE 3 mike at ubuntu:~/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/bin/cortexa9hf-vfp-neon-poky-linux-gnueabi$ On Jul 14, 2014, at 2:28 AM, Karel Gardas wrote: > On 07/12/14 07:27 AM, Michael Jones wrote: >> Karel, >> >> I have failed to figure out how to make this happen: >> >> ("target arch", "ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}?) >> > > This is result of running ./configure on arm/ubuntu12.04 -- so I don't cross-compile, but rather compile natively. This is still preferred way to be able to run testsuite AFAIK... > >> I have added poky to the list of vendors in aclocal.m4 then configured like this: >> >> /configure --target=arm-poky-linux-gnueabi --with-gcc=arm-poky-linux-gnueabi-gcc >> >> But I end up with ARMv5. >> >> I am new to Autotools and the Haskell build system, so I am not sure what controls this. I assume the idea is that the gcc cross-compiler compiles some code that checks for versions when it evaluates stuff like: >> >> AC_COMPILE_IFELSE([ >> AC_LANG_PROGRAM( >> [], >> [#if defined(__ARM_ARCH_2__) || \ >> defined(__ARM_ARCH_3__) || \ >> defined(__ARM_ARCH_3M__) || \ >> defined(__ARM_ARCH_4__) || \ >> defined(__ARM_ARCH_4T__) || \ >> > > You arm-poky-linux-gnueabi-gcc -v tells what? Also > arm-poky-linux-gnueabi-gcc -dM -E - < /dev/null may tell you something. > >> So I then suspect the compiler needs options like -mcpu=cortex-a9 -mfpu=neon to make the proper version defined, so that the code can check the architecture. > > It depends on how the compiler is configured. -v will tell you. Mine looks like: > > karel at panda:~$ gcc -v > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper > Target: arm-linux-gnueabi > Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi > Thread model: posix > gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) > > > Please note --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb -- I'm sure you will also be able to build a cross-compiler using those option, so it'll generate ARMv7A code by default, use just half of VFPv3 regs (VFPv3-D16) and generate Thumbs isns by default (not ARM). > > Karel From allbery.b at gmail.com Mon Jul 14 15:06:27 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 14 Jul 2014 11:06:27 -0400 Subject: Fwd: Installing ghc-7.8.3 OS X bindist fails on Xcode 4 CLI-only machine In-Reply-To: References: Message-ID: FWIW Mark had this reply but is apparently not subscribed to, or being rejected by, ghc-users and asked me to forward it. ---------- Forwarded message ---------- From: Mark Lentczner Date: Mon, Jul 14, 2014 at 7:34 AM Subject: Re: Installing ghc-7.8.3 OS X bindist fails on Xcode 4 CLI-only machine To: Christiaan Baaij Cc: glasgow-haskell-users Yes - this is a known problem in GHC (#9257 ) The problem is that there is one gcc invocation in the "make install" step (!) and that the clang/gcc detection isn't applied at bindist configuire time. Hence, that gcc invocation is based on the compiler of the machine that built the bindist (clang), not the compiler of the machine it is being installed on (gcc). Note that this doesn't affect the installed GHC system: The compiler detection at bindist configure time *is* applied to the ghc tree it installs, just not the bindist make itself! Work around is very easy: make install CC_CLANG_BACKEND=0 - Mark ? -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From gabriel439 at gmail.com Mon Jul 14 15:16:16 2014 From: gabriel439 at gmail.com (Gabriel Gonzalez) Date: Mon, 14 Jul 2014 08:16:16 -0700 Subject: Avoiding BlockedIndefinitelyOnSTM exceptions In-Reply-To: <932501F0-0348-4939-B930-CE92C3F878E3@gmail.com> References: <53C340BA.7000209@gmail.com> <932501F0-0348-4939-B930-CE92C3F878E3@gmail.com> Message-ID: <53C3F440.5030506@gmail.com> I don't quite understand your question, but I'll try to give a fuller explanation of the problem I was trying to solve to see if it perhaps answers your question. The motivation behind `pipes-concurrency` was to make it easy for readers and writers to coordinate implicitly (using the garbage collector) instead of explicitly. Here's an example of code that people would use `pipes-concurrency` to write: main = do (output, input) <- spawn Single a1 <- async $ runEffect $ someProducer >-> toOutput output a2 <- async $ runEffect $ fromInput input >-> someConsumer mapM_ wait [a1, a2] For people unfamiliar with `pipes` or `pipes-concurrency`, what the above code does is it `spawn`s a `TMVar` that you can read or write. Then it forks two threads, one of which feeds some values to the `TMVar` and the other of which reads some values from the `TMVar`. What was neat about the way `pipes-concurrency` works is that: * If `someProducer` produces fewer values than `someConsumer` requests from `TMVar`, then `someConsumer` would detect that and gracefully terminate instead of trying to read a value from the now-permanently-empty `TMVar`. * If `someConsumer` consumes fewer values than `someProducer` feeds to the `TMVar` then `someProducer` would detect that and gracefully terminate instead of trying to write a new value to the now-permanently-full `TMVar`. Note that throwing an exception to either of these threads is not a suitable substitute for graceful termination in more sophisticated examples. The rationale behind graceful termination is to allow running more logic in these threads after they are done reading or writing from the STM variable. My feeling is that the garbage collector already knows that these reads or writes are doomed, so why not make use of that knowledge to gracefully recover from doomed transactions? On 07/14/2014 12:19 AM, Neil Davies wrote: > Gabriel > > Is the underlying issue one of ?scope? - STM variables have global scope, would a batter approach to be to create scope of such things and then some overall recovery mechanism could handle such an exception within that scope? > > Neil > > On 14 Jul 2014, at 03:30, Gabriel Gonzalez wrote: > >> I have what may sound like an unusual request: I would like to automatically avoid `BlockedIndefinitelyOnSTM` exceptions with a primitive that looks something like this: >> >> safe :: STM a -> STM (Maybe a) >> >> This hypothetical `safe` primitive would attempt a transaction, and if `ghc` detects that this transaction would fail because of an `BlockedIndefinitelyOnSTM` exception it will return `Nothing` instead of throwing an uncatchable exception. >> >> I originally simulated a limited form of this behavior using `pipes-concurrency`. I instrumented the garbage collector (using weak references) to detect when an STM variable was garbage collected and to safely cancel any transactions that depended on those variables. You can see the implementation here: >> >> https://github.com/Gabriel439/Haskell-Pipes-Concurrency-Library/blob/23e7e2dab472b7e4cde7bea31227a917ce5d5375/src/Pipes/Concurrent.hs#L170 >> >> The original purpose behind this was to easily read and write to a channel without having to count references to the channel. I reasoned that the garbage collector *already knew* how many open references there were to channel, so I thought "why not use the garbage collector to gracefully cancel transactions that would block just before they would trigger the exception?" >> >> This worked really well up until ghc-7.8 changed something and the above trick no longer works. To be honest, I'm surprised that it ever worked at all, which is why I'm not requesting restoring the original behavior. Instead, I think providing something like the above `safe` primitive would be nicer, if possible. >> >> Would it be possible to implement something like `safe`? >> >> Alternatively, is it possible to make the `BlockedIndefinitelyOnSTM` exception catchable? >> >> P.S. I'm also interested in learning more about what may have caused the change in behavior in the transition from ghc-7.6 to ghc-7.8. What changes were made to the interaction between STM and weak references that may have triggered this? >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From karel.gardas at centrum.cz Mon Jul 14 16:12:13 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Mon, 14 Jul 2014 18:12:13 +0200 Subject: Cross compiling for Cortex A9 In-Reply-To: <67CEBBAE-CC1F-47CC-9A21-AA94C4A25149@proclivis.com> References: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> <53BFBDDE.1040509@centrum.cz> <1515908B-FC78-4DD8-AB57-287C4B99065C@proclivis.com> <53C394AE.4020303@centrum.cz> <67CEBBAE-CC1F-47CC-9A21-AA94C4A25149@proclivis.com> Message-ID: <53C4015D.9060009@centrum.cz> On 07/14/14 04:58 PM, Michael Jones wrote: > Karel, > > Thanks. This helps. > > If I understand, you have Linux running on a Panda, and on that Panda > system you have gcc, and you compile GHC on the Panda itself, rather > than build a cross compiler. I can see the advantage of building this > way. Correct! > As far as cross compilers, I have a reason for trying to build a > cross compiler, other than the ability to keep the image of the > target small. That is, eventually, I want to be able to compile for > an RTOS and/or bare iron system. I decided that learning to cross > compile for Linux first would be a good approach. Learn the build > system on something known to work. So I probably will not give up on > that. That is right, in future I'd also like to give a try to port GHC to some free RTOS and for this I'd need to use cross-compiling anyway, so I'll be on the same boat... > I got a book on Autoconfig. I?ll just have to dig a level deeper into > the whole build system. Mainly it means learning the M4 system. I > have never used it. > > Below are the defines from the command you suggested. Thanks for > that, got me over an ignorance hump. At least this define, > __ARM_ARCH_5T__, is in the aclocal.m4 file. So I will have to study > the macros until I figure out what controls the gcc options passed to > the gcc cross compiler. I guess my question is what actually controls > this result ("target arch", "ArchARM {armISA = ARMv7, armISAExt = > [VFPv3,NEON], armABI = HARD}?)? > > Are these controlled by the defines below, or are they controlled by > passing gcc arguments to the gcc compiler when the Haskell compiler > calls gcc? Basically speaking all those are controlled by platform gcc. That means if you pass the right option to your cross-compiling gcc you should also get the same result, so for example if you use: gcc -mfloat-abi=hard -march=armv7-a -mfpu=vfpv3-d16 you should get the same settings like me. But anyway, please note that ABI you set to your cross-compiler *have to* match the ABI provided by the target RTOS/OS! I hope that's clear. :-) Cheers, Karel From christiaan.baaij at gmail.com Mon Jul 14 16:54:34 2014 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Mon, 14 Jul 2014 18:54:34 +0200 Subject: Installing ghc-7.8.3 OS X bindist fails on Xcode 4 CLI-only machine In-Reply-To: References: Message-ID: Thanks, the work-around did the trick. On 14 July 2014 16:34, Mark Lentczner wrote: > Yes - this is a known problem in GHC (#9257 > ) > The problem is that there is one gcc invocation in the "make install" step > (!) and that the clang/gcc detection isn't applied at bindist configuire > time. Hence, that gcc invocation is based on the compiler of the machine > that built the bindist (clang), not the compiler of the machine it is being > installed on (gcc). > > Note that this doesn't affect the installed GHC system: The compiler > detection at bindist configure time *is* applied to the ghc tree it > installs, just not the bindist make itself! > > Work around is very easy: > > make install CC_CLANG_BACKEND=0 > > > - Mark > ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Mon Jul 14 17:08:00 2014 From: qdunkan at gmail.com (Evan Laforge) Date: Mon, 14 Jul 2014 10:08:00 -0700 Subject: Fwd: how to get ghci to load compiled modules in 7.8? In-Reply-To: References: Message-ID: I sent this to haskell-cafe, but there was no response. On stackoverflow there was no response either. I'm trying one last time, but adding ghc-users (which I should have done at the beginning!). Surely it can't be that no one knows how to load modules in ghci? I know a lot of work was done to enable this, as in https://ghc.haskell.org/trac/ghc/wiki/DynamicByDefault, it seems a waste if no one actually knows how to use it! The 7.8.1 release notes make reference to -dynamic-too, and an unexplained "Dynamic Ghci", but implies ghci should just work. Do I need to compile ghci myself in a dynamic way? The DynamicByDefault page also implies that, but I assumed the binary distributions would come with it compiled the right way. This has almost disabled ghci for my work (it can be used, but very slowly and with much retyping of commands, and I find myself avoiding the REPL now), so it's a big regression from 7.6! I added another paragraph from the stackoverflow question. Also, I can't get this to work on linux either, not just OS X. BTW, I got a nice bump in my profiles after upgrading, so 7.8 is mostly good news. Just this one awkward thing keeps it from being all good news. ---------- Forwarded message ---------- I recently upgraded to 7.8.2 and I have a silly question. How do you get ghci to load compiled modules? When I try this: % cat >T.hs module T where x :: Int x = 42 % ghc -c -dynamic-too T.hs % s T.dyn_hi T.dyn_o T.hi T.hs T.o % ghci GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package filepath-1.3.0.2 ... linking ... done. Prelude> :l T [1 of 1] Compiling T ( T.hs, interpreted ) Ok, modules loaded: T. *T> It still loads the file interpreted, even though there is a .dyn_o present. What am I doing wrong? This is on x86-64 OS X. There is one other thing which may be related. Since I load everything interpreted now, I've noticed that the input gets very laggy when I have a hundred or so modules loaded. Also the haskeline state gets confused, e.g. I hit escape k to get the previous line, but then it spontaneously goes back into insert mode again. It stays balky and awkward for about 15 seconds before returning to normal slightly. It's almost as if, after loading all the bytecode, it's still doing tons of work in the background, with constant GC freezes. But what work could it be doing? The bytecode is loaded and I haven't asked it to do anything yet! I don't know if this is new to 7.8, or if it's a result of loading bytecode instead of binary. Update: loading with -fobject-code to force compilation reduces some of the balkiness, but some is still there! So maybe this is a regression from 7.6? From rwbarton at gmail.com Mon Jul 14 17:36:11 2014 From: rwbarton at gmail.com (Reid Barton) Date: Mon, 14 Jul 2014 13:36:11 -0400 Subject: how to get ghci to load compiled modules in 7.8? In-Reply-To: References: Message-ID: On Mon, Jul 14, 2014 at 1:08 PM, Evan Laforge wrote: > I sent this to haskell-cafe, but there was no response. On > stackoverflow there was no response either. I'm trying one last time, > but adding ghc-users (which I should have done at the beginning!). > Surely it can't be that no one knows how to load modules in ghci? I > know a lot of work was done to enable this, as in > https://ghc.haskell.org/trac/ghc/wiki/DynamicByDefault, it seems a > waste if no one actually knows how to use it! > See https://ghc.haskell.org/trac/ghc/ticket/8736. The current workaround for GHC 7.8 is to compile with -dynamic, not -dynamic-too. Regards, Reid Barton -------------- next part -------------- An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Mon Jul 14 18:13:57 2014 From: qdunkan at gmail.com (Evan Laforge) Date: Mon, 14 Jul 2014 11:13:57 -0700 Subject: how to get ghci to load compiled modules in 7.8? In-Reply-To: References: Message-ID: On Mon, Jul 14, 2014 at 10:36 AM, Reid Barton wrote: > See https://ghc.haskell.org/trac/ghc/ticket/8736. The current workaround for > GHC 7.8 is to compile with -dynamic, not -dynamic-too. That was it! Thanks so much. As an aside, I was kind of expecting a faster link time due to -dynamic, but apparently not. Oh well, I'm happy enough ghci is back. One thing, how about an addition to the release notes in the -dynamic-too section saying "By the way, this doesn't actually work, see https://ghc.haskell.org/trac/ghc/ticket/8736." I'll go update my stackoverflow question. I'm a little surprised, no one else seems to use ghci, or I'd think there would be lots of shouting about this. Or maybe no one has upgraded to 7.8 yet. From qdunkan at gmail.com Mon Jul 14 18:48:25 2014 From: qdunkan at gmail.com (Evan Laforge) Date: Mon, 14 Jul 2014 11:48:25 -0700 Subject: how to get ghci to load compiled modules in 7.8? In-Reply-To: References: Message-ID: On Mon, Jul 14, 2014 at 11:13 AM, Evan Laforge wrote: > As an aside, I was kind of expecting a faster link time due to > -dynamic, but apparently not. Oh well, I'm happy enough ghci is back. Aha, I needed to pass -dynamic when linking too. Sorry for the noise. From qdunkan at gmail.com Mon Jul 14 19:35:13 2014 From: qdunkan at gmail.com (Evan Laforge) Date: Mon, 14 Jul 2014 12:35:13 -0700 Subject: how to get ghci to load compiled modules in 7.8? In-Reply-To: References: Message-ID: On Mon, Jul 14, 2014 at 11:13 AM, Evan Laforge wrote: > On Mon, Jul 14, 2014 at 10:36 AM, Reid Barton wrote: >> See https://ghc.haskell.org/trac/ghc/ticket/8736. The current workaround for >> GHC 7.8 is to compile with -dynamic, not -dynamic-too. > > That was it! Thanks so much. Actually... not quite. -dynamic seems let ghci load, but when I load with the GHCI API, I get this: compile error: : cannot find normal object file ?build/debug/obj/Util/Contro.o? while linking an interpreted expression The proper name is 'Control.hs.dyn_o', so it looks like the suffix mangling code is getting confused. I must be doing something different than ghci anyway, because I have to pass -dynamic in the GHCI API to load, while ghci doesn't seem to need it. And of course ghci doesn't get the mangled filename. One thing is that I'm using '-osuf .hs.o', which is a bit confusing, since it should actually be '.hs.o_dyn', but there's no -odynsuf and I don't really know how all the name mangling in there works. I'll take a look in the ghci code to see how it's doing things. From qdunkan at gmail.com Mon Jul 14 19:40:26 2014 From: qdunkan at gmail.com (Evan Laforge) Date: Mon, 14 Jul 2014 12:40:26 -0700 Subject: how to get ghci to load compiled modules in 7.8? In-Reply-To: References: Message-ID: On Mon, Jul 14, 2014 at 12:35 PM, Evan Laforge wrote: > Actually... not quite. -dynamic seems let ghci load, but when I load > with the GHCI API, I get this: > > compile error: : > cannot find normal object file ?build/debug/obj/Util/Contro.o? > while linking an interpreted expression Ack.. I keep doing this. It turns out this goes away if I link with '-dynamic' too. I had turned it off when playing the flag permutation game. So I think I finally have everything working now! Still, the Contro.o thing does look buggy. From brandon.m.simmons at gmail.com Mon Jul 14 22:55:57 2014 From: brandon.m.simmons at gmail.com (Brandon Simmons) Date: Mon, 14 Jul 2014 18:55:57 -0400 Subject: Why no `instance (Monoid a, Applicative f)=> Monoid (f a)` for IO? Message-ID: It seems to me that this should be true for all `f a` like: instance (Monoid a, Applicative f)=> Monoid (f a) where mappend = liftA2 mappend mempty = pure mempty But I can't seem to find the particular `instance (Monoid a)=> Monoid (IO a)` anywhere. Would that instance be incorrect, or does it live somewhere else? FWIW I noticed this when I started thinking about an instance I wanted for 'contravariant': instance (Monoid a, Applicative f)=> Monoid (Op (f a) b) where mempty = Op $ const $ pure mempty mappend (Op f) (Op g) = Op (\b-> liftA2 mappend (f b) (g b)) at which point I realized (I think) all `f a` are monoidal, and so we ought to be able to get the instance above with just a deriving Monoid. Brandon From ekmett at gmail.com Tue Jul 15 02:55:36 2014 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 14 Jul 2014 22:55:36 -0400 Subject: Why no `instance (Monoid a, Applicative f)=> Monoid (f a)` for IO? In-Reply-To: References: Message-ID: There are monads for which you want another Monoid, e.g. Maybe provides a different unit, because it pretends to lift a Semigroup into a Monoid. There are also monoids that take a parameter of kind * that would overlap with this instance. So we can't (and shouldn't) have the global Monoid instance like you give there first. As for the particular case of IO a, lifting may be a reasonable option there. A case could be made for adding an `instance Monoid a => Monoid (IO a)`, but for such a ubiquitously used type, expect that this wouldn't be an easy sell. You'd possibly have to deal with everyone and their brother coming out of the woodwork offering up every other Monoid they happened to use on IO. Why? IO provides a notion of failing action you could use for zero and you can build an (<|>) like construction on it as well, so the 'multiplicative' structure isn't the _only_ option for your monoid. Even within the multiplicative structure using the monoid isn't necessarily ideal as you might leak more memory with an IO a monoid that lifts () than you would with working specifically on IO (). You can argue the case that the choice you made is a sensible default instance by instance, but when there isn't a real canonical choice we do tend to err on the side of leaving things open as orphans are at least possible, but once the choice is made it is very very hard to unmake. I say this mostly so you know the kinds of objections proposals like this usually see, not to flat out reject the idea of the particular case of this instance for IO. I will say the global 'instance (Applicative f, Monoid m) => Monoid (f m)' won't fly for overlap reasons though. -Edward On Mon, Jul 14, 2014 at 6:55 PM, Brandon Simmons < brandon.m.simmons at gmail.com> wrote: > It seems to me that this should be true for all `f a` like: > > instance (Monoid a, Applicative f)=> Monoid (f a) where > mappend = liftA2 mappend > mempty = pure mempty > > But I can't seem to find the particular `instance (Monoid a)=> Monoid > (IO a)` anywhere. Would that instance be incorrect, or does it live > somewhere else? > > FWIW I noticed this when I started thinking about an instance I wanted > for 'contravariant': > > instance (Monoid a, Applicative f)=> Monoid (Op (f a) b) where > mempty = Op $ const $ pure mempty > mappend (Op f) (Op g) = Op (\b-> liftA2 mappend (f b) (g b)) > > at which point I realized (I think) all `f a` are monoidal, and so we > ought to be able to get the instance above with just a deriving > Monoid. > > Brandon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brandon.m.simmons at gmail.com Tue Jul 15 14:31:59 2014 From: brandon.m.simmons at gmail.com (Brandon Simmons) Date: Tue, 15 Jul 2014 10:31:59 -0400 Subject: Why no `instance (Monoid a, Applicative f)=> Monoid (f a)` for IO? In-Reply-To: References: Message-ID: On Mon, Jul 14, 2014 at 10:55 PM, Edward Kmett wrote: > There are monads for which you want another Monoid, e.g. Maybe provides a > different unit, because it pretends to lift a Semigroup into a Monoid. > > There are also monoids that take a parameter of kind * that would overlap > with this instance. > > So we can't (and shouldn't) have the global Monoid instance like you give > there first. Right, sorry. I just meant that as a bit of context. My proposal is adding `instance Monoid a => Monoid (IO a)`. > > As for the particular case of IO a, lifting may be a reasonable option > there. > > A case could be made for adding an `instance Monoid a => Monoid (IO a)`, but > for such a ubiquitously used type, expect that this wouldn't be an easy > sell. > > You'd possibly have to deal with everyone and their brother coming out of > the woodwork offering up every other Monoid they happened to use on IO. > > Why? > > IO provides a notion of failing action you could use for zero and you can > build an (<|>) like construction on it as well, so the 'multiplicative' > structure isn't the _only_ option for your monoid. Can you give an example of what you mean here? Would that be something involving exceptions? > > Even within the multiplicative structure using the monoid isn't necessarily > ideal as you might leak more memory with an IO a monoid that lifts () than > you would with working specifically on IO (). > > You can argue the case that the choice you made is a sensible default > instance by instance, but when there isn't a real canonical choice we do > tend to err on the side of leaving things open as orphans are at least > possible, but once the choice is made it is very very hard to unmake. Right like Sum/Product for Num types. But here there's good reason, I think, to choose one instance over others, because we already have the monoid structure of Applicative and Monad. You can still have a wrapper newtype with different instances for the alternatives, as was done with Applicative for [] and ZipList. But I might be misunderstanding, since I'm not really sure what the alternative instances you mention would look like. Thanks, Brandon > > I say this mostly so you know the kinds of objections proposals like this > usually see, not to flat out reject the idea of the particular case of this > instance for IO. > > I will say the global 'instance (Applicative f, Monoid m) => Monoid (f m)' > won't fly for overlap reasons though. > > -Edward > > > On Mon, Jul 14, 2014 at 6:55 PM, Brandon Simmons > wrote: >> >> It seems to me that this should be true for all `f a` like: >> >> instance (Monoid a, Applicative f)=> Monoid (f a) where >> mappend = liftA2 mappend >> mempty = pure mempty >> >> But I can't seem to find the particular `instance (Monoid a)=> Monoid >> (IO a)` anywhere. Would that instance be incorrect, or does it live >> somewhere else? >> >> FWIW I noticed this when I started thinking about an instance I wanted >> for 'contravariant': >> >> instance (Monoid a, Applicative f)=> Monoid (Op (f a) b) where >> mempty = Op $ const $ pure mempty >> mappend (Op f) (Op g) = Op (\b-> liftA2 mappend (f b) (g b)) >> >> at which point I realized (I think) all `f a` are monoidal, and so we >> ought to be able to get the instance above with just a deriving >> Monoid. >> >> Brandon >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From qdunkan at gmail.com Thu Jul 17 01:32:22 2014 From: qdunkan at gmail.com (Evan Laforge) Date: Wed, 16 Jul 2014 18:32:22 -0700 Subject: extra "ambiguous type variable" errors after a "couldn't match" error? Message-ID: 7.8.3 has a new behaviour where a "plain" type error will cause "ambiguous type variable" errors, e.g.: module M where broken :: [Int] broken = () ambiguous :: a -> [String] ambiguous _ = map show [1..] When imported in ghci, I get: M.hs:4:10: Couldn't match expected type ?[Int]? with actual type ?()? In the expression: () In an equation for ?broken?: broken = () M.hs:7:19: No instance for (Show a0) arising from a use of ?show? The type variable ?a0? is ambiguous [ ... and then more for Enum and Num ] It seems like the 'a' type variable causes this to happen. But I don't see why a type error in another place should cause 'ambiguous' to become ambiguous. From simonpj at microsoft.com Thu Jul 17 09:02:12 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 17 Jul 2014 09:02:12 +0000 Subject: extra "ambiguous type variable" errors after a "couldn't match" error? In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF1042F749@DB3PRD3001MB020.064d.mgd.msft.net> Good point! See https://ghc.haskell.org/trac/ghc/ticket/9323 Simon | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces at haskell.org] On Behalf Of Evan Laforge | Sent: 17 July 2014 02:32 | To: GHC users | Subject: extra "ambiguous type variable" errors after a "couldn't | match" error? | | 7.8.3 has a new behaviour where a "plain" type error will cause | "ambiguous type variable" errors, e.g.: | | module M where | | broken :: [Int] | broken = () | | ambiguous :: a -> [String] | ambiguous _ = map show [1..] | | When imported in ghci, I get: | | M.hs:4:10: | Couldn't match expected type ?[Int]? with actual type ?()? | In the expression: () | In an equation for ?broken?: broken = () | | M.hs:7:19: | No instance for (Show a0) arising from a use of ?show? | The type variable ?a0? is ambiguous | [ ... and then more for Enum and Num ] | | It seems like the 'a' type variable causes this to happen. But I don't | see why a type error in another place should cause 'ambiguous' | to become ambiguous. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users at haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From qdunkan at gmail.com Thu Jul 17 16:55:27 2014 From: qdunkan at gmail.com (Evan Laforge) Date: Thu, 17 Jul 2014 09:55:27 -0700 Subject: extra "ambiguous type variable" errors after a "couldn't match" error? In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF1042F749@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF1042F749@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: On Thu, Jul 17, 2014 at 2:02 AM, Simon Peyton Jones wrote: > Good point! See > https://ghc.haskell.org/trac/ghc/ticket/9323 Ah, fixed in the next release. Ok, that's good enough for me, it's only a minor annoyance. From brandon.m.simmons at gmail.com Fri Jul 18 20:13:01 2014 From: brandon.m.simmons at gmail.com (Brandon Simmons) Date: Fri, 18 Jul 2014 16:13:01 -0400 Subject: Avoiding BlockedIndefinitelyOnSTM exceptions Message-ID: > I have what may sound like an unusual request: I would like to > automatically avoid `BlockedIndefinitelyOnSTM` exceptions with a > primitive that looks something like this: Have you seen ezyang's post here? Lots of hairy details that are probably relevant http://blog.ezyang.com/2011/07/blockedindefinitelyonmvar/ Brandon From winterkoninkje at gmail.com Sun Jul 20 03:24:09 2014 From: winterkoninkje at gmail.com (wren romano) Date: Sat, 19 Jul 2014 23:24:09 -0400 Subject: Avoiding BlockedIndefinitelyOnSTM exceptions In-Reply-To: <53C3F440.5030506@gmail.com> References: <53C340BA.7000209@gmail.com> <932501F0-0348-4939-B930-CE92C3F878E3@gmail.com> <53C3F440.5030506@gmail.com> Message-ID: On Mon, Jul 14, 2014 at 11:16 AM, Gabriel Gonzalez wrote: > I don't quite understand your question, but I'll try to give a fuller > explanation of the problem I was trying to solve to see if it perhaps > answers your question. I think the suggestion was something like this: -- | The @s@ type is an abstract "heap id" just like in 'ST'. type STSTM s a -- | The second argument allows handling 'BlockedIndefinitelyOnSTM' etc. runSTSTM :: (forall s. STSTM s a) -> (STMError -> b) -> b The idea being that, if the problem with catching BlockedIndefinitelyOnSTM has to do with the fact that all STM variables have global scope and so even if we could catch the exception itself we'd still have problems with cleaning up the collateral damage[1], then that's why it doesn't make sense to allow BlockedIndefinitelyOnSTM to be caught. However, by using an abstract heap-id we can bundle all related STSTM variables together, and we know that once runSTSTM exits they can't be accessed from anywhere else? so even if there's an error, we can still clean up all the variables, threads, and other jetsam associated with this STSTM computation. [1] I don't know if this is actually the reason why why BlockedIndefinitelyOnSTM is uncatchable, rather it sounded like this is what Neil Davies was suggesting to be the reason. Also, I do seem to recall something like this actually being the case; though it's unclear whether the STSTM approach would actually be able to solve the problem. -- Live well, ~wren From winterkoninkje at gmail.com Sun Jul 20 03:48:35 2014 From: winterkoninkje at gmail.com (wren romano) Date: Sat, 19 Jul 2014 23:48:35 -0400 Subject: Avoiding BlockedIndefinitelyOnSTM exceptions In-Reply-To: References: <53C340BA.7000209@gmail.com> <932501F0-0348-4939-B930-CE92C3F878E3@gmail.com> <53C3F440.5030506@gmail.com> Message-ID: On Sat, Jul 19, 2014 at 11:24 PM, wren romano wrote: > -- | The second argument allows handling 'BlockedIndefinitelyOnSTM' etc. > runSTSTM :: (forall s. STSTM s a) -> (STMError -> b) -> b That should've been something more sensible, like: atomicallySTSTM :: (forall s. STSTM s a) -> (STMError -> b) -> IO (Either a b) > The idea being that, if the problem with catching > BlockedIndefinitelyOnSTM has to do with the fact that all STM > variables have global scope and so even if we could catch the > exception itself we'd still have problems with cleaning up the > collateral damage[1], then that's why it doesn't make sense to allow > BlockedIndefinitelyOnSTM to be caught. > > [1] I don't know if this is actually the reason why why > BlockedIndefinitelyOnSTM is uncatchable, rather it sounded like this > is what Neil Davies was suggesting to be the reason. Also, I do seem > to recall something like this actually being the case; though it's > unclear whether the STSTM approach would actually be able to solve the > problem. Fwiw, after (re)reading ezyang's blog post about BlockedIndefinitelyOnSTM, it seems clear that this is not actually what the problem is. Though he also mentioned that the exact details of BlockedIndefinitelyOnSTM shouldn't be relied upon, since the exception is just a trick to kill off useless threads in order to collect more garbage. ... In terms of solving your actual problem in pipes, it seems like what you really want are weak-references for STM. That way you don't rely on the behavior of BlockedIndefinitelyOnSTM, and you can still get garbage collection to send you signals whenever something becomes inaccessible, allowing you to handle things however you like. Seems like it shouldn't be too hard to do, since weak-references for IO are already supported; though, of course, it'll still take a fair deal of hacking to implement it. -- Live well, ~wren From i.hamsa at gmail.com Sun Jul 20 07:26:52 2014 From: i.hamsa at gmail.com (i hamsa) Date: Sun, 20 Jul 2014 10:26:52 +0300 Subject: Failure compiling ghc-mtl with ghc-7.8.{2,3} Message-ID: I was trying to upgrade to ghc-7.8 the other day, and got this compilation failure when building ghc-mtl-1.2.1.0 (see the end of the message). I'm using the haskell overlay on Gentoo Linux straight out of the box, no local cabal installations of anything. Now I was told that other people can compile ghc-mtl with 7.8 just fine, so there must be something broken in my specific configuration. What would be an effective way to approach the situation? In the sources I see that an instance of MonadIO GHC.Ghc does exist. I don't understand these errors. Are there multiple different MonadIO classes in different modules? Thank you and happy hacking. Now the errors: Control/Monad/Ghc.hs:42:15: No instance for (GHC.MonadIO Ghc) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (GHC.ExceptionMonad Ghc) Control/Monad/Ghc.hs:46:15: No instance for (MonadIO GHC.Ghc) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadIO Ghc) Control/Monad/Ghc.hs:49:15: No instance for (GHC.MonadIO Ghc) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (GHC.GhcMonad Ghc) -- this is the real i From semanticphilosopher at gmail.com Sun Jul 20 08:45:44 2014 From: semanticphilosopher at gmail.com (Neil Davies) Date: Sun, 20 Jul 2014 09:45:44 +0100 Subject: Avoiding BlockedIndefinitelyOnSTM exceptions In-Reply-To: References: <53C340BA.7000209@gmail.com> <932501F0-0348-4939-B930-CE92C3F878E3@gmail.com> <53C3F440.5030506@gmail.com> Message-ID: <7A8DA918-36B9-407D-906E-5EAC3C789A29@gmail.com> Wren That is sort of idea I was alluding to - there is a communication scope, the set of things that now need be cleaned up. In designing systems I'm always aggregating scope of failures to create ?units of redundancy? and handling / recovering (and making sure failure within that scope becomes ?total?) - reduces the complexity of reasoning about fault modes. Neil On 20 Jul 2014, at 04:48, wren romano wrote: > On Sat, Jul 19, 2014 at 11:24 PM, wren romano wrote: >> -- | The second argument allows handling 'BlockedIndefinitelyOnSTM' etc. >> runSTSTM :: (forall s. STSTM s a) -> (STMError -> b) -> b > > That should've been something more sensible, like: > > atomicallySTSTM :: (forall s. STSTM s a) -> (STMError -> b) -> IO > (Either a b) > >> The idea being that, if the problem with catching >> BlockedIndefinitelyOnSTM has to do with the fact that all STM >> variables have global scope and so even if we could catch the >> exception itself we'd still have problems with cleaning up the >> collateral damage[1], then that's why it doesn't make sense to allow >> BlockedIndefinitelyOnSTM to be caught. >> >> [1] I don't know if this is actually the reason why why >> BlockedIndefinitelyOnSTM is uncatchable, rather it sounded like this >> is what Neil Davies was suggesting to be the reason. Also, I do seem >> to recall something like this actually being the case; though it's >> unclear whether the STSTM approach would actually be able to solve the >> problem. > > Fwiw, after (re)reading ezyang's blog post about > BlockedIndefinitelyOnSTM, it seems clear that this is not actually > what the problem is. Though he also mentioned that the exact details > of BlockedIndefinitelyOnSTM shouldn't be relied upon, since the > exception is just a trick to kill off useless threads in order to > collect more garbage. > > ... > > In terms of solving your actual problem in pipes, it seems like what > you really want are weak-references for STM. That way you don't rely > on the behavior of BlockedIndefinitelyOnSTM, and you can still get > garbage collection to send you signals whenever something becomes > inaccessible, allowing you to handle things however you like. Seems > like it shouldn't be too hard to do, since weak-references for IO are > already supported; though, of course, it'll still take a fair deal of > hacking to implement it. > > -- > Live well, > ~wren > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From ezyang at mit.edu Sun Jul 20 18:01:39 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Sun, 20 Jul 2014 19:01:39 +0100 Subject: Failure compiling ghc-mtl with ghc-7.8.{2,3} In-Reply-To: References: Message-ID: <1405879190-sup-6948@sabre> The last time I saw this error, it was because the package database was messed up (there was an instance of MonadIO in scope, but it was for the wrong package.) However, I don't know what the source of the problem is here. Edward Excerpts from i hamsa's message of 2014-07-20 08:26:52 +0100: > I was trying to upgrade to ghc-7.8 the other day, and got this > compilation failure when building ghc-mtl-1.2.1.0 (see the end of the > message). > > I'm using the haskell overlay on Gentoo Linux straight out of the box, > no local cabal installations of anything. > > Now I was told that other people can compile ghc-mtl with 7.8 just > fine, so there must be something broken in my specific configuration. > What would be an effective way to approach the situation? > > In the sources I see that an instance of MonadIO GHC.Ghc does exist. I > don't understand these errors. Are there multiple different MonadIO > classes in different modules? > > Thank you and happy hacking. > > Now the errors: > > Control/Monad/Ghc.hs:42:15: > No instance for (GHC.MonadIO Ghc) > arising from the 'deriving' clause of a data type declaration > Possible fix: > use a standalone 'deriving instance' declaration, > so you can specify the instance context yourself > When deriving the instance for (GHC.ExceptionMonad Ghc) > > Control/Monad/Ghc.hs:46:15: > No instance for (MonadIO GHC.Ghc) > arising from the 'deriving' clause of a data type declaration > Possible fix: > use a standalone 'deriving instance' declaration, > so you can specify the instance context yourself > When deriving the instance for (MonadIO Ghc) > > Control/Monad/Ghc.hs:49:15: > No instance for (GHC.MonadIO Ghc) > arising from the 'deriving' clause of a data type declaration > Possible fix: > use a standalone 'deriving instance' declaration, > so you can specify the instance context yourself > When deriving the instance for (GHC.GhcMonad Ghc) > From i.hamsa at gmail.com Sun Jul 20 18:25:36 2014 From: i.hamsa at gmail.com (i hamsa) Date: Sun, 20 Jul 2014 21:25:36 +0300 Subject: Failure compiling ghc-mtl with ghc-7.8.{2,3} In-Reply-To: <1405879190-sup-6948@sabre> References: <1405879190-sup-6948@sabre> Message-ID: I think I found the problem. package ghc-7.8.3 requires transformers-0.3.0.0 package mtl-2.2.1 requires transformers-0.4.1.0 package exceptions-0.6.1 requires transformers-0.4.1.0 I wonder how is this ever supposed to work :( On Sun, Jul 20, 2014 at 9:01 PM, Edward Z. Yang wrote: > The last time I saw this error, it was because the package database > was messed up (there was an instance of MonadIO in scope, but it > was for the wrong package.) However, I don't know what the source > of the problem is here. > > Edward > > Excerpts from i hamsa's message of 2014-07-20 08:26:52 +0100: >> I was trying to upgrade to ghc-7.8 the other day, and got this >> compilation failure when building ghc-mtl-1.2.1.0 (see the end of the >> message). >> >> I'm using the haskell overlay on Gentoo Linux straight out of the box, >> no local cabal installations of anything. >> >> Now I was told that other people can compile ghc-mtl with 7.8 just >> fine, so there must be something broken in my specific configuration. >> What would be an effective way to approach the situation? >> >> In the sources I see that an instance of MonadIO GHC.Ghc does exist. I >> don't understand these errors. Are there multiple different MonadIO >> classes in different modules? >> >> Thank you and happy hacking. >> >> Now the errors: >> >> Control/Monad/Ghc.hs:42:15: >> No instance for (GHC.MonadIO Ghc) >> arising from the 'deriving' clause of a data type declaration >> Possible fix: >> use a standalone 'deriving instance' declaration, >> so you can specify the instance context yourself >> When deriving the instance for (GHC.ExceptionMonad Ghc) >> >> Control/Monad/Ghc.hs:46:15: >> No instance for (MonadIO GHC.Ghc) >> arising from the 'deriving' clause of a data type declaration >> Possible fix: >> use a standalone 'deriving instance' declaration, >> so you can specify the instance context yourself >> When deriving the instance for (MonadIO Ghc) >> >> Control/Monad/Ghc.hs:49:15: >> No instance for (GHC.MonadIO Ghc) >> arising from the 'deriving' clause of a data type declaration >> Possible fix: >> use a standalone 'deriving instance' declaration, >> so you can specify the instance context yourself >> When deriving the instance for (GHC.GhcMonad Ghc) >> -- this is the real i From ezyang at mit.edu Sun Jul 20 18:36:26 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Sun, 20 Jul 2014 19:36:26 +0100 Subject: Failure compiling ghc-mtl with ghc-7.8.{2,3} In-Reply-To: References: <1405879190-sup-6948@sabre> Message-ID: <1405881341-sup-4142@sabre> It looks like you will have to install old versions of mtl/exceptions which work on transformers-0.3.0.0, although undoubtedly the real problem is that GHC should update what version of transformers it is distributing. Edawrd Excerpts from i hamsa's message of 2014-07-20 19:25:36 +0100: > I think I found the problem. > > package ghc-7.8.3 requires transformers-0.3.0.0 > package mtl-2.2.1 requires transformers-0.4.1.0 > package exceptions-0.6.1 requires transformers-0.4.1.0 > > I wonder how is this ever supposed to work :( > > On Sun, Jul 20, 2014 at 9:01 PM, Edward Z. Yang wrote: > > The last time I saw this error, it was because the package database > > was messed up (there was an instance of MonadIO in scope, but it > > was for the wrong package.) However, I don't know what the source > > of the problem is here. > > > > Edward > > > > Excerpts from i hamsa's message of 2014-07-20 08:26:52 +0100: > >> I was trying to upgrade to ghc-7.8 the other day, and got this > >> compilation failure when building ghc-mtl-1.2.1.0 (see the end of the > >> message). > >> > >> I'm using the haskell overlay on Gentoo Linux straight out of the box, > >> no local cabal installations of anything. > >> > >> Now I was told that other people can compile ghc-mtl with 7.8 just > >> fine, so there must be something broken in my specific configuration. > >> What would be an effective way to approach the situation? > >> > >> In the sources I see that an instance of MonadIO GHC.Ghc does exist. I > >> don't understand these errors. Are there multiple different MonadIO > >> classes in different modules? > >> > >> Thank you and happy hacking. > >> > >> Now the errors: > >> > >> Control/Monad/Ghc.hs:42:15: > >> No instance for (GHC.MonadIO Ghc) > >> arising from the 'deriving' clause of a data type declaration > >> Possible fix: > >> use a standalone 'deriving instance' declaration, > >> so you can specify the instance context yourself > >> When deriving the instance for (GHC.ExceptionMonad Ghc) > >> > >> Control/Monad/Ghc.hs:46:15: > >> No instance for (MonadIO GHC.Ghc) > >> arising from the 'deriving' clause of a data type declaration > >> Possible fix: > >> use a standalone 'deriving instance' declaration, > >> so you can specify the instance context yourself > >> When deriving the instance for (MonadIO Ghc) > >> > >> Control/Monad/Ghc.hs:49:15: > >> No instance for (GHC.MonadIO Ghc) > >> arising from the 'deriving' clause of a data type declaration > >> Possible fix: > >> use a standalone 'deriving instance' declaration, > >> so you can specify the instance context yourself > >> When deriving the instance for (GHC.GhcMonad Ghc) > >> > From glaebhoerl at gmail.com Sun Jul 20 21:22:05 2014 From: glaebhoerl at gmail.com (=?UTF-8?B?R8OhYm9yIExlaGVs?=) Date: Sun, 20 Jul 2014 23:22:05 +0200 Subject: Avoiding BlockedIndefinitelyOnSTM exceptions In-Reply-To: References: <53C340BA.7000209@gmail.com> <932501F0-0348-4939-B930-CE92C3F878E3@gmail.com> <53C3F440.5030506@gmail.com> Message-ID: On Sun, Jul 20, 2014 at 5:48 AM, wren romano wrote: > On Sat, Jul 19, 2014 at 11:24 PM, wren romano > wrote: > > -- | The second argument allows handling 'BlockedIndefinitelyOnSTM' > etc. > > runSTSTM :: (forall s. STSTM s a) -> (STMError -> b) -> b > > That should've been something more sensible, like: > > atomicallySTSTM :: (forall s. STSTM s a) -> (STMError -> b) -> IO > (Either a b) > Wouldn't combining it wih ST defeat the purpose of STM? The purpose of STM being to synchronize access to shared variables using atomic transactions. If all the variables in your atomic transaction are guaranteed to be local and not touched by any other transaction, which I believe the above type says, then you don't need a transaction at all. Or was the idea to create some kind of outer scope within which individual atomic (sub)transactions may share access to variables, but not without? > > > The idea being that, if the problem with catching > > BlockedIndefinitelyOnSTM has to do with the fact that all STM > > variables have global scope and so even if we could catch the > > exception itself we'd still have problems with cleaning up the > > collateral damage[1], then that's why it doesn't make sense to allow > > BlockedIndefinitelyOnSTM to be caught. > > > > [1] I don't know if this is actually the reason why why > > BlockedIndefinitelyOnSTM is uncatchable, rather it sounded like this > > is what Neil Davies was suggesting to be the reason. Also, I do seem > > to recall something like this actually being the case; though it's > > unclear whether the STSTM approach would actually be able to solve the > > problem. > > Fwiw, after (re)reading ezyang's blog post about > BlockedIndefinitelyOnSTM, it seems clear that this is not actually > what the problem is. Though he also mentioned that the exact details > of BlockedIndefinitelyOnSTM shouldn't be relied upon, since the > exception is just a trick to kill off useless threads in order to > collect more garbage. > > ... > > In terms of solving your actual problem in pipes, it seems like what > you really want are weak-references for STM. That way you don't rely > on the behavior of BlockedIndefinitelyOnSTM, and you can still get > garbage collection to send you signals whenever something becomes > inaccessible, allowing you to handle things however you like. Seems > like it shouldn't be too hard to do, since weak-references for IO are > already supported; though, of course, it'll still take a fair deal of > hacking to implement it. > > -- > Live well, > ~wren > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From winterkoninkje at gmail.com Mon Jul 21 03:29:05 2014 From: winterkoninkje at gmail.com (wren romano) Date: Sun, 20 Jul 2014 23:29:05 -0400 Subject: Avoiding BlockedIndefinitelyOnSTM exceptions In-Reply-To: References: <53C340BA.7000209@gmail.com> <932501F0-0348-4939-B930-CE92C3F878E3@gmail.com> <53C3F440.5030506@gmail.com> Message-ID: On Sun, Jul 20, 2014 at 5:22 PM, G?bor Lehel wrote: > On Sun, Jul 20, 2014 at 5:48 AM, wren romano > wrote: >> >> On Sat, Jul 19, 2014 at 11:24 PM, wren romano >> wrote: >> > -- | The second argument allows handling 'BlockedIndefinitelyOnSTM' >> > etc. >> > runSTSTM :: (forall s. STSTM s a) -> (STMError -> b) -> b >> >> That should've been something more sensible, like: >> >> atomicallySTSTM :: (forall s. STSTM s a) -> (STMError -> b) -> IO >> (Either a b) Yeah, that's not quite what I meant either. Will have to think about it more. > Wouldn't combining it wih ST defeat the purpose of STM? The purpose of STM > being to synchronize access to shared variables using atomic transactions. > If all the variables in your atomic transaction are guaranteed to be local > and not touched by any other transaction, which I believe the above type > says, then you don't need a transaction at all. > > Or was the idea to create some kind of outer scope within which individual > atomic (sub)transactions may share access to variables, but not without? Yeah, the idea is to create smaller scopes to collect all the related references into a single heap/region, isolating them from other heaps, allowing the heap to be gc'ed in one go, etc. Arranging local scopes is generally a good idea since global scope is non-compositional. STM just says that heap interactions are transactional, it doesn't say there can be only one heap/region. Indeed, there can be performance benefits for adding regions to thread-based parallelism like STM. Since threads accessing disjoint regions cannot interfere with one another we have very strong guarantees about their data-flow and synchronization properties. This, in turn, can be used by the runtime to reduce memory traffic: associate each heap with a core, distributed as evenly as possible over the cores, and schedule all the threads over a given heap to be run on the core for that heap (or on "nearby" cores). Similarly there can be runtime performance benefits since we can use tricks like card marking to quickly check whether any other thread has modified our region; if not, then commit immediately; if so, then do the expensive check of running through the STM log to see if there's really a conflict. -- Live well, ~wren From austin at well-typed.com Mon Jul 21 11:56:00 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 21 Jul 2014 06:56:00 -0500 Subject: GHC 7.10.1 tickets Message-ID: Hello *, We need to be sorting out tickets for 7.10.1. Last week, I spent some time remilestoning things to get them into the rough correct places (roughly), but we all need some help to get an idea of what we should fix for the release. Here's a query to look at: https://ghc.haskell.org/trac/ghc/query?status=!closed&milestone=7.10.1&order=priority I have already categorized these tickets roughly, but we'll probably still address some of the priorities on existing tickets of course. These are all of the 7.10.1 tickets currently, but there are some important things to note: 1) There are a lot of them! 2) Most of the development team is probably not going to pay attention to many of them unless they are high or highest priority in Trac. (That's just the result of having so many tickets for 7.10.1 at the moment.) So I'm asking if people out there with the time can help chip in and give some input on the ticket! - If there's a ticket that interests you, please comment on it! - Say why you think it should have its priority elevated for 7.10.1. - It will certainly be easier if you offer to help. Then we can move it upwards and we'll look at it. Finally, if you are *really* dedicated or a newcomer - please go through the tickets and see if any of them can be closed, reassigned, marked as duplicates, etc. There are certainly some dead tickets and probably easy tickets for newcomers, so just spend a few minutes looking if you're interested! (Otherwise they just end up getting punted off in batch modifications) Thanks! ~~~~~~~ BTW, for developers, you can look at your assigned tickets for 7.10.1 here, it's also always on the sidebar: https://ghc.haskell.org/trac/ghc/query?owner=%24USER&status=infoneeded&status=merge&status=new&status=patch&milestone=7.10.1&order=priority -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From cheater00 at gmail.com Mon Jul 21 17:51:07 2014 From: cheater00 at gmail.com (cheater00 .) Date: Mon, 21 Jul 2014 19:51:07 +0200 Subject: Type family stopped compiling on upgrade from GHC 7.6.3 to 7.8.3 Message-ID: Hi, I was experimenting a bit with type families recently and ran into a bit of an issue. Given that I don't know type families that well yet, I was wondering if I made an error somewhere. One thing is that I can't find any relevant changes in the GHC release notes for 7.8.1, .2 or .3. Maybe this code contains an error which 7.6.3 simply wasn't able to find? Thanks. -------- -- this code compiles in 7.6.3, but breaks in 7.8.3 with the following message: -- TypeFamilies.hs:14:31: -- ?End? of kind ?*? is not promotable -- In the kind ?End? -- In 7.6.3, using :kind!, I can see that the type synonyms contained in the family do work the way I intend them to. {-# Language GADTs , TypeFamilies , DataKinds #-} module TypeFamilies where data End = Least | Spot Float | Most deriving (Eq, Show) data Interval = IntervalCons { left :: End, right :: End } deriving (Eq, Show) type family Interval2 (a :: End) (b :: End) :: Interval type instance Interval2 Least Most = IntervalCons Least Most type instance Interval2 (Spot l) Most = IntervalCons (Spot l) Most type instance Interval2 Least (Spot r) = IntervalCons Least (Spot r) type instance Interval2 (Spot l) (Spot r) = IntervalCons (Spot l) (Spot r) From simonpj at microsoft.com Tue Jul 22 08:57:12 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 22 Jul 2014 08:57:12 +0000 Subject: Type family stopped compiling on upgrade from GHC 7.6.3 to 7.8.3 In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF104353CB@DB3PRD3001MB020.064d.mgd.msft.net> I don't know why 7.6.3 accepts it. 'Float' is a valid type but not a valid kind. For it to be a useful kind we'd need float literal at the type level, and we have no such thing. You can use Nat instead, which does exist at the type level. Simon | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces at haskell.org] On Behalf Of cheater00 . | Sent: 21 July 2014 18:51 | To: glasgow-haskell-users at haskell.org | Subject: Type family stopped compiling on upgrade from GHC 7.6.3 to | 7.8.3 | | Hi, I was experimenting a bit with type families recently and ran into | a bit of an issue. Given that I don't know type families that well yet, | I was wondering if I made an error somewhere. One thing is that I can't | find any relevant changes in the GHC release notes for 7.8.1, .2 or .3. | | Maybe this code contains an error which 7.6.3 simply wasn't able to | find? | | Thanks. | | -------- | | -- this code compiles in 7.6.3, but breaks in 7.8.3 with the following | message: | -- TypeFamilies.hs:14:31: | -- ?End? of kind ?*? is not promotable | -- In the kind ?End? | -- In 7.6.3, using :kind!, I can see that the type synonyms contained | in the family do work the way I intend them to. | | | {-# Language | GADTs | , TypeFamilies | , DataKinds | #-} | module TypeFamilies where | | data End = Least | Spot Float | Most | deriving (Eq, Show) | | data Interval = IntervalCons { left :: End, right :: End } | deriving (Eq, Show) | | type family Interval2 (a :: End) (b :: End) :: Interval | type instance Interval2 Least Most = IntervalCons Least | Most | type instance Interval2 (Spot l) Most = IntervalCons (Spot l) | Most | type instance Interval2 Least (Spot r) = IntervalCons Least | (Spot r) | type instance Interval2 (Spot l) (Spot r) = IntervalCons (Spot l) | (Spot r) | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users at haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From cheater00 at gmail.com Tue Jul 22 09:20:59 2014 From: cheater00 at gmail.com (cheater00 .) Date: Tue, 22 Jul 2014 11:20:59 +0200 Subject: Type family stopped compiling on upgrade from GHC 7.6.3 to 7.8.3 In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF104353CB@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF104353CB@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Indeed, I hadn't come to use that at the type level; the original code used my own types which ended up holding LocalTime; I used Float as a simplification as it displayed the same weird behaviour. I guess in the act of randomly walking parseable type family code I have inadvertently unearthed a bug, which someone else inadvertently fixed, making me a sort of human QuickCheck. On 22 Jul 2014 10:57, "Simon Peyton Jones" wrote: > I don't know why 7.6.3 accepts it. 'Float' is a valid type but not a > valid kind. For it to be a useful kind we'd need float literal at the type > level, and we have no such thing. You can use Nat instead, which does > exist at the type level. > > Simon > > | -----Original Message----- > | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- > | bounces at haskell.org] On Behalf Of cheater00 . > | Sent: 21 July 2014 18:51 > | To: glasgow-haskell-users at haskell.org > | Subject: Type family stopped compiling on upgrade from GHC 7.6.3 to > | 7.8.3 > | > | Hi, I was experimenting a bit with type families recently and ran into > | a bit of an issue. Given that I don't know type families that well yet, > | I was wondering if I made an error somewhere. One thing is that I can't > | find any relevant changes in the GHC release notes for 7.8.1, .2 or .3. > | > | Maybe this code contains an error which 7.6.3 simply wasn't able to > | find? > | > | Thanks. > | > | -------- > | > | -- this code compiles in 7.6.3, but breaks in 7.8.3 with the following > | message: > | -- TypeFamilies.hs:14:31: > | -- ?End? of kind ?*? is not promotable > | -- In the kind ?End? > | -- In 7.6.3, using :kind!, I can see that the type synonyms contained > | in the family do work the way I intend them to. > | > | > | {-# Language > | GADTs > | , TypeFamilies > | , DataKinds > | #-} > | module TypeFamilies where > | > | data End = Least | Spot Float | Most > | deriving (Eq, Show) > | > | data Interval = IntervalCons { left :: End, right :: End } > | deriving (Eq, Show) > | > | type family Interval2 (a :: End) (b :: End) :: Interval > | type instance Interval2 Least Most = IntervalCons Least > | Most > | type instance Interval2 (Spot l) Most = IntervalCons (Spot l) > | Most > | type instance Interval2 Least (Spot r) = IntervalCons Least > | (Spot r) > | type instance Interval2 (Spot l) (Spot r) = IntervalCons (Spot l) > | (Spot r) > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users at haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Wed Jul 23 11:57:00 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 23 Jul 2014 13:57:00 +0200 Subject: Looking for list comprehensions use cases Message-ID: <201407231357.00773.jan.stolarek@p.lodz.pl> Haskellers, recently I've been looking into the possibility of creating some new optimisations for GHC. These would be mostly aimed at list comprehensions. Here's where I need your help: 1. Do you have complex list comprehensions usage examples from real code? By complex I mean nested list comprehensions, reading from more than one list ([ ...| x <- xs, y <- ys ... ]) etc. 2. Do you have list comprehensions code that you had to optimize by hand because GHC was unable to make them fast enough? Janek From choener at tbi.univie.ac.at Wed Jul 23 12:28:27 2014 From: choener at tbi.univie.ac.at (Christian =?iso-8859-1?Q?H=F6ner?= zu Siederdissen) Date: Wed, 23 Jul 2014 14:28:27 +0200 Subject: Looking for list comprehensions use cases In-Reply-To: <201407231357.00773.jan.stolarek@p.lodz.pl> References: <201407231357.00773.jan.stolarek@p.lodz.pl> Message-ID: <20140723122827.GA9948@lambda.fritz.box> Hi Janek, yes to both -- in a way. See Section 5.3 here for lists: http://dl.acm.org/citation.cfm?id=2543736 For my usual work, I use stream fusion and manually 'flatten' everything in all of ADPfusion and rather large bunch of other work building on top of that. ;-) Giegerich's original ADP is full or list comprehensions -- every single function uses them, and does not require a lot of additional machinery to run. http://bibiserv.techfak.uni-bielefeld.de/adp/ Note that if you want to introduce deep optimizations, it'll be a larger project. See also Coutts' phd thesis ([2] in our paper), and the original stream fusion paper [3]. Gruss, Christian === [2] D. Coutts. Stream Fusion: Practical Shortcut Fusion for Coinductive Sequence Types. PhD thesis, University of Oxford, 2010. [3] D. Coutts, R. Leshchinskiy, and D. Stewart. Stream fusion: From lists to streams to nothing at all. In Proceedings of the 12th ACM SIGPLAN International Conference on Functional Programming, pages 315? 326, Freiburg, Germany, 2007. ACM. * Jan Stolarek [23.07.2014 13:57]: > Haskellers, > > recently I've been looking into the possibility of creating some new optimisations for GHC. These > would be mostly aimed at list comprehensions. Here's where I need your help: > > 1. Do you have complex list comprehensions usage examples from real code? By complex I mean > nested list comprehensions, reading from more than one list ([ ...| x <- xs, y <- ys ... ]) etc. > > 2. Do you have list comprehensions code that you had to optimize by hand because GHC was unable to > make them fast enough? > > Janek > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From cheater00 at gmail.com Wed Jul 23 14:49:14 2014 From: cheater00 at gmail.com (cheater00 .) Date: Wed, 23 Jul 2014 16:49:14 +0200 Subject: Type family stopped compiling on upgrade from GHC 7.6.3 to 7.8.3 In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF104353CB@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Dear all, while still not understanding kinds and type families well enough, my random explorations have led me to finding syntax which currently is accepted in 7.8.3 but seems to be surprising as well. This is to mean the code is probably bogus, but GHC somehow manages not to notice. If I write: data Cmp a where Inf :: Cmp a Sup :: Cmp a V :: a -> Cmp a deriving (Show, Eq) data family CmpInterval (a :: Cmp k) (b :: Cmp k) :: * data instance CmpInterval Inf Sup = Always data instance CmpInterval (V c) Sup = Starting c data instance CmpInterval Inf (V d) = Ending d data instance CmpInterval (V c) (V d) = c `Interval` d that compiles without complaint. However, if I add deriving (Show) to any instance but the first one: data family CmpInterval (a :: Cmp k) (b :: Cmp k) :: * data instance CmpInterval Inf Sup = Always data instance CmpInterval (V c) Sup = Starting c data instance CmpInterval Inf (V d) = Ending d data instance CmpInterval (V c) (V d) = c `Interval` d deriving (Show) then I get: src/Parser.hs:864:13: Can't make a derived instance of ?Show (CmpInterval ('V c) ('V d))?: No family instance for ?CmpInterval ('V c) ('V d)? In the data instance declaration for ?CmpInterval? Which is surprising, because the instance gets accepted without error, whereas if we actually try to use it then it turns out not to be there. I was wondering if I again did something wrong (I'm still negotiating with type families whether they'll let me understand them) and if so, whether GHC would normally be expected to tell me of that - or do I need to populate the type families with types and/or values in order to let GHC finally figure out the code I'm writing is bogus? Thanks! On Tue, Jul 22, 2014 at 11:20 AM, cheater00 . wrote: > Indeed, I hadn't come to use that at the type level; the original code used > my own types which ended up holding LocalTime; I used Float as a > simplification as it displayed the same weird behaviour. > > I guess in the act of randomly walking parseable type family code I have > inadvertently unearthed a bug, which someone else inadvertently fixed, > making me a sort of human QuickCheck. > > On 22 Jul 2014 10:57, "Simon Peyton Jones" wrote: >> >> I don't know why 7.6.3 accepts it. 'Float' is a valid type but not a >> valid kind. For it to be a useful kind we'd need float literal at the type >> level, and we have no such thing. You can use Nat instead, which does exist >> at the type level. >> >> Simon >> >> | -----Original Message----- >> | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- >> | bounces at haskell.org] On Behalf Of cheater00 . >> | Sent: 21 July 2014 18:51 >> | To: glasgow-haskell-users at haskell.org >> | Subject: Type family stopped compiling on upgrade from GHC 7.6.3 to >> | 7.8.3 >> | >> | Hi, I was experimenting a bit with type families recently and ran into >> | a bit of an issue. Given that I don't know type families that well yet, >> | I was wondering if I made an error somewhere. One thing is that I can't >> | find any relevant changes in the GHC release notes for 7.8.1, .2 or .3. >> | >> | Maybe this code contains an error which 7.6.3 simply wasn't able to >> | find? >> | >> | Thanks. >> | >> | -------- >> | >> | -- this code compiles in 7.6.3, but breaks in 7.8.3 with the following >> | message: >> | -- TypeFamilies.hs:14:31: >> | -- ?End? of kind ?*? is not promotable >> | -- In the kind ?End? >> | -- In 7.6.3, using :kind!, I can see that the type synonyms contained >> | in the family do work the way I intend them to. >> | >> | >> | {-# Language >> | GADTs >> | , TypeFamilies >> | , DataKinds >> | #-} >> | module TypeFamilies where >> | >> | data End = Least | Spot Float | Most >> | deriving (Eq, Show) >> | >> | data Interval = IntervalCons { left :: End, right :: End } >> | deriving (Eq, Show) >> | >> | type family Interval2 (a :: End) (b :: End) :: Interval >> | type instance Interval2 Least Most = IntervalCons Least >> | Most >> | type instance Interval2 (Spot l) Most = IntervalCons (Spot l) >> | Most >> | type instance Interval2 Least (Spot r) = IntervalCons Least >> | (Spot r) >> | type instance Interval2 (Spot l) (Spot r) = IntervalCons (Spot l) >> | (Spot r) >> | _______________________________________________ >> | Glasgow-haskell-users mailing list >> | Glasgow-haskell-users at haskell.org >> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From eir at cis.upenn.edu Wed Jul 23 15:22:55 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 23 Jul 2014 11:22:55 -0400 Subject: Type family stopped compiling on upgrade from GHC 7.6.3 to 7.8.3 In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF104353CB@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: This seems to be a bug in GHC. I can write the Show instance manually: instance (Show c, Show d) => Show (CmpInterval (V c) (V d)) where show (c `Interval` d) = show c ++ " `Interval` " ++ show d Perhaps you should file a bug report -- your code looks sensible to me. Richard On Jul 23, 2014, at 10:49 AM, "cheater00 ." wrote: > Dear all, > while still not understanding kinds and type families well enough, my > random explorations have led me to finding syntax which currently is > accepted in 7.8.3 but seems to be surprising as well. This is to mean > the code is probably bogus, but GHC somehow manages not to notice. > > If I write: > > data Cmp a where > Inf :: Cmp a > Sup :: Cmp a > V :: a -> Cmp a > deriving (Show, Eq) > > data family CmpInterval (a :: Cmp k) (b :: Cmp k) :: * > data instance CmpInterval Inf Sup = Always > data instance CmpInterval (V c) Sup = Starting c > data instance CmpInterval Inf (V d) = Ending d > data instance CmpInterval (V c) (V d) = c `Interval` d > > that compiles without complaint. However, if I add deriving (Show) to > any instance but the first one: > > data family CmpInterval (a :: Cmp k) (b :: Cmp k) :: * > data instance CmpInterval Inf Sup = Always > data instance CmpInterval (V c) Sup = Starting c > data instance CmpInterval Inf (V d) = Ending d > data instance CmpInterval (V c) (V d) = c `Interval` d > deriving (Show) > > then I get: > > src/Parser.hs:864:13: > Can't make a derived instance of > ?Show (CmpInterval ('V c) ('V d))?: > No family instance for ?CmpInterval ('V c) ('V d)? > In the data instance declaration for ?CmpInterval? > > Which is surprising, because the instance gets accepted without error, > whereas if we actually try to use it then it turns out not to be > there. > > I was wondering if I again did something wrong (I'm still negotiating > with type families whether they'll let me understand them) and if so, > whether GHC would normally be expected to tell me of that - or do I > need to populate the type families with types and/or values in order > to let GHC finally figure out the code I'm writing is bogus? > > Thanks! > > On Tue, Jul 22, 2014 at 11:20 AM, cheater00 . wrote: >> Indeed, I hadn't come to use that at the type level; the original code used >> my own types which ended up holding LocalTime; I used Float as a >> simplification as it displayed the same weird behaviour. >> >> I guess in the act of randomly walking parseable type family code I have >> inadvertently unearthed a bug, which someone else inadvertently fixed, >> making me a sort of human QuickCheck. >> >> On 22 Jul 2014 10:57, "Simon Peyton Jones" wrote: >>> >>> I don't know why 7.6.3 accepts it. 'Float' is a valid type but not a >>> valid kind. For it to be a useful kind we'd need float literal at the type >>> level, and we have no such thing. You can use Nat instead, which does exist >>> at the type level. >>> >>> Simon >>> >>> | -----Original Message----- >>> | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- >>> | bounces at haskell.org] On Behalf Of cheater00 . >>> | Sent: 21 July 2014 18:51 >>> | To: glasgow-haskell-users at haskell.org >>> | Subject: Type family stopped compiling on upgrade from GHC 7.6.3 to >>> | 7.8.3 >>> | >>> | Hi, I was experimenting a bit with type families recently and ran into >>> | a bit of an issue. Given that I don't know type families that well yet, >>> | I was wondering if I made an error somewhere. One thing is that I can't >>> | find any relevant changes in the GHC release notes for 7.8.1, .2 or .3. >>> | >>> | Maybe this code contains an error which 7.6.3 simply wasn't able to >>> | find? >>> | >>> | Thanks. >>> | >>> | -------- >>> | >>> | -- this code compiles in 7.6.3, but breaks in 7.8.3 with the following >>> | message: >>> | -- TypeFamilies.hs:14:31: >>> | -- ?End? of kind ?*? is not promotable >>> | -- In the kind ?End? >>> | -- In 7.6.3, using :kind!, I can see that the type synonyms contained >>> | in the family do work the way I intend them to. >>> | >>> | >>> | {-# Language >>> | GADTs >>> | , TypeFamilies >>> | , DataKinds >>> | #-} >>> | module TypeFamilies where >>> | >>> | data End = Least | Spot Float | Most >>> | deriving (Eq, Show) >>> | >>> | data Interval = IntervalCons { left :: End, right :: End } >>> | deriving (Eq, Show) >>> | >>> | type family Interval2 (a :: End) (b :: End) :: Interval >>> | type instance Interval2 Least Most = IntervalCons Least >>> | Most >>> | type instance Interval2 (Spot l) Most = IntervalCons (Spot l) >>> | Most >>> | type instance Interval2 Least (Spot r) = IntervalCons Least >>> | (Spot r) >>> | type instance Interval2 (Spot l) (Spot r) = IntervalCons (Spot l) >>> | (Spot r) >>> | _______________________________________________ >>> | Glasgow-haskell-users mailing list >>> | Glasgow-haskell-users at haskell.org >>> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From p.k.f.holzenspies at utwente.nl Wed Jul 23 16:06:58 2014 From: p.k.f.holzenspies at utwente.nl (p.k.f.holzenspies at utwente.nl) Date: Wed, 23 Jul 2014 16:06:58 +0000 Subject: GhcPlugin-writing and "finding things" Message-ID: Dear GHC-ers, I'm working on a plugin for GHC that should help compile the library with which this plugin is to ship. What this plugin does is traverse the CoreProgram(s) to find things of types defined in my library and optimizes them. I have worked out how to "find" things, but I was wondering whether the API could be improved for plugin-writers. For the sake of argument, I have the following: - module Foo: library for users to import, containing functions, ADTs etc - module Foo.Plugin: GhcPlugin that compiles out all uses of things in Foo > module Foo where > > data Foo x = Foo x > > runFoo :: Foo x -> x > runFoo (Foo x) = x This example is trivial and I imagine GHC will have no trouble eliminating most cases of this, but imagine more complex stuff. Now, if I want to traverse the CoreProgram in my plugin, I need to find occurrences of these, so somewhere there's stuff like: > pass tcFoo _ _ (NonRec b expr) > | varType b `containsTyConAnywhere` tcFoo > = {- clever stuff to compile out Foo -} My problem is "getting" tcFoo in this example. Below is how I do it now. Maybe I'm being thick, or maybe there's just no simpler way. This is my 'plugin' function in Foo.Plugin: > plugin = Plugin $ \opts todo -> do > hsc <- getHscEnv > dfs <- getDynFlags > fr <- liftIO $ findImportedModule hsc (mkModuleName "Foo") Nothing > mod <- case fr of > Found ml m -> return m > _ -> panic "Failed to (unambiguously) find 'Foo' (using findImportedModule)" > onc <- getOrigNameCache > let nms = lookupWithDefaultModuleEnv nms (panic "No names defined for module 'Foo'") mod > find_ d occ fnd nm > = maybe > (fail $ "Failed to find " ++ d ++ " '" ++ nm ++ "'") > fnd > (lookupOccEnv nms $ occ nm) > tcFind = find_ "TyCon" mkTcOcc lookupTyCon > dcFind = find_ "DataCon" mkDataOcc lookupDataCon > idFind = find_ "Id" mkVarOcc lookupId > tcFoo <- tcFind "Foo" > dcFoo <- dcFind "Foo" > idRunFoo <- idFind "runFoo" > return $ CoreDoPluginPass "Foo optimisation" (pass tcFoo dcFoo idRunFoo) : todo I have the following questions: 1) Is this a/the right way to "find" those things in the plugin? 2) There seems to be a lot to gain with quasi-quoting a la Template Haskell for people writing plugins to go with a library that they wrote. Can such QQ be done? Has it been considered? 3) Is findImportedModule the right function to find my starting point to begin with? 4) What is the 'Maybe FastString' argument in findImportedModule for? I've been trying to put in the FSs of PackageIDs, but they make the lookup fail. This (dumb) example really made me nervous: > fr <- liftIO $ findImportedModule hsc (mkModuleName "Foo") Nothing > mod <- case fr of > Found ml m -> do > fr' <- liftIO $ findImportedModule hsc (moduleName m) (packageIdFS $ packageId m) Here, fr' should always be a "Found ml' m'" such that ml == ml' and m == m', but... it consistently results in NotFound{} for me. Also, I find this especially round-about. Shouldn't Paths_Foo.hs (the Cabal-generated file) maybe contain variables for every module in the package? In my case it would thus contain some "modFoo :: Module" Comments and suggestions more than welcome! Regards, Philip From afarmer at ittc.ku.edu Wed Jul 23 17:22:03 2014 From: afarmer at ittc.ku.edu (Andrew Farmer) Date: Wed, 23 Jul 2014 12:22:03 -0500 Subject: GhcPlugin-writing and "finding things" In-Reply-To: References: Message-ID: Have you considered using HERMIT for this? I think this is a rough approximation of what you are trying to do (using HERMIT): import HERMIT.Plugin import HERMIT.Dictionary plugin = hermitPlugin $ \ opts -> firstPhase $ run $ tryR $ innermostR $ promoteBindR compileFooBindR compileFooBindR :: RewriteH CoreBind compileFooBindR = prefixFailMsg "compileFooBindR failed: " $ do NonRec b rhs <- idR -- only match on non-recursive bindings tcFoo <- findTyConT "Foo" -- can be fully qualified name if target code doesn't import directly guardMsg (varType b `containsTyConAnywhere` tyFoo) "does not contain Foo" -- abort if binder doesn't contain Foo in type return $ NonRec b $ {- magicCompileFunction -} rhs The goal of HERMIT is to make writing these plugins easier. For instance, if you give a fully qualified name to findTyConT (or the other find functions), and HERMIT can't find the name in scope in the target module, it'll look in the package database for the appropriate interface and load it. You can even run your compilation functions interactively and view their output in a REPL. To do so, change your plugin to: plugin = hermitPlugin $ firstPhase . interactive exts exts :: Externals exts = [ external "compile-foo" (promoteBindR compileFooBindR) [ "compiles bindings involving Foo" ] ] {- compileFooBindR as before -} Then you can navigate around your AST and use the "compile-foo" command to test out your compilation. If you want to try, I'd highly recommend using the latest from github, rather than what is on hackage: https://github.com/ku-fpg/hermit Here are a few examples of larger HERMIT plugins: https://github.com/xich/hermit-syb/blob/master/hermit-syb/HERMIT/Optimization/SYB.hs#L28 https://github.com/conal/lambda-ccc/blob/master/src/LambdaCCC/Reify.hs#L866 Let me know if you have questions! Andrew On Wed, Jul 23, 2014 at 11:06 AM, wrote: > Dear GHC-ers, > > I'm working on a plugin for GHC that should help compile the library with which this plugin is to ship. What this plugin does is traverse the CoreProgram(s) to find things of types defined in my library and optimizes them. I have worked out how to "find" things, but I was wondering whether the API could be improved for plugin-writers. > > For the sake of argument, I have the following: > - module Foo: library for users to import, containing functions, ADTs etc > - module Foo.Plugin: GhcPlugin that compiles out all uses of things in Foo > >> module Foo where >> >> data Foo x = Foo x >> >> runFoo :: Foo x -> x >> runFoo (Foo x) = x > > > This example is trivial and I imagine GHC will have no trouble eliminating most cases of this, but imagine more complex stuff. Now, if I want to traverse the CoreProgram in my plugin, I need to find occurrences of these, so somewhere there's stuff like: > >> pass tcFoo _ _ (NonRec b expr) >> | varType b `containsTyConAnywhere` tcFoo >> = {- clever stuff to compile out Foo -} > > My problem is "getting" tcFoo in this example. Below is how I do it now. Maybe I'm being thick, or maybe there's just no simpler way. This is my 'plugin' function in Foo.Plugin: > >> plugin = Plugin $ \opts todo -> do >> hsc <- getHscEnv >> dfs <- getDynFlags >> fr <- liftIO $ findImportedModule hsc (mkModuleName "Foo") Nothing >> mod <- case fr of >> Found ml m -> return m >> _ -> panic "Failed to (unambiguously) find 'Foo' (using findImportedModule)" >> onc <- getOrigNameCache >> let nms = lookupWithDefaultModuleEnv nms (panic "No names defined for module 'Foo'") mod >> find_ d occ fnd nm >> = maybe >> (fail $ "Failed to find " ++ d ++ " '" ++ nm ++ "'") >> fnd >> (lookupOccEnv nms $ occ nm) >> tcFind = find_ "TyCon" mkTcOcc lookupTyCon >> dcFind = find_ "DataCon" mkDataOcc lookupDataCon >> idFind = find_ "Id" mkVarOcc lookupId >> tcFoo <- tcFind "Foo" >> dcFoo <- dcFind "Foo" >> idRunFoo <- idFind "runFoo" >> return $ CoreDoPluginPass "Foo optimisation" (pass tcFoo dcFoo idRunFoo) : todo > > I have the following questions: > > 1) Is this a/the right way to "find" those things in the plugin? > 2) There seems to be a lot to gain with quasi-quoting a la Template Haskell for people writing plugins to go with a library that they wrote. Can such QQ be done? Has it been considered? > 3) Is findImportedModule the right function to find my starting point to begin with? > 4) What is the 'Maybe FastString' argument in findImportedModule for? I've been trying to put in the FSs of PackageIDs, but they make the lookup fail. This (dumb) example really made me nervous: > >> fr <- liftIO $ findImportedModule hsc (mkModuleName "Foo") Nothing >> mod <- case fr of >> Found ml m -> do >> fr' <- liftIO $ findImportedModule hsc (moduleName m) (packageIdFS $ packageId m) > > Here, fr' should always be a "Found ml' m'" such that ml == ml' and m == m', but... it consistently results in NotFound{} for me. Also, I find this especially round-about. Shouldn't Paths_Foo.hs (the Cabal-generated file) maybe contain variables for every module in the package? In my case it would thus contain some "modFoo :: Module" > > Comments and suggestions more than welcome! > > Regards, > Philip > > > > > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From p.k.f.holzenspies at utwente.nl Thu Jul 24 09:38:51 2014 From: p.k.f.holzenspies at utwente.nl (p.k.f.holzenspies at utwente.nl) Date: Thu, 24 Jul 2014 09:38:51 +0000 Subject: GhcPlugin-writing and "finding things" In-Reply-To: References: Message-ID: Dear Andrew, Thanks for your suggestion. I had considered it earlier and decided against it for the extra dependencies. Maybe I was too picky there. I will give it another go. Could there possibly be a subset of hermit that plugin-writers could depend on, but that have fewer dependencies? I find it hard to explain to people why they require things like ansi-terminal if they want to use my parser-combinators. I still think this isn't an unreasonable use case to take on board for future GHC API design, though. Also, the thing with findImportedModule still scares me. Regards, Philip > -----Original Message----- > From: xichekolas at gmail.com [mailto:xichekolas at gmail.com] On Behalf Of > Andrew Farmer > Sent: woensdag 23 juli 2014 19:22 > To: Holzenspies, P.K.F. (EWI) > Cc: glasgow-haskell-users at haskell.org > Subject: Re: GhcPlugin-writing and "finding things" > > Have you considered using HERMIT for this? I think this is a rough > approximation of what you are trying to do (using HERMIT): > > import HERMIT.Plugin > import HERMIT.Dictionary > > plugin = hermitPlugin $ \ opts -> firstPhase $ run $ tryR $ innermostR > $ promoteBindR compileFooBindR > > compileFooBindR :: RewriteH CoreBind > compileFooBindR = prefixFailMsg "compileFooBindR failed: " $ do > NonRec b rhs <- idR -- only match on non-recursive bindings > tcFoo <- findTyConT "Foo" -- can be fully qualified name if target > code doesn't import directly > guardMsg (varType b `containsTyConAnywhere` tyFoo) "does not contain > Foo" -- abort if binder doesn't contain Foo in type > return $ NonRec b $ {- magicCompileFunction -} rhs > > The goal of HERMIT is to make writing these plugins easier. For > instance, if you give a fully qualified name to findTyConT (or the > other find functions), and HERMIT can't find the name in scope in the > target module, it'll look in the package database for the appropriate > interface and load it. > > You can even run your compilation functions interactively and view > their output in a REPL. To do so, change your plugin to: > > plugin = hermitPlugin $ firstPhase . interactive exts > > exts :: Externals > exts = [ external "compile-foo" (promoteBindR compileFooBindR) [ > "compiles bindings involving Foo" ] ] > > {- compileFooBindR as before -} > > Then you can navigate around your AST and use the "compile-foo" > command to test out your compilation. > > If you want to try, I'd highly recommend using the latest from github, > rather than what is on hackage: > > https://github.com/ku-fpg/hermit > > Here are a few examples of larger HERMIT plugins: > > https://github.com/xich/hermit-syb/blob/master/hermit- > syb/HERMIT/Optimization/SYB.hs#L28 > https://github.com/conal/lambda- > ccc/blob/master/src/LambdaCCC/Reify.hs#L866 > > Let me know if you have questions! > > Andrew > > On Wed, Jul 23, 2014 at 11:06 AM, wrote: > > Dear GHC-ers, > > > > I'm working on a plugin for GHC that should help compile the library > with which this plugin is to ship. What this plugin does is traverse the > CoreProgram(s) to find things of types defined in my library and > optimizes them. I have worked out how to "find" things, but I was > wondering whether the API could be improved for plugin-writers. > > > > For the sake of argument, I have the following: > > - module Foo: library for users to import, containing functions, ADTs > etc > > - module Foo.Plugin: GhcPlugin that compiles out all uses of things > in Foo > > > >> module Foo where > >> > >> data Foo x = Foo x > >> > >> runFoo :: Foo x -> x > >> runFoo (Foo x) = x > > > > > > This example is trivial and I imagine GHC will have no trouble > eliminating most cases of this, but imagine more complex stuff. Now, if > I want to traverse the CoreProgram in my plugin, I need to find > occurrences of these, so somewhere there's stuff like: > > > >> pass tcFoo _ _ (NonRec b expr) > >> | varType b `containsTyConAnywhere` tcFoo > >> = {- clever stuff to compile out Foo -} > > > > My problem is "getting" tcFoo in this example. Below is how I do it > now. Maybe I'm being thick, or maybe there's just no simpler way. This > is my 'plugin' function in Foo.Plugin: > > > >> plugin = Plugin $ \opts todo -> do > >> hsc <- getHscEnv > >> dfs <- getDynFlags > >> fr <- liftIO $ findImportedModule hsc (mkModuleName "Foo") Nothing > >> mod <- case fr of > >> Found ml m -> return m > >> _ -> panic "Failed to (unambiguously) find 'Foo' (using > findImportedModule)" > >> onc <- getOrigNameCache > >> let nms = lookupWithDefaultModuleEnv nms (panic "No names defined > for module 'Foo'") mod > >> find_ d occ fnd nm > >> = maybe > >> (fail $ "Failed to find " ++ d ++ " '" ++ nm ++ "'") > >> fnd > >> (lookupOccEnv nms $ occ nm) > >> tcFind = find_ "TyCon" mkTcOcc lookupTyCon > >> dcFind = find_ "DataCon" mkDataOcc lookupDataCon > >> idFind = find_ "Id" mkVarOcc lookupId > >> tcFoo <- tcFind "Foo" > >> dcFoo <- dcFind "Foo" > >> idRunFoo <- idFind "runFoo" > >> return $ CoreDoPluginPass "Foo optimisation" (pass tcFoo dcFoo > idRunFoo) : todo > > > > I have the following questions: > > > > 1) Is this a/the right way to "find" those things in the plugin? > > 2) There seems to be a lot to gain with quasi-quoting a la Template > Haskell for people writing plugins to go with a library that they wrote. > Can such QQ be done? Has it been considered? > > 3) Is findImportedModule the right function to find my starting > point to begin with? > > 4) What is the 'Maybe FastString' argument in findImportedModule > for? I've been trying to put in the FSs of PackageIDs, but they make the > lookup fail. This (dumb) example really made me nervous: > > > >> fr <- liftIO $ findImportedModule hsc (mkModuleName "Foo") Nothing > >> mod <- case fr of > >> Found ml m -> do > >> fr' <- liftIO $ findImportedModule hsc (moduleName m) > (packageIdFS $ packageId m) > > > > Here, fr' should always be a "Found ml' m'" such that ml == ml' and m > == m', but... it consistently results in NotFound{} for me. Also, I find > this especially round-about. Shouldn't Paths_Foo.hs (the Cabal-generated > file) maybe contain variables for every module in the package? In my > case it would thus contain some "modFoo :: Module" > > > > Comments and suggestions more than welcome! > > > > Regards, > > Philip > > > > > > > > > > > > > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > From mike at proclivis.com Fri Jul 25 04:00:53 2014 From: mike at proclivis.com (Michael Jones) Date: Thu, 24 Jul 2014 22:00:53 -0600 Subject: Cross compiling for Cortex A9 In-Reply-To: <53C4015D.9060009@centrum.cz> References: <257A9D96-51C0-4820-8B98-D1A87531776A@proclivis.com> <53BFBDDE.1040509@centrum.cz> <1515908B-FC78-4DD8-AB57-287C4B99065C@proclivis.com> <53C394AE.4020303@centrum.cz> <67CEBBAE-CC1F-47CC-9A21-AA94C4A25149@proclivis.com> <53C4015D.9060009@centrum.cz> Message-ID: <4FC55335-526F-4007-BD0E-C8620DED6653@proclivis.com> I have some progress, and a problem. First, note I am using the 7.8.3 tar ball, for this discussion here. If you read through, you will see a request for help at the end. It looks like the cross compilation is trying to build stage2 when it shouldn?t. In order to get the resulting stage1 cross compiler to have: ,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}") I hacked this: AC_DEFUN([GET_ARM_ISA], [ changequote(, )dnl ARM_ISA=ARMv7 ARM_ISA_EXT="[VFPv3,NEON]" changequote([, ])dnl [ARM_ABI="HARD"] ]) Now, my gcc cross compiler does not default to ARMv7. To compile for my Cortex A, I add these options: -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 So I need to make sure that when building the libraries with stage1, it passes the correct options. To do that: AC_DEFUN([FPTOOLS_SET_C_LD_FLAGS], [ AC_MSG_CHECKING([Setting up $2, $3, $4 and $5]) ? arm-poky-*) $2="$$2 -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9" ;; Which results in a stage1 compiler with: ,("C compiler flags"," -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 -fno-stack-protector?) As the build proceeds, all calls to stage1 are completing. Then, the build gets to this point: "inplace/bin/mkdirhier" compiler/stage2/build//. "rm" -f compiler/stage2/build/Config.hs Creating compiler/stage2/build/Config.hs ... done. And I assume this means it is trying to build stage2. Correct me if I am wrong. Eventually I get a build failure like this: gcc -E -DMAKING_GHC_BUILD_SYSTEM_DEPENDENCIES -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 -fno-stack-protector -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -DGHCI -I'/home/mike/ghc-7.8.3/libraries/process/include' -I'/home/mike/ghc-7.8.3/libraries/directory/include' -I'/home/mike/ghc-7.8.3/libraries/unix/include' -I'/home/mike/ghc-7.8.3/libraries/time/include' -I'/home/mike/ghc-7.8.3/libraries/containers/include' -I'/home/mike/ghc-7.8.3/libraries/bytestring/include' -I'/home/mike/ghc-7.8.3/libraries/base/include' -I'/home/mike/ghc-7.8.3/rts/dist/build' -I'/home/mike/ghc-7.8.3/includes' -I'/home/mike/ghc-7.8.3/includes/dist-derivedconstants/header' -MM -x c compiler/parser/cutils.c -MF compiler/stage2/build/.depend-v.c_asm.bit gcc: error: unrecognized command line option ?-mthumb-interwork? gcc: error: unrecognized command line option ?-mfloat-abi=hard? gcc: error: unrecognized command line option ?-mfpu=neon? make[1]: *** [compiler/stage2/build/.depend-v.c_asm] Error 1 make: *** [all] Error 2 It is applying the -march? arguments to the local gcc. I am guessing that compiling for stage2 is using the local gcc because stage2 is only built when not making a cross compiler. Now, in build.mk I have: BuildFlavour = quick-cross Which is supposed to prevent stage2 compilation. Something is wrong. Either I need to stop stage2 compilation, if that is what this is really doing, or prevent gcc from using the extra arguments. But I see no reason to run gcc. Seems like that would only be used at stage0 if at all. Mike On Jul 14, 2014, at 10:12 AM, Karel Gardas wrote: > On 07/14/14 04:58 PM, Michael Jones wrote: >> Karel, >> >> Thanks. This helps. >> >> If I understand, you have Linux running on a Panda, and on that Panda >> system you have gcc, and you compile GHC on the Panda itself, rather >> than build a cross compiler. I can see the advantage of building this >> way. > > Correct! > >> As far as cross compilers, I have a reason for trying to build a >> cross compiler, other than the ability to keep the image of the >> target small. That is, eventually, I want to be able to compile for >> an RTOS and/or bare iron system. I decided that learning to cross >> compile for Linux first would be a good approach. Learn the build >> system on something known to work. So I probably will not give up on >> that. > > That is right, in future I'd also like to give a try to port GHC to some free RTOS and for this I'd need to use cross-compiling anyway, so I'll be on the same boat... > >> I got a book on Autoconfig. I?ll just have to dig a level deeper into >> the whole build system. Mainly it means learning the M4 system. I >> have never used it. >> >> Below are the defines from the command you suggested. Thanks for >> that, got me over an ignorance hump. At least this define, >> __ARM_ARCH_5T__, is in the aclocal.m4 file. So I will have to study >> the macros until I figure out what controls the gcc options passed to >> the gcc cross compiler. I guess my question is what actually controls >> this result ("target arch", "ArchARM {armISA = ARMv7, armISAExt = >> [VFPv3,NEON], armABI = HARD}?)? >> >> Are these controlled by the defines below, or are they controlled by >> passing gcc arguments to the gcc compiler when the Haskell compiler >> calls gcc? > > Basically speaking all those are controlled by platform gcc. That means if you pass the right option to your cross-compiling gcc you should also get the same result, so for example if you use: > > gcc -mfloat-abi=hard -march=armv7-a -mfpu=vfpv3-d16 > > you should get the same settings like me. > > But anyway, please note that ABI you set to your cross-compiler *have to* match the ABI provided by the target RTOS/OS! I hope that's clear. :-) > > Cheers, > Karel -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Jul 25 10:59:11 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 25 Jul 2014 10:59:11 +0000 Subject: GhcPlugin-writing and "finding things" In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF104391F8@DB3PRD3001MB020.064d.mgd.msft.net> Philip You are right: there are some missing pieces. * First you need to ask where your plugin's special library module "Foo" is in the file system. This is what findImportedModule is for, and it seems quite reasonable. However, it (or some variant) should be available to you in CoreM. * Next, suppose you special library module defines a special type "T". You need to get its Name. For this you a CoreM variant of IfaceEnv.lookupOrig. The function CoreMonad.getOrigNameCache is far too low level and should be killed. Instead, CoreMonad should expose lookupOrig :: Module -> OccName -> CoreM Name It should be an easy function to write, using IfaceEnv.lookupOrig; maybe a tiny bit of refactoring. * Next you want to get from T's Name to T's TyCon. Here CoreMonad is fine: it offers lookupThing :: Name -> CoreM TyThing This function calls TcEnv.tcLookupGlobal, which will automatically load Foo.hi if need be. So your code should look like foo_mod <- findImportedModule "Foo" t_name <- lookupOrig foo_mod (mkTcOcc "T") t_tycon <- lookupThing t_name corresponding to these three steps. I suspect that the error cases of findImported module should be dealt with via exceptions in CoreM, to de-clutter the code. Some of the above suggests a bit of cleaning up of the CoreM API. Would someone like to undertake that? I can advise, but I don't want to lead. Simon | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces at haskell.org] On Behalf Of p.k.f.holzenspies at utwente.nl | Sent: 23 July 2014 17:07 | To: glasgow-haskell-users at haskell.org | Subject: GhcPlugin-writing and "finding things" | | Dear GHC-ers, | | I'm working on a plugin for GHC that should help compile the library | with which this plugin is to ship. What this plugin does is traverse | the CoreProgram(s) to find things of types defined in my library and | optimizes them. I have worked out how to "find" things, but I was | wondering whether the API could be improved for plugin-writers. | | For the sake of argument, I have the following: | - module Foo: library for users to import, containing functions, ADTs | etc | - module Foo.Plugin: GhcPlugin that compiles out all uses of things in | Foo | | > module Foo where | > | > data Foo x = Foo x | > | > runFoo :: Foo x -> x | > runFoo (Foo x) = x | | | This example is trivial and I imagine GHC will have no trouble | eliminating most cases of this, but imagine more complex stuff. Now, if | I want to traverse the CoreProgram in my plugin, I need to find | occurrences of these, so somewhere there's stuff like: | | > pass tcFoo _ _ (NonRec b expr) | > | varType b `containsTyConAnywhere` tcFoo | > = {- clever stuff to compile out Foo -} | | My problem is "getting" tcFoo in this example. Below is how I do it | now. Maybe I'm being thick, or maybe there's just no simpler way. This | is my 'plugin' function in Foo.Plugin: | | > plugin = Plugin $ \opts todo -> do | > hsc <- getHscEnv | > dfs <- getDynFlags | > fr <- liftIO $ findImportedModule hsc (mkModuleName "Foo") Nothing | > mod <- case fr of | > Found ml m -> return m | > _ -> panic "Failed to (unambiguously) find 'Foo' (using | findImportedModule)" | > onc <- getOrigNameCache | > let nms = lookupWithDefaultModuleEnv nms (panic "No names defined | for module 'Foo'") mod | > find_ d occ fnd nm | > = maybe | > (fail $ "Failed to find " ++ d ++ " '" ++ nm ++ "'") | > fnd | > (lookupOccEnv nms $ occ nm) | > tcFind = find_ "TyCon" mkTcOcc lookupTyCon | > dcFind = find_ "DataCon" mkDataOcc lookupDataCon | > idFind = find_ "Id" mkVarOcc lookupId | > tcFoo <- tcFind "Foo" | > dcFoo <- dcFind "Foo" | > idRunFoo <- idFind "runFoo" | > return $ CoreDoPluginPass "Foo optimisation" (pass tcFoo dcFoo | > idRunFoo) : todo | | I have the following questions: | | 1) Is this a/the right way to "find" those things in the plugin? | 2) There seems to be a lot to gain with quasi-quoting a la Template | Haskell for people writing plugins to go with a library that they | wrote. Can such QQ be done? Has it been considered? | 3) Is findImportedModule the right function to find my starting point | to begin with? | 4) What is the 'Maybe FastString' argument in findImportedModule for? | I've been trying to put in the FSs of PackageIDs, but they make the | lookup fail. This (dumb) example really made me nervous: | | > fr <- liftIO $ findImportedModule hsc (mkModuleName "Foo") Nothing | > mod <- case fr of | > Found ml m -> do | > fr' <- liftIO $ findImportedModule hsc (moduleName m) | > (packageIdFS $ packageId m) | | Here, fr' should always be a "Found ml' m'" such that ml == ml' and m | == m', but... it consistently results in NotFound{} for me. Also, I | find this especially round-about. Shouldn't Paths_Foo.hs (the Cabal- | generated file) maybe contain variables for every module in the | package? In my case it would thus contain some "modFoo :: Module" | | Comments and suggestions more than welcome! | | Regards, | Philip | | | | | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users at haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From cheater00 at gmail.com Sat Jul 26 16:40:52 2014 From: cheater00 at gmail.com (cheater00 .) Date: Sat, 26 Jul 2014 18:40:52 +0200 Subject: Type family stopped compiling on upgrade from GHC 7.6.3 to 7.8.3 In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF104353CB@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Thanks all for the conversation, it seems that Simon fixed the bug before I could even report it, displaying his expectably excellent programming abilities. On Wed, Jul 23, 2014 at 5:22 PM, Richard Eisenberg wrote: > This seems to be a bug in GHC. I can write the Show instance manually: > > instance (Show c, Show d) => Show (CmpInterval (V c) (V d)) where > show (c `Interval` d) = show c ++ " `Interval` " ++ show d > > Perhaps you should file a bug report -- your code looks sensible to me. > > Richard > > On Jul 23, 2014, at 10:49 AM, "cheater00 ." wrote: > >> Dear all, >> while still not understanding kinds and type families well enough, my >> random explorations have led me to finding syntax which currently is >> accepted in 7.8.3 but seems to be surprising as well. This is to mean >> the code is probably bogus, but GHC somehow manages not to notice. >> >> If I write: >> >> data Cmp a where >> Inf :: Cmp a >> Sup :: Cmp a >> V :: a -> Cmp a >> deriving (Show, Eq) >> >> data family CmpInterval (a :: Cmp k) (b :: Cmp k) :: * >> data instance CmpInterval Inf Sup = Always >> data instance CmpInterval (V c) Sup = Starting c >> data instance CmpInterval Inf (V d) = Ending d >> data instance CmpInterval (V c) (V d) = c `Interval` d >> >> that compiles without complaint. However, if I add deriving (Show) to >> any instance but the first one: >> >> data family CmpInterval (a :: Cmp k) (b :: Cmp k) :: * >> data instance CmpInterval Inf Sup = Always >> data instance CmpInterval (V c) Sup = Starting c >> data instance CmpInterval Inf (V d) = Ending d >> data instance CmpInterval (V c) (V d) = c `Interval` d >> deriving (Show) >> >> then I get: >> >> src/Parser.hs:864:13: >> Can't make a derived instance of >> ?Show (CmpInterval ('V c) ('V d))?: >> No family instance for ?CmpInterval ('V c) ('V d)? >> In the data instance declaration for ?CmpInterval? >> >> Which is surprising, because the instance gets accepted without error, >> whereas if we actually try to use it then it turns out not to be >> there. >> >> I was wondering if I again did something wrong (I'm still negotiating >> with type families whether they'll let me understand them) and if so, >> whether GHC would normally be expected to tell me of that - or do I >> need to populate the type families with types and/or values in order >> to let GHC finally figure out the code I'm writing is bogus? >> >> Thanks! >> >> On Tue, Jul 22, 2014 at 11:20 AM, cheater00 . wrote: >>> Indeed, I hadn't come to use that at the type level; the original code used >>> my own types which ended up holding LocalTime; I used Float as a >>> simplification as it displayed the same weird behaviour. >>> >>> I guess in the act of randomly walking parseable type family code I have >>> inadvertently unearthed a bug, which someone else inadvertently fixed, >>> making me a sort of human QuickCheck. >>> >>> On 22 Jul 2014 10:57, "Simon Peyton Jones" wrote: >>>> >>>> I don't know why 7.6.3 accepts it. 'Float' is a valid type but not a >>>> valid kind. For it to be a useful kind we'd need float literal at the type >>>> level, and we have no such thing. You can use Nat instead, which does exist >>>> at the type level. >>>> >>>> Simon >>>> >>>> | -----Original Message----- >>>> | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- >>>> | bounces at haskell.org] On Behalf Of cheater00 . >>>> | Sent: 21 July 2014 18:51 >>>> | To: glasgow-haskell-users at haskell.org >>>> | Subject: Type family stopped compiling on upgrade from GHC 7.6.3 to >>>> | 7.8.3 >>>> | >>>> | Hi, I was experimenting a bit with type families recently and ran into >>>> | a bit of an issue. Given that I don't know type families that well yet, >>>> | I was wondering if I made an error somewhere. One thing is that I can't >>>> | find any relevant changes in the GHC release notes for 7.8.1, .2 or .3. >>>> | >>>> | Maybe this code contains an error which 7.6.3 simply wasn't able to >>>> | find? >>>> | >>>> | Thanks. >>>> | >>>> | -------- >>>> | >>>> | -- this code compiles in 7.6.3, but breaks in 7.8.3 with the following >>>> | message: >>>> | -- TypeFamilies.hs:14:31: >>>> | -- ?End? of kind ?*? is not promotable >>>> | -- In the kind ?End? >>>> | -- In 7.6.3, using :kind!, I can see that the type synonyms contained >>>> | in the family do work the way I intend them to. >>>> | >>>> | >>>> | {-# Language >>>> | GADTs >>>> | , TypeFamilies >>>> | , DataKinds >>>> | #-} >>>> | module TypeFamilies where >>>> | >>>> | data End = Least | Spot Float | Most >>>> | deriving (Eq, Show) >>>> | >>>> | data Interval = IntervalCons { left :: End, right :: End } >>>> | deriving (Eq, Show) >>>> | >>>> | type family Interval2 (a :: End) (b :: End) :: Interval >>>> | type instance Interval2 Least Most = IntervalCons Least >>>> | Most >>>> | type instance Interval2 (Spot l) Most = IntervalCons (Spot l) >>>> | Most >>>> | type instance Interval2 Least (Spot r) = IntervalCons Least >>>> | (Spot r) >>>> | type instance Interval2 (Spot l) (Spot r) = IntervalCons (Spot l) >>>> | (Spot r) >>>> | _______________________________________________ >>>> | Glasgow-haskell-users mailing list >>>> | Glasgow-haskell-users at haskell.org >>>> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > From simonpj at microsoft.com Tue Jul 29 09:11:05 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 29 Jul 2014 09:11:05 +0000 Subject: Overlapping and incoherent instances Message-ID: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> Friends One of GHC's more widely-used features is overlapping (and sometimes incoherent) instances. The user-manual documentation is here. The use of overlapping/incoherent instances is controlled by LANGUAGE pragmas: OverlappingInstances and IncoherentInstances respectively. However the overlap/incoherent-ness is a property of the *instance declaration* itself, and has been for a long time. Using LANGUAGE OverlappingInstances simply sets the "I am an overlapping instance" flag for every instance declaration in that module. This is a Big Hammer. It give no clue about *which* particular instances the programmer is expecting to be overlapped, nor which are doing the overlapping. It brutally applies to every instance in the module. Moreover, when looking at an instance declaration, there is no nearby clue that it might be overlapped. The clue might be in the command line that compiles that module! Iavor has recently implemented per-instance-declaration pragmas, so you can say instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... instance {-# OVERLAPPING #-} Show [Char] where ... This is much more precise (it affects only those specific instances) and it is much clearer (you see it when you see the instance declaration). This new feature will be in GHC 7.10 and I'm sure you will be happy about that. But I propose also to deprecate the LANGUAGE pragmas OverlappingInstances and IncoherentInstances, as way to encourage everyone to use the new feature instead of the old big hammer. The old LANGUAGE pragmas will continue to work, of course, for at least another complete release cycle. We could make that two cycles if it was helpful. However, if you want deprecation-free libraries, it will entail a wave of library updates. This email is just to warn you, and to let you yell if you think this is a bad idea. It would actually not be difficult to retain the old LANGUAGE pragmas indefinitely - it just seems wrong not to actively push authors in the right direction. These deprecations of course popped up in the test suite, so I've been replacing them with per-instance pragmas there too. Interestingly in some cases, when looking for which instances needed the pragmas, I found...none. So OverlappingInstances was entirely unnecessary. Maybe library authors will find that too! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Tue Jul 29 09:50:08 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 29 Jul 2014 11:50:08 +0200 Subject: Overlapping and incoherent instances In-Reply-To: <53D76989.2070808@nh2.me> ("Niklas \=\?utf-8\?Q\?Hamb\=C3\=BCchen\?\= \=\?utf-8\?Q\?\=22's\?\= message of "Tue, 29 Jul 2014 11:29:45 +0200") References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <53D76989.2070808@nh2.me> Message-ID: <87lhrcbijz.fsf@gnu.org> On 2014-07-29 at 11:29:45 +0200, Niklas Hamb?chen wrote: >> instance {-# OVERLAPPABLE #-} Show a => Show [a] where ? > > Is the syntax somewhat flexible in where the pragma can be placed? > For example, some might prefer > > {-# OVERLAPPING #-} > instance Show [Char] where ? This variant may also be more convenient in cases where you need to CPP-guard that pragma, as it's on a separate line. From johan.tibell at gmail.com Tue Jul 29 10:02:19 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 29 Jul 2014 12:02:19 +0200 Subject: Overlapping and incoherent instances In-Reply-To: <87lhrcbijz.fsf@gnu.org> References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <53D76989.2070808@nh2.me> <87lhrcbijz.fsf@gnu.org> Message-ID: On Tue, Jul 29, 2014 at 11:50 AM, Herbert Valerio Riedel wrote: > On 2014-07-29 at 11:29:45 +0200, Niklas Hamb?chen wrote: >>> instance {-# OVERLAPPABLE #-} Show a => Show [a] where ? >> >> Is the syntax somewhat flexible in where the pragma can be placed? >> For example, some might prefer >> >> {-# OVERLAPPING #-} >> instance Show [Char] where ? > > This variant may also be more convenient in cases where you need to > CPP-guard that pragma, as it's on a separate line. Agreed, and if we remove the old pragma (even with a deprecation cycle) you'll see quite a few of those as many library authors try to have their libraries compile with the last 3 major GHC versions. P.S. For e.g. INLINABLE we require that you mention the function name next to the pragma (which means that you can e.g. put the pragma after the declaration). What's the rationale to not require {-# OVERLAPPING Show [Char] #-} here? Perhaps it's too annoying to have to repeat the types? From daniel.trstenjak at gmail.com Tue Jul 29 10:37:14 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Tue, 29 Jul 2014 12:37:14 +0200 Subject: Overlapping and incoherent instances In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <53D76989.2070808@nh2.me> <87lhrcbijz.fsf@gnu.org> Message-ID: <20140729103714.GA15071@machine> On Tue, Jul 29, 2014 at 12:02:19PM +0200, Johan Tibell wrote: > What's the rationale to not require > > {-# OVERLAPPING Show [Char] #-} > > here? Perhaps it's too annoying to have to repeat the types? This one might be written at the top of the file, so it would be easier to overlook it, than having it directly at the instance declaration, which seems to be one of the major points for OVERLAPPING and OVERLAPPABLE. Greetings, Daniel From johan.tibell at gmail.com Tue Jul 29 10:48:08 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 29 Jul 2014 12:48:08 +0200 Subject: Overlapping and incoherent instances In-Reply-To: <20140729103714.GA15071@machine> References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <53D76989.2070808@nh2.me> <87lhrcbijz.fsf@gnu.org> <20140729103714.GA15071@machine> Message-ID: On Tue, Jul 29, 2014 at 12:37 PM, Daniel Trstenjak wrote: > > On Tue, Jul 29, 2014 at 12:02:19PM +0200, Johan Tibell wrote: >> What's the rationale to not require >> >> {-# OVERLAPPING Show [Char] #-} >> >> here? Perhaps it's too annoying to have to repeat the types? > > This one might be written at the top of the file, so it would be easier > to overlook it, than having it directly at the instance declaration, > which seems to be one of the major points for OVERLAPPING and OVERLAPPABLE. The same could be said for e.g. INLINE. The extra flexibility is nice to have (e.g. because you can opt to put the pragma after the declaration, to de-emphasize it.) From gtener at gmail.com Tue Jul 29 10:59:20 2014 From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=) Date: Tue, 29 Jul 2014 12:59:20 +0200 Subject: Overlapping and incoherent instances In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <53D76989.2070808@nh2.me> <87lhrcbijz.fsf@gnu.org> <20140729103714.GA15071@machine> Message-ID: I think it may also lead to cleaner code. I would rather write a single section like this: #if NEW_GHC {-# bunch of OVERLAPPABLE declarations #-} #endif at the start of the file rather than have to insert a lot of CPP-guarded pragmas later. But it may be seen as an editor/IDE issue and bikeshedding on the whole. -- Krzysztof On Tue, Jul 29, 2014 at 12:48 PM, Johan Tibell wrote: > On Tue, Jul 29, 2014 at 12:37 PM, Daniel Trstenjak > wrote: > > > > On Tue, Jul 29, 2014 at 12:02:19PM +0200, Johan Tibell wrote: > >> What's the rationale to not require > >> > >> {-# OVERLAPPING Show [Char] #-} > >> > >> here? Perhaps it's too annoying to have to repeat the types? > > > > This one might be written at the top of the file, so it would be easier > > to overlook it, than having it directly at the instance declaration, > > which seems to be one of the major points for OVERLAPPING and > OVERLAPPABLE. > > The same could be said for e.g. INLINE. The extra flexibility is nice > to have (e.g. because you can opt to put the pragma after the > declaration, to de-emphasize it.) > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Jul 29 11:02:35 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 29 Jul 2014 11:02:35 +0000 Subject: Overlapping and incoherent instances In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <53D76989.2070808@nh2.me> <87lhrcbijz.fsf@gnu.org> Message-ID: <618BE556AADD624C9C918AA5D5911BEF2207B596@DB3PRD3001MB020.064d.mgd.msft.net> The current implementation requires the pragma exactly where showed it. I'm not keen on allowing it to be separated. I suppose with some more parser jiggery pokery it could be allowed immediately before (or, better, after). But cpp would let you say instance #if blah {-# OVERLAPPABLE #-} #endif Show a => Show [a] where ... Simon | -----Original Message----- | From: Johan Tibell [mailto:johan.tibell at gmail.com] | Sent: 29 July 2014 11:02 | To: Herbert Valerio Riedel | Cc: Niklas Hamb?chen; Haskell Libraries (libraries at haskell.org); GHC | users; Simon Peyton Jones; ghc-devs | Subject: Re: Overlapping and incoherent instances | | On Tue, Jul 29, 2014 at 11:50 AM, Herbert Valerio Riedel | wrote: | > On 2014-07-29 at 11:29:45 +0200, Niklas Hamb?chen wrote: | >>> instance {-# OVERLAPPABLE #-} Show a => Show [a] where ? | >> | >> Is the syntax somewhat flexible in where the pragma can be placed? | >> For example, some might prefer | >> | >> {-# OVERLAPPING #-} | >> instance Show [Char] where ? | > | > This variant may also be more convenient in cases where you need to | > CPP-guard that pragma, as it's on a separate line. | | Agreed, and if we remove the old pragma (even with a deprecation | cycle) you'll see quite a few of those as many library authors try to | have their libraries compile with the last 3 major GHC versions. | | P.S. For e.g. INLINABLE we require that you mention the function name | next to the pragma (which means that you can e.g. put the pragma after | the declaration). What's the rationale to not require | | {-# OVERLAPPING Show [Char] #-} | | here? Perhaps it's too annoying to have to repeat the types? From eir at cis.upenn.edu Tue Jul 29 12:13:22 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 29 Jul 2014 08:13:22 -0400 Subject: Overlapping and incoherent instances In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF2207B596@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <53D76989.2070808@nh2.me> <87lhrcbijz.fsf@gnu.org> <618BE556AADD624C9C918AA5D5911BEF2207B596@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I think one nice thing about this proposal is that it doesn't seem (to me) to require CPP around the pragma: unrecognized pragmas are warned about but are otherwise harmless. Are folks very keen to have *warning-free* compilation on several GHC versions? Personally, I would aim for warning-free compilation on a most recent version, and otherwise successful compilation on older versions. The only place CPP would be needed is around the LANGUAGE pragma, in order to avoid the deprecation warning in 7.10. One other issue this brings up: how does this all interact with -XSafe? Right now, Safety can be inferred by looking at the set of LANGUAGE pragmas and the import list. (Right?) With the change as implemented, Safe inference would require looking at all instance declarations. Is this OK? Richard On Jul 29, 2014, at 7:02 AM, Simon Peyton Jones wrote: > The current implementation requires the pragma exactly where showed it. > > I'm not keen on allowing it to be separated. > > I suppose with some more parser jiggery pokery it could be allowed immediately before (or, better, after). > > But cpp would let you say > > instance > #if blah > {-# OVERLAPPABLE #-} > #endif > Show a => Show [a] where ... > > Simon > > | -----Original Message----- > | From: Johan Tibell [mailto:johan.tibell at gmail.com] > | Sent: 29 July 2014 11:02 > | To: Herbert Valerio Riedel > | Cc: Niklas Hamb?chen; Haskell Libraries (libraries at haskell.org); GHC > | users; Simon Peyton Jones; ghc-devs > | Subject: Re: Overlapping and incoherent instances > | > | On Tue, Jul 29, 2014 at 11:50 AM, Herbert Valerio Riedel > | wrote: > | > On 2014-07-29 at 11:29:45 +0200, Niklas Hamb?chen wrote: > | >>> instance {-# OVERLAPPABLE #-} Show a => Show [a] where ? > | >> > | >> Is the syntax somewhat flexible in where the pragma can be placed? > | >> For example, some might prefer > | >> > | >> {-# OVERLAPPING #-} > | >> instance Show [Char] where ? > | > > | > This variant may also be more convenient in cases where you need to > | > CPP-guard that pragma, as it's on a separate line. > | > | Agreed, and if we remove the old pragma (even with a deprecation > | cycle) you'll see quite a few of those as many library authors try to > | have their libraries compile with the last 3 major GHC versions. > | > | P.S. For e.g. INLINABLE we require that you mention the function name > | next to the pragma (which means that you can e.g. put the pragma after > | the declaration). What's the rationale to not require > | > | {-# OVERLAPPING Show [Char] #-} > | > | here? Perhaps it's too annoying to have to repeat the types? > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From allbery.b at gmail.com Tue Jul 29 13:40:08 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 29 Jul 2014 09:40:08 -0400 Subject: Overlapping and incoherent instances In-Reply-To: <53D79483.3000302@ifi.lmu.de> References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <53D76989.2070808@nh2.me> <53D79483.3000302@ifi.lmu.de> Message-ID: On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel wrote: > +1. I like Niklas' syntax better. Also OVERLAPPABLE is a horrible word, > OVERLAPPING sound less formidable (even though it might be slightly less > accurrate). We already get "overlap ok" in instance-related type errors, so OVERLAP_OK wouldn't be particularly alien even if it doesn't quite fit in with existing pragmas. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtener at gmail.com Tue Jul 29 15:56:02 2014 From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=) Date: Tue, 29 Jul 2014 17:56:02 +0200 Subject: Overlapping and incoherent instances In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <53D76989.2070808@nh2.me> <53D79483.3000302@ifi.lmu.de> Message-ID: How about CAN_OVERLAP? -- Krzysztof 29-07-2014 15:40, "Brandon Allbery" napisa?(a): > On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel > wrote: > >> +1. I like Niklas' syntax better. Also OVERLAPPABLE is a horrible word, >> OVERLAPPING sound less formidable (even though it might be slightly less >> accurrate). > > > We already get "overlap ok" in instance-related type errors, so OVERLAP_OK > wouldn't be particularly alien even if it doesn't quite fit in with > existing pragmas. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Jul 29 16:29:45 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 29 Jul 2014 16:29:45 +0000 Subject: Overlapping and incoherent instances In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <53D76989.2070808@nh2.me> <53D79483.3000302@ifi.lmu.de> Message-ID: <618BE556AADD624C9C918AA5D5911BEF2207FD01@DB3PRD3001MB020.064d.mgd.msft.net> CAN_OVERLAP and CAN_BE_OVERLAPPED? (instead of OVERLAPPING and OVERLAPPABLE) Or CAN-OVERLAP, CAN-BE-OVERLAPPED That?s ok with me if that?s what you all want! Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Krzysztof Skrzetnicki Sent: 29 July 2014 16:56 To: Brandon Allbery Cc: Simon Peyton Jones; Andreas Abel; GHC users; Haskell Libraries (libraries at haskell.org); ghc-devs Subject: Re: Overlapping and incoherent instances How about CAN_OVERLAP? -- Krzysztof 29-07-2014 15:40, "Brandon Allbery" > napisa?(a): On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel > wrote: +1. I like Niklas' syntax better. Also OVERLAPPABLE is a horrible word, OVERLAPPING sound less formidable (even though it might be slightly less accurrate). We already get "overlap ok" in instance-related type errors, so OVERLAP_OK wouldn't be particularly alien even if it doesn't quite fit in with existing pragmas. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net _______________________________________________ Libraries mailing list Libraries at haskell.org http://www.haskell.org/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Jul 29 16:37:13 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 29 Jul 2014 16:37:13 +0000 Subject: Overlapping and incoherent instances In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <53D76989.2070808@nh2.me> <87lhrcbijz.fsf@gnu.org> <618BE556AADD624C9C918AA5D5911BEF2207B596@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF2207FD98@DB3PRD3001MB020.064d.mgd.msft.net> | One other issue this brings up: how does this all interact with -XSafe? | Right now, Safety can be inferred by looking at the set of LANGUAGE | pragmas and the import list. (Right?) With the change as implemented, | Safe inference would require looking at all instance declarations. Is | this OK? I'm honestly not sure, but I do know that, in the implementation, each instance declaration keeps track of (a) whether it is OVERLAPPABLE/OVERLAPPING/INCOHERENT, and (b) the setting of -XSafe in the module where the instance declaration is given. This doesn't change. So I can't answer your question directly, but I think that the behaviour is unchanged from that at present. Simon | | Richard | | On Jul 29, 2014, at 7:02 AM, Simon Peyton Jones | wrote: | | > The current implementation requires the pragma exactly where showed | it. | > | > I'm not keen on allowing it to be separated. | > | > I suppose with some more parser jiggery pokery it could be allowed | immediately before (or, better, after). | > | > But cpp would let you say | > | > instance | > #if blah | > {-# OVERLAPPABLE #-} | > #endif | > Show a => Show [a] where ... | > | > Simon | > | > | -----Original Message----- | > | From: Johan Tibell [mailto:johan.tibell at gmail.com] | > | Sent: 29 July 2014 11:02 | > | To: Herbert Valerio Riedel | > | Cc: Niklas Hamb?chen; Haskell Libraries (libraries at haskell.org); | GHC | > | users; Simon Peyton Jones; ghc-devs | > | Subject: Re: Overlapping and incoherent instances | > | | > | On Tue, Jul 29, 2014 at 11:50 AM, Herbert Valerio Riedel | > | | > | wrote: | > | > On 2014-07-29 at 11:29:45 +0200, Niklas Hamb?chen wrote: | > | >>> instance {-# OVERLAPPABLE #-} Show a => Show [a] where . | > | >> | > | >> Is the syntax somewhat flexible in where the pragma can be | placed? | > | >> For example, some might prefer | > | >> | > | >> {-# OVERLAPPING #-} | > | >> instance Show [Char] where . | > | > | > | > This variant may also be more convenient in cases where you need | > | > to CPP-guard that pragma, as it's on a separate line. | > | | > | Agreed, and if we remove the old pragma (even with a deprecation | > | cycle) you'll see quite a few of those as many library authors try | > | to have their libraries compile with the last 3 major GHC versions. | > | | > | P.S. For e.g. INLINABLE we require that you mention the function | > | name next to the pragma (which means that you can e.g. put the | > | pragma after the declaration). What's the rationale to not require | > | | > | {-# OVERLAPPING Show [Char] #-} | > | | > | here? Perhaps it's too annoying to have to repeat the types? | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users at haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > From iavor.diatchki at gmail.com Tue Jul 29 17:28:56 2014 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 29 Jul 2014 10:28:56 -0700 Subject: Overlapping and incoherent instances In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <53D76989.2070808@nh2.me> <53D79483.3000302@ifi.lmu.de> <618BE556AADD624C9C918AA5D5911BEF2207FD01@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Hello, I have no strong feelings about what words we use, but I wanted to point out that while we are thinking of names, we may want to consider 3 (and not just 2). Currently we have: * OVERLAPPING: This instances may overlap existing instances * OVERLAPPABLE: This instance may be overlapped by existing instances * OVERLAPS: This instance is both OVERLAPPING and OVERLAPPABLE Of course, the 3rd one (OVERLAPS) could be replaced by a comma separated list of the first two, but I could not see how to make this work easily with GHC's pragmas. It would not be hard to simply allow 2 pragmas after the `instance` keyword, but both of those seem rather long. Either way, I'll keep an eye on the discussion, and would be happy to change the names if a consesus is reached. -Iavor On Tue, Jul 29, 2014 at 9:57 AM, David Thomas wrote: > Honestly, I think "OVERLAPS" and "OVERLAPPED" are perfectly clear. > > On Tue, Jul 29, 2014 at 9:52 AM, David Feuer > wrote: > > CAN-OVERLAP and CAN-BE-OVERLAPPED are nice and clear. A little long, > perhaps. > > > > On Tue, Jul 29, 2014 at 12:29 PM, Simon Peyton Jones > > wrote: > >> CAN_OVERLAP and CAN_BE_OVERLAPPED? > >> > >> > >> > >> (instead of OVERLAPPING and OVERLAPPABLE) > >> > >> > >> > >> Or CAN-OVERLAP, CAN-BE-OVERLAPPED > >> > >> > >> > >> That?s ok with me if that?s what you all want! > >> > >> > >> > >> Simon > >> > >> > >> > >> From: Glasgow-haskell-users > >> [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of > Krzysztof > >> Skrzetnicki > >> Sent: 29 July 2014 16:56 > >> To: Brandon Allbery > >> Cc: Simon Peyton Jones; Andreas Abel; GHC users; Haskell Libraries > >> (libraries at haskell.org); ghc-devs > >> > >> > >> Subject: Re: Overlapping and incoherent instances > >> > >> > >> > >> How about CAN_OVERLAP? > >> > >> -- > >> Krzysztof > >> > >> 29-07-2014 15:40, "Brandon Allbery" napisa?(a): > >> > >> On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel > >> wrote: > >> > >> +1. I like Niklas' syntax better. Also OVERLAPPABLE is a horrible word, > >> OVERLAPPING sound less formidable (even though it might be slightly less > >> accurrate). > >> > >> > >> > >> We already get "overlap ok" in instance-related type errors, so > OVERLAP_OK > >> wouldn't be particularly alien even if it doesn't quite fit in with > existing > >> pragmas. > >> > >> > >> > >> -- > >> > >> brandon s allbery kf8nh sine nomine > associates > >> > >> allbery.b at gmail.com > ballbery at sinenomine.net > >> > >> unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > >> > >> > >> _______________________________________________ > >> Libraries mailing list > >> Libraries at haskell.org > >> http://www.haskell.org/mailman/listinfo/libraries > >> > >> > >> _______________________________________________ > >> Libraries mailing list > >> Libraries at haskell.org > >> http://www.haskell.org/mailman/listinfo/libraries > >> > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From singpolyma at singpolyma.net Tue Jul 29 23:41:53 2014 From: singpolyma at singpolyma.net (Stephen Paul Weber) Date: Tue, 29 Jul 2014 18:41:53 -0500 Subject: Overlapping and incoherent instances In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <20140729234153.GE31802@singpolyma-liberty> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... > >instance {-# OVERLAPPING #-} Show [Char] where ... This, to me, is an admission that developers are not going to want to turn overlapping on globally in general, and so the current language extensions would not make sense to get adopted into the core language at any point. I agree with this idea, and so would second the proposal mentioned at that a language extension that adds actual keywords to tag instances that should be allowed to overlap be added, instead of resorting to pragmas. This seems like an approach that could be useful in general and one could imagine moving "past" an extension to the core language at some point, potentially. - -- Stephen Paul Weber, @singpolyma See for how I prefer to be contacted edition right joseph -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJT2DFBAAoJENEcKRHOUZzemmIQAJEbSjPyx745UI6mkuhBVhKl LQWJlpu0/kzBHaFJl/mWcghKxoBFWwU+pCTh/Pr2oj0rp/KGskBLlplIqB4btZTA ov2MpPrsHm1M37MuGyMtiBhs57UJE+saKKuvcH3qzLZyBCHorE3lFcKAFbNupBrL e/vgNblQ70KGmDRAKqbAQHm9anoGeZUJPgQ9ylVEH4nBYLDo0YSNo/zTeB7fK2yv xBE+Ul3YGfhzf82cLJhYNQOpi5wJ3JEDBevKXcGRzr4Mhzn2Lke+26tu0tx6sOSN snPX2REoeQD1AfXvuNKSxV7BL+CQeyAOOmm2Isj3vW/oO3gkqpfRjCFc+ZSPEjlG XQ3S7L7cgNB34rd6sOFzTv83PXvsH0a0d5RqKUM2kN/qGEjSbAQ1FVyJEUcaEmzr jBnVnWq+abCOSOBg4joGfTxjq0zufdjxkzScEJVDVZ4pIXoxej7HJBi8UfIvo3Jo EDMGGsLSedt4tR2LzYf/5up7GPfuBsFQQzuIcdgMG8/zYca7zWPJgyunlXAPcbzr RvM/gf63SCBuVaQjrtv2Zhzp3PucWOL94NEmLYONU3uuEmo6bq1VO42fOUcl7X/1 UyhFbtoV7s/7PVClxdD4Ag9PumtSfl/CSvN0BA8AzDwTuHWNOPdThAHFqfAtRsD0 GyNzVRNOGuze9SqkLc4T =YeKu -----END PGP SIGNATURE----- From felipe.lessa at gmail.com Wed Jul 30 01:47:16 2014 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Tue, 29 Jul 2014 22:47:16 -0300 Subject: Overlapping and incoherent instances In-Reply-To: <20140729234153.GE31802@singpolyma-liberty> References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <20140729234153.GE31802@singpolyma-liberty> Message-ID: <53D84EA4.1040807@gmail.com> On 29-07-2014 20:41, Stephen Paul Weber wrote: >> instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... > >> instance {-# OVERLAPPING #-} Show [Char] where ... > > This, to me, is an admission that developers are not going to want to turn > overlapping on globally in general, and so the current language extensions > would not make sense to get adopted into the core language at any point. > I agree with this idea, and so would second the proposal mentioned at > > that a language extension that adds actual keywords to tag instances that > should be allowed to overlap be added, instead of resorting to pragmas. > This seems like an approach that could be useful in general and one could > imagine moving "past" an extension to the core language at some point, > potentially. OTOH, the pragma is mostly harmless for older GHC versions, while the keyword approach needs a preprocessor. -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From singpolyma at singpolyma.net Wed Jul 30 01:56:08 2014 From: singpolyma at singpolyma.net (Stephen Paul Weber) Date: Wed, 30 Jul 2014 01:56:08 +0000 Subject: Overlapping and incoherent instances In-Reply-To: <53D84EA4.1040807@gmail.com> References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <20140729234153.GE31802@singpolyma-liberty> <53D84EA4.1040807@gmail.com> Message-ID: <20140730015608.GA17277@singpolyma.net> Somebody signing messages as Felipe Lessa wrote: >OTOH, the pragma is mostly harmless for older GHC versions, while the >keyword approach needs a preprocessor. Only if *both* the old LANGUAGE pragma and the new pragma were employed, which will generate a deprecation warning for awhile and then eventually (likely) be rejected by newer GHCs, thus requiring a prepropcessor in either case. -- Stephen Paul Weber, @singpolyma See for how I prefer to be contacted edition right joseph From johan.tibell at gmail.com Wed Jul 30 12:55:47 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 30 Jul 2014 14:55:47 +0200 Subject: Overlapping and incoherent instances In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <53D76989.2070808@nh2.me> <53D79483.3000302@ifi.lmu.de> <618BE556AADD624C9C918AA5D5911BEF2207FD01@DB3PRD3001MB020.064d.mgd.msft.net> <53D8DFE5.1010609@ifi.lmu.de> Message-ID: On Wed, Jul 30, 2014 at 2:50 PM, Ivan Lazar Miljenovic wrote: > On 30 July 2014 22:07, Andreas Abel wrote: >> I am a bit surprised by the distinction you outline below. This is maybe >> because I am native German, not English. The German equivalent of >> "overlap", "?berschneiden/?berlappen", is used exclusively in a symmetrical >> fashion. It's like in English, if I say "our interests overlap", then it is >> pointless to ask whether my interest are overlapping yours or are overlapped >> by yours. I want to alert you to the fact that non-native English speaker >> might have little understanding for a distinction between "OVERLAPPING" and >> "OVERLAPPABLE". >> >> Let's try to guess what it meant: Given >> >> A) instance Bla Char >> B) instance Bla a => Bla [a] >> C) instance Bla String >> >> you will in context A,B write C as OVERLAPPING, >> and in context A,C write B as OVERLAPPABLE? > > IIUC, B will be OVERLAPPABLE ("you can overlap this") and C will be > OVERLAPPING ("I'm overlapping an existing one") whereas C will be > plain. Apologies if this question doesn't make sense. Can we really talk about overlapping, given that instances can be written in different modules, moved between modules, or removed? From anthony_clayden at clear.net.nz Thu Jul 31 01:20:21 2014 From: anthony_clayden at clear.net.nz (AntC) Date: Thu, 31 Jul 2014 01:20:21 +0000 (UTC) Subject: Overlapping and incoherent instances References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: > Simon Peyton Jones microsoft.com> writes: > Tue Jul 29 09:11:05 UTC 2014 > ... > This is a Big Hammer. I agree with Simon's motivation that the whole-module overlap pragma is often too brutal. But I think that what Iavor has developed is still too brutal. (Sorry, and I hadn't known about these instance-level pragmas before now.) For my 2d, I think Andreas made an important distinction: > Andreas Abel andreas.abel at ifi.lmu.de > Wed Jul 30 12:07:01 UTC 2014 > The German equivalent of "overlap", ..., is used exclusively in a > symmetrical fashion. It's like in English, if I say "our interests > overlap", then it is pointless to ask whether my interest are > overlapping yours or are overlapped by yours. I'd say that the English "overlap" is also used in a symmetrical fashion (outside of specialist Haskell instances usage). There's a difference between: - this instance is nec. narrower than some other instance (IOW anything that's a substitution for this instance, is ipso facto a substitution for some wider) - vs. a partial overlap (some substitutions will fit this instance only, some will fit another instance, not this one, some will fit both) In my experience, unintended partial overlaps are the nastiest to diagnose. And partial overlaps are very seldom needed in practice. They're often a symptom that two separately-developed libraries are clashing. (For example the HList libraries -- as originally released -- used overlap extensively, but no partial overlaps.) So I would like the pragmas to be able to say: OK for this instance to subsumes or be subsumed by some other instance but it must not partially overlap any instance. (I guess this is beyond the question Simon's OP asked.) AntC From simonpj at microsoft.com Thu Jul 31 07:20:31 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 31 Jul 2014 07:20:31 +0000 Subject: Overlapping and incoherent instances In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF2208260F@DB3PRD3001MB020.064d.mgd.msft.net> 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 messages. My apologies for that. Some key points: * There is a useful distinction between overlapping and overlappable, but if you don't want to be bothered with it you can just say OVERLAPS (which means both). * Overlap between two candidate instances is allowed if either has the relevant property. This is a bit sloppy, but reduces the annotation burden. Actually, with this per-instance stuff I think it'd be perfectly defensible to require both to be annotated, but that's a different discussion. I hope that helps clarify. I'm really pretty certain that the basic proposal here is good: it implements the current semantics in a more fine-grained manner. My main motivation was to signal the proposed deprecation of the global per-module flag -XoverlappingInstances. Happily people generally seem fine with this. It is, after all, precisely what deprecations are for ("the old thing still works for now, but it won't do so for ever, and you should change as soon as is convenient"). Thanks Simon From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Simon Peyton Jones Sent: 29 July 2014 10:11 To: ghc-devs; GHC users; Haskell Libraries (libraries at haskell.org) Subject: Overlapping and incoherent instances Friends One of GHC's more widely-used features is overlapping (and sometimes incoherent) instances. The user-manual documentation is here. The use of overlapping/incoherent instances is controlled by LANGUAGE pragmas: OverlappingInstances and IncoherentInstances respectively. However the overlap/incoherent-ness is a property of the *instance declaration* itself, and has been for a long time. Using LANGUAGE OverlappingInstances simply sets the "I am an overlapping instance" flag for every instance declaration in that module. This is a Big Hammer. It give no clue about *which* particular instances the programmer is expecting to be overlapped, nor which are doing the overlapping. It brutally applies to every instance in the module. Moreover, when looking at an instance declaration, there is no nearby clue that it might be overlapped. The clue might be in the command line that compiles that module! Iavor has recently implemented per-instance-declaration pragmas, so you can say instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... instance {-# OVERLAPPING #-} Show [Char] where ... This is much more precise (it affects only those specific instances) and it is much clearer (you see it when you see the instance declaration). This new feature will be in GHC 7.10 and I'm sure you will be happy about that. But I propose also to deprecate the LANGUAGE pragmas OverlappingInstances and IncoherentInstances, as way to encourage everyone to use the new feature instead of the old big hammer. The old LANGUAGE pragmas will continue to work, of course, for at least another complete release cycle. We could make that two cycles if it was helpful. However, if you want deprecation-free libraries, it will entail a wave of library updates. This email is just to warn you, and to let you yell if you think this is a bad idea. It would actually not be difficult to retain the old LANGUAGE pragmas indefinitely - it just seems wrong not to actively push authors in the right direction. These deprecations of course popped up in the test suite, so I've been replacing them with per-instance pragmas there too. Interestingly in some cases, when looking for which instances needed the pragmas, I found...none. So OverlappingInstances was entirely unnecessary. Maybe library authors will find that too! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Jul 31 08:13:43 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 31 Jul 2014 08:13:43 +0000 Subject: Overlapping and incoherent instances In-Reply-To: <53D9F758.4080606@chalmers.se> References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF2208260F@DB3PRD3001MB020.064d.mgd.msft.net> <53D9F758.4080606@chalmers.se> Message-ID: <618BE556AADD624C9C918AA5D5911BEF2208409B@DB3PRD3001MB020.064d.mgd.msft.net> 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 #-} Bla a => Bla [a] you are, with GHC 7.8, making precisely the same decision when you decide whether or not to add {-# LANGUAGE OverlappingInstances #-} to that module. Perhaps that wasn't clear in what I wrote; apologies. So your proposal seems to be this don't remove -XOverlappingInstances, because that will prevent programmers from "flipping on/off pragmas until their program goes through". It's hard to argue AGAINST providing the opportunity for more careful programmers to express their intentions more precisely, which is what the OVERLAP/OVERLAPPABLE pragmas do. Concerning deprecating OverlappingInstances, my gut feel is that it is positively a good thing to guide programmers towards a more robust programming style. But my reason for starting this thread was to see whether or not others' gut feel is similar. Simon | -----Original Message----- | From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of | Andreas Abel | Sent: 31 July 2014 08:59 | To: Simon Peyton Jones; ghc-devs; GHC users; Haskell Libraries | (libraries at haskell.org) | Subject: Re: Overlapping and incoherent instances | | On 31.07.2014 09:20, Simon Peyton Jones wrote: | > Friends, in sending my message below, I should also have sent a link | > to | > | > https://ghc.haskell.org/trac/ghc/ticket/9242#comment:25 | | Indeed. | | Quoting from the spec: | | * Eliminate any candidate IX for which both of the following hold: | * There is another candidate IY that is strictly more specific; | that is, IY is a substitution instance of IX but not vice versa. | | * Either IX is overlappable or IY is overlapping. | | Mathematically, this makes a lot of sense. But put on the hat of | library writers, and users, and users that don't rtfm. Looking out | from under this hat, the one may always wonder whether one should make | one's generic instances OVERLAPPABLE or not. | | If I create a library with type class Bla and | | instance Bla a => Bla [a] | | I could be a nice library writer and spare my users from declaring | their Bla String instances as OVERLAPPING, so I'd write | | instance {-# OVERLAPPABLE #-} Bla a => Bla [a] | | Or maybe that would be malicious? | | I think the current proposal is too sophisticated. There are no | convincing examples given in the discussion so far that demonstrate | where this sophistication pays off in practice. | | Keep in mind that 99% of the Haskell users will never study the | instance resolution algorithm or its specification, but just flip | on/off pragmas until their code goes through. [At least that was my | approach: whenever GHC asks for one more LANGUAGE pragma, just throw it | in.] | | Cheers, | Andreas | | | > 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 messages. My apologies for that. | > | > Some key points: | > | > *There is a useful distinction between /overlapping/ and | > /overlappable/, but if you don't want to be bothered with it you can | > just say OVERLAPS (which means both). | > | > *Overlap between two candidate instances is allowed if /either/ has | > the relevant property. This is a bit sloppy, but reduces the | > annotation burden. Actually, with this per-instance stuff I think | > it'd be perfectly defensible to require both to be annotated, but | > that's a different discussion. | > | > I hope that helps clarify. | > | > I'm really pretty certain that the basic proposal here is good: it | > implements the current semantics in a more fine-grained manner. My | > main motivation was to signal the proposed deprecation of the global | > per-module flag -XoverlappingInstances. Happily people generally | seem | > fine with this. It is, after all, precisely what deprecations are | for | > ("the old thing still works for now, but it won't do so for ever, and | > you should change as soon as is convenient"). | > | > Thanks | > | > Simon | > | > *From:*Libraries [mailto:libraries-bounces at haskell.org] *On Behalf Of | > *Simon Peyton Jones | > *Sent:* 29 July 2014 10:11 | > *To:* ghc-devs; GHC users; Haskell Libraries (libraries at haskell.org) | > *Subject:* Overlapping and incoherent instances | > | > Friends | > | > One of GHC's more widely-used features is overlapping (and sometimes | > incoherent) instances. The user-manual documentation is here | > . | > | > The use of overlapping/incoherent instances is controlled by LANGUAGE | > pragmas: OverlappingInstances and IncoherentInstances respectively. | > | > However the overlap/incoherent-ness is a property of the **instance | > declaration** itself, and has been for a long time. Using LANGUAGE | > OverlappingInstances simply sets the "I am an overlapping instance" | > flag for every instance declaration in that module. | > | > This is a Big Hammer. It give no clue about **which** particular | > instances the programmer is expecting to be overlapped, nor which are | > doing the overlapping. It brutally applies to every instance in | the | > module. Moreover, when looking at an instance declaration, there is | > no nearby clue that it might be overlapped. The clue might be in the | > command line that compiles that module! | > | > Iavor has recently implemented per-instance-declaration pragmas, so | > you can say | > | > instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... | > | > instance {-# OVERLAPPING #-} Show [Char] where ... | > | > This is much more precise (it affects only those specific instances) | > and it is much clearer (you see it when you see the instance | declaration). | > | > This new feature will be in GHC 7.10 and I'm sure you will be happy | > about that. *But I propose also to deprecate the LANGUAGE pragmas | > OverlappingInstances and IncoherentInstances*, as way to encourage | > everyone to use the new feature instead of the old big hammer. The | > old LANGUAGE pragmas will continue to work, of course, for at least | > another complete release cycle. We could make that two cycles if it | was helpful. | > | > However, if you want deprecation-free libraries, it will entail a | wave | > of library updates. | > | > This email is just to warn you, and to let you yell if you think this | is | > a bad idea. It would actually not be difficult to retain the old | > LANGUAGE pragmas indefinitely - it just seems wrong not to actively | > push authors in the right direction. | > | > These deprecations of course popped up in the test suite, so I've | been | > replacing them with per-instance pragmas there too. Interestingly in | > some cases, when looking for which instances needed the pragmas, I | > found...none. So OverlappingInstances was entirely unnecessary. Maybe | > library authors will find that too! | > | > Simon | > | > | > | > _______________________________________________ | > Libraries mailing list | > Libraries at haskell.org | > http://www.haskell.org/mailman/listinfo/libraries | > | | | -- | Andreas Abel <>< Du bist der geliebte Mensch. | | Department of Computer Science and Engineering Chalmers and Gothenburg | University, Sweden | | andreas.abel at gu.se | http://www2.tcs.ifi.lmu.de/~abel/ | _______________________________________________ | Libraries mailing list | Libraries at haskell.org | http://www.haskell.org/mailman/listinfo/libraries From ekmett at gmail.com Thu Jul 31 08:18:55 2014 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 31 Jul 2014 04:18:55 -0400 Subject: Overlapping and incoherent instances In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF2208409B@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF2208260F@DB3PRD3001MB020.064d.mgd.msft.net> <53D9F758.4080606@chalmers.se> <618BE556AADD624C9C918AA5D5911BEF2208409B@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: 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 can't break up the file without inducing orphans) This is just a passing comment, while I'm thinking about it, not a serious attempt to derail the topic! -Edward On Thu, Jul 31, 2014 at 4:13 AM, Simon Peyton Jones wrote: > 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 #-} Bla a => Bla [a] > you are, with GHC 7.8, making precisely the same decision when you decide > whether or not to add {-# LANGUAGE OverlappingInstances #-} to that module. > Perhaps that wasn't clear in what I wrote; apologies. > > So your proposal seems to be this > > don't remove -XOverlappingInstances, because that will prevent > programmers from "flipping on/off pragmas until their program > goes through". > > It's hard to argue AGAINST providing the opportunity for more careful > programmers to express their intentions more precisely, which is what the > OVERLAP/OVERLAPPABLE pragmas do. > > Concerning deprecating OverlappingInstances, my gut feel is that it is > positively a good thing to guide programmers towards a more robust > programming style. But my reason for starting this thread was to see > whether or not others' gut feel is similar. > > Simon > > | -----Original Message----- > | From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of > | Andreas Abel > | Sent: 31 July 2014 08:59 > | To: Simon Peyton Jones; ghc-devs; GHC users; Haskell Libraries > | (libraries at haskell.org) > | Subject: Re: Overlapping and incoherent instances > | > | On 31.07.2014 09:20, Simon Peyton Jones wrote: > | > Friends, in sending my message below, I should also have sent a link > | > to > | > > | > https://ghc.haskell.org/trac/ghc/ticket/9242#comment:25 > | > | Indeed. > | > | Quoting from the spec: > | > | * Eliminate any candidate IX for which both of the following hold: > | * There is another candidate IY that is strictly more specific; > | that is, IY is a substitution instance of IX but not vice versa. > | > | * Either IX is overlappable or IY is overlapping. > | > | Mathematically, this makes a lot of sense. But put on the hat of > | library writers, and users, and users that don't rtfm. Looking out > | from under this hat, the one may always wonder whether one should make > | one's generic instances OVERLAPPABLE or not. > | > | If I create a library with type class Bla and > | > | instance Bla a => Bla [a] > | > | I could be a nice library writer and spare my users from declaring > | their Bla String instances as OVERLAPPING, so I'd write > | > | instance {-# OVERLAPPABLE #-} Bla a => Bla [a] > | > | Or maybe that would be malicious? > | > | I think the current proposal is too sophisticated. There are no > | convincing examples given in the discussion so far that demonstrate > | where this sophistication pays off in practice. > | > | Keep in mind that 99% of the Haskell users will never study the > | instance resolution algorithm or its specification, but just flip > | on/off pragmas until their code goes through. [At least that was my > | approach: whenever GHC asks for one more LANGUAGE pragma, just throw it > | in.] > | > | Cheers, > | Andreas > | > | > | > 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 messages. My apologies for that. > | > > | > Some key points: > | > > | > *There is a useful distinction between /overlapping/ and > | > /overlappable/, but if you don't want to be bothered with it you can > | > just say OVERLAPS (which means both). > | > > | > *Overlap between two candidate instances is allowed if /either/ has > | > the relevant property. This is a bit sloppy, but reduces the > | > annotation burden. Actually, with this per-instance stuff I think > | > it'd be perfectly defensible to require both to be annotated, but > | > that's a different discussion. > | > > | > I hope that helps clarify. > | > > | > I'm really pretty certain that the basic proposal here is good: it > | > implements the current semantics in a more fine-grained manner. My > | > main motivation was to signal the proposed deprecation of the global > | > per-module flag -XoverlappingInstances. Happily people generally > | seem > | > fine with this. It is, after all, precisely what deprecations are > | for > | > ("the old thing still works for now, but it won't do so for ever, and > | > you should change as soon as is convenient"). > | > > | > Thanks > | > > | > Simon > | > > | > *From:*Libraries [mailto:libraries-bounces at haskell.org] *On Behalf Of > | > *Simon Peyton Jones > | > *Sent:* 29 July 2014 10:11 > | > *To:* ghc-devs; GHC users; Haskell Libraries (libraries at haskell.org) > | > *Subject:* Overlapping and incoherent instances > | > > | > Friends > | > > | > One of GHC's more widely-used features is overlapping (and sometimes > | > incoherent) instances. The user-manual documentation is here > | > | extensions.html#instance-overlap>. > | > > | > The use of overlapping/incoherent instances is controlled by LANGUAGE > | > pragmas: OverlappingInstances and IncoherentInstances respectively. > | > > | > However the overlap/incoherent-ness is a property of the **instance > | > declaration** itself, and has been for a long time. Using LANGUAGE > | > OverlappingInstances simply sets the "I am an overlapping instance" > | > flag for every instance declaration in that module. > | > > | > This is a Big Hammer. It give no clue about **which** particular > | > instances the programmer is expecting to be overlapped, nor which are > | > doing the overlapping. It brutally applies to every instance in > | the > | > module. Moreover, when looking at an instance declaration, there is > | > no nearby clue that it might be overlapped. The clue might be in the > | > command line that compiles that module! > | > > | > Iavor has recently implemented per-instance-declaration pragmas, so > | > you can say > | > > | > instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... > | > > | > instance {-# OVERLAPPING #-} Show [Char] where ... > | > > | > This is much more precise (it affects only those specific instances) > | > and it is much clearer (you see it when you see the instance > | declaration). > | > > | > This new feature will be in GHC 7.10 and I'm sure you will be happy > | > about that. *But I propose also to deprecate the LANGUAGE pragmas > | > OverlappingInstances and IncoherentInstances*, as way to encourage > | > everyone to use the new feature instead of the old big hammer. The > | > old LANGUAGE pragmas will continue to work, of course, for at least > | > another complete release cycle. We could make that two cycles if it > | was helpful. > | > > | > However, if you want deprecation-free libraries, it will entail a > | wave > | > of library updates. > | > > | > This email is just to warn you, and to let you yell if you think this > | is > | > a bad idea. It would actually not be difficult to retain the old > | > LANGUAGE pragmas indefinitely - it just seems wrong not to actively > | > push authors in the right direction. > | > > | > These deprecations of course popped up in the test suite, so I've > | been > | > replacing them with per-instance pragmas there too. Interestingly in > | > some cases, when looking for which instances needed the pragmas, I > | > found...none. So OverlappingInstances was entirely unnecessary. Maybe > | > library authors will find that too! > | > > | > Simon > | > > | > > | > > | > _______________________________________________ > | > Libraries mailing list > | > Libraries at haskell.org > | > http://www.haskell.org/mailman/listinfo/libraries > | > > | > | > | -- > | Andreas Abel <>< Du bist der geliebte Mensch. > | > | Department of Computer Science and Engineering Chalmers and Gothenburg > | University, Sweden > | > | andreas.abel at gu.se > | http://www2.tcs.ifi.lmu.de/~abel/ > | _______________________________________________ > | Libraries mailing list > | Libraries at haskell.org > | http://www.haskell.org/mailman/listinfo/libraries > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Jul 31 11:02:59 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 31 Jul 2014 11:02:59 +0000 Subject: Overlapping and incoherent instances In-Reply-To: <53DA060E.90206@chalmers.se> References: <618BE556AADD624C9C918AA5D5911BEF2207B3A1@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF2208260F@DB3PRD3001MB020.064d.mgd.msft.net> <53D9F758.4080606@chalmers.se> <618BE556AADD624C9C918AA5D5911BEF2208409B@DB3PRD3001MB020.064d.mgd.msft.net> <53DA060E.90206@chalmers.se> Message-ID: <618BE556AADD624C9C918AA5D5911BEF22084361@DB3PRD3001MB020.064d.mgd.msft.net> | 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, "OVERLAPS" is precisely what you want. I don't care whether it is called "OVERLAP" or "OVERLAPS". So it sounds as if you are content. (I assume you don't want to *prevent* careful programmers from saying something more precise.) Simon | | On 31.07.2014 10:13, Simon Peyton Jones wrote: | > 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 #-} Bla a => Bla [a] you are, with GHC | > 7.8, making precisely the same decision when you decide whether or | not to add {-# LANGUAGE OverlappingInstances #-} to that module. | Perhaps that wasn't clear in what I wrote; apologies. | > | > So your proposal seems to be this | > | > don't remove -XOverlappingInstances, because that will prevent | > programmers from "flipping on/off pragmas until their program | > goes through". | > | > It's hard to argue AGAINST providing the opportunity for more careful | programmers to express their intentions more precisely, which is what | the OVERLAP/OVERLAPPABLE pragmas do. | > | > Concerning deprecating OverlappingInstances, my gut feel is that it | is positively a good thing to guide programmers towards a more robust | programming style. But my reason for starting this thread was to see | whether or not others' gut feel is similar. | > | > Simon | > | > | -----Original Message----- | > | From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of | > | Andreas Abel | > | Sent: 31 July 2014 08:59 | > | To: Simon Peyton Jones; ghc-devs; GHC users; Haskell Libraries | > | (libraries at haskell.org) | > | Subject: Re: Overlapping and incoherent instances | > | | > | On 31.07.2014 09:20, Simon Peyton Jones wrote: | > | > Friends, in sending my message below, I should also have sent a | > | > link to | > | > | > | > https://ghc.haskell.org/trac/ghc/ticket/9242#comment:25 | > | | > | Indeed. | > | | > | Quoting from the spec: | > | | > | * Eliminate any candidate IX for which both of the following | hold: | > | * There is another candidate IY that is strictly more specific; | > | that is, IY is a substitution instance of IX but not vice | versa. | > | | > | * Either IX is overlappable or IY is overlapping. | > | | > | Mathematically, this makes a lot of sense. But put on the hat of | > | library writers, and users, and users that don't rtfm. Looking out | > | from under this hat, the one may always wonder whether one should | > | make one's generic instances OVERLAPPABLE or not. | > | | > | If I create a library with type class Bla and | > | | > | instance Bla a => Bla [a] | > | | > | I could be a nice library writer and spare my users from declaring | > | their Bla String instances as OVERLAPPING, so I'd write | > | | > | instance {-# OVERLAPPABLE #-} Bla a => Bla [a] | > | | > | Or maybe that would be malicious? | > | | > | I think the current proposal is too sophisticated. There are no | > | convincing examples given in the discussion so far that demonstrate | > | where this sophistication pays off in practice. | > | | > | Keep in mind that 99% of the Haskell users will never study the | > | instance resolution algorithm or its specification, but just flip | > | on/off pragmas until their code goes through. [At least that was | my | > | approach: whenever GHC asks for one more LANGUAGE pragma, just | throw | > | it in.] | > | | > | Cheers, | > | Andreas | > | | > | | > | > 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 messages. My apologies for that. | > | > | > | > Some key points: | > | > | > | > *There is a useful distinction between /overlapping/ and | > | > /overlappable/, but if you don't want to be bothered with it you | > | > can just say OVERLAPS (which means both). | > | > | > | > *Overlap between two candidate instances is allowed if /either/ | > | > has the relevant property. This is a bit sloppy, but reduces the | > | > annotation burden. Actually, with this per-instance stuff I | think | > | > it'd be perfectly defensible to require both to be annotated, but | > | > that's a different discussion. | > | > | > | > I hope that helps clarify. | > | > | > | > I'm really pretty certain that the basic proposal here is good: | it | > | > implements the current semantics in a more fine-grained manner. | > | > My main motivation was to signal the proposed deprecation of the | > | > global per-module flag -XoverlappingInstances. Happily people | > | > generally | > | seem | > | > fine with this. It is, after all, precisely what deprecations | are | > | for | > | > ("the old thing still works for now, but it won't do so for ever, | > | > and you should change as soon as is convenient"). | > | > | > | > Thanks | > | > | > | > Simon | > | > | > | > *From:*Libraries [mailto:libraries-bounces at haskell.org] *On | Behalf | > | > Of *Simon Peyton Jones | > | > *Sent:* 29 July 2014 10:11 | > | > *To:* ghc-devs; GHC users; Haskell Libraries | > | > (libraries at haskell.org) | > | > *Subject:* Overlapping and incoherent instances | > | > | > | > Friends | > | > | > | > One of GHC's more widely-used features is overlapping (and | > | > sometimes | > | > incoherent) instances. The user-manual documentation is here | > | > | > s- | > | extensions.html#instance-overlap>. | > | > | > | > The use of overlapping/incoherent instances is controlled by | > | > LANGUAGE | > | > pragmas: OverlappingInstances and IncoherentInstances | respectively. | > | > | > | > However the overlap/incoherent-ness is a property of the | > | > **instance | > | > declaration** itself, and has been for a long time. Using | > | > LANGUAGE OverlappingInstances simply sets the "I am an | overlapping instance" | > | > flag for every instance declaration in that module. | > | > | > | > This is a Big Hammer. It give no clue about **which** particular | > | > instances the programmer is expecting to be overlapped, nor which | are | > | > doing the overlapping. It brutally applies to every instance | in | > | the | > | > module. Moreover, when looking at an instance declaration, there | > | > is no nearby clue that it might be overlapped. The clue might be | > | > in the command line that compiles that module! | > | > | > | > Iavor has recently implemented per-instance-declaration pragmas, | > | > so you can say | > | > | > | > instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... | > | > | > | > instance {-# OVERLAPPING #-} Show [Char] where ... | > | > | > | > This is much more precise (it affects only those specific | > | > instances) and it is much clearer (you see it when you see the | > | > instance | > | declaration). | > | > | > | > This new feature will be in GHC 7.10 and I'm sure you will be | > | > happy about that. *But I propose also to deprecate the LANGUAGE | > | > pragmas OverlappingInstances and IncoherentInstances*, as way to | > | > encourage everyone to use the new feature instead of the old big | > | > hammer. The old LANGUAGE pragmas will continue to work, of | > | > course, for at least another complete release cycle. We could | > | > make that two cycles if it | > | was helpful. | > | > | > | > However, if you want deprecation-free libraries, it will entail a | > | wave | > | > of library updates. | > | > | > | > This email is just to warn you, and to let you yell if you think | > | > this | > | is | > | > a bad idea. It would actually not be difficult to retain the | old | > | > LANGUAGE pragmas indefinitely - it just seems wrong not to | > | > actively push authors in the right direction. | > | > | > | > These deprecations of course popped up in the test suite, so I've | > | been | > | > replacing them with per-instance pragmas there too. | Interestingly | > | > in some cases, when looking for which instances needed the | > | > pragmas, I found...none. So OverlappingInstances was entirely | > | > unnecessary. Maybe library authors will find that too! | > | > | > | > Simon | > | > | > | > | > | > | > | > _______________________________________________ | > | > Libraries mailing list | > | > Libraries at haskell.org | > | > http://www.haskell.org/mailman/listinfo/libraries | > | > | > | | > | | > | -- | > | Andreas Abel <>< Du bist der geliebte Mensch. | > | | > | Department of Computer Science and Engineering Chalmers and | > | Gothenburg University, Sweden | > | | > | andreas.abel at gu.se | > | http://www2.tcs.ifi.lmu.de/~abel/ | > | _______________________________________________ | > | Libraries mailing list | > | Libraries at haskell.org | > | http://www.haskell.org/mailman/listinfo/libraries | > _______________________________________________ | > Libraries mailing list | > Libraries at haskell.org | > http://www.haskell.org/mailman/listinfo/libraries | > | | | -- | Andreas Abel <>< Du bist der geliebte Mensch. | | Department of Computer Science and Engineering Chalmers and Gothenburg | University, Sweden | | andreas.abel at gu.se | http://www2.tcs.ifi.lmu.de/~abel/