On 04/05/2010, at 13:30, Luke Palmer wrote:
On Mon, May 3, 2010 at 11:07 AM, Kyle Murphy orc...@gmail.com wrote:
The fact that it doesn't is proof enough that there's a problem
with it even if that problem is simply that the types you're using aren't
exactly correct. Further, I'd argue that
On 03/05/2010, at 22:04, Johan Tibell wrote:
On Mon, May 3, 2010 at 11:12 AM, Simon Peyton-Jones simo...@microsoft.com
wrote:
| Does this mean DPH is ready for abuse?
|
| The wiki page sounds pretty tentative, but it looks like it's been awhile
| since it's been updated.
|
|
On 04/05/2010, at 09:21, Christian Höner zu Siederdissen wrote:
Hi,
on that topic, consider this (rather trivial) array:
a = array (1,10) [ (i,f i) | i -[1..10]] where
f 1 = 1
f 2 = 1
f i = a!(i-1) + a!(i-2)
(aah, school ;)
Right now, I am abusing vector in ST by doing this:
On 03/05/2010, at 06:02, Jaco van Iterson wrote:
I was just wondering what methods are best to design/model the software in
bigger projects when you are planning to use Haskell.
Is there no difference compared to other languages? Are there any Haskell
tools?
In addition to what Don said,
On 24/04/2010, at 22:42, Roman Leshchinskiy wrote:
On 24/04/2010, at 22:06, Barak A. Pearlmutter wrote:
I was thinking of this:
data T = T Double deriving ( Eq, Ord )
... GHC basically produces
instance Ord T where
compare (T x) (T y) = compare x y
t u = compare t u == LT
On 24/04/2010, at 07:29, Don Stewart wrote:
Oh, the Platform has very strict standards about APIs,
What is an API? The package versioning policy only seems to talk about types
and function signatures. John's old-locale example shows that this is not
enough.
Would it perhaps make sense for at
On 24/04/2010, at 18:06, Ivan Lazar Miljenovic wrote:
Roman Leshchinskiy r...@cse.unsw.edu.au writes:
On 24/04/2010, at 07:29, Don Stewart wrote:
Oh, the Platform has very strict standards about APIs,
What is an API? The package versioning policy only seems to talk about
types
On 24/04/2010, at 18:54, Ivan Lazar Miljenovic wrote:
Roman Leshchinskiy r...@cse.unsw.edu.au writes:
On 24/04/2010, at 18:06, Ivan Lazar Miljenovic wrote:
I would think that the API is all the
functions/classes/datatypes/instances/etc. exported from the library in
combination
On 24/04/2010, at 19:56, Barak A. Pearlmutter wrote:
And yet a lot of generic code is written in terms of compare.
That's can be an advantage, because often that code *should* blow up
when it gets a NaN. E.g., sorting a list of Floats which includes a
NaN.
However, often you will know
On 24/04/2010, at 22:06, Barak A. Pearlmutter wrote:
Currently the standard prelude has default definition:
...
compare x y
| x == y= EQ
| x = y= LT
| otherwise = GT
I'd suggest
[...]
compare x y
| x y = LT
| x
On 23/04/2010, at 01:34, Barak A. Pearlmutter wrote:
I'd suggest that compare involving a NaN should yield
error violation of the law of the excluded middle
Please think of the poor guys trying to write high-performance code in Haskell!
Roman
On 24/04/2010, at 07:15, Barak A. Pearlmutter wrote:
In all seriousness, I think it is reasonable when isNaN x for
x C
x == C
x C
C x
C == x
C x
to all be False, for all floats C, even C=x, as a sort of efficient
weak Bool bottom. This is what the FP hardware does --- so it is very
In package vector, primitive vectors (the ones that Data.Vector.Unboxed is
built on top of) are represented as follows (ByteArray and friends are wrappers
for various GHC primitives provided by package primitive):
data Vector a = Vector Int -- offset into the ByteArray
On 18/04/2010, at 08:07, Ben wrote:
On Fri, Apr 16, 2010 at 11:19 PM, Roman Leshchinskiy r...@cse.unsw.edu.au
wrote:
That said, it would be quite possible to provide something like the
following:
fold_inplace :: Vector v a = (v a - b - v a) - v a - [b] - v a
as far as i understand
On 17/04/2010, at 13:32, Ben wrote:
module Main where
import qualified Data.Vector.Generic as V
import qualified Data.Vector.Unboxed as UV
type Vec = UV.Vector Double
axpy :: Double - Vec - Vec - Vec
axpy a x y = V.zipWith (+) (V.map (* a) x) y
sumVecs :: [(Double, Vec)] - Vec
On 17/04/2010, at 11:00, Conal Elliott wrote:
I'm unsure now, but I think I tried making Basis a data type (not syn) and
ran into the problem I mentioned above. The Basis *synonyms* also have
HasTrie instances, which is crucially important. If we switch to (injective)
data types, then we
On 16/04/2010, at 18:06, Mathieu Boespflug wrote:
shortestPath :: [(Int, Int, Int)] - UArray Int Int
shortestPath g = runSTUArray $ do
let mnew = newArray (0, SIZE * SIZE) 1
mread arr i j = unsafeRead arr (i * SIZE + j)
mwrite arr i j x = unsafeWrite arr (i * SIZE + j) x
On 15/04/2010, at 02:55, John Lato wrote:
The problem isn't with criterion itself, but with vector-algorithms.
The vector library relies heavily on type families, which have dodgy
support in ghc-6.10.
As a matter of fact, this particular problem is easy to fix by adding a couple
of type
On 14/04/2010, at 09:05, Xiao-Yong Jin wrote:
I want to use 'mapM' on Data.Vector.Vector, but it looks
like the only 'mapM' defined is in
Data.Vector.Fusion.Stream.Monadic. I'm able to use 'stream'
and 'liftStream' to convert a 'Vector' to a monadic stream,
on which I can use 'mapM'. But I
On 15/04/2010, at 00:30, Brent Yorgey wrote:
On Wed, Apr 14, 2010 at 09:51:52AM +0100, Stephen Tetley wrote:
On 14 April 2010 03:48, Brent Yorgey byor...@seas.upenn.edu wrote:
Can someone more well-versed in the intricacies of type checking with
associated types explain this? Or is this a
On 08/04/2010, at 01:38, Henning Thielemann wrote:
On Apr 6, 2010, at 5:30 PM, Roman Leshchinskiy wrote:
In fact, the only safe-ish use for it I have found is to use
Storable-related functions in ST, hoping that the instances don't actually
use any real IO functionality. Arguably
On 07/04/2010, at 07:33, Nicolas Frisby wrote:
I haven't been able to find it via Google or Haddock. An old message
suggests is was just a matter of exceptions?
I don't think that's correct. You can implement unsafePerformIO in terms
unsafeIOToST:
unsafePerformIO :: IO a - a
unsafePerformIO
On 04/04/2010, at 05:33, Chad Scherrer wrote:
Roman Leshchinskiy rl at cse.unsw.edu.au writes:
Ah. I missed that. Then your best bet is probably
replicate n action = munstream v $ Fusion.Stream.Monadic.generateM n (const
action)
$ new n
It's uglier
On 02/04/2010, at 12:16, Don Stewart wrote:
Chad.Scherrer:
Hi,
I'd like to be able to do replicateM, but over a vector instead of a list.
Right now I'm doing this:
The operation you are looking for is called newWith. It probably should be
called replicate.
Roman? Can we generate frozen
On 02/04/2010, at 13:01, Don Stewart wrote:
rl:
replicate :: Int - a - New a
replicate n x = Generic.New.unstream (Fusion.Stream.replicate n x)
and then either
Mutable.run (replicate n x)
to get a mutable vector or
new (replicate n x)
Hmm, but here 'a' is pure. I don't
On 31/03/2010, at 18:14, Achim Schneider wrote:
We have a lot of useful interfaces (e.g. ListLike, Edison), but they
don't seem to enjoy wide-spread popularity.
Perhaps that's an indication that we need different interfaces? IMO, huge
classes which generalise every useful function we can
I'm wondering... Since the DPH libraries are shipped with GHC by default are we
allowed to use them for the shootout?
Roman
On 30/03/2010, at 19:25, Simon Marlow wrote:
The shootout (sorry, Computer Language Benchmarks Game) recently updated to
GHC 6.12.1, and many of the results got worse.
On 29/03/2010, at 02:27, Lennart Augustsson wrote:
Does anything change if you swap the first two rhss?
No, not as far as I can tell.
On Sun, Mar 28, 2010 at 1:28 AM, Roman Leshchinskiy r...@cse.unsw.edu.au
wrote:
On 28/03/2010, at 09:47, Lennart Augustsson wrote:
It's important
On 28/03/2010, at 01:36, Jan-Willem Maessen wrote:
It's worth pointing out that there's a bit of bang-pattern mysticism going on
in this conversation (which has not been uncommon of late!). A non-buggy
strictness analyzer should expose the strictness of these functions without
difficulty.
On 27/03/2010, at 05:27, John Meacham wrote:
Here are jhc's timings for the same programs on my machine. gcc and ghc
both used -O3 and jhc had its full standard optimizations turned on.
jhc:
./hs.out 5.12s user 0.07s system 96% cpu 5.380 total
gcc:
./a.out 5.58s user 0.00s system 97%
On 28/03/2010, at 11:07, John Meacham wrote:
I have not thoroughly checked it, but I think there are a couple things
going on here:
It could also be worthwhile to float out (i*i + j*j) in rangeK instead of
computing it in every loop iteration. Neither ghc nor gcc can do this; if jhc
can then
On 28/03/2010, at 09:47, Lennart Augustsson wrote:
It's important to switch from mod to rem. This can be done by a
simple abstract interpretation.
Also, changing the definition of rem from
a `rem` b
| b == 0 = divZeroError
| a == minBound b == (-1) =
On 19/03/2010, at 08:48, Daniel Fischer wrote:
Am Donnerstag 18 März 2010 21:57:34 schrieb Daniel Fischer:
Contrary to my expectations, however, using unboxed arrays is slower
than straight arrays (in my tests).
However, a few {-# SPECIALISE #-} pragmas set the record straight.
This is
On 17/03/2010, at 03:16, Louis Wasserman wrote:
I'm not willing to do this sort of typeclass wrapper thing, primarily because
nothing else in containers does -- even though we might have a Mapping type
class that handles both IntMap and Map, we don't.
I'm inclined to let that design
On 06/03/2010, at 03:10, stefan kersten wrote:
i'm still curious, though, why my three versions of direct convolution perform
so differently (see attached file). in particular, i somehow expected conv_3
to
be the slowest and conv_2 to perform similar to conv_1. any ideas? i haven't
had
a
On 08/03/2010, at 12:17, Alexander Solla wrote:
GHC even optimizes it to:
fib = fib
Sounds like an implementation bug, not an infinite dimensional vector space
bug. My guess is that strictness is getting in the way, and forcing what
would be a lazy call to fib in the corresponding
On 05/03/2010, at 04:34, stefan kersten wrote:
i've been hunting down some performance problems in DSP code using vector and
the single most important transformation seems to be throwing in INLINE
pragmas
for any function that uses vector combinators and is to be called from
higher-level
On 17/02/2010, at 18:37, Isaac Dupree wrote:
LLVM and GCC are open-source projects that are improving over time... is
there any particular reason we expect GCC to have poor numeric performance
forever?
Past experience :-) GCC has been around for a while and if it doesn't optimise
numeric
Hi everyone,
I am pleased to announce the release of version 0.5 of package vector, a
high-performance Haskell array library with a powerful loop fusion framework.
The main highlights compared to previous versions are:
* DPH-style unboxed vectors (in Data.Vector.Unboxed) which use associated
On 12/02/2010, at 23:28, Dan Doel wrote:
On Thursday 11 February 2010 8:54:15 pm Dan Doel wrote:
On Thursday 11 February 2010 12:43:10 pm stefan kersten wrote:
On 10.02.10 19:03, Bryan O'Sullivan wrote:
I'm thinking of switching the statistics library over to using vector.
that would be
On 12/02/2010, at 12:39, Don Stewart wrote:
bos:
I'm thinking of switching the statistics library over to using vector.
uvector
is pretty bit-rotted in comparison to vector at this point, and it's really
seeing no development, while vector is The Shiny Future. Roman, would you
call
the
On 12/02/2010, at 12:40, Don Stewart wrote:
rl:
On 11/02/2010, at 05:03, Bryan O'Sullivan wrote:
I'm thinking of switching the statistics library over to using vector.
uvector is pretty bit-rotted in comparison to vector at this point, and
it's really seeing no development, while vector
On 12/02/2010, at 12:54, Dan Doel wrote:
I also notice that vector seems to have discarded the idea of
Vec (A * B) = Vec A * Vec B
Oh no, it hasn't. In contrast to uvector/DPH, which use a custom strict tuple
type for rather outdated reasons, vector uses normal tuples. For instance,
On 12/02/2010, at 13:49, Don Stewart wrote:
rl:
On 12/02/2010, at 12:39, Don Stewart wrote:
bos:
I'm thinking of switching the statistics library over to using vector.
uvector
is pretty bit-rotted in comparison to vector at this point, and it's really
seeing no development, while vector
On 11/02/2010, at 05:03, Bryan O'Sullivan wrote:
I'm thinking of switching the statistics library over to using vector.
uvector is pretty bit-rotted in comparison to vector at this point, and it's
really seeing no development, while vector is The Shiny Future. Roman, would
you call the
On 18/12/2009, at 00:37, Stephen Lavelle wrote:
Given
class MyClass k where
type AssociatedType k :: *
Is there a way of requiring AssociatedType be of class Eq, say?
This works with -XFlexibleContexts:
class Eq (AssociatedType k) = MyClass k where
type AssociatedType k :: *
Roman
On 15/12/2009, at 06:53, Brad Larsen wrote:
On another note, does this (or perhaps better phrased, will this) bug
also affect Data Parallel Haskell?
Luckily, no. DPH represents arrays of user-defined types by unboxed arrays
(that's essentially what the vectoriser does). It does use boxed
On 28/11/2009, at 07:45, Henning Thielemann wrote:
Is there also a darcs repository?
Yes, http://www.cse.unsw.edu.au/~rl/code/darcs/NoSlow.
Roman
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
I'm pleased to announce NoSlow, a nascent benchmark suite for various array
(and list) libraries with particular emphasis on finding out how well they fuse
things. At the moment, it knows about
* standard lists
* primitive DPH arrays (dph-prim-seq)
* uvector
* vector
* storablevector
On 18/11/2009, at 21:10, Simon Peyton-Jones wrote:
Yes I think it can, although you are right to point out that I said nothing
about type inference. One minor thing is that you've misunderstood the
proposal a bit. It ONLY springs into action when there's a dot. So you'd
have to write
Simon, have you given any thought to how this interacts with type system
extensions, in particular with GADTs and type families? The proposal relies on
being able to find the type of a term but it's not entirely clear to me what
that means. Here is an example:
foo :: F Int - Int
foo :: Int -
On 16/11/2009, at 22:46, Alexey Khudyakov wrote:
Problems begin when you need non-contiguous block. Easiest way to so
is indexing.
FWIW, this operation is called backpermute and is probably exported as bpermute
in uvector.
Roman
___
Haskell-Cafe
On 13/11/2009, at 18:04, Bryan O'Sullivan wrote:
main = do
args - getArgs
forM_ args $ \a - do
s - B.readFile a
let t = T.decodeUtf8 s
print (T.length t)
The streamUtf8 function looks roughly like this:
streamUtf8 :: OnDecodeError - ByteString - Stream Char
streamUtf8 onErr bs
On 05/11/2009, at 04:01, Bulat Ziganshin wrote:
oh, can we stop saying about shootout? if you want to see speed of
pure haskell code, look at papers about fast arrays/strings - their
authors have measured that lazy lists are hundreds times slower than
idiomatic C code. is use of lazy lists
On 04/11/2009, at 13:23, Daniel Peebles wrote:
In the presence of fusion (as is the case in uvector), it's hard to
give meaningful time complexities for operations as they depend on
what operations they are paired with. We need to think of a better way
to express this behavior in the
On 04/11/2009, at 13:12, brian wrote:
indexU :: UA e = UArr e - Int - e
O(n). indexU extracts an element out of an immutable unboxed array.
This is a typo (unless Don inserted a nop loop into the original DPH
code).
Roman
___
Haskell-Cafe
On 04/11/2009, at 13:35, wren ng thornton wrote:
Roman Leshchinskiy wrote:
On 04/11/2009, at 13:23, Daniel Peebles wrote:
In the presence of fusion (as is the case in uvector), it's hard to
give meaningful time complexities for operations as they depend on
what operations they are paired
On 04/11/2009, at 14:07, Gregory Crosswhite wrote:
Actually, it's not a typo. If you look at the source, what you'll
see is
indexU arr n = indexS (streamU arr) n
I suspect it gets rewritten back to the O(1) version somewhere after
is has had a chance to fuse. If not, then it's a bug. In
On 04/11/2009, at 14:38, Philippos Apolinarius wrote:
And here comes the reason for writing this article. In the previous
version of the Gauss elimination algorithm, I have imported
Data.Array.IO. I also wrote a version of the program that imports
Data.Array.ST. The problem is that I
On 12/05/2009, at 14:45, Reiner Pope wrote:
The Stream datatype seems to be much better suited to representing
loops than the list datatype is. So, instead of programming with the
lists, why don't we just use the Stream datatype directly?
I think the main reason is that streams don't store
On 27/03/2009, at 18:32, Don Stewart wrote:
I don't think this is still the case.
Roman, do you remember?
Hmm, not really. I recall that there was some sort of problem which I
didn't have time to investigate then but it's been so long...
Roman
On 07/03/2009, at 09:26, Claus Reinke wrote:
My preferred spec would be roughly
{-# NOINLINE f #-}
as now
{-# INLINE f #-}works as now, which is for non-recursive f only
(might in future
be taken as go-ahead for analysis-based recursion unfolding)
{-# INLINE f PEEL n #-}
inline
On 09/03/2009, at 11:47, Claus Reinke wrote:
Btw, have any of the Haskell array optimization researchers
considered fixpoints yet?
This, for instance, is a very nice paper:
http://www.pllab.riec.tohoku.ac.jp/~ohori/research/OhoriSasanoPOPL07.pdf
However, in the context of high-performance
On 01/03/2009, at 04:49, Don Stewart wrote:
So now, since we've gone to such effort to produce a tiny loop like,
this,
can't we unroll it just a little? Sadly, my attempts to get GCC to
trigger
its loop unroller on this guy haven't succeeded. -funroll-loops and
-funroll-all-loops doesn't
On 30/11/2008, at 11:36, Don Stewart wrote:
Should mutable arrays have list-like APIs? All the usual operations,
just in-place and destructive where appropriate?
I don't know. To be honest, I don't think that the term mutable
array describes a single data structure. For instance, one of the
On 29/11/2008, at 11:49, Claus Reinke wrote:
Yes, it is very difficult. A sensible API for a standard array
library is something that needs more research. FWIW, I don't know
of any other language that has what I'd like to see in Haskell. C+
+ probably comes closest but they have it easy
On 30/11/2008, at 02:43, Brad Larsen wrote:
On Fri, 28 Nov 2008 19:00:38 -0500, Roman Leshchinskiy [EMAIL PROTECTED]
wrote:
On 29/11/2008, at 10:47, Claus Reinke wrote:
[...]
And would it be difficult for you all to agree on a standard API, to
make switching between the alternatives easy
On 30/11/2008, at 10:43, Sebastian Sylvan wrote:
This, on the other hand does not use more than one core:
-- compiler command line (from shootout code): ghc --make -fcpr-off -
threaded -fdph-par -package dph-base -Odph -XPArr parr2.hs
-- execution as before
main = print $ [: True | n - [:
On 30/11/2008, at 08:32, Andrew Coppin wrote:
Henning Thielemann wrote:
I suspect that this particular function is less useful than you
think.
It safes one allocation and might be faster since it uses less cache,
but on the other hand, it cannot be fused.
Hmm, I haven't seen your original
On 28/11/2008, at 20:04, Simon Marlow wrote:
So we have two vector libraries, vector and uvector, which have a
lot in common - they are both single-dimension array types that
support unboxed instances and have list-like operations with
fusion. They ought to be unified, really.
Yes. This
On 29/11/2008, at 08:43, Andrew Coppin wrote:
What *I* propose is that somebody [you see what I did there?] should
sit down, take stock of all the multitudes of array libraries, what
features they have, what obvious features they're missing, and think
up a good API from scratch. Once we
On 29/11/2008, at 10:47, Claus Reinke wrote:
But I don't want Perl, I want a well designed language and well
designed libraries.
I think it's find to let libraries proliferate, but at some point you
also need to step back and abstract.
-- Lennart
Especially so if the free marketeers claim
Hi again,
a big thank you to all the people who offered us machines. I think we
should be fine now. World domination is just around the corner!
Roman
On 27/11/2008, at 18:45, Roman Leshchinskiy wrote:
Hi all,
we, the DPH team, are at the moment in the very unfortunate
situation
Hi all,
we, the DPH team, are at the moment in the very unfortunate situation
of not having a proper machine for running our benchmarks on. Could a
kind soul maybe give us (i.e., me) access to a quadcore or 2xquadcore
x86 Linux or OS X machine? I only need to build ghc on it and run
On 15/10/2008, at 20:41, Malcolm Wallace wrote:
Phil proposes that, although retaining the instances of Enum for Float
and Double, we simplify the definitions of the numericEnumFrom family:
numericEnumFromThenTo :: (Fractional a, Ord a) = a - a - a -
[a]
numericEnumFrom =
On 16/10/2008, at 21:34, Simon Peyton-Jones wrote:
For strict *constructors*, on the other hand, we *do* guarantee to
evaluate the argument before building the constructor. We generate
a wrapper thus
wC = \ab. case a of { a' - C a' b }
(Remember 'case' always evaluates in Core.) So
On 23/09/2008, at 14:59, Roman Leshchinskiy wrote:
dotp :: [:Int:] - [:Int:] - Int
dotp v w = I.sumP [: (I.*) x y | x - v, y - w :]
The way the vectoriser works at the moment, it will repeat the array
w (lengthP v) times, i.e., create an array of length (lengthP v *
lengthP w
Hi Austin,
first of all, thanks a lot for taking the time to report your results!
On 23/09/2008, at 11:48, Austin Seipp wrote:
* The vectorise pass boosts compilation times *a lot*. I don't think
this is exactly unwarrented since it seems like a pretty complicated
transformation, but while
On 28/08/2008, at 19:27, Simon Peyton-Jones wrote:
Duncan, I'm not following every detail here, but it's clear that you
have some clear mental infrastructure in your head that informs and
underpins the way Cabal is. Cabal takes the view that..., has
principles, and is clearly partitioned
On 28/08/2008, at 21:10, Ian Lynagh wrote:
On Thu, Aug 28, 2008 at 10:27:22AM +0100, Simon Peyton-Jones wrote:
PS: concerning your last point, about separating the Simple build
system, that might indeed be good. Indeed, the GHC plan described
here
On 28/08/2008, at 23:59, Simon Marlow wrote:
The important thing about Cabal's way of specifying dependencies is
that they can be made sound with not much difficulty. If I say that
my package depends on base==3.0 and network==1.0, then I can
guarantee that as long as those dependencies
On 29/08/2008, at 03:11, Ian Lynagh wrote:
On Fri, Aug 29, 2008 at 12:57:59AM +1000, Roman Leshchinskiy wrote:
On 28/08/2008, at 21:10, Ian Lynagh wrote:
On Thu, Aug 28, 2008 at 10:27:22AM +0100, Simon Peyton-Jones wrote:
PS: concerning your last point, about separating the Simple build
On 29/08/2008, at 01:31, Simon Marlow wrote:
Roman Leshchinskiy wrote:
On 28/08/2008, at 23:59, Simon Marlow wrote:
The important thing about Cabal's way of specifying dependencies
is that they can be made sound with not much difficulty. If I say
that my package depends on base==3.0
On 16/08/2008, at 00:12, Ian Lynagh wrote:
On Fri, Aug 15, 2008 at 11:12:20AM +1000, Manuel M T Chakravarty
wrote:
Moreover, as I wrote a few times before, some reasons for switching
in
the first place are invalidated by not having the core libraries in
git, too. For example, one
On 14/08/2008, at 06:32, Duncan Coutts wrote:
On Wed, 2008-08-13 at 22:47 +1000, Roman Leshchinskiy wrote:
Again, I'm not arguing against a build system written in Haskell. I'd
just like it to be completely separated from Haskell's packaging
system. In particular, polluting a package
On 14/08/2008, at 18:01, Simon Marlow wrote:
Roman Leshchinskiy wrote:
But that is precisely my (other) point. A lot of that work is
really unnecessary and could be done by Cabal since it only or
mostly depends on the package information. Instead, it is
implemented somewhere
On 13/08/2008, at 17:47, Simon Marlow wrote:
Roman Leshchinskiy wrote:
On 12/08/2008, at 20:11, Simon Marlow wrote:
- Extract the code from Cabal that generates Makefiles, and treat
it as
part of the GHC build system. Rather than generating a Makefile
complete with build rules, we
On 13/08/2008, at 20:34, Simon Marlow wrote:
Roman Leshchinskiy wrote:
Of course there should be a standard build system for simple
packages. It could be part of Cabal or a separate tool (for which
Cabal could, again, act as a preprocessor).
GHC is a special case: we already need a build
On 10/08/2008, at 14:40, Manuel M T Chakravarty wrote:
Personally, I am more than happy to stay with darcs, too, but my
understanding was that at least the Simons decided that we are going
to move from darcs to git. All I am saying is that whatever vcs ghc
uses, you need to be able to
On 10/08/2008, at 05:38, Don Stewart wrote:
Instead, if we just use ubiquitous, common tools -- like git -- for
everything, we minimise the pain for people, and sit firmly in the
mainstream of open source.
While I agree with this in general, I'm not sure it really applies to
vcs (especially
On 30/07/2008, at 23:46, Simon Marlow wrote:
We can talk about the general issues on IRC. But I thought I'd
answer a few of the specific questions quickly:
Thanks, Simon!
Roman Leschinskiy wrote:
I don't think I understand how GHC itself is built any longer,
either. What does
Jules Bean wrote:
It would also be helpful to have someone explain why we have:
Ptr a
ByteString
IOUArray
IOCArray
Data.Storable.StorableArray
UArr
Of course, I know the answers to some of those questions, ByteString is
obviously less polymorphic than all the others there, and Ptr a doesn't
stefan kersten wrote:
(2) personally i much prefer the list-like interface provided by the
stream-fusion powered libraries (ndp, uvector, vector). can't the
stream-fusion framework and correspondingly the vector interface be
separated from the memory representation, provided a particular
Levi Stephen wrote:
On Sun, Jul 13, 2008 at 12:31 AM, Roman Leshchinskiy
[EMAIL PROTECTED] wrote:
Hi all,
the vector library will eventually provide fast, Int-indexed arrays with a
powerful fusion framework. It's very immature at the moment (I haven't
tested most of the code) and implements
Hi all,
the vector library will eventually provide fast, Int-indexed arrays with
a powerful fusion framework. It's very immature at the moment (I haven't
tested most of the code) and implements just a few combinators but I
thought releasing early wouldn't hurt. Use at your own risk and
Sebastian Sylvan wrote:
Is there any more (easily-digested, like a paper) information available
about this? Specifically what things can happen in-place, and future
extensions...
Apart from the stream fusion papers, unfortunately no, it's all very
much work in progress. Basically, at the
Simon Peyton-Jones wrote:
Ah -- Roman you mean you want to add a phase-ordering constraint at some time
*other* than when you declare one or other of the phases. Are you sure this is
important?
Fairly. I've explained why in a follow-up to Max's message.
Also, why do you want phase
Max Bolingbroke wrote:
Hi Roman,
Three things. Firstly, what would lenient ordering be useful for? You
probably had a specific use case in mind?
I suspect that when you have multiple plugins all specifying
constraints on the phase ordering independently it is possible to end
up in a situation
Max Bolingbroke wrote:
If you don't need a dependency and it can be ignored anyway, why would you
want to specify it in the first place? I just can't quite imagine a
situation in which I would use this.
I think it makes sense because many of the inter-pass dependencies we
have in the GHC
Hi Max,
sorry for replying so late, I've completely forgotten about this.
I would be interested in feedback on the design before the
implementation is complete and in the wild. I'm especially interested
in hearing if you believe that loss of support for numeric phase
numbers 2 is a problem,
101 - 200 of 245 matches
Mail list logo
