Re: Do we need to maintain PrimRep.VecRep?

There's also the question of whether or not the high level simd ops that llvm exposes are the ones that can be easily supported by the native code Gen without duplicating llvm specific logic around lowering on various architectures. Though for the basic horizontal operations that are currently

Re: Testsuite total failure on Windows

I get the same spam ranking for Simon's emails. My gmail app says it's because they're from Microsoft but doesn't fill requirements for microsoft.com . Presumably this is because the sender is the list server and not the normal mail server. So it doesn't seem easy to fix. But it would be weird if

Re: Testsuite total failure on Windows

Hi Simon, Is this you working on my show-stopping problem with the tetssuite? > sh: line 0: cd: > c:/users/simonpj/appdata/local/temp/ghctest-qbd2zw123.T9662: No such file > or directory > I pushed a fix. It was my mistake. It turns out there are 2 types of Python on Windows (msys2 and

Testsuite total failure on Windows

Thomie Is this you working on my show-stopping problem with the tetssuite? sh: line 0: cd: c:/users/simonpj/appdata/local/temp/ghctest-qbd2zw123.T9662: No such file or directory If so, thank you! If not, might you look (email attached). I am so stuck. Even a commit to roll back

Suggestions for improving the PVP. Was Re: Why upper bound version numbers?

On Monday, June 6, 2016 23:15:00 -0700, Herbert Valerio Riedel wrote: > Unfortunately, GHC's `base` package has a *huge* API surface. So with> each > GHC release we're usually forced to perform a major version bump to > satisfy the PVP, even if just a tiny part only very few packages use of >

Re: Do we need to maintain PrimRep.VecRep?

Ahh, I see... I finally found the primops, machops, and code generator for x86: MO_V_Insert {} -> needLlvm MO_V_Extract {} -> needLlvm MO_V_Add {} -> needLlvm MO_V_Sub {} -> needLlvm ... > The reason this is not available more widely is lack of support

Re: Do we need to maintain PrimRep.VecRep?

Only programs that use vector primops will generate VecRep's. GHC is not such a program. The branch of vector that I modified to use vector primops will generate VecRep's. You can find it here: https://github.com/mainland/vector/tree/simd It uses a modified version of primitive. See here, for

Re: Do we need to maintain PrimRep.VecRep?

Thanks, I can see the TyCons with VecReps there.. but I still can't see how the terms are constructed? Can you show me some example programs, or functions in the compiler, that generate vector terms? (e.g. terms with types with VecReps) 2016-06-07 10:48 GMT-04:00 Geoffrey Mainland

Re: Do we need to maintain PrimRep.VecRep?

VecRep is used for vector operations. If you aren't using LLVM, you won't see them. VecRep's are generated by utils/genprimopcode/Main.hs. Check out compiler/stage1/build/primop-vector-tys.hs-incl in your build tree---should be plenty of generated VecRep's there :) Cheers, Geoff On 06/07/2016

Re: Why upper bound version numbers?

> On 7 Jun 2016, at 7:02 am, Dominick Samperi wrote: > > Why would a package developer want to upper bound the version number > for packages like base? For example, the clash package requires > > base >= 4.2 && base <= 4.3 I put an upper bound on all my libraries as a

Do we need to maintain PrimRep.VecRep?

I have some code that does things depending on PrimReps of terms and so I have to handle VecRep there. To understand what VecRep exactly is and how to use it I looked at its uses, and all I can find was that we have a wired-in DataCon `vecRepDataCon` which has a type that I thought should have

Help! Windows build broken in teestsuite

Aargh! The Windows build is broken again. This time it’s the testsuite. It seems to be trying to run the test in a temp directory, and failing to find the directory. Thomie, could this be something to do with your work on the testsuite? Please fix! Or tell me what to revert.It leaves me

Re: Why upper bound version numbers?

Others have already commented on many aspects of this discussion, but I just wanted to mention that cabal has an '--allow-newer' flag to disregard these constraints, so '--allow-newer=base' would allow you to try and compile this package with GHC 8. Since GHC 8 is very recent though and base 4.3

Re: Why upper bound version numbers?

Given that I'm the maintainer of the 'clash' package, I wanted to say that the 'clash' package has been deprecated in favour of the 'clash-ghc' package (for some time now, and this is stated on hackage). Sadly, 'clash-ghc' will not compile on ghc 8.0.1 right now either; it only compiles

Re: Why upper bound version numbers?

On 2016-06-07 at 02:58:34 +0200, Dominick Samperi wrote: > I guess what you are saying is that this policy will prevent packages > from installing with new versions of ghc until the maintainer has had > a chance to test the package with the new version, and has updated the > upper version limit.

Re: Why upper bound version numbers?

Aforementioned versioning policy: https://wiki.haskell.org/Package_versioning_policy On Mon, Jun 6, 2016 at 5:58 PM, Dominick Samperi wrote: > I guess what you are saying is that this policy will prevent packages > from installing with new versions of ghc until the