Re: SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal

[Howard B. Golden]

Hi Yitzchak,

I believe there are good explanations of open source licenses aimed at lawyers 
and management. I don't think their fears are well-founded. If you work for a 
timid company that isn't willing to learn, you should consider going elsewhere. 
You may be happier in the long run. 

Respectfully,

Howard

> On May 20, 2015, at 7:39 AM, Yitzchak Gale  wrote:
> 
> The license issue is a real concern for any company using
> GHC to develop a product whose binaries they distribute to
> customers. And it is concern for GHC itself, if we want
> GHC to continue to be viewed as a candidate for use in
> industry.
> 
> The real issue is not whether you can explain why this
> license is OK, or whether anyone is actually going to the
> trouble of building GHC without GMP.
> 
> The issue is the risk of a *potential* legal issue and its
> potential disastrous cost as *perceived* by lawyers and
> management. A potential future engineering cost, no
> matter how large and even if only marginally practical,
> is perceived as manageable and controllable, whereas a
> poorly understood potential future legal threat is perceived
> as an existential risk to the entire company.
> 
> With GMP, we do have an engineering workaround to side-step
> the legal problem entirely if needed. Whereas if cpphs were
> to be linked into GHC with its current license, I would be
> ethically obligated to report it to my superiors, and the
> response might very well be: Then never mind, let's do the
> simple and safe thing and just rewrite all of our applications in
> Java or C#.
> 
> Keeping the license as is seems to be important to Malcolm.
> So could we have an option to build GHC without cpphs
> and instead use it as a stand-alone external program?
> That would make the situation no worse than GMP.
> 
> Thanks,
> Yitz
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Interactions between type-checker plugins

[Iavor Diatchki]

Hi,

I am not sure about the "deferred type errors", as I never use that feature.

To create new wanted variables, usually you use "newWantedEvVar".
This gives you some evidence (well, really a place-holder for the actual
evidence), and a "freshness" flag.   You do two different things depending
on the freshness:

   - If the evidence is "Fresh", then you have a brand new wanted
constraint and you emit it as a new sub-goal (i.e., the usual thing)
   - if the evidence is cached, this means that this same constraint
already exists;  in that case you can use the returned evidence as needed,
but you don't emit a new wanted constraint.

This is a bit nicer than the "newWantedEvVarNC" as it generates fewer
constraints.

-Iavor




On Wed, May 20, 2015 at 12:26 AM, Christiaan Baaij <
christiaan.ba...@gmail.com> wrote:

> Hi Iavor, Adam, List,
>
> I managed to fix the error message location by using:
> `newWantedEvVarNC`(
> https://downloads.haskell.org/~ghc/7.10.1/docs/html/libraries/ghc-7.10.1/TcSMonad.html#v:newWantedEvVarNC
> )
>
> So now the output of my test suite is:
> ```
> [1 of 2] Compiling ErrorTests   ( tests/ErrorTests.hs,
> dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise-tmp/ErrorTests.o
> ) [GHC.TypeLits.Normalise changed]
>
> tests/ErrorTests.hs:14:13: Warning:
> Couldn't match type ‘GCD 6 8’ with ‘4’
> Expected type: Proxy (GCD 6 8) -> Proxy 4
>   Actual type: Proxy 4 -> Proxy 4
> In the expression: id
> In an equation for ‘testFail1’: testFail1 = id
>
> tests/ErrorTests.hs:17:13: Warning:
> Couldn't match type ‘GCD 6 9’ with ‘GCD 6 8’
> NB: ‘GCD’ is a type function, and may not be injective
> Expected type: Proxy (GCD 6 8 + x) -> Proxy (x + GCD 6 9)
>   Actual type: Proxy (x + GCD 6 9) -> Proxy (x + GCD 6 9)
> In the expression: id
> In an equation for ‘testFail2’: testFail2 = id
> [2 of 2] Compiling Main ( tests/Main.hs,
> dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise-tmp/Main.o )
> [GHC.TypeLits.Normalise changed]
> Linking dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise ...
> Running 1 test suites...
> Test suite test-ghc-tynat-normalise: RUNNING...
> ghc-typelits-natnormalise
>   Basic functionality
> GCD 6 8 ~ 2:OK
> GCD 6 8 + x ~ x + GCD 10 8: OK
>   errors
> GCD 6 8 ~ 4:OK
> GCD 6 8 + x ~ x + GCD 9 6:  FAIL
>   No exception!
>
> 1 out of 4 tests failed (0.01s)
> ```
>
> But evaluating the expression still doesn’t throw an exception because I
> solved the original constraint.
>
> — Christiaan
>
> On 19 May 2015, at 18:44, Christiaan Baaij 
> wrote:
>
> I have yet to test this properly, but I don't think your suggestions
> (which you happen to give with 1 minute of eachother...) play nicely with
> error reporting.
> Here is an output of my testsuite:
>
> ```
>  [1 of 2] Compiling ErrorTests   ( tests/ErrorTests.hs,
> dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise-tmp/ErrorTests.o
> ) [GHC.TypeLits.Normalise changed]
>
> tests/ErrorTests.hs:1:1: Warning:
>Couldn't match type ‘GCD 6 9’ with ‘GCD 6 8’
>NB: ‘GCD’ is a type function, and may not be injective
>Expected type: Proxy (GCD 6 8 + x) -> Proxy (x + GCD 6 9)
>  Actual type: Proxy (x + GCD 6 9) -> Proxy (x + GCD 6 9)
>
> tests/ErrorTests.hs:14:13: Warning:
>Couldn't match type ‘GCD 6 8’ with ‘4’
>Expected type: Proxy (GCD 6 8) -> Proxy 4
>  Actual type: Proxy 4 -> Proxy 4
>In the expression: id
>In an equation for ‘testFail1’: testFail1 = id
> [2 of 2] Compiling Main ( tests/Main.hs,
> dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise-tmp/Main.o )
> [GHC.TypeLits.Normalise changed]
> Linking dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise ...
> Running 1 test suites...
> Test suite test-ghc-tynat-normalise: RUNNING...
> ghc-typelits-natnormalise
>  Basic functionality
>GCD 6 8 ~ 2:OK
>GCD 6 8 + x ~ x + GCD 10 8: OK
>  errors
>GCD 6 8 ~ 4:OK
>GCD 6 8 + x ~ x + GCD 9 6:  FAIL
>  No exception!
>
> 1 out of 4 tests failed (0.00s)
>  ```
>
> Note that 'ErrorTest.hs' is compiled with '-fdefer-type-errors'.
> There's a two things you may notice
> * The first error message's location is '1:1'
> * Evaluation the function with the type-error does not raise an exception.
>
> So by solving the constraint
> "GCD 6 8 + x ~ x + GCD 9 6"
> The boxed/run-time coercion no longer errors.
> Also, I'm using newSimpleWanted (
> https://downloads.haskell.org/~ghc/7.10.1/docs/html/libraries/ghc-7.10.1/TcMType.html#v:newSimpleWanted)
> to create the new wanted constraint.
> But for some reason the errror message doesn't get the source-error
> location of the original constraint.
> Perhaps I shouldn't be using 'newSimpleWanted' to create new wanted
> constraints?
>
> The sources for the plugins are over here:
> https://github.com/christiaanb/ghc-typelits-natnormalise
> https:

Re: Non-deterministic package IDs are really bad in 7.10

[Mateusz Kowalczyk]

On 05/19/2015 08:33 AM, Joachim Breitner wrote:
> Hi,
> 
> Am Dienstag, den 19.05.2015, 07:27 +0100 schrieb Mateusz Kowalczyk:
>> On 05/19/2015 06:46 AM, Daniel Peebles wrote:
>>> Don't Nix builds all happen in a randomly generated temporary directory by
>>> default? Then you just copy to $out in installPhase. Perhaps stabilizing
>>> the build directory would help alleviate some of the immediate problems, if
>>> what Joachim is describing affects us too.
>>
>> Oh, I was far too hasty in reading the bug on the Debian tracker. Yes, I
>> suppose this could be a problem for us though I'd like to see it first
>> before trying to work around it.
> 
> it’s easy to check: Just run
> $ ghc --show-iface /usr/lib/ghc/base-4.7.0.2/System/Info.hi|grep Dep
> addDependentFile "/build/ghc-LIQtDg/ghc-7.8.4/includes/ghcplatform.h"
> addDependentFile "libraries/base/dist-install/build/autogen/cabal_macros.h"
> addDependentFile "/usr/include/stdc-predef.h"

Seems we're good?:

[nix-shell:~]$ ghc --show-iface
/nix/store/rnxk1a1bz4rgy1rw4973blbfp9f0ic89-ghc-7.8.4/lib/ghc-7.8.4/base-4.7.0.2/System/Info.hi
 | grep Dep
addDependentFile "libraries/base/dist-install/build/autogen/cabal_macros.h"
addDependentFile
"/nix/store/6k9z1sfl7kghmagwd205k3i81pbcw57s-glibc-2.21/include/stdc-predef.h"

With our new architecture using 7.10.1:

[nix-shell:~]$ ghc --show-iface
/nix/store/j50pk13r5jysqk20gsyjdi89qcpfii57-ghc-7.10.1/lib/ghc-7.10.1/base_I5BErHzyOm07EBNpKBEeUv/System/Info.hi
| grep Dep
addDependentFile "libraries/base/dist-install/build/autogen/cabal_macros.h"
addDependentFile
"/nix/store/c2zjp7bqmp5wvpkrpl7p7sfhxbdyfryy-glibc-2.21/include/stdc-predef.h"


> If you see the build path appearing there, you are affected by the bug.

In light of above, I don't know if I should be happy because we don't
seem to be affected or scared that it's just subtle and will bite us
regardless.

> 
> Greetings,
> Joachim
> 
> 
> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 


-- 
Mateusz K.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal

[Bardur Arantsson]

On 05/20/2015 03:39 PM, Yitzchak Gale wrote:
[--snip--]
> Keeping the license as is seems to be important to Malcolm.
> So could we have an option to build GHC without cpphs
> and instead use it as a stand-alone external program?
> That would make the situation no worse than GMP.

I don't see any need for an option. Just bundle cpphs together with GHC
and build/use it as an external program. AFAICT this has absolutely no
licensing implications for GHC, derived from GHC or anything compiled
with GHC.

Regards,

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: SV: [Haskell-cafe] RFC: "Native -XCPP" Proposal

[Yitzchak Gale]

The license issue is a real concern for any company using
GHC to develop a product whose binaries they distribute to
customers. And it is concern for GHC itself, if we want
GHC to continue to be viewed as a candidate for use in
industry.

The real issue is not whether you can explain why this
license is OK, or whether anyone is actually going to the
trouble of building GHC without GMP.

The issue is the risk of a *potential* legal issue and its
potential disastrous cost as *perceived* by lawyers and
management. A potential future engineering cost, no
matter how large and even if only marginally practical,
is perceived as manageable and controllable, whereas a
poorly understood potential future legal threat is perceived
as an existential risk to the entire company.

With GMP, we do have an engineering workaround to side-step
the legal problem entirely if needed. Whereas if cpphs were
to be linked into GHC with its current license, I would be
ethically obligated to report it to my superiors, and the
response might very well be: Then never mind, let's do the
simple and safe thing and just rewrite all of our applications in
Java or C#.

Keeping the license as is seems to be important to Malcolm.
So could we have an option to build GHC without cpphs
and instead use it as a stand-alone external program?
That would make the situation no worse than GMP.

Thanks,
Yitz
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: [commit: ghc] master: Refactor tuple constraints (ffc2150)

[Simon Peyton Jones]

Eek.  Well spotted. The "30" is really odd compared to all the other instances, 
so best to use "7". I'm validating a patch now.

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
|  Christiaan Baaij
|  Sent: 20 May 2015 14:02
|  To: ghc-devs@haskell.org
|  Subject: Re: [commit: ghc] master: Refactor tuple constraints
|  (ffc2150)
|  
|  Hi,
|  
|  This patch broke the ‘Binary’ instance for ‘IfaceType’ in
|  ‘iface/IfaceType.hs’
|  Specifically, it changed:
|  
|  ```
|  put_ bh (IfaceLitTy n)
| = do { putByte bh 30; put_ bh n }
|  ```
|  
|  to:
|  
|  ```
|  put_ bh (IfaceLitTy n)
| = do { putByte bh 7; put_ bh n }
|  ```
|  
|  However, the ‘get’ definition was left as:
|  
|  ```
|  30 -> do n <- get bh
|   return (IfaceLitTy n)
|  ```
|  
|  I don’t know what’s preferable:
|  - revert the definition of `put_`,
|  - or update the `get` definition to `7`
|  
|  Regards,
|  
|  Christiaan
|  
|  
|  > On 18 May 2015, at 14:45, g...@git.haskell.org wrote:
|  >
|  > Repository : ssh://g...@git.haskell.org/ghc
|  >
|  > On branch  : master
|  > Link   :
|  http://ghc.haskell.org/trac/ghc/changeset/ffc21506894c7887d3620423aaf8
|  6bc6113a1071/ghc
|  >
|  >> ---
|  >
|  > commit ffc21506894c7887d3620423aaf86bc6113a1071
|  > Author: Simon Peyton Jones 
|  > Date:   Mon May 11 23:19:14 2015 +0100
|  >
|  >Refactor tuple constraints
|  >
|  >Make tuple constraints be handled by a perfectly ordinary
|  >type class, with the component constraints being the
|  >superclasses:
|  >class (c1, c2) => (c2, c2)
|  >
|  >This change was provoked by
|  >
|  >  #10359  inability to re-use a given tuple
|  >  constraint as a whole
|  >
|  >  #9858   confusion between term tuples
|  >  and constraint tuples
|  >
|  >but it's generally a very nice simplification. We get rid of
|  > -  In Type, the TuplePred constructor of PredTree,
|  >and all the code that dealt with TuplePreds
|  > -  In TcEvidence, the constructors EvTupleMk, EvTupleSel
|  >
|  >See Note [How tuples work] in TysWiredIn.
|  >
|  >Of course, nothing is ever entirely simple. This one
|  >proved quite fiddly.
|  >
|  >- I did quite a bit of renaming, which makes this patch
|  >  touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
|  >
|  >- I made constraint tuples known-key rather than wired-in.
|  >  This is different to boxed/unboxed tuples, but it proved
|  >  awkward to have all the superclass selectors wired-in.
|  >  Easier just to use the standard mechanims.
|  >
|  >- While I was fiddling with known-key names, I split the TH Name
|  >  definitions out of DsMeta into a new module THNames.  That
|  meant
|  >  that the known-key names can all be gathered in PrelInfo,
|  without
|  >  causing module loops.
|  >
|  >- I found that the parser was parsing an import item like
|  >  T( .. )
|  >  as a *data constructor* T, and then using setRdrNameSpace to
|  >  fix it.  Stupid!  So I changed the parser to parse a *type
|  >  constructor* T, which means less use of setRdrNameSpace.
|  >
|  >  I also improved setRdrNameSpace to behave better on Exact
|  Names.
|  >  Largely on priciple; I don't think it matters a lot.
|  >
|  >- When compiling a data type declaration for a wired-in thing
|  like
|  >  tuples (,), or lists, we don't really need to look at the
|  >  declaration.  We have the wired-in thing!  And not doing so
|  avoids
|  >  having to line up the uniques for data constructor workers etc.
|  >  See Note [Declarations for wired-in things]
|  >
|  >- I found that FunDeps.oclose wasn't taking superclasses into
|  >  account; easily fixed.
|  >
|  >- Some error message refactoring for invalid constraints in
|  TcValidity
|  >
|  >- Haddock needs to absorb the change too; so there is a submodule
|  update
|  >
|  >
|  >> ---
|  >
|  > ffc21506894c7887d3620423aaf86bc6113a1071
|  > compiler/basicTypes/BasicTypes.hs  |  21 +-
|  > compiler/basicTypes/DataCon.hs |   1 -
|  > compiler/basicTypes/RdrName.hs |  28 +-
|  > compiler/basicTypes/Unique.hs  |  28 +-
|  > compiler/basicTypes/VarSet.hs  |  23 +-
|  > compiler/coreSyn/CoreLint.hs   |   2 +-
|  > compiler/coreSyn/MkCore.hs |   7 +-
|  > compiler/coreSyn/PprCore.hs|   4 +-
|  > compiler/deSugar/Check.hs  |   2 +-
|  > compiler/deSugar/DsArrows.hs   |   2 +-
|  > compiler/deSugar/DsBinds.hs|  25 +-
|  > compiler/deSugar/DsCCall.hs|   6 +-
|  > compiler/

RE: Some test data

[Tamar Christina]

Hi Ben,

I haven't noticed a target for ARM in the split script which is why it
wasn't in my list. I'll check later but my guess if the ARM version of
the compiler does not support obj-split.

Cheers,
TamarFrom: Ben Gamari
Sent: ‎5/‎20/‎2015 14:38
To: Tamar Christina; GHC
Subject: Re: Some test data
Tamar Christina  writes:

> Hi All,
>
>
> I’m currently busy rewriting the GHC-split perl script into Haskell and 
> require some for the platforms I don’t have at the moment.
>
>
> I require an example file(s) for:
>
>   - Apple Darwin
>
>   - Sparc
>
>  - PowerPC Linux
>
>  - X86 Linux
>
>  - X86_64 Linux
>
Is this to say that you have an ARM? If not I would be willing to do
some testing once my hardware arrives (which may be a month or so sadly;
it's currently drifting across the Atlantic).

Cheers,

- Ben
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: Refactor tuple constraints (ffc2150)

[Christiaan Baaij]

Hi,

This patch broke the ‘Binary’ instance for ‘IfaceType’ in ‘iface/IfaceType.hs’
Specifically, it changed:

```
put_ bh (IfaceLitTy n)
   = do { putByte bh 30; put_ bh n }
```

to:

```
put_ bh (IfaceLitTy n)
   = do { putByte bh 7; put_ bh n }
```

However, the ‘get’ definition was left as:

```
30 -> do n <- get bh
 return (IfaceLitTy n)
```

I don’t know what’s preferable:
- revert the definition of `put_`,
- or update the `get` definition to `7`

Regards,

Christiaan


> On 18 May 2015, at 14:45, g...@git.haskell.org wrote:
> 
> Repository : ssh://g...@git.haskell.org/ghc
> 
> On branch  : master
> Link   : 
> http://ghc.haskell.org/trac/ghc/changeset/ffc21506894c7887d3620423aaf86bc6113a1071/ghc
> 
>> ---
> 
> commit ffc21506894c7887d3620423aaf86bc6113a1071
> Author: Simon Peyton Jones 
> Date:   Mon May 11 23:19:14 2015 +0100
> 
>Refactor tuple constraints
> 
>Make tuple constraints be handled by a perfectly ordinary
>type class, with the component constraints being the
>superclasses:
>class (c1, c2) => (c2, c2)
> 
>This change was provoked by
> 
>  #10359  inability to re-use a given tuple
>  constraint as a whole
> 
>  #9858   confusion between term tuples
>  and constraint tuples
> 
>but it's generally a very nice simplification. We get rid of
> -  In Type, the TuplePred constructor of PredTree,
>and all the code that dealt with TuplePreds
> -  In TcEvidence, the constructors EvTupleMk, EvTupleSel
> 
>See Note [How tuples work] in TysWiredIn.
> 
>Of course, nothing is ever entirely simple. This one
>proved quite fiddly.
> 
>- I did quite a bit of renaming, which makes this patch
>  touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
> 
>- I made constraint tuples known-key rather than wired-in.
>  This is different to boxed/unboxed tuples, but it proved
>  awkward to have all the superclass selectors wired-in.
>  Easier just to use the standard mechanims.
> 
>- While I was fiddling with known-key names, I split the TH Name
>  definitions out of DsMeta into a new module THNames.  That meant
>  that the known-key names can all be gathered in PrelInfo, without
>  causing module loops.
> 
>- I found that the parser was parsing an import item like
>  T( .. )
>  as a *data constructor* T, and then using setRdrNameSpace to
>  fix it.  Stupid!  So I changed the parser to parse a *type
>  constructor* T, which means less use of setRdrNameSpace.
> 
>  I also improved setRdrNameSpace to behave better on Exact Names.
>  Largely on priciple; I don't think it matters a lot.
> 
>- When compiling a data type declaration for a wired-in thing like
>  tuples (,), or lists, we don't really need to look at the
>  declaration.  We have the wired-in thing!  And not doing so avoids
>  having to line up the uniques for data constructor workers etc.
>  See Note [Declarations for wired-in things]
> 
>- I found that FunDeps.oclose wasn't taking superclasses into
>  account; easily fixed.
> 
>- Some error message refactoring for invalid constraints in TcValidity
> 
>- Haddock needs to absorb the change too; so there is a submodule update
> 
> 
>> ---
> 
> ffc21506894c7887d3620423aaf86bc6113a1071
> compiler/basicTypes/BasicTypes.hs  |  21 +-
> compiler/basicTypes/DataCon.hs |   1 -
> compiler/basicTypes/RdrName.hs |  28 +-
> compiler/basicTypes/Unique.hs  |  28 +-
> compiler/basicTypes/VarSet.hs  |  23 +-
> compiler/coreSyn/CoreLint.hs   |   2 +-
> compiler/coreSyn/MkCore.hs |   7 +-
> compiler/coreSyn/PprCore.hs|   4 +-
> compiler/deSugar/Check.hs  |   2 +-
> compiler/deSugar/DsArrows.hs   |   2 +-
> compiler/deSugar/DsBinds.hs|  25 +-
> compiler/deSugar/DsCCall.hs|   6 +-
> compiler/deSugar/DsExpr.hs |   5 +-
> compiler/deSugar/DsMeta.hs | 840 +
> compiler/deSugar/Match.hs  |   4 +-
> compiler/ghc.cabal.in  |   3 +-
> compiler/ghci/RtClosureInspect.hs  |   7 +-
> compiler/hsSyn/Convert.hs  |   4 +-
> compiler/hsSyn/HsExpr.hs   |   3 +-
> compiler/hsSyn/HsPat.hs|  35 +-
> compiler/hsSyn/HsTypes.hs  |   2 +-
> compiler/iface/BinIface.hs |  14 +-
> compiler/iface/BuildTyCl.hs|   4 +
> compiler/iface/IfaceSyn.hs |   9 +-
> compiler/ifac

Re: Some test data

[Ben Gamari]

Tamar Christina  writes:

> Hi All,
>
>
> I’m currently busy rewriting the GHC-split perl script into Haskell and 
> require some for the platforms I don’t have at the moment.
>
>
> I require an example file(s) for:
>
>   - Apple Darwin
>
>   - Sparc
>
>  - PowerPC Linux
>
>  - X86 Linux
>
>  - X86_64 Linux
>
Is this to say that you have an ARM? If not I would be willing to do
some testing once my hardware arrives (which may be a month or so sadly;
it's currently drifting across the Atlantic).

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

FFI problems on 64-bit Windows

[Yitzchak Gale]

As I am sure many people have noticed, there is
currently a serious problem with FFI on 64-bit
Windows. It often happens that when you link
in FFI against a standard DLL, the resulting
application segfaults as soon as any function
from the DLL is called.

I experienced this problem with Bryan's text-icu
library when I linked it against the standard
Windows 64-bit DLLs provided by the ICU
project.

In this case, the workaround I found is to link
instead against DLLs built using mingw-w64 and
provided as part of MSYS2:

https://mail.haskell.org/pipermail/haskell-cafe/2015-May/119737.html

On reddit, /u/awson (is that Kyra?) pointed out that
this issue is probably caused by a serious bug in
GNU binutils that was fixed about two months ago:

https://sourceware.org/bugzilla/show_bug.cgi?id=16598

Is it possible to update the MSYS2/mingw-w64 toolchain
used by GHC to a recent version that includes this
fix?

Thanks,
Yitz
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC Trac slow again

[Herbert Valerio Riedel]

On 2015-05-20 at 12:48:50 +0200, Simon Peyton Jones wrote:
> Did you manage to fix your Trac re-initialiser?  Trac is soul-destroyingly 
> slow today

...the periodic apache2 reloader is still working... not sure why it's
still slow *today*... (otoh, for me it's currently not that slow)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

GHC Trac slow again

[Simon Peyton Jones]

Herbert
Did you manage to fix your Trac re-initialiser?  Trac is soul-destroyingly slow 
today

Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

API to “raise concern” in Phabricator

[Joachim Breitner]

Hi,

with https://perf.haskell.org/ghc/ up and running I’m wondering about
the best way to notify us about regressions. A mail to ghc-commits is
one possibility, but maybe it’s neater to integrate that into
Phabricator.

How hard would it be comment and optionally “raise concern” with a
commit automatically?

Or, put differently, I want a script that takes a git commit, a comment,
and a flag that indicated whether a concern should be raised, and then
does that on Phabricator.

It seems that https://phabricator.haskell.org/conduit/ is an entry
point, but I only see methods for attaching comments to DRs.

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org


signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Interactions between type-checker plugins

[Christiaan Baaij]

Hi Iavor, Adam, List,

I managed to fix the error message location by using:
`newWantedEvVarNC`(https://downloads.haskell.org/~ghc/7.10.1/docs/html/libraries/ghc-7.10.1/TcSMonad.html#v:newWantedEvVarNC
 
)

So now the output of my test suite is:
```
[1 of 2] Compiling ErrorTests   ( tests/ErrorTests.hs, 
dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise-tmp/ErrorTests.o ) 
[GHC.TypeLits.Normalise changed]

tests/ErrorTests.hs:14:13: Warning:
Couldn't match type ‘GCD 6 8’ with ‘4’
Expected type: Proxy (GCD 6 8) -> Proxy 4
  Actual type: Proxy 4 -> Proxy 4
In the expression: id
In an equation for ‘testFail1’: testFail1 = id

tests/ErrorTests.hs:17:13: Warning:
Couldn't match type ‘GCD 6 9’ with ‘GCD 6 8’
NB: ‘GCD’ is a type function, and may not be injective
Expected type: Proxy (GCD 6 8 + x) -> Proxy (x + GCD 6 9)
  Actual type: Proxy (x + GCD 6 9) -> Proxy (x + GCD 6 9)
In the expression: id
In an equation for ‘testFail2’: testFail2 = id
[2 of 2] Compiling Main ( tests/Main.hs, 
dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise-tmp/Main.o ) 
[GHC.TypeLits.Normalise changed]
Linking dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise ...
Running 1 test suites...
Test suite test-ghc-tynat-normalise: RUNNING...
ghc-typelits-natnormalise
  Basic functionality
GCD 6 8 ~ 2:OK
GCD 6 8 + x ~ x + GCD 10 8: OK
  errors
GCD 6 8 ~ 4:OK
GCD 6 8 + x ~ x + GCD 9 6:  FAIL
  No exception!

1 out of 4 tests failed (0.01s)
```

But evaluating the expression still doesn’t throw an exception because I solved 
the original constraint.

— Christiaan

> On 19 May 2015, at 18:44, Christiaan Baaij  wrote:
> 
> I have yet to test this properly, but I don't think your suggestions (which 
> you happen to give with 1 minute of eachother...) play nicely with error 
> reporting.
> Here is an output of my testsuite:
> 
> ```
> [1 of 2] Compiling ErrorTests   ( tests/ErrorTests.hs, 
> dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise-tmp/ErrorTests.o 
> ) [GHC.TypeLits.Normalise changed]
> 
> tests/ErrorTests.hs:1:1: Warning:
>Couldn't match type ‘GCD 6 9’ with ‘GCD 6 8’
>NB: ‘GCD’ is a type function, and may not be injective
>Expected type: Proxy (GCD 6 8 + x) -> Proxy (x + GCD 6 9)
>  Actual type: Proxy (x + GCD 6 9) -> Proxy (x + GCD 6 9)
> 
> tests/ErrorTests.hs:14:13: Warning:
>Couldn't match type ‘GCD 6 8’ with ‘4’
>Expected type: Proxy (GCD 6 8) -> Proxy 4
>  Actual type: Proxy 4 -> Proxy 4
>In the expression: id
>In an equation for ‘testFail1’: testFail1 = id
> [2 of 2] Compiling Main ( tests/Main.hs, 
> dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise-tmp/Main.o ) 
> [GHC.TypeLits.Normalise changed]
> Linking dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise ...
> Running 1 test suites...
> Test suite test-ghc-tynat-normalise: RUNNING...
> ghc-typelits-natnormalise
>  Basic functionality
>GCD 6 8 ~ 2:OK
>GCD 6 8 + x ~ x + GCD 10 8: OK
>  errors
>GCD 6 8 ~ 4:OK
>GCD 6 8 + x ~ x + GCD 9 6:  FAIL
>  No exception!
> 
> 1 out of 4 tests failed (0.00s)
> ```
> 
> Note that 'ErrorTest.hs' is compiled with '-fdefer-type-errors'.
> There's a two things you may notice
> * The first error message's location is '1:1'
> * Evaluation the function with the type-error does not raise an exception.
> 
> So by solving the constraint
> "GCD 6 8 + x ~ x + GCD 9 6"
> The boxed/run-time coercion no longer errors.
> Also, I'm using newSimpleWanted 
> (https://downloads.haskell.org/~ghc/7.10.1/docs/html/libraries/ghc-7.10.1/TcMType.html#v:newSimpleWanted
>  
> )
>  to create the new wanted constraint.
> But for some reason the errror message doesn't get the source-error location 
> of the original constraint.
> Perhaps I shouldn't be using 'newSimpleWanted' to create new wanted 
> constraints?
> 
> The sources for the plugins are over here:
> https://github.com/christiaanb/ghc-typelits-natnormalise 
> 
> https://github.com/christiaanb/ghc-typelits-extra 
> 
> 
> Cheers,
> 
> Christiaan
> 
> 
> 
> On 19 May 2015 at 18:01, Iavor Diatchki  > wrote:
> Hi Christiaan,
> 
> 
> Plugins should return the solved constraints in the first field of 
> `TcPLuginOk`, and additional sub-goals in the second.
> The constraints in the first list are marked as solved, and do not need to be 
> processed further,  while the constraints
> in the second list will be added to the work queue, for further processing.  
> Also, the solutions of wanted goals ma