Re: [Haskell-cafe] haskell version of fractal benchmark

[Donald Bruce Stewart]

dons:
> sic:
> > * Andrew Coppin <[EMAIL PROTECTED]> [070608 02:45]:
> > >Bayley, Alistair wrote:
> > > 
> > > [[1]mailto:[EMAIL PROTECTED] On Behalf Of Andrew Coppin
> > > 
> > > Donald Bruce Stewart wrote:
> > > 
> > > Some things to remember using Doubles:
> > > 
> > > * {-# OPTIONS -fexcess-precision #-}
> > > * -fvia-C
> > > * -fbang-patterns
> > > * -optc-O2 -optc-mfpmath=sse -optc-msse2
> > > * -optc-march=pentium4
> > > 
> > > 1. What do all those things do?
> > > 2. Is the effect actually that large?
> > > 
> > > Large? Depends what you mean by large, but adding a few flags to get
> > > just a 10-20% speedup isn't to be ignored:
> > > 
> > >Sure - if it really is 10-20%. (And not, say, 0.001 - 0.002%.)
> > 
> > A single data point for all of this, I have a program that calculates:
> > 
> > P^1_i = S_i/sum_k S_k
> > P^m_i = sum_{k!=i} P^1_k*P^m-1_i(S_~k)
> > 
> > Here's timings for the different options:
> > 
> > options  run timecompile time
> > none  46.401   3.136
> > -O 5.033   4.906
> > -O24.967   6.755
> > -O2 -fexcess-precision 3.710   6.396
> > all listed options 3.602   6.344

My apologies. Misread that last line. 

/me drinks more tea.

-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] haskell version of fractal benchmark

[Donald Bruce Stewart]

sic:
> * Andrew Coppin <[EMAIL PROTECTED]> [070608 02:45]:
> >Bayley, Alistair wrote:
> > 
> > [[1]mailto:[EMAIL PROTECTED] On Behalf Of Andrew Coppin
> > 
> > Donald Bruce Stewart wrote:
> > 
> > Some things to remember using Doubles:
> > 
> > * {-# OPTIONS -fexcess-precision #-}
> > * -fvia-C
> > * -fbang-patterns
> > * -optc-O2 -optc-mfpmath=sse -optc-msse2
> > * -optc-march=pentium4
> > 
> > 1. What do all those things do?
> > 2. Is the effect actually that large?
> > 
> > Large? Depends what you mean by large, but adding a few flags to get
> > just a 10-20% speedup isn't to be ignored:
> > 
> >Sure - if it really is 10-20%. (And not, say, 0.001 - 0.002%.)
> 
> A single data point for all of this, I have a program that calculates:
> 
> P^1_i = S_i/sum_k S_k
> P^m_i = sum_{k!=i} P^1_k*P^m-1_i(S_~k)
> 
> Here's timings for the different options:
> 
> options  run timecompile time
> none  46.401   3.136
> -O 5.033   4.906
> -O24.967   6.755
> -O2 -fexcess-precision 3.710   6.396
> all listed options 3.602   6.344
> 

Due to a (now fixed in 6.6.1 I think) bug in GHC 6.6, -fexcess-precision
*must* be inserted in a pragma. Did you do that?

{-# OPTIONS -fexcess-precision #-}

See the bug report here,

http://hackage.haskell.org/trac/ghc/ticket/1138

-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] haskell version of fractal benchmark

[Scott Cruzen]

* Andrew Coppin <[EMAIL PROTECTED]> [070608 02:45]:
>Bayley, Alistair wrote:
> 
> [[1]mailto:[EMAIL PROTECTED] On Behalf Of Andrew Coppin
> 
> Donald Bruce Stewart wrote:
> 
> Some things to remember using Doubles:
> 
> * {-# OPTIONS -fexcess-precision #-}
> * -fvia-C
> * -fbang-patterns
> * -optc-O2 -optc-mfpmath=sse -optc-msse2
> * -optc-march=pentium4
> 
> 1. What do all those things do?
> 2. Is the effect actually that large?
> 
> Large? Depends what you mean by large, but adding a few flags to get
> just a 10-20% speedup isn't to be ignored:
> 
>Sure - if it really is 10-20%. (And not, say, 0.001 - 0.002%.)

A single data point for all of this, I have a program that calculates:

P^1_i = S_i/sum_k S_k
P^m_i = sum_{k!=i} P^1_k*P^m-1_i(S_~k)

Here's timings for the different options:

options  run timecompile time
none  46.401   3.136
-O 5.033   4.906
-O24.967   6.755
-O2 -fexcess-precision 3.710   6.396
all listed options 3.602   6.344

Results with -fexcess-precision are very insignificantly different
(1.0 e-7).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Data polymophism

[Tomasz Zielonka]

On Fri, Jun 08, 2007 at 07:49:20PM +0200, Tomasz Zielonka wrote:
> On Fri, Jun 08, 2007 at 05:23:23PM +0200, Phlex wrote:
> > But i don't seem to find a way to get out of this DbIndex type to 
> > actually work on the enclosed index.
> > 
> > for instance, this doesn't work:
> > liftDbIndex (DbIndex index) fun = DbIndex (fun index)
> 
> The compiler probably can't infer higher-ranker types, so you have to
> write you type signature explicitly. Try:
> 
> liftDbIndex :: Index_ i2 a2 k2 =>
>(forall a1 k1 i1. Index_ i1 a1 k1 => i1 -> i2) -> DbIndex 
> -> DbIndex

Now I think that this type signature will be too restrictive. Ideally, i2, a2 
and
k2 would be existentially quantified, like

liftDbIndex :: (forall a1 k1 i1. Index_ i1 a1 k1 => i1 -> (exists. Index_ 
i2 a2 k2 => i2)) ->
   DbIndex -> DbIndex

AFAIK such type isn't supported by any Haskell compiler, so we have to
use the existential quantification from DbIndex:

liftDbIndex :: (forall a1 k1 i1. Index_ i1 a1 k1 => i1 -> DbIndex) -> 
DbIndex -> DbIndex
liftDbIndex f (DbIndex i) = f i

Best regards
Tomek
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Fast number parsing with strict bytestrings [Was: Re: Seemingly subtle change causes large performance variation]

[Donald Bruce Stewart]

conal:
> 
>Lovely!
>
>Perhaps a stylistic shift would encourage writing this sort
>of elegant, fusion-friendly code.
>-- Generalized version of "interact".  Encapsulates data
>getter & putter.
>genInteract :: IO i -> (o -> IO ()) -> ((i -> o) -> IO
>())
>genInteract get put = \ f -> get >>= put . f

Yes, I think this is a good idea. Perhaps even a small module 
for doing fast folds over lists of lines (abstracting out the
cache/demand/traversal code from solution #3.)

Also, I realise I'd missed another optimisatoin for #3, minimal copying
to do the alignment. Gains another 10%:

process k !i (s:t:ts) | S.last s /= '\n' = process k (add k i s') ts'
  where
(s',r)  = S.breakEnd (=='\n') s
(r',rs) = S.break(=='\n') t
ts' = S.concat [r,r',S.singleton '\n'] : unsafeTail rs : ts

Here, we copy only the smallest amount from the end of the current
chunk, and the start of the next chunk, to do \n aligning. Gets us down
to:

$ time ./G < in
29359
./G < in  0.19s user 0.02s system 96% cpu 0.210 total

And the code:

{-# OPTIONS -fbang-patterns #-}

import Data.Char
import Data.Maybe
import Data.ByteString.Base
import qualified Data.ByteString.Char8  as S
import qualified Data.ByteString.Lazy.Char8 as L

main = do
ss <- L.getContents -- done with IO now.

let (l,ls) = L.break (=='\n') ss

-- don't need count, we're allocating lazily
k  = fst . fromJust . L.readInt . last . L.split ' ' $ l

-- a lazy list of strict chunks
file   = L.toChunks (L.tail ls)

print $ process k 0 file

divisibleBy :: Int -> Int -> Bool
a `divisibleBy` n = a `rem` n == 0

-- -
--
-- Optimised parsing of strict bytestrings representing \n separated numbers
--

--
-- we have the file as a list of cache chunks
-- align them on \n boundaries, and process each chunk separately
-- when the next chunk is demanded, it will be read in.
--
process :: Int -> Int -> [S.ByteString] -> Int
process k i []  = i

process k !i (s:t:ts) | S.last s /= '\n' = process k (add k i s') ts'
  where
(s',r)  = S.breakEnd (=='\n') s
(r',rs) = S.break(=='\n') t
ts' = S.concat [r,r',S.singleton '\n'] : unsafeTail rs : ts

process k i (s: ss) = process k (add k i s) ss

--
-- process a single cache-sized chunk of numbers, \n aligned
--
add :: Int -> Int -> S.ByteString -> Int
add k i s = if S.null s then i else test k i (parse x) xs
  where (x,xs) = uncons s
{-# INLINE add #-}

--
-- process a single line, until \n
--
test :: Int -> Int -> Int -> ByteString -> Int
test k i !n t
| y == '\n' = -- done reading the line, process it:
if n `divisibleBy` k then add k (i+1) ys
 else add k i ys
| otherwise = test k i n' ys
  where (y,ys) = uncons t
n' = parse y + 10 * n

parse c  = ord c - ord '0'

-- fastest way to take the head of a strict bytestring
uncons s = (w2c (unsafeHead s), unsafeTail s)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] LaTeX

[Andrés Sicard Ramírez]

On 6/8/07, Alfonso Acosta <[EMAIL PROTECTED]> wrote:


> \newcommand{\pp}{+ \hspace{-0.2cm} +}

Why 0.2cm? Wouldn't that depend on the font size?



You are right. It depends on the font size.

using ems as the

hspace size sounds more reasonable.



Yes, we can define \pp in this way, or we can define it as

\newcommand{\pp}{+ \negthinspace +}.

--
Andrés
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] class MonoidBreak?

[Stefan O'Rear]

On Fri, Jun 08, 2007 at 07:24:09AM -0700, Alex Jacobson wrote:
> Dan Piponi wrote:
> >On 6/7/07, Alex Jacobson <[EMAIL PROTECTED]> wrote:
> >>Is there a standard class that looks something like this:
> >>
> >>class (Monoid m) => MonoidBreak m where
> >> mbreak::a->m a->(m a,m a)
> >
> >I think you have some kind of kind issue going on here. If m is a
> >Monoid I'm not sure what m a means. Looks like you're trying to factor
> >elements of monoids in some way. Maybe you mean
> >
> >class (Monoid m) => MonoidBreak m where
> >   mbreak::a->m->(m,m)
> >
> >Though I'm not sure what the relationship between m and a is intended 
> >to be.
> 
> Ok how about this class:
> 
>   class (Monoid m) => MonoidBreak m where
>   mbreak::m->m->m
> 
> And the condition is
> 
>   mappend (mbreak y z) y == z

Consider baz x = mbreak x mempty

now:

baz x `mappend` x = mappend (mbreak x mempty) x = mempty

Thus, baz is a left-inverse operator, and (m, mappend, mempty, baz)
forms a group.

Going the other way using a hypothetical Group class:

instance Group m => MonoidBreak m where
mbreak n p = p `mappend` negate n

satisfies your law.

Stefan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Memoization

[Peter Berry]

On 08/06/07, Peter Berry <[EMAIL PROTECTED]> wrote:

You could generate F and the Memoizable instance using TH or DrIFT or
the like (allowing derivation would be really nice :). Actually F
could be considered a dependent type, so you could define a pretty
much universal instance using TH with that mechanism.


I meant "associated type" of course.

--
Peter Berry <[EMAIL PROTECTED]>
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: type versus data declarations

[Brandon S. Allbery KF8NH]

On Jun 8, 2007, at 16:25 , Emilio Jesús Gallego Arias wrote:

Yeah, in general Haskell types don't carry constraints, however, I  
don't

see the reason that this doesn't work when using type level macros, as


type F a = C a => a


should just be a macro and substitute.


It is.  That's the problem.

Macros can't know anything about the contexts in which they're used.   
In the type system, this translates to implicit "forall" constraints:


> type F' a = forall a. C a => a

The result of this is that a simple use like

> foo :: F a -> F a

expands the macros literally, with the implicit "forall" because the  
macro expansion has to assume it is independent of everything else:


> foo' :: (forall a. C a => a) -> (forall a. C a => a)

This means the two "a"s are independent and can't be unified by the  
typechecker.


In theory I suppose the simple macro expansion could be replaced by  
some type expression which would allow the typechecker to recognize  
that any (F a)s used in a given type can be unified, but I have no  
idea what it would look like.  (Then again, I'm no type hacker.)  And  
I find myself wondering if that would lead to problems when expanding  
complex types.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Problem when class function doesn't mention all type parameters or...

[Daniil Elovkov]

Hi again
So, I keep trying to implement the dsl, I mentioned yesterday. I ran
into a problem which can be illustrated by the following small
example.


class Cl s1 a1 s2 a2 where
   clF :: a1 -> a2


clF doesn't mention s1 and s2, they're used only to restrict types below


data T s a where
   C :: (Cl s1 a1 s2 a2) => T s1 a1 -> T s2 a2



f :: T s a -> a
f (C t) = let v = f t in clF v


This doesn't typecheck with the error
  Could not deduce (Cl s11 a1 s2 a) from the context (Cl s1 a1 s a)
  arising from use of `clF'

Here T depends on s, while the result of f doesn't. What happens is s gets lost.

I'm not sure if the problem is that stated in the subject, really.
But, I wonder how at all ghc should guess about s parameters.

Maybe if f were T s a -> (s,a) where s were never evaluated...
...but no, this


f :: T s a -> (s,a)
f (C t) = let (s,v) = f t in (s,clF v)


also fails to unify those s types.

Can someone sched some light, please?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Memoization

[Peter Berry]

Sorry for digging up such an old thread, but my undergraduate
dissertation is on this topic so I couldn't resist. :)

(Some credit in the following goes to my supervisor, Ulrich Berger.)


Mark Engelberg wrote:
> I'd like to write a memoization utility.  Ideally, it would look
> something like this:
>
> memoize :: (a->b) -> (a->b)


The type you actually want is more like:

memoFix :: ((a -> b) -> a -> b) -> a -> b

which is like the normal fixpoint function (defined only over
functions) except that it adds the memoization magic. The reason being
that you can then memoize recursive calls as well (without having to
figure out how to dive into the function definition and replace
recursive calls with calls to the memoized version).

On 27/05/07, apfelmus <[EMAIL PROTECTED]> wrote:

Note that due to parametricity, any function of this type is necessarily
either id or _|_. In other words, there are only two functions of type

  ∀a∀b. (a->b) -> (a->b)


Of course, this only talks about the value of id, not its behaviour.
fix :: ((a -> b) -> a -> b) -> a -> b = memoFix in the sense that the
values they compute are the same, but practically speaking they are
different since the latter does memoization.


That's because the functions has to work for all types a and b in the
same way, i.e. it may not even inspect how the given types a or b look
like. You need type classes to get a reasonable type for the function
you want

  memoize :: Memoizable a => (a->b) -> (a->b)


Now, how to implement something like this? Of course, one needs a finite
map that stores values b for keys of type a. It turns out that such a
map can be constructed recursively based on the structure of a:

  Map ()b  := b
  Map (Either a a') b  := (Map a b, Map a' b)
  Map (a,a')b  := Map a (Map a' b)

Here,  Map a b  is the type of a finite map from keys a to values b. Its
construction is based on the following laws for functions

() -> b  =~=  b
  (a + a') -> b  =~=  (a -> b) x (a' -> b) -- = case analysis
  (a x a') -> b  =~=  a -> (a' -> b)   -- = currying


class Memoizable a f | a -> f where
   memIso :: (a -> b) :~= f b

where a :~= b represents an isomorphism between two types, and f is
the generalized trie functor indexed on the type a and storing values
of its parameter type (here b). Note that this only works if a is
algebraic (i.e. can be represented as a generalized trie using the
isomorphisms above and a couple more to deal with recursive and higher
kinded types[1]). And it almost goes without saying that you can only
memoize pure functions.

Then memoFix actually has a constrained type, namely:

memoFix :: Memoizable a f => ((a -> b) -> a -> b) -> a -> b

You can then take a recursive function like:

f :: A -> B
f x = ... f y ...

and transform it so it takes its own fixpoint as an argument:

f' :: (A -> B) -> A -> B
f' f x = ... f y ...

and then, if you have an instance

instance Memoizable A F where
   memIso = ...

after defining F, you can create the memo function with

fM : A -> B
fM = memoFix f'

You could generate F and the Memoizable instance using TH or DrIFT or
the like (allowing derivation would be really nice :). Actually F
could be considered a dependent type, so you could define a pretty
much universal instance using TH with that mechanism.


For further and detailed explanations, see


[1]

  R. Hinze. Memo functions, polytypically!
  http://www.informatik.uni-bonn.de/~ralf/publications.html#P11

and

  R. Hinze. Generalizing generalized tries.
  http://www.informatik.uni-bonn.de/~ralf/publications.html#J4


also:
T. Altenkirch. Representations of first order function types as
terminal coalgebras.
http://www.cs.nott.ac.uk/~txa/publ/tlca01a.pdf

which unfortunately you probably won't understand unless you know
about category/domain theory (I haven't figured it all out myself).

--
Peter Berry <[EMAIL PROTECTED]>
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: type versus data declarations

[Emilio Jesús Gallego Arias]

Hi Alfonso!

"Alfonso Acosta" <[EMAIL PROTECTED]> writes:

> On 6/8/07, Emilio Jesús Gallego Arias <[EMAIL PROTECTED]> wrote:
>
> Yep, you're right. a is alredy universally quantified in the RHS. This
> is probably what you're looking for:
>
> type FSet a = forall a. Show a => (a -> Double)
>
>> I'm not looking yet for existential types, as then my functions will
>> have to hold for every a, which turns out to be very inconvenient.
>
> hold?

See,

> type FSet = forall a . Show a => (a -> Double)

> up :: Double -> Double
> up x = x + 1

> m :: FSet
> m = up

This doesn't work.

I really want to use some functions that are not general enough. If the
function cannot touch it's value (as it's the case with forall), then
the function is almost useless, unless you'd like to do some type level
programming. I'd like to have different functions for the same type, so
I cannot pack it into a type class.

>> The reason I don't want to use data, which works ok, is because I'd like
>> to use FSet as a function, but not to write the type constraint in every
>> function using as it is now.
>
> I know, it can be a pain to have to carry the type class constraints
> everywhere. Maybe the type redefinition using existentials I wrote
> above can help. Otherwise I guess you'll have to cope with writting
> the constraint in every function signature.

Yeah, in general Haskell types don't carry constraints, however, I don't
see the reason that this doesn't work when using type level macros, as

> type F a = C a => a

should just be a macro and substitute.

Regards,

Emilio

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] LaTeX

[Alfonso Acosta]

On 6/8/07, Andrés Sicard Ramírez <[EMAIL PROTECTED]> wrote:

You can define

\newcommand{\pp}{+ \hspace{-0.2cm} +}


Why 0.2cm? Wouldn't that depend on the font size? using ems as the
hspace size sounds more reasonable.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: type versus data declarations

[Alfonso Acosta]

On 6/8/07, Alfonso Acosta <[EMAIL PROTECTED]> wrote:


Yep, you're right. a is alredy universally quantified in the RHS. This
is probably what you're looking for:

type FSet a = forall a. Show a => FSet (a -> Double)


I meant

type FSet a = forall a. Show a => (a -> Double)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: type versus data declarations

[Alfonso Acosta]

Hi again,


On 6/8/07, Emilio Jesús Gallego Arias <[EMAIL PROTECTED]> wrote:

I guess this is due to types like

> type A a = Show a => a
> type B a = Show a => a


You're right. This is not valid in the standard nor GHC.


so if you do

> f :: A a -> B b
it should get translated to
> f :: (Show a => a) -> (Show b => b)

Which is not valid. I wonder if regrouping all the contexts in the left
side should work:

> f :: (Show a, Show b) => a -> b


Maybe it can be feasible to implement that behavior, but it clearly
doesn't work like that right now. Maybe some GHC guru reading this
could explain why?

You can get the effect you want by using existentials to pack the
constraint with the type

type Discard a = forall b. Show b => a -> b -> (a, String)

thus, a function f :: Discard a -> Discard b would expand to something like

f :: (forall b. Show b => a -> b -> (a, String)) -> (forall c. Show c
=> b -> c -> (c, String))


> In addition you seem to be trying to pack a dictionary with the type
> (something you cannot do in Haskell without existentials). This is

Why? My first guess it that there's no way to translate that to system
F, but if we look at 'type' as a macro, it could make sense.


No idea, but that's how it works (I've been hitting myself against the
wall to solve similar problems and existentials seem the only way to
go).


> just a guess, but it seems that a definition using existentials is
> what you're looking for.
>
> data FSet a = forall a. Show a => FSet (a -> Double)

That would be

> data FSet = forall a. Show a => FSet (a -> Double)

not?


Yep, you're right. a is alredy universally quantified in the RHS. This
is probably what you're looking for:

type FSet a = forall a. Show a => FSet (a -> Double)



I'm not looking yet for existential types, as then my functions will
have to hold for every a, which turns out to be very inconvenient.


hold?


The reason I don't want to use data, which works ok, is because I'd like
to use FSet as a function, but not to write the type constraint in every
function using as it is now.


I know, it can be a pain to have to carry the type class constraints
everywhere. Maybe the type redefinition using existentials I wrote
above can help. Otherwise I guess you'll have to cope with writting
the constraint in every function signature.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Data polymophism

[Tomasz Zielonka]

On Fri, Jun 08, 2007 at 05:23:23PM +0200, Phlex wrote:
> But i don't seem to find a way to get out of this DbIndex type to 
> actually work on the enclosed index.
> 
> for instance, this doesn't work:
> liftDbIndex (DbIndex index) fun = DbIndex (fun index)

The compiler probably can't infer higher-ranker types, so you have to
write you type signature explicitly. Try:

liftDbIndex :: Index_ i2 a2 k2 =>
   (forall a1 k1 i1. Index_ i1 a1 k1 => i1 -> i2) -> DbIndex -> 
DbIndex

Best regards
Tomek
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Fast number parsing with strict bytestrings [Was: Re: Seemingly subtle change causes large performance variation]

[Conal Elliott]

Lovely!

Perhaps a stylistic shift would encourage writing this sort of elegant,
fusion-friendly code.

   -- Generalized version of "interact".  Encapsulates data getter &
putter.
   genInteract :: IO i -> (o -> IO ()) -> ((i -> o) -> IO ())
   genInteract get put = \ f -> get >>= put . f

The intention here is that i and o are pure value types (no IO).  Solutions
2 and three use the following specialization.

   -- Lazy ByteString in and showable out
   lGetPrint :: Show o => (L.ByteString -> o) -> IO ()
   lGetPrint = genInteract L.getContents print

Then rewrite solution 2 as follows:

   main = lGetPrint f
where
  f contents = foldl' (test k) 0 . map int . take n $ ls
where
  (l:ls) = L.lines contents
  [n,k]  = map int (L.split ' ' l)

And solution 3 similarly.

Plug: for additional examples and a more general approach to separating out
IO, my blog post "separating IO from logic -- example
",
which uses the TV  library.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] LaTeX

[Andrés Sicard Ramírez]

You can define

\newcommand{\pp}{+ \hspace{-0.2cm} +}

On 6/8/07, Andrew Coppin <[EMAIL PROTECTED]> wrote:


Does anybody know what the magical LaTeX command is to turn (say) "++"
into two overprinted pluses? (As seems to be fashionable...)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



--
Andrés
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Data polymophism

[Christian Maeder]

Phlex schrieb:
> I have this class which gives a common interface to (UniqueIndex a k)
> and (MultiIndex a k) :

I do not understand this

> class (Show a, Key_ k) => Index_ i a k  | i -> k, k -> a where
>   buildKey :: (a -> k)

this method "buildKey" is not sufficient to derive the type "i" in an
application ("i" determines "k" but not vice versa)

[...]
> Now i need to have these indexes in a list, so i declared that type :
> 
> data DbIndex = forall a k i. (Show a, Key_ k, Index_ i a k) => DbIndex i

  data DbIndex = forall a k i. (Index_ i a k) => DbIndex i

should do as well.

> for instance, this doesn't work:
> liftDbIndex (DbIndex index) fun = DbIndex (fun index)

you can apply only a method of Index_ to index.

> this doesn't work either :
> dbIndexBuildKey (DbIndex index) value = (buildKey index) value

buildKey's type is not sufficient (see above)

> How can i access the enclosed concrete index, via its Index_ class ?

Add corresponding methods to the class. (Alternatively or additionally
store an index as a dynamic value.)

HTH Christian
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re[2]: [Haskell-cafe] Re: Keys and Maps [Was: Re: I just don't get it (data structures and OO)]

[J. Garrett Morris]

On 6/8/07, Bulat Ziganshin <[EMAIL PROTECTED]> wrote:

> I second that. I particularly like the elimination of ]'s. We certainly
> need some symbol to separate the map and the key; but we do really need
> to also mark "here be the end of the key"?

and how (arr ! "key" ++ "data") should be parsed? :)



Roughly the same way you'd parse 2 * 3 + 4.

/g

--
The man who'd introduced them didn't much like either of them, though
he acted as if he did, anxious as he was to preserve good relations at
all times. One never knew, after all, now did one now did one now did
one.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] LaTeX

[Andrew Coppin]

Does anybody know what the magical LaTeX command is to turn (say) "++" 
into two overprinted pluses? (As seems to be fashionable...)


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Data polymophism

[Phlex]

Hello all,

It seems this message was lost somehow, so i'm trying to send it again 
sorry if it comes up twice on the list !


I have this class which gives a common interface to (UniqueIndex a k) 
and (MultiIndex a k) :


class (Show a, Key_ k) => Index_ i a k  | i -> k, k -> a where
  buildKey :: (a -> k)
  insertIndex :: Id -> a -> i -> Maybe i
  deleteIndex :: Id -> a -> i -> i
  updateIndex :: Id -> a -> a -> i -> Maybe i
  updateIndex id oldItem newItem index = insertIndex id newItem $ 
deleteIndex id oldItem index



Now i need to have these indexes in a list, so i declared that type :

data DbIndex = forall a k i. (Show a, Key_ k, Index_ i a k) => DbIndex i

Up to this point everything is fine, I can create concrete Indexes and 
put these different index types in the same list, after wrapping them in 
a DbIndex.


But i don't seem to find a way to get out of this DbIndex type to 
actually work on the enclosed index.


for instance, this doesn't work:
liftDbIndex (DbIndex index) fun = DbIndex (fun index)

this doesn't work either :
dbIndexBuildKey (DbIndex index) value = (buildKey index) value

How can i access the enclosed concrete index, via its Index_ class ?
Maybe am I totally on the wrong track ?

Thanks in advance,
Sacha
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Parallelism and expensive calculations that may not be needed

[Simon Marlow]

Felipe Almeida Lessa wrote:

On 6/8/07, Simon Marlow <[EMAIL PROTECTED]> wrote:
The problem occurs when you've found the Nothing, but the rest of the 
list has
already been sparked.  You really want to throw away all those sparks, 
but
there's no way to do that currently.  One way you could improve the 
situation
though is to only spark the next N elements in the list, limiting the 
amount of

speculation.


I see. I was hoping that GHC would see that the sparked thunk could be
garbage collected (as the rest of the list with sparks was thrown
away) and would not force it. It is expensive to GC before starting
every spark, of course, but maybe the GC could look for sparks that
could be removed whenever it collects?


Actually at the moment the GC treats sparks as roots, but that's wrong.  Thanks 
for reminding me, I must fix that sometime.


Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: [Haskell] ANN: Catch (first ever release)

[Neil Mitchell]

Following up on haskell-cafe:

Hi Chris,


>  For the last few years I've been working on a pattern-match checker
> for Haskell, named Catch. I'm now happy to make a release:
I would love to use this with regex-tdfa (and the other regex-* modules).

At the moment regex-tdfa is uses a few extensions such as recursive "mdo"
notation and parts hook up to the MPTC + fundeps used in regex-base.  The
MPTC+fundeps are not part of the workhorse modules, they are just "type class
syntactic sugar" that makes it easier for the library consumer.  But "mdo" _is_
used in two of the important internal functions.


You have several options:

* Wait until GHC Core is working, when Catch will work with all these
things automatically.

* Rewrite your code to eliminate mdo, if you wish to port regex to Yhc
you will need to do this anyway.

* Find an mdo preprocessor (I think one exists?) and preprocess the
code before checking.

Obviously the GHC Core one is least work for you, but won't be
available for a while.

Thanks

Neil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Data polymorphism ?

[Phlex]

Hello all,

I have this class which gives a common interface to (UniqueIndex a k) 
and (MultiIndex a k) :


class (Show a, Key_ k) => Index_ i a k  | i -> k, k -> a where
   buildKey :: (a -> k)
   insertIndex :: Id -> a -> i -> Maybe i
   deleteIndex :: Id -> a -> i -> i
   updateIndex :: Id -> a -> a -> i -> Maybe i
   updateIndex id oldItem newItem index = insertIndex id newItem $ 
deleteIndex id oldItem index



Now i need to have these indexes in a list, so i declared that type :

data DbIndex = forall a k i. (Show a, Key_ k, Index_ i a k) => DbIndex i

Up to this point everything is fine, I can create concrete Indexes and 
put these different index types in the same list, after wrapping them in 
a DbIndex.


But i don't seem to find a way to get out of this DbIndex type to 
actually work on the enclosed index.


for instance, this doesn't work:
liftDbIndex (DbIndex index) fun = DbIndex (fun index)

this doesn't work either :
dbIndexBuildKey (DbIndex index) value = (buildKey index) value

How can i access the enclosed concrete index, via its Index_ class ?
Maybe am I totally on the wrong track ?

Thanks in advance,
Sacha
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] class MonoidBreak?

[Alex Jacobson]

Ok how about this class:

  class (Monoid m) => MonoidBreak m where
  mbreak::m->m->m

And the condition is

  mappend (mbreak y z) y == z


-Alex-

Dan Piponi wrote:

On 6/7/07, Alex Jacobson <[EMAIL PROTECTED]> wrote:

Is there a standard class that looks something like this:

class (Monoid m) => MonoidBreak m where
 mbreak::a->m a->(m a,m a)


I think you have some kind of kind issue going on here. If m is a
Monoid I'm not sure what m a means. Looks like you're trying to factor
elements of monoids in some way. Maybe you mean

class (Monoid m) => MonoidBreak m where
   mbreak::a->m->(m,m)

Though I'm not sure what the relationship between m and a is intended 
to be.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] haskell version of fractal benchmark

[Simon Peyton-Jones]

3) -fbang-patterns

Better than `seq`

Do you mean "more convenient than" or "generates better code than".  I don't 
think the latter should be true; send a counterexample if you find one!

Simon


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: type versus data declarations

[Emilio Jesús Gallego Arias]

Hi Alfonso!

"Alfonso Acosta" <[EMAIL PROTECTED]> writes:

>> > type FSet a = Show a => (a -> Double)
>
> type only works for redefinitions (i.e. adding the |Show a| constraint
> makes FSet a different type to (a -> Double)).

Yes, I know.

What I mean, if type is a type macro, why cannot it expand type
constraints too?

Quoting the GHC manual
> >7.4.1.3. Liberalised type synonyms
>
> Type synonyms are like macros at the type level, and GHC does validity
> checking on types only after expanding type synonyms.

Seemed to me like a syntactical restriction, however that parses OK, but
the typer complains.

I guess this is due to types like

> type A a = Show a => a
> type B a = Show a => a

so if you do

> f :: A a -> B b
it should get translated to
> f :: (Show a => a) -> (Show b => b)

Which is not valid. I wonder if regrouping all the contexts in the left
side should work:

> f :: (Show a, Show b) => a -> b

> In addition you seem to be trying to pack a dictionary with the type
> (something you cannot do in Haskell without existentials). This is

Why? My first guess it that there's no way to translate that to system
F, but if we look at 'type' as a macro, it could make sense.

> just a guess, but it seems that a definition using existentials is
> what you're looking for.
>
> data FSet a = forall a. Show a => FSet (a -> Double)

That would be

> data FSet = forall a. Show a => FSet (a -> Double)

not? The above is like

> data FSet b = forall a. Show a => FSet (a -> Double)

I'm not looking yet for existential types, as then my functions will
have to hold for every a, which turns out to be very inconvenient.

The reason I don't want to use data, which works ok, is because I'd like
to use FSet as a function, but not to write the type constraint in every
function using as it is now.

> type FSet a = a -> Double
> a :: Show a => FSet a
> ...

Thanks for your answer,

Emilio

pd: Greetings from Angel too :)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] killThread on a terminated thread.

[Bit Connor]

Hello,

Is it safe to use killThread to terminate a thread that has already
terminated(it's IO action has run to completion)? Or are ThreadIds
reused, potentially causing an unwanted thread to be terminated?

I'm using ghc 6.6

Thanks,
bit
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Parallelism and expensive calculations that may not be needed

[Felipe Almeida Lessa]

On 6/8/07, Simon Marlow <[EMAIL PROTECTED]> wrote:

The problem occurs when you've found the Nothing, but the rest of the list has
already been sparked.  You really want to throw away all those sparks, but
there's no way to do that currently.  One way you could improve the situation
though is to only spark the next N elements in the list, limiting the amount of
speculation.


I see. I was hoping that GHC would see that the sparked thunk could be
garbage collected (as the rest of the list with sparks was thrown
away) and would not force it. It is expensive to GC before starting
every spark, of course, but maybe the GC could look for sparks that
could be removed whenever it collects?


Hope this helps...


Thanks! It sure helps!

Cheers,

--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Fast number parsing with strict bytestrings [Was: Re: Seemingly subtle change causes large performance variation]

[Bulat Ziganshin]

Hello Donald,

Friday, June 8, 2007, 5:42:41 AM, you wrote:

> Previous experience[1] indicates it is pretty hard to write a C line
> parsing program[2] that that run this fast.  And the code, with comments:

[2] uses gets() function while your haskell code read whole buffer
each time. that is the obvious source of slowness

-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] type versus data declarations

[Alfonso Acosta]

Hola Emilio!

On 6/7/07, Emilio Jesús Gallego Arias <[EMAIL PROTECTED]> wrote:

Hello,

I'm wondering why you can write

> data FSet a = Show a => M (a -> Double)
>
> a :: FSet Double
> a = M $ \x -> 0

and it works, but

> type FSet a = Show a => (a -> Double)


type only works for redefinitions (i.e. adding the |Show a| constraint
makes FSet a different type to (a -> Double)).

In addition you seem to be trying to pack a dictionary with the type
(something you cannot do in Haskell without existentials). This is
just a guess, but it seems that a definition using existentials is
what you're looking for.

data FSet a = forall a. Show a => FSet (a -> Double)

Cheers,

PD: Saluda Ángel de mi parte :)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Optimising UTF8-CString -> String marshaling, plus comments on withCStringLen/peekCStringLen

[Alistair Bayley]

Simon,


You're right, both versions should give the same code.  Which version of GHC 
are you using?  Both with the HEAD and with 6.6.1 I get the nice unboxed code 
with the `seq` version too.  My test program is below.


I'm using 6.6, so I'll upgrade to 6.6.1 and retest. Preusmably you're
only interested if this behaviour persists in 6.6.1. I'll check both
cases and make a test cases for them if necessary.

Thanks,
Alistair
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] HopenGL

[Jon Harrop]

On Friday 08 June 2007 01:19:02 Jason Dagit wrote:
> Did you remember to do all the double buffering operations?  Did you
> setup the clear color first?  One thing that you have to be careful
> about with OpenGL is that you correctly manage the state of the opengl
> machine.  Haskell should have a purely functional scene graph built on
> top of HOpenGL -- it's something I would like to work on -- but no one
> seems to be doing it.

I would very much like to do something similar, having implemented purely 
functional scene graphs on top of OpenGL in OCaml and DirectX in F#:

  http://www.ffconsultancy.com/products/smoke_vector_graphics/
  http://www.ffconsultancy.com/products/fsharp_for_visualization/

Immutability is very useful in this area and, in particular, it makes a scene 
graph implementation in a functional language much more accessible than 
something like Windows Presentation Foundation.

I am now working on a cross-platform GUI based upon our vector graphics work 
(Smoke). This can be similarly elegant by referencing purely functional scene 
graphs from nodes in the GUI description tree.

I would be very interested to see how this is done in Haskell so, if anyone 
does attempt this, please keep me in the loop.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?e
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] haskell version of fractal benchmark

[Andrew Coppin]

Bayley, Alistair wrote:

  
[mailto:[EMAIL PROTECTED]] On Behalf Of Andrew Coppin

Donald Bruce Stewart wrote:


  Some things to remember using Doubles:

* {-# OPTIONS -fexcess-precision #-} 
* -fvia-C
* -fbang-patterns
* -optc-O2 -optc-mfpmath=sse -optc-msse2
* -optc-march=pentium4
  

1. What do all those things do?
2. Is the effect actually that large?

  
  
Large? Depends what you mean by large, but adding a few flags to get
just a 10-20% speedup isn't to be ignored:
  


Sure - if it really is 10-20%. (And not, say, 0.001 - 0.002%.)



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re[2]: [Haskell-cafe] Re: Keys and Maps [Was: Re: I just don't get it (data structures and OO)]

[Bulat Ziganshin]

> I second that. I particularly like the elimination of ]'s. We certainly
> need some symbol to separate the map and the key; but we do really need
> to also mark "here be the end of the key"?

and how (arr ! "key" ++ "data") should be parsed? :)


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] haskell version of fractal benchmark

[Donald Bruce Stewart]

Alistair_Bayley:
> > [mailto:[EMAIL PROTECTED] On Behalf Of Donald 
> > Bruce Stewart
> > 
> > 3) -fbang-patterns
> > 
> > Better than `seq`
> 
> Better in the "more convenient to write" sense, right? AFAIUI, seq and
> bang patterns should be equivalent.
> 

Yes, in the 'more convenient' sense. Adding strictness speculatively,
while trying to debug a leak, is easier when inserting !, than to insert
`seq`'s. It also doesn't obfuscate the code as much as the seq tricks
do.

-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: haskell wiki indexing

[Simon Marlow]

Jason Dagit wrote:

On 5/22/07, Robin Green <[EMAIL PROTECTED]> wrote:

On Tue, 22 May 2007 15:05:48 +0100
Duncan Coutts <[EMAIL PROTECTED]> wrote:

> On Tue, 2007-05-22 at 14:40 +0100, Claus Reinke wrote:
>
> > so the situation for mailing lists and online docs seems to have
> > improved, but there is still the wiki indexing/rogue bot issue,
> > and lots of fine tuning (together with watching the logs to spot
> > any issues arising out of relaxing those restrictions). perhaps
> > someone on this list would be willing to volunteer to look into
> > those robots/indexing issues on haskell.org?-)
>
> The main problem, and the reason for the original (temporary!) measure
> was bots indexing all possible diffs between old versions of wiki
> pages. URLs like:
>
> http://haskell.org/haskellwiki/?title=Quicksort&diff=9608&oldid=9607
>
> For pages with long histories this O(n^2) number of requests starts to
> get quite large and the wiki engine does not seem well optimised for
> getting arbitrary diffs. So we ended up with bots holding open many
> http server connections. They were not actually causing much server
> cpu load or generating much traffic but once the number of nearly hung
> connections got up to the http child process limit then we are
> effectively in a DOS situation.
>
> So if we can ban bots from the page histories or turn them off for the
> bot user agents or something then we might have a cure. Perhaps we
> just need to upgrade our media wiki software or find out how other
> sites using this software deal with the same issue of bots reading
> page histories.

http://en.wikipedia.org/robots.txt

Wikipedia uses URLs starting with /w/ for "dynamic" pages (well, all
pages are dynamic in a sense, but you know what I mean I hope.) And
then puts /w/ in robots.txt.


Does anyone know the status of applying a workaround such as this?  I
really miss being able to find things on the haskell wiki via google
search.  I don't like the mediawiki search at all.


The status is that nobody has stepped up and volunteered to look after 
haskell.org's robots.txt file.  It needs someone with the time and experience to 
look into what needs doing, make the changes, fix problems as the arise, and 
update it as necessary in the future.  Anyone?


Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] haskell version of fractal benchmark

[Bayley, Alistair]

> [mailto:[EMAIL PROTECTED] On Behalf Of Donald 
> Bruce Stewart
> 
> 3) -fbang-patterns
> 
> Better than `seq`

Better in the "more convenient to write" sense, right? AFAIUI, seq and
bang patterns should be equivalent.

Alistair
*
Confidentiality Note: The information contained in this message,
and any attachments, may contain confidential and/or privileged
material. It is intended solely for the person(s) or entity to
which it is addressed. Any review, retransmission, dissemination,
or taking of any action in reliance upon this information by
persons or entities other than the intended recipient(s) is
prohibited. If you received this in error, please contact the
sender and delete the material from any computer.
*
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Parallelism and expensive calculations that may not be needed

[Simon Marlow]

Felipe Almeida Lessa wrote:


(Sorry if this is a newbie question, couldn't find the answer anywhere)

Suppose I have an expensive function (such that even to be reduced to WHNF
it takes a long processing time)


expensive :: Foo -> Maybe Bar


and I want to calculate it on multiple processors, like in


calculate = parMap rnf expensive


Well, fine. But suppose that then I give the result to a function like


final xs = reverse $ final' xs [] where
final' [] r = r
final' (x:xs) r = case x of Nothing -> []
Just x  -> final' xs (x:r)


Given list :: [Foo], a sequential calculation as in


resultS = final $ map expensive list


would not call expensive after finding a Nothing. But


resultP = final $ calculate list


will keep calculating all the other expensive's because they were sparked?


Right.  This is an example of speculation: you don't know in advance how much 
work you really have to do, so any work you do in parallel may or may not be 
necessary.


If we fire off the whole list in parallel, we might end up doing a lot of work 
on the elements at the end of the list, which are less likely to be required 
than the elements at the front of the list.  That's a bad strategy: we need to 
prioritise the elements near the front.  Fortunately GHC's built-in strategy for 
picking sparks to evaluate picks the oldest ones first, so this shouldn't be a 
problem.


The problem occurs when you've found the Nothing, but the rest of the list has 
already been sparked.  You really want to throw away all those sparks, but 
there's no way to do that currently.  One way you could improve the situation 
though is to only spark the next N elements in the list, limiting the amount of 
speculation.


Hope this helps...

Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: ghc wiki registration failure ( was: Failure in GHC compilation)

[Simon Marlow]

Daniil Elovkov wrote:


I wanted to add a couple of words that another solution would be to
add an option to xargs in target.mk
xargs -n NNN
where NNN is less than the OS limit.

(That helped me to build LambdaVM on windows, there are quite a lot of
class files there, and no SPLITOBJS will obviously help)
Editing target.mk isn't a good thing, probably. Maybe some $XARGSOPTS
could be introduced...

BUT trying to register on the wiki resulted in an error with this
python traceback


Use the guest login for now.  We're in limbo waiting to upgrade to the new Trac 
to fix problems with spam, and I had to turn off account registering for now.


Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] HopenGL

[Ruben Zilibowitz]

Hi,

Thanks. I eventually figured it out by doing pretty much what you  
suggested with Lines.hs. I discovered that the thing that made lines  
come out only in black was:

lighting $= Enabled
So disabling lighting before drawing lines and re-enabling it  
afterwards allows me to draw colored lines now. Thanks for the  
suggestions.


Ruben

On 08/06/2007, at 10:19 AM, Jason Dagit wrote:


On 6/7/07, Ruben Zilibowitz <[EMAIL PROTECTED]> wrote:

Hi,

Thanks for the reply. The Lines.hs example program seems to work just
right. Unfortunately I still can't get colored lines to work in my 3d
program.



Maybe it has something to do with the fact my one is 3d and
the example program is in 2d.


This is unlikely because of the way OpenGL does 3d vs. 2d.  In OpenGL,
2d is just a special case of 3d where 0 is used for the z coordinate.

More likely than 3d vs. 2d is that you're not drawing in the correct
part of coordinate space, the view volume is incorrect or something
like that.

I would try to work Lines.hs into your current example or start
borrowing code from it and putting them into your example until you
either break Lines.hs in the same way or your example starts to work.
Does Lines.hs still work when you switch it over to 3d?  It should,
but that could be a nice test to help you debug things.

Did you remember to do all the double buffering operations?  Did you
setup the clear color first?  One thing that you have to be careful
about with OpenGL is that you correctly manage the state of the opengl
machine.  Haskell should have a purely functional scene graph built on
top of HOpenGL -- it's something I would like to work on -- but no one
seems to be doing it.  For me at least, it's a matter of time and
priority.  Maybe in a few months to a year I'll get some time for it,
but don't hold your breath :)

Jason


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] haskell version of fractal benchmark

[Donald Bruce Stewart]

andrewcoppin:
> Donald Bruce Stewart wrote:
> >Some things to remember using Doubles:
> >
> >* {-# OPTIONS -fexcess-precision #-} 
> >* -fvia-C
> >* -fbang-patterns
> >* -optc-O2 -optc-mfpmath=sse -optc-msse2
> >* -optc-march=pentium4
> >  
> 
> 1. What do all those things do?

Check the GHC user's guide.

> 2. Is the effect actually that large?

1) {-# OPTIONS -fexcess-precision #-

I've had this halved runtimes for runtimes for numeric-intensive programs.

2) -fvia-C

Probably still worth 10% for Double-based stuff (maybe more).

3) -fbang-patterns

Better than `seq`

4) -optc-O2 -optc-mfpmath=sse -optc-msse2 -optc-march=pentium4

Can be worth 0 to hmm, quite a few, percent, depending on the code.
This is all assuming you've written low level code anyway, so that the 
effects of, say, using SSE instructions are actually apparent.

-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] haskell version of fractal benchmark

[Bayley, Alistair]

> [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Coppin
> 
> Donald Bruce Stewart wrote:
> > Some things to remember using Doubles:
> >
> > * {-# OPTIONS -fexcess-precision #-} 
> > * -fvia-C
> > * -fbang-patterns
> > * -optc-O2 -optc-mfpmath=sse -optc-msse2
> > * -optc-march=pentium4
> 
> 1. What do all those things do?
> 2. Is the effect actually that large?

Large? Depends what you mean by large, but adding a few flags to get
just a 10-20% speedup isn't to be ignored:

 
http://www.haskell.org/haskellwiki/Performance/GHC#Crank_up_the_gcc_flag
s
  http://www.haskell.org/haskellwiki/Performance/Floating_Point

Alistair
*
Confidentiality Note: The information contained in this message,
and any attachments, may contain confidential and/or privileged
material. It is intended solely for the person(s) or entity to
which it is addressed. Any review, retransmission, dissemination,
or taking of any action in reliance upon this information by
persons or entities other than the intended recipient(s) is
prohibited. If you received this in error, please contact the
sender and delete the material from any computer.
*
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] haskell version of fractal benchmark

[Andrew Coppin]

Donald Bruce Stewart wrote:

Some things to remember using Doubles:

* {-# OPTIONS -fexcess-precision #-} 
* -fvia-C

* -fbang-patterns
* -optc-O2 -optc-mfpmath=sse -optc-msse2
* -optc-march=pentium4
  


1. What do all those things do?
2. Is the effect actually that large?

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] OK, so this VIM thing -- how do I make it actually work?

[Arthur van Leeuwen]

On 5-jun-2007, at 10:58, Michael T. Richter wrote:

I've given up on getting a decent text editor for editing Haskell  
(specifically literate Haskell -- plain Haskell works fine in  
GEDIT).  Instead I fire up VIM and get ... a total mess.  At first  
I think maybe I've screwed up a whole bunch of settings or  
something, so I nuke everything in my home directory that begins  
with .vim and then, for added measure, head over to /usr/share and  
nuke the entire ./vim directory tree.  I then reinstall vim (from  
the Ubuntu Edgy archives) to get a brand new set of config files  
unsullied by my hands.


I still get a dog's breakfast.

A screen shot of what I'm seeing with a representative example of  
a .lhs file to show what I mean can be found at http:// 
img357.imageshack.us/img357/5798/gvimexamplezv4.png.  (I've pared  
it down to the minimum I could find that shows the behaviour  
clearly.)  The problems I'm seeing are the ugly white-on-red for  
underlines, the lack of any kind of differentiation for keywords/ 
operators/etc. vs. identifiers (although some punctuation is  
recognized, specifically curly braces), comments not being noted,  
etc.  Basically it looks like the Haskell is simply not being  
recognized at all (and, if the @saBinds@ thing is what I think it  
is, it looks like some latex isn't being recognized fully either).


Can anybody vim-centric please take a look at this and give me a  
few educated guesses as to what is happening here?


Yes, I can. What you see happening is that the syntax highlighter  
doesn't get

completely switched from TeX mode to Haskell mode on the change marked
by \begin{code} (and back again on \end{code}). Therefore, lone  
underscores
(which are usually in error in TeX outside of mathematics) are marked  
as errors.
This should be fixed. I'll look into it. The reason I've never run  
into it is simple:

I tend not to use underscores in my Haskell code. :)

With regards, Arthur van Leeuwen.

--

  /\/ |   [EMAIL PROTECTED]   | Work like you don't need  
the money
/__\  /  | A friend is someone with whom | Love like you have never  
been hurt
/\/__ | you can dare to be yourself   | Dance like there's nobody  
watching




___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe