I believe Geoff is working on adding AVX. I expect he’d be interested in your
patches.
Simon
From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org] On
Behalf Of Carter Schonwald
Sent: 13 February 2013 05:59
To: Michael Baikov
Cc: ghc-devs@haskell.org
Subject: Re: Vector primo
From: Sergei Trofimovich
Fixed bootstrap failure on linux for --target=mingw32
Signed-off-by: Sergei Trofimovich
---
configure.ac | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index b679520..7553a7a 100644
--- a/configure.ac
+++ b/co
Thanks for pushing on this! The summary of my comments is this: I think that
we should have 1 or 2 low-level (not necessarily safe) GHC modules that contain
all the bits that GHC needs to know about, and move all other bits into a
separate library, which is to be used by the actual users of t
From: Sergei Trofimovich
Fixed bootstrap failure on linux for --target=mingw32 of such kind:
"/usr/bin/ghc" -o utils/hsc2hs/dist/build/tmp/hsc2hs -static -H32m -O -w
-package-db libraries/bootstrapping.conf -hide-all-packages -i
-iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dis
> By which I mean having this family of proposed primops. Its not obvious to
> me at least how GHC could intelligently infer / use these implicitly for
> the end user / library writer.
I have couple of ideas how to implement this, but having explicit set
of primops will make using of the vector i
By which I mean having this family of proposed primops. Its not obvious to
me at least how GHC could intelligently infer / use these implicitly for
the end user / library writer.
On Feb 13, 2013 12:07 AM, "Michael Baikov" wrote:
> Recently merged vector primops support only 16 bytes operands - I
Yes please! having these (for valid target arches/ CPU targets) would be
really really valuable for me.
On Feb 13, 2013 12:07 AM, "Michael Baikov" wrote:
>
> Recently merged vector primops support only 16 bytes operands - Int32
> x 4, Double x 2 and so on. Current AVX instructions support 256 bi
Recently merged vector primops support only 16 bytes operands - Int32
x 4, Double x 2 and so on. Current AVX instructions support 256 bit
operands and with simple cut'n'paste work it's possible to support at
least Double x 4 operands. I made those changes and GHC generates
(using llvm) proper AVX c
Hi all,
> I've merged the new parallel I/O manager that Andreas Voellmy and Kazu
> Yamamoto have been working on. The new parallel I/O manager scales much better
> than the current one*: the number of requests per second scales almost
> linearly up to 32 cores I believe. Perhaps Andreas could post
On Mon, Jan 28, 2013 at 12:30:54AM +0300, Sergei Trofimovich wrote:
>
> Gentoo calls 'w64' a mingw flavour with mingw-w64 runtime.
Applied, thanks!
Thanks
Ian
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc
On 2/12/13, Richard Eisenberg wrote:
> I've just pushed a commit to the type-reasoning branch with a strawman
> proposal of a reorganization of these definitions. Specifically, this commit
> breaks TypeLits into the following five files:
>
> - GHC.TypeEq, which contains the definitions for (:~:),
Hi Richard,
Thanks for pushing on this! The summary of my comments is this: I think
that we should have 1 or 2 low-level (not necessarily safe) GHC modules
that contain all the bits that GHC needs to know about, and move all other
bits into a separate library, which is to be used by the actual
> Thanks for sharing! My perspective is of course as a user. I don't think
> I've ever run into a case where the compiler broken a previous work e.g.
> C++ program. On the other hand I have to make a release of most of the
> libraries I maintain with every GHC release (to bump cabal version
> cons
On 02/12/2013 09:37 AM, Simon Marlow wrote:
> On 11/02/13 23:03, Johan Tibell wrote:
>> Hi,
>>
> Of course we do also make well-intentioned changes to libraries, via the
> library proposal process, and some of these break APIs. But it wouldn't
> do any harm to batch these up and defer them until t
I've had a look. As you say, the changes are modest.
For (2), I'd like to see a
Note [Overriding the GHC.Prim interface]
with the field decl for sOverridePrimIface in DynFlags, with enough commentary
to explain what is going on.
In particular, this Dyn
I doubt it matters. I was just curious. But it might do no harm to have it
there, commented out, because it's an example of how do to the "modify"
operation on TrieMaps
S
| -Original Message-
| From: Richard Eisenberg [mailto:e...@cis.upenn.edu]
| Sent: 12 February 2013 15:08
| To: S
I was working in a ghc tree that I thought was clean (i.e. was a checkout of
HEAD), but evidently was not.
In my other work, I needed to update lookupType_mod, but wasn't sure how to.
So, I looked for use sites. When I found none, I must have gone into this ghc
tree, removed the exports, and ch
Hi all,
I filed this to vector's trac.
http://trac.haskell.org/vector/ticket/91
Thanks,
On Tue, 12 Feb 2013 22:12:02 +0900, José Pedro Magalhães wrote:
Hi Roman,
Just to remind you of the patch to vector I've previously sent you.
Whenever you can apply it,
we can remove the "temporary f
NO... but I've just discovered that my 'time' link tree had some .hs files in
it, NOT pointers to the source tree. I have no clue why.
That turned out to be the problem. Sorry for the noise
S
From: josepedromagalh...@gmail.com [mailto:josepedromagalh...@gmail.com] On
Behalf Of José Pedro Mag
I'm using the bindists for some versions, and the ~simonmar/fp/ installs
(which I've assumed are bindist) for the ones that already existed there
(ie 7.0.1 to 7.4.1, excepting 7.0.4).
$ md5sum ghc*bz2
0fc26b4c1d10ff9dc8b0cbe9453d48d3 ghc-7.0.4-x86_64-unknown-linux.tar.bz2
de67ecfe619b0126d8a8b93d
Hi Simon,
I pushed to the wrong branch, but that should be fixed now. Does a
./sync-all pull solve it?
Cheers,
Pedro
On Tue, Feb 12, 2013 at 1:47 PM, Simon Peyton-Jones
wrote:
> Pedro: did you miss something?
>
> ** **
>
> This is breaking my build.
>
> ** **
>
> I have your last patc
Pedro: did you miss something?
This is breaking my build.
I have your last patch 12ba4321d34d646cf9040ad12810c4257d26ade9
Simon
url = http://darcs.haskell.org/libraries/time.git/
libraries/time/Data/Time/Calendar/Days.hs:30:9:
`typeOf' is not a (visible) method of class `Typeabl
Hi Ashley,
Just to remind you of the patch to time I've previously sent you. Whenever
you can apply it,
we can remove the "temporary fix" patch on the GHC copy of the repo.
Thanks,
Pedro
On Wed, Nov 28, 2012 at 3:05 PM, José Pedro Magalhães wrote:
> Hi Ashley,
>
> I'm attaching a patch to the
Hi Roman,
Just to remind you of the patch to vector I've previously sent you.
Whenever you can apply it,
we can remove the "temporary fix" patch on the GHC copy of the repo.
Thanks,
Pedro
On Wed, Nov 28, 2012 at 3:03 PM, José Pedro Magalhães wrote:
> Hi Roman,
>
> I'm attaching a patch to the
Yes, same for time. I've contacted the maintainers a while ago, and will do
so
again today.
Cheers,
Pedro
On Tue, Feb 12, 2013 at 11:07 AM, Simon Peyton-Jones
wrote:
> Hang on... vector has an upstream repo; see
> http://hackage.haskell.org/trac/ghc/wiki/Repositories
> and in particular the "Up
On 12/02/13 03:17, Johan Tibell wrote:
Hi Nicolas!
I tried to reproduce the difference between 7.0.4 and 7.6.2 on the
exp3_8, wheel-sieve1, and primes and couldn't get the same percent
difference as you. We need to reconcile these differences somehow. Lets
start with more exact machine specs. I
Hang on... vector has an upstream repo; see
http://hackage.haskell.org/trac/ghc/wiki/Repositories
and in particular the "Upstream repo?" bullet.
So we may need to do more than push to the mirror?
Simon
| -Original Message-
| From: ghc-commits-boun...@haskell.org [mailto:ghc-commits-
| bo
Seconded. Well done guys.
Cheers,
Simon
On 12/02/13 08:46, Simon Peyton-Jones wrote:
Andreas, Kazu, Johan
That is a truly monumental sequence of patches! Thank you all for
working so hard on making GHC better.
Better together! Onward and upward.
Simon
*From:*ghc-devs-boun...@haske
Andreas, Kazu, Johan
That is a truly monumental sequence of patches! Thank you all for working so
hard on making GHC better.
Better together! Onward and upward.
Simon
From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org] On
Behalf Of Johan Tibell
Sent: 12 February 2013 07:
- Currently, the internals of GHC assign types like "0" the kind
GHC.TypeLits.Nat, so Nat and Symbol *must* remain in the GHC.TypeLits module.
Unfortunately, the plumbing around GHC.TypeLits.Unsafe want Nat and Symbol to
be defined in GHC.TypeLits.Internals. So, I created a TypeLits.hs-boot file
On 11/02/13 23:03, Johan Tibell wrote:
Hi,
I think reducing breakages is not necessarily, and maybe not even
primarily, an issue of releases. It's more about realizing that the cost
of breaking things (e.g. changing library APIs) has gone up as the
Haskell community and ecosystem has grown. We n
Richard
Thanks. I'm content for you, Iavor, Stephanie, Conor, Adam, Pedro, Dimitrios
(etc) to figure out what to do here, and merge to HEAD.
Simon
| -Original Message-
| From: ghc-commits-boun...@haskell.org [mailto:ghc-commits-
| boun...@haskell.org] On Behalf Of Richard Eisenberg
|
Thanks for fixing.
You removed lookupType_mod from TrieMap. It was defined and exported but not
called. How did validate spot that? I'm sure there are quite a few such
functions in GHC.
Simon
| -Original Message-
| From: ghc-commits-boun...@haskell.org [mailto:ghc-commits-
| boun...
33 matches
Mail list logo
