Re: [Haskell-cafe] environment variables for runghc?

[Erik de Castro Lopo]

Alexander Dunlap wrote:

> I doubt there's an env variable, but you could do
> 
> $ alias ghc='ghc -Wall'

Sorry, doesn't work. I'm pretty sure runghc uses ghc directly
and doesn't invoke a user shell to  do so.

Erik
-- 
-
Erik de Castro Lopo
-
"If I were on life-support, I'd rather have it run by a Gameboy
than a Windows box."
-- Cliff Wells in comp.lang.python
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] environment variables for runghc?

[Alexander Dunlap]

I doubt there's an env variable, but you could do

$ alias ghc='ghc -Wall'

Alex

On Tue, Mar 3, 2009 at 7:07 PM, Erik de Castro Lopo
 wrote:
> Hi all,
>
> Is there some environment variable I can set so that runghc can
> be told to always use -Wall?
>
> Cheers,
> Erik
> --
> -
> Erik de Castro Lopo
> -
> "... a discussion of C++'s strengths and flaws always sounds
> like an argument about whether one should face north or east
> when one is sacrificing one's goat to the rain god."
> -- Thant Tessman
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Data.Binary stack overflow with Data.Sequence String

[Gwern Branwen]

So recently I've been having issues with Data.Binary & Data.Sequence;
I serialize a 'Seq String'

You can see the file here: http://code.haskell.org/yi/Yi/IReader.hs

The relevant function seems to be:

-- | Read in database from 'dbLocation' and then parse it into an 'ArticleDB'.
readDB :: YiM ArticleDB
readDB = io $ (dbLocation >>= r) `catch` (\_ -> return empty)
  where r x = fmap (decode . BL.fromChunks . return) $ B.readFile x
-- We read in with strict bytestrings to guarantee the
file is closed,
-- and then we convert it to the lazy bytestring
data.binary expects.
-- This is inefficient, but alas...

My current serialized file is about 9.4M. I originally thought that
the issue might be the recent upgrade in Yi to binary 0.5, but I
unpulled patches back to past that, and the problem still manifested.

Whenever yi tries to read the articles.db file, it stack overflows. It
actually stack-overflowed on even smaller files, but I managed to bump
the size upwards, it seems, by the strict-Bytestring trick.
Unfortunately, my personal file has since passed whatever that limit
was.

I've read carefully the previous threads on Data.Binary and Data.Map
stack-overflows, but none of them seem to help; hacking some $!s or
seqs into readDB seems to make no difference, and Seq is supposed to
be a strict datastructure already! Doing things in GHCi has been
tedious, and hasn't enlightened me much: sometimes things overflow and
sometimes they don't. It's all very frustrating and I'm seriously
considering going back to using the original read/show code unless
anyone knows how to fix this - that approach may be many times slower,
but I know it will work.

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

[Haskell-cafe] environment variables for runghc?

[Erik de Castro Lopo]

Hi all,

Is there some environment variable I can set so that runghc can
be told to always use -Wall?

Cheers,
Erik
-- 
-
Erik de Castro Lopo
-
"... a discussion of C++'s strengths and flaws always sounds
like an argument about whether one should face north or east
when one is sacrificing one's goat to the rain god."
-- Thant Tessman
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Status of Haskell under OsX

[Manuel M T Chakravarty]

Ross Mellgren:
I use this configuration exclusively... it wasn't actually that hard  
to set up once I found out that the .pc files are shipped in a  
strange directory buried in the frameworks.


I posted how I got it working back in December: 
http://sourceforge.net/mailarchive/message.php?msg_name=3E883695-30D3-4CBE-AD14-B08C24D343EF%40z.odi.ac


That does work nicely.  Thanks for the pointer.  I added a paragraph  
on the Haskell wiki for easy reference:


  http://www.haskell.org/haskellwiki/Gtk2Hs#Using_the_GTK.2B_OS_X_Framework

Manuel


On Mar 2, 2009, at 6:39 PM, Manuel M T Chakravarty wrote:

BTW, there is a nice native version of GTK for Mac OS X as a proper  
framework:


http://www.gtk-osx.org/

Unfortunately, it seems rather difficult to build gtk2hs with the  
GTK+ framework as the framework doesn't support pkg-config and  
gtk2hs knows nothing about Mac frameworks.  However, GHC has  
support for frameworks; so, it should be possible to get this to  
work.


Manuel

Arne Dehli Halvorsen:

Manuel M T Chakravarty wrote:

I'm planning to purchase a MacBookPro so I'm wondering how well
Haskell is supported under this platform.


At least two of the regular contributors to GHC work on Macs.   
That should ensure that Mac OS X is well supported.  Installation  
is trivial with the Mac OS X installer package:


http://haskell.org/ghc/download_ghc_6_10_1.html#macosxintel

Hi, following on from this point:

How does one get gtk2hs running on a mac?

I have a MacBook Pro, and I've had ghc installed for some time now.

(first in 6.8.2 (packaged),
then 6.10.1 (packaged),
then 6.8.2 via macports 1.6
then 6.10.1 via macports 1.7)

I tried to install gtk2hs via macports, but it didn't work.
(0.9.12? on 6.8.2, then on 6.10.1)
Is there a recipe one could follow?
Can I get the preconditions via macports, and then use cabal to  
install

gtk2hs 0.10?

Grateful for assistance,
Arne D H


Manuel


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


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


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

Re: [Haskell-cafe] Memory usage when passing arrays in state

[Daniel Fischer]

Am Mittwoch, 4. März 2009 02:30 schrieb Tobias Olausson:
> Thank you Daniel.
> As I understood it DiffArrays are supposed to be faster than the regular

They may be supposed to be faster, but they aren't.
If you want anything resembling speed, use UArrays, STUArrays, or, if your 
array elements cannot be unboxed, plain Arrays and STArrays, or some other 
array-package from Hackage (I don't know which are good, though, the above 
are good enough for me).

> Array due to the fact that it doesnt copy the entire Array, but just
> updates the position that changes, and keeps some kind of "changelog" on
> the array. But when looking at the statistics for my sample program, it
> seems that it allocates a lot more than what should be needed, which would
> indicate that maybe the array is copied anyway.
> At this point, the DiffArray/DiffUArray are the only functional arrays,
> right?

No. They are probably the most dysfunctional arrays around.

> I mean, I can add two and two together and see that it
> equals...four, and if the only functional array is sort of broken, that
> means so is my program. Are there any alternatives that are fast aswell?
>
> //Tobias

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

Re: [Haskell-cafe] Memory usage when passing arrays in state

[Ryan Ingram]

I've found DiffArrays to be way too slow/memory-hogging for real usage.

Since you are in IO already (StateT s IO), you'll probably be better
off using a mutable array for a data structure.

Some things are still best done in the imperative style.  You can be a
bit safer by using ST as the bottom monad, however, and returning the
result as a pure array.  This gives you a single copy per "runST".

Alternatively, use IntMap instead of arrays if you want a pure data
structure with reasonably efficient update/lookup.

  -- ryan

On Tue, Mar 3, 2009 at 4:44 PM, Tobias Olausson  wrote:
> Hello all.
> I am currently implementing an emulation of a CPU, in which the CPU's
> RAM is part of the internal state
> that is passed around in the program using a state monad. However, the
> program performs
> unexpectingly bad, and some profiling information makes us believe
> that the problem is the high
> memory usage of the program.
>
> The program below is similar to our main program used when testing a
> sorting algorithm in this CPU:
>
> module Main where
>
> import Control.Monad.State.Lazy
> import Data.Word
> import Data.Array.Diff
> import Control.Concurrent (threadDelay)
>
> data LoopState = LoopState
>    { intVal :: Integer
>    , diff   :: DiffUArray Word8 Word8
>    }
>
> initState :: LoopState
> initState = LoopState 0 (array (0x00,0xFF) [(idx,0)|idx<-[0x00..0xFF]])
>
> main :: IO ()
> main = do
>    execStateT looper initState >>= putStrLn . show . intVal
>
> looper :: StateT LoopState IO ()
> looper = do
>    st <- get
>    let res = intVal st + 1
>        idx = fromIntegral res
>    put $ st { intVal = res, diff = (diff st) // [(idx,idx)] }
>    if res == 1300
>        then return ()
>        else looper
>
> Of course our program does more than updating a counter ;-)
> Compiling and running this program yields the following result:
>
> [~]:[olaussot] >> ghc --make -O2 -o array ArrayPlay.hs
> [~]:[olaussot] >> ./array +RTS -sstderr
> ./array +RTS -sstderr
> 1300
>     313,219,740 bytes allocated in the heap
>   1,009,986,984 bytes copied during GC
>     200,014,828 bytes maximum residency (8 sample(s))
>       4,946,648 bytes maximum slop
>             393 MB total memory in use (3 MB lost due to fragmentation)
>
>  Generation 0:   590 collections,     0 parallel,  3.06s,  3.09s elapsed
>  Generation 1:     8 collections,     0 parallel,  3.56s,  4.21s elapsed
>
>  INIT  time    0.00s  (  0.00s elapsed)
>  MUT   time    0.27s  (  0.27s elapsed)
>  GC    time    6.62s  (  7.30s elapsed)
>  EXIT  time    0.00s  (  0.00s elapsed)
>  Total time    6.89s  (  7.57s elapsed)
>
>  %GC time      96.1%  (96.4% elapsed)
>
>  Alloc rate    1,155,958,754 bytes per MUT second
>
>  Productivity   3.9% of total user, 3.6% of total elapsed
>
> Why does the program spend 96.1% of its total running time collecting garbage?
> Any tips to make this program perform better are appreciated.
> Please do tell if anything is unclear.
>
> --
> Tobias Olausson
> tob...@gmail.com
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Difficulties in accessing inner elements of data types

[Andrew Wagner]

Seems like Conal's semantic editor combinators could be of interest too, if
I'm understanding correctly:
http://conal.net/blog/posts/semantic-editor-combinators/

On Tue, Mar 3, 2009 at 8:00 PM, Tim Docker  wrote:

> > While writing an OrgFile is fairly easy, reading (and
> > accessing inner parts) of an org file is very tedious,
> > and modifying them is horrendous.
>
> Have you looked at
>
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/data-accessor
>
> It's something I've used successfully when wanting to
> manipulate the internals of complex types.
>
> Tim
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Memory usage when passing arrays in state

[Daniel Fischer]

Am Mittwoch, 4. März 2009 01:44 schrieb Tobias Olausson:
> Hello all.
> I am currently implementing an emulation of a CPU, in which the CPU's
> RAM is part of the internal state
> that is passed around in the program using a state monad. However, the
> program performs
> unexpectingly bad, and some profiling information makes us believe
> that the problem is the high
> memory usage of the program.
>
> The program below is similar to our main program used when testing a
> sorting algorithm in this CPU:
>
> module Main where
>
> import Control.Monad.State.Lazy

Not good, use Control.Monad.State.Strict

> import Data.Word
> import Data.Array.Diff
> import Control.Concurrent (threadDelay)
>
> data LoopState = LoopState
> { intVal :: Integer
> , diff   :: DiffUArray Word8 Word8

Diff(U)Arrays tend to be slow, use them with care.

> }
>
> initState :: LoopState
> initState = LoopState 0 (array (0x00,0xFF) [(idx,0)|idx<-[0x00..0xFF]])
>
> main :: IO ()
> main = do
> execStateT looper initState >>= putStrLn . show . intVal
>
> looper :: StateT LoopState IO ()
> looper = do
> st <- get
> let res = intVal st + 1
> idx = fromIntegral res
> put $ st { intVal = res, diff = (diff st) // [(idx,idx)] }
> if res == 1300
> then return ()
> else looper

You're being too lazy, building a huge thunk that only gets evaluated at the 
end of the loop. You have to force evaluation earlier.

>
> Of course our program does more than updating a counter ;-)
> Compiling and running this program yields the following result:
>
> [~]:[olaussot] >> ghc --make -O2 -o array ArrayPlay.hs
> [~]:[olaussot] >> ./array +RTS -sstderr
> ./array +RTS -sstderr
> 1300
>  313,219,740 bytes allocated in the heap
>1,009,986,984 bytes copied during GC
>  200,014,828 bytes maximum residency (8 sample(s))
>4,946,648 bytes maximum slop
>  393 MB total memory in use (3 MB lost due to fragmentation)
>
>   Generation 0:   590 collections, 0 parallel,  3.06s,  3.09s elapsed
>   Generation 1: 8 collections, 0 parallel,  3.56s,  4.21s elapsed
>
>   INIT  time0.00s  (  0.00s elapsed)
>   MUT   time0.27s  (  0.27s elapsed)
>   GCtime6.62s  (  7.30s elapsed)
>   EXIT  time0.00s  (  0.00s elapsed)
>   Total time6.89s  (  7.57s elapsed)
>
>   %GC time  96.1%  (96.4% elapsed)
>
>   Alloc rate1,155,958,754 bytes per MUT second
>
>   Productivity   3.9% of total user, 3.6% of total elapsed
>
> Why does the program spend 96.1% of its total running time collecting
> garbage? Any tips to make this program perform better are appreciated.
> Please do tell if anything is unclear.

Nothing gets evaluated until the end, so nothing can be discarded earlier.

--
{-# LANGUAGE BangPatterns #-}
module Main where

import Control.Monad.State.Strict
import Data.Word
import Data.Array.Unboxed
import Data.Array.ST
import Data.Array.MArray

update :: UArray Word8 Word8 -> Word8 -> Word8 -> UArray Word8 Word8
update arr i v = runSTUArray $ do
sar <- unsafeThaw arr
writeArray sar i v
return sar

data LoopState = LoopState
{ intVal :: !Integer
, diff   :: !(UArray Word8 Word8)
}

initState :: LoopState
initState = LoopState 0 (array (0x00,0xFF) [(idx,0)|idx<-[0x00 .. 0xFF]])

main :: IO ()
main = do
execStateT looper initState >>= putStrLn . show . intVal

looper :: StateT LoopState IO ()
looper = do
LoopState i df <- get
let res = i + 1
idx = fromIntegral res
!ndf = update df idx idx
put (LoopState res ndf)
if res == 1300
then return ()
else looper
--

Is much better behaved. I didn't investigate if every strictness annotation is 
necessary.

>
> --
> Tobias Olausson
> tob...@gmail.com

Cheers,
Daniel

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

Re: [Haskell-cafe] Memory usage when passing arrays in state

[Tobias Olausson]

Thank you Daniel.
As I understood it DiffArrays are supposed to be faster than the regular
Array due to the fact that it doesnt copy the entire Array, but just updates
the position that changes, and keeps some kind of "changelog" on the array.
But when looking at the statistics for my sample program, it seems that
it allocates a lot more than what should be needed, which would indicate that
maybe the array is copied anyway.
At this point, the DiffArray/DiffUArray are the only functional arrays, right?
I mean, I can add two and two together and see that it equals...four, and
if the only functional array is sort of broken, that means so is my program.
Are there any alternatives that are fast aswell?

//Tobias

2009/3/4 Daniel Peebles :
> This may be completely unrelated to your problem, but there's a ticket
> in the GHC trac saying that DiffArray is unusably slow:
> http://hackage.haskell.org/trac/ghc/ticket/2727 . It doesn't analyze
> the cause of the slowness, so it's quite possible that it may be
> related to GC as in your case.
>
> Cheers,
> Dan
>
> On Tue, Mar 3, 2009 at 7:44 PM, Tobias Olausson  wrote:
>> Hello all.
>> I am currently implementing an emulation of a CPU, in which the CPU's
>> RAM is part of the internal state
>> that is passed around in the program using a state monad. However, the
>> program performs
>> unexpectingly bad, and some profiling information makes us believe
>> that the problem is the high
>> memory usage of the program.
>>
>> The program below is similar to our main program used when testing a
>> sorting algorithm in this CPU:
>>
>> module Main where
>>
>> import Control.Monad.State.Lazy
>> import Data.Word
>> import Data.Array.Diff
>> import Control.Concurrent (threadDelay)
>>
>> data LoopState = LoopState
>>    { intVal :: Integer
>>    , diff   :: DiffUArray Word8 Word8
>>    }
>>
>> initState :: LoopState
>> initState = LoopState 0 (array (0x00,0xFF) [(idx,0)|idx<-[0x00..0xFF]])
>>
>> main :: IO ()
>> main = do
>>    execStateT looper initState >>= putStrLn . show . intVal
>>
>> looper :: StateT LoopState IO ()
>> looper = do
>>    st <- get
>>    let res = intVal st + 1
>>        idx = fromIntegral res
>>    put $ st { intVal = res, diff = (diff st) // [(idx,idx)] }
>>    if res == 1300
>>        then return ()
>>        else looper
>>
>> Of course our program does more than updating a counter ;-)
>> Compiling and running this program yields the following result:
>>
>> [~]:[olaussot] >> ghc --make -O2 -o array ArrayPlay.hs
>> [~]:[olaussot] >> ./array +RTS -sstderr
>> ./array +RTS -sstderr
>> 1300
>>     313,219,740 bytes allocated in the heap
>>   1,009,986,984 bytes copied during GC
>>     200,014,828 bytes maximum residency (8 sample(s))
>>       4,946,648 bytes maximum slop
>>             393 MB total memory in use (3 MB lost due to fragmentation)
>>
>>  Generation 0:   590 collections,     0 parallel,  3.06s,  3.09s elapsed
>>  Generation 1:     8 collections,     0 parallel,  3.56s,  4.21s elapsed
>>
>>  INIT  time    0.00s  (  0.00s elapsed)
>>  MUT   time    0.27s  (  0.27s elapsed)
>>  GC    time    6.62s  (  7.30s elapsed)
>>  EXIT  time    0.00s  (  0.00s elapsed)
>>  Total time    6.89s  (  7.57s elapsed)
>>
>>  %GC time      96.1%  (96.4% elapsed)
>>
>>  Alloc rate    1,155,958,754 bytes per MUT second
>>
>>  Productivity   3.9% of total user, 3.6% of total elapsed
>>
>> Why does the program spend 96.1% of its total running time collecting 
>> garbage?
>> Any tips to make this program perform better are appreciated.
>> Please do tell if anything is unclear.
>>
>> --
>> Tobias Olausson
>> tob...@gmail.com
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>



-- 
Tobias Olausson
tob...@gmail.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Memory usage when passing arrays in state

[Daniel Peebles]

This may be completely unrelated to your problem, but there's a ticket
in the GHC trac saying that DiffArray is unusably slow:
http://hackage.haskell.org/trac/ghc/ticket/2727 . It doesn't analyze
the cause of the slowness, so it's quite possible that it may be
related to GC as in your case.

Cheers,
Dan

On Tue, Mar 3, 2009 at 7:44 PM, Tobias Olausson  wrote:
> Hello all.
> I am currently implementing an emulation of a CPU, in which the CPU's
> RAM is part of the internal state
> that is passed around in the program using a state monad. However, the
> program performs
> unexpectingly bad, and some profiling information makes us believe
> that the problem is the high
> memory usage of the program.
>
> The program below is similar to our main program used when testing a
> sorting algorithm in this CPU:
>
> module Main where
>
> import Control.Monad.State.Lazy
> import Data.Word
> import Data.Array.Diff
> import Control.Concurrent (threadDelay)
>
> data LoopState = LoopState
>    { intVal :: Integer
>    , diff   :: DiffUArray Word8 Word8
>    }
>
> initState :: LoopState
> initState = LoopState 0 (array (0x00,0xFF) [(idx,0)|idx<-[0x00..0xFF]])
>
> main :: IO ()
> main = do
>    execStateT looper initState >>= putStrLn . show . intVal
>
> looper :: StateT LoopState IO ()
> looper = do
>    st <- get
>    let res = intVal st + 1
>        idx = fromIntegral res
>    put $ st { intVal = res, diff = (diff st) // [(idx,idx)] }
>    if res == 1300
>        then return ()
>        else looper
>
> Of course our program does more than updating a counter ;-)
> Compiling and running this program yields the following result:
>
> [~]:[olaussot] >> ghc --make -O2 -o array ArrayPlay.hs
> [~]:[olaussot] >> ./array +RTS -sstderr
> ./array +RTS -sstderr
> 1300
>     313,219,740 bytes allocated in the heap
>   1,009,986,984 bytes copied during GC
>     200,014,828 bytes maximum residency (8 sample(s))
>       4,946,648 bytes maximum slop
>             393 MB total memory in use (3 MB lost due to fragmentation)
>
>  Generation 0:   590 collections,     0 parallel,  3.06s,  3.09s elapsed
>  Generation 1:     8 collections,     0 parallel,  3.56s,  4.21s elapsed
>
>  INIT  time    0.00s  (  0.00s elapsed)
>  MUT   time    0.27s  (  0.27s elapsed)
>  GC    time    6.62s  (  7.30s elapsed)
>  EXIT  time    0.00s  (  0.00s elapsed)
>  Total time    6.89s  (  7.57s elapsed)
>
>  %GC time      96.1%  (96.4% elapsed)
>
>  Alloc rate    1,155,958,754 bytes per MUT second
>
>  Productivity   3.9% of total user, 3.6% of total elapsed
>
> Why does the program spend 96.1% of its total running time collecting garbage?
> Any tips to make this program perform better are appreciated.
> Please do tell if anything is unclear.
>
> --
> Tobias Olausson
> tob...@gmail.com
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Difficulties in accessing inner elements of data types

[Tim Docker]

> While writing an OrgFile is fairly easy, reading (and
> accessing inner parts) of an org file is very tedious,
> and modifying them is horrendous.

Have you looked at

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/data-accessor

It's something I've used successfully when wanting to
manipulate the internals of complex types.

Tim


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

[Haskell-cafe] OpenVG: Linker errors with ghc --make, but not with ghci?

[Peter Verswyvelen]

I followed the instructions on how to build OpenVG on Windows. It works fine
when I run the examples using "GHCi -lopenvg32", but when compiling it with
"GHC --make -lopenvg32" I get a bunch of linker errors, like
C:\Program
Files\Haskell\OpenVG-0.1\ghc-6.10.1/libHSOpenVG-0.1.a(Paths.o):fake:(.text+0x82):
undefined reference to `vgInterpolatePath'
C:\Program
Files\Haskell\OpenVG-0.1\ghc-6.10.1/libHSOpenVG-0.1.a(Paths.o):fake:(.text+0x40d):
undefined reference to `vgModifyPathCoords'
etc

However it does seem that the libopenvg32.a file contains all these
undefined references, and it is in the gcc-lib directory of GHC.

I'm a stuck. Any hints?

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

[Haskell-cafe] Memory usage when passing arrays in state

[Tobias Olausson]

Hello all.
I am currently implementing an emulation of a CPU, in which the CPU's
RAM is part of the internal state
that is passed around in the program using a state monad. However, the
program performs
unexpectingly bad, and some profiling information makes us believe
that the problem is the high
memory usage of the program.

The program below is similar to our main program used when testing a
sorting algorithm in this CPU:

module Main where

import Control.Monad.State.Lazy
import Data.Word
import Data.Array.Diff
import Control.Concurrent (threadDelay)

data LoopState = LoopState
{ intVal :: Integer
, diff   :: DiffUArray Word8 Word8
}

initState :: LoopState
initState = LoopState 0 (array (0x00,0xFF) [(idx,0)|idx<-[0x00..0xFF]])

main :: IO ()
main = do
execStateT looper initState >>= putStrLn . show . intVal

looper :: StateT LoopState IO ()
looper = do
st <- get
let res = intVal st + 1
idx = fromIntegral res
put $ st { intVal = res, diff = (diff st) // [(idx,idx)] }
if res == 1300
then return ()
else looper

Of course our program does more than updating a counter ;-)
Compiling and running this program yields the following result:

[~]:[olaussot] >> ghc --make -O2 -o array ArrayPlay.hs
[~]:[olaussot] >> ./array +RTS -sstderr
./array +RTS -sstderr
1300
 313,219,740 bytes allocated in the heap
   1,009,986,984 bytes copied during GC
 200,014,828 bytes maximum residency (8 sample(s))
   4,946,648 bytes maximum slop
 393 MB total memory in use (3 MB lost due to fragmentation)

  Generation 0:   590 collections, 0 parallel,  3.06s,  3.09s elapsed
  Generation 1: 8 collections, 0 parallel,  3.56s,  4.21s elapsed

  INIT  time0.00s  (  0.00s elapsed)
  MUT   time0.27s  (  0.27s elapsed)
  GCtime6.62s  (  7.30s elapsed)
  EXIT  time0.00s  (  0.00s elapsed)
  Total time6.89s  (  7.57s elapsed)

  %GC time  96.1%  (96.4% elapsed)

  Alloc rate1,155,958,754 bytes per MUT second

  Productivity   3.9% of total user, 3.6% of total elapsed

Why does the program spend 96.1% of its total running time collecting garbage?
Any tips to make this program perform better are appreciated.
Please do tell if anything is unclear.

--
Tobias Olausson
tob...@gmail.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Theory about uncurried functions

[Jonathan Cast]

On Wed, 2009-03-04 at 01:35 +0100, Henning Thielemann wrote:
> On Tue, 3 Mar 2009, Peter Verswyvelen wrote:
> 
> > Now, does a similar theory exist of functions that always have one
> > input and one output, but these inputs and outputs are *always*
> > tuples? Or maybe this does not make any sense?
> 
> I don't think one can forbid currying.

Sure you can, just work in a category with finite products (and possibly
finite co-products) but not exponentials.  Of course, then your language
is first order --- and this doesn't do anything to stop partial
application, which is still easy --- but it's quite possible.

jcc


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

Re: [Haskell-cafe] Theory about uncurried functions

[Henning Thielemann]

On Tue, 3 Mar 2009, Peter Verswyvelen wrote:


Now, does a similar theory exist of functions that always have one
input and one output, but these inputs and outputs are *always*
tuples? Or maybe this does not make any sense?


I don't think one can forbid currying. It's just a question, whether 
people use it commonly or not. But that was already said in this thread.


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

Re: [Haskell-cafe] Theory about uncurried functions

[Dan Weston]

Not a better programmer, just a better human being.

Peter Verswyvelen wrote:

Thank you all for this information. It was very enlightening.

Too bad I don't know category theory, since I think it would give me a
better view on the different forms and essence of "computing".

Maybe this raises a new question: does understanding category theory
makes you a better *programmer*?


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

Re: [Haskell-cafe] DSLs with {in,}equalities

[Henning Thielemann]

On Tue, 3 Mar 2009, Brandon S. Allbery KF8NH wrote:


On 2009 Mar 2, at 23:13, Andrew Hunter wrote:

a) Hide Prelude.(<) and define a simple < that builds the AST term I want.
b) Come up with a new symbol for it that doesn't look totally awful.


I guess aesthetics differ; I'd use e.g. $<$, where the $ (to me, from other 
contexts) means "symbolic".


... like escaping '<' in LaTeX. Funny!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Left fold enumerator - a real pearl overlooked?

[Henning Thielemann]

John A. De Goes schrieb:

> Elsewhere, laziness can be a real boon, so I don't understand your
> question, "Why have laziness in Haskell at all?"

As I have written, many libaries process their data lazily (or could be
changed to do so without altering their interface) but their interface
can forbid application to data that is fetched from the outside world.
Say you are used to 'map', 'filter', 'foldr' - you cannot use them on
data fetched by the iteratee/enumerator approach.

Actually, Lazy I/O and exceptions can work together if you drop the
exceptions that are baked into IO monad and use explicit exceptions
(synchronous and asynchronous ones) as I develop them in the
explicit-exception package. I'm however still searching for a good set
of combinators.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] possible memory leak in uvector 0.1.0.3

[Claus Reinke]

That helps to make things clearer, I think. One issue is
the nature of Maps (strict in keys, non-strict in values).

- neither singleton nor unionWith are strict in the Map values, so
   nothing here forces the evaluation of rate or constructionof UArr

But, as I have written, in one of my tests I also tried rnf to force 
evaluation:

rnf v `seq` rnf m `seq` return m
Isn't this sufficient?


It will force the Map that results from the repeated unioning,
but does not ensure that this is done in an efficient way.


A standard trick to keep Map values evaluated by construction
is to make the availability of keys dependent on their values, eg
(singleton key) $! value. That won't help with unionWith and
the appendUs, but it should allow the source string references
to be dropped early, as the singletons are constructed.


Tried; but, even using union instead of unionWith, the memory 
grows fast as before.


Strange. I built myself a small wrapper to make your code
fragment compilable, and just replacing (unionWith appendU)
with (union) makes a drastic difference - as it should.

It is rather annoying that Data.IntMap doesn't provide a strict
form of unionWith or insertWith (Data.Map does at least provide
insertWith'). But we can define our own, at the cost of an extra
lookup. We can then foldl' that insertWith' directly over the ratings 
list, bypassing the non-strict parts of the Data.IntMap API (see

code below).

Claus 
  (who still thinks that all Maps should be parameterized

   over their key-value pair type constructor, so that the default
   non-strict Maps would result from using non-strict pairs

   type IntMap = IntMapP (,)

   while the often desired element-strict Maps would result 
   from using strict pairs, with no other change in API


   type IntMapStrict = IntMapP (:*:)
   )

---
{-# LANGUAGE TypeOperators #-}
import qualified Data.ByteString.Lazy as L
import Data.Array.Vector
import qualified Data.IntMap as IM
import Data.List
import Data.Word
import qualified Data.ByteString.Lazy.Char8 as L8
import Data.Maybe
import System.IO

-- don't use this for real, test wrapper only
ratings :: L.ByteString -> [(Word32,Word8)]
ratings = map (\[i,r]->(fromIntegral $ fst $ fromJust $ L8.readInt i
  ,fromIntegral $ fst $ fromJust $ L8.readInt r))
   . map L8.words . L8.lines

parse handle = do
 contents <- L.hGetContents handle
 let v =  map singleton' $ ratings contents
 let m = foldl' (\m (kw,v)->insertWith' appendU (fromIntegral kw,v) m) IM.empty 
v
 -- let m = foldl1' (IM.unionWith appendU) v
 -- let m = foldl1' (IM.union) v
 return $! m

 where
   -- Build a Map with a single movie rating
   singleton' :: (Word32, Word8) -> (Int,UArr Rating)
   singleton' (id, rate) =
 ((fromIntegral $ id), (singletonU $ pairS (id, rate)))
 -- (IM.singleton (fromIntegral $ id)) $ (singletonU $ pairS (id, rate))

insertWith' op (k,v) m =
 maybe (IM.insert k v m)
   (\old->((IM.insert k) $! (v `op` old)) m)
   (IM.lookup k m)

type Rating = Word32 :*: Word8
type MovieRatings = IM.IntMap (UArr Rating) -- UArr from uvector

-- more test wrapper, some trivial input data
generate = withFile "in.data" WriteMode $ \h->
   mapM_ (\(i,r)->hPutStrLn h $ show i++" "++show r) 
   $ take 100 $ cycle [(i,i)|i<-[0..100]]


main = withFile "in.data" ReadMode parse >>= print

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

Re: [Haskell-cafe] Theory about uncurried functions

[Peter Verswyvelen]

Thank you all for this information. It was very enlightening.

Too bad I don't know category theory, since I think it would give me a
better view on the different forms and essence of "computing".

Maybe this raises a new question: does understanding category theory
makes you a better *programmer*?

On Tue, Mar 3, 2009 at 8:45 PM, Hans Aberg  wrote:
> On 3 Mar 2009, at 10:43, Peter Verswyvelen wrote:
>
>> Lambda calculus is a nice theory in which every function always has
>> one input and one output. Functions with multiple arguments can be
>> simulated because functions are first class and hence a function can
>> "return" a function. Multiple outputs cannot be done, one must embed
>> these outputs in some data type, e.g. using a tuple, or one must use
>> continuation passing style.
>>
>> Now, does a similar theory exist of functions that always have one
>> input and one output, but these inputs and outputs are *always*
>> tuples? Or maybe this does not make any sense?
>
> I think most of the replies have already described it, but the Church's
> lambda-calculus is just a minimal theory describing a way to construct
> functions, which turns out to be quite general, including all algorithms.
> The first lambda-calculus he describes in his book does not even include the
> constant functions - for some reason it is convenient.
>
> So if you want to have more, just add it. That is why functional computer
> languages like Haskell can exist.
>
> As for currying, it builds on the fact that in the category of sets (but
> others may not have it) one has a natural equivalence (arguments can also be
> functions)
>      psi: Hom(A x B, C) --> Hom(A, Hom(B, C))
>                 f       |-> (a |-> (b |-> f(a, b)))
>    ((a, b) |-> g(a)(b)) <-|      g
> So it simply means that set-theoretic products can be rewritten into
> iterated functions. (Strictly speaking, currying involves a choice of
> natural equivalence psi.)
>
> In axiomatic set theory, it is common to construct tuplets (i.e.,
> set-theoretic products) so that (x) = x, (x_1, ..., x_n) = ((x_1, ...,
> x_(n-1), x_n), and one might set () to the empty set (so that, for example,
> the real R  ^0 has only one point). The recursive formula has slipped into
> functional languages. Pure math, unless there are special requirements, uses
> naive set theory in which that recursion formula would not be used: in
> computer lingo, it corresponds to the implementation (axiomatic set theory),
> and is not part of the interface (naive set theory).
>
> By contrast, in lists, [x] is not the same as x. (If S is a set, the set of
> lists with elements from S is the free monoid on S.)
>
> But you might view f() as passing the object () to f, f(x) passes x to f,
> and f(x_1, ..., x_n) passes (x_1, ..., x_n) to f.
>
> So the only addition needed is to add the objects (x_1, ..., x_n), n = 0, 1,
> 2, ..., to your language. You can still curry the functions if you like to -
> a convention, just as already noted.
>
>  Hans Aberg
>
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] monadic MapReduce

[David Menendez]

On Mon, Mar 2, 2009 at 6:57 PM, Anish Muttreja  wrote:
> How about this. Is there a reason why I can't
> replace the variables b and c in the type signature of mapReduce with with 
> (IO b')
> and (IO c'). b and c  can be any types.
>
> mapReduce :: Strategy (IO b')    -- evaluation strategy for mapping
>           -> (a -> IO b')      -- map function
>           -> Strategy (IO c')    -- evaluation strategy for reduction
>           -> ([IO b'] -> (IO c'))    -- reduce function
>           -> [a]           -- list to map over
>           -> (IO c')
>
> Just remember to wrap all values back in the IO monad.

This is possible, but it probably won't do what you want. The input to
the reduce function will be  a list of "IO a" values, not the results
of performing the IO.

-- 
Dave Menendez 

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

Re: [Haskell-cafe] Stacking State on State.....

[Phil]

I've had a look at your example - it's raised yet more questions in my mind!


On 02/03/2009 23:36, "Daniel Fischer"  wrote:


> A stupid example:
> --
> module UhOh where
> 
> import Control.Monad
> import Control.Monad.State.Lazy
> --import Control.Monad.State.Strict
> 
> 
> uhOh :: State s ()
> uhOh = State $ \_ -> undefined
> 
> uhOhT :: Monad m => StateT s m ()
> uhOhT = StateT $ \_ -> return undefined
> 
> uhOhT2 :: Monad m => StateT s m ()
> uhOhT2 = StateT $ \_ -> undefined
> 
> oy :: State s ()
> oy = State $ \_ -> ((),undefined)
> 
> oyT :: Monad m => StateT s m ()
> oyT = StateT $ \_ -> return ((),undefined)
> 
> hum :: State Int Int
> hum = do
> k <- get
> w <- uhOh
> put (k+2)
> return w
> return (k+1)
> 
> humT :: Monad m => StateT Int m Int
> humT = do
> k <- get
> w <- uhOhT
> put (k+2)
> return w
> return (k+1)
> 
> 
> humT2 :: Monad m => StateT Int m Int
> humT2 = do
> k <- get
> w <- uhOhT2
> put (k+2)
> return w
> return (k+1)
> 
> 
> whoa n = runState (replicateM_ n hum >> hum) 1
> 
> whoaT n = runStateT (replicateM_ n humT >> humT) 1
> 
> whoaT2 n = runStateT (replicateM_ n humT2 >> humT2) 1
> 
> yum :: State Int Int
> yum = do
> k <- get
> w <- oy
> put (k+2)
> return w
> return (k+1)
> 
> yumT :: Monad m => StateT Int m Int
> yumT = do
> k <- get
> w <- oyT
> put (k+2)
> return w
> return (k+1)
> 
> hoha n = runState (replicateM_ n yum >> yum) 1
> 
> hohaT n = runStateT (replicateM_ n yumT >> yumT) 1
> 
> oops m = runState m 1
> --
> 
> What happens with
> 
> whoa 10
> hoha 10
> oops (whoaT 10)
> oops (whoaT2 10)
> oops (hohaT 10)
> 
> respectively when the Lazy or Strict library is imported?
> Answer first, then test whether you were right.

OK, I had a think about this - I'm not 100% clear but:

UhOh - OK for lazy, Bad for Strict.  "undefined" 'could' be of the form
(a,s) so the lazy accepts it, but the strict version tries to produce (a,s)
out of undefined and fails.

Oy - Both are OK here.  The pair form is retained and neither will go as far
as to analyse the contents of either element of the pair, as neither is
used.

UhOhT - OK for lazy, Bad for Strict. Same as Oh UhOh, but as we have
transformer we return inside a Monad.

UhOhT2 - Bad for both - transformers should return a Monad.

OyT - Same as Oy, but returned inside a monad.


The thing which confuses me is why we care about these functions at all hum,
yum, etc.  Although these inspect the State Monads above they stick the
values in to 'w' which is never used (I think), because the first return
statement just produces "M w" which is not returned because of the return
(k+1) afterwards??

Because lazy and strict are only separated by the laziness on the bind
between contiguous hum and yum states, I would have thought that laziness on
w would have been the same on both.

Hmmm. But I suppose each call to hum and yum is increment stating in it's
corresponding UhOh and Oy function.  Thus causing these to be strictly
evaluated one level deeper In which case I do understand.

We have:

hum >> hum >> hum  .

And At each stage we are also doing UhOh >> UhOh >> UhOh inside the hums?

Is this right, I'm not so sure?  I'm in danger of going a bit cross-eyed
here!


> 
>> This means that each new (value,state) is just passed around as a thunk and
>> not even evaluated to the point where a pair is constructed - it's just a
>> blob, and could be anything as far as haskell is concerned.
> 
> Not quite anything, it must have the correct type, but whether it's
> _|_, (_|_,_|_), (a,_|_), (_|_,s) or (a,s) (where a and s denote non-_|_
> elements of the respective types), the (>>=) doesn't care. Whether any
> evaluation occurs is up to (>>=)'s arguments.
> 

By correct type you mean that it must *feasibly* be a pair... But the lazy
pattern matching doesn't verify that it *is* a pair.  Thus if we returned
something that could never be a pair, it will fail to compile, but if it is
of the form X or (X,X) it won't check any further than that, but if it was
say [X] that wouldn't work even for lazy - haskell doesn't trust us that
much!?

>> It follows that each new state cannot evaluated even if we make newStockSum
>> strict as (by adding a bang) because the state tuple newStockSum is wrapped
>> in is completely unevaluated - so even if newStockSum is evaluated INSIDE
>> this blob, haskell will still keep the whole chain.
> 
> Well, even with the bang, newStockSum will only be evaluated if somebody looks
> at what mc delivers. In the Strict case, (>>=) does, so newStockSum is
> evaluated at each step.

When you say 'looks' at it do you mean it is the final print state on the
result that ultimately causes the newStockSum to be evaluated in the lazy
version?  Thus we are saying we evaluate it only because we kno

Re: [Haskell-cafe] Re: How to build sourceview depend for gtk2hs?

[Brandon S. Allbery KF8NH]

On Mar 3, 2009, at 17:04 , Andy Stewart wrote:

"Brandon S. Allbery KF8NH"  writes:

On Mar 3, 2009, at 16:52 , Andy Stewart wrote:

* sourceview : no
* gtksourceview2 : yes



I'm pretty sure you can have only one or the other, not both; as  
such you want gtksourceview2 if you

have both.
So i can use SourceView if i have config pass "sourceview" or  
"gtksourceview2"?

Can you explain the difference between "sourceview" and
"gtksourceview2"?



gtksourceview2 is a newer version (2.x vs. 1.x),  They're not 100%  
compatible (API changes) so you have to pick one when building Gtk2hs;  
if they were independent packages as with the C versions it would be  
possible to build both and pick one when building an application.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
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] Re: How to build sourceview depend for gtk2hs?

[Andy Stewart]

"Brandon S. Allbery KF8NH"  writes:

> On Mar 3, 2009, at 16:52 , Andy Stewart wrote:
>> * sourceview : no
>> * gtksourceview2 : yes
>
>
> I'm pretty sure you can have only one or the other, not both; as such you 
> want gtksourceview2 if you
> have both.
So i can use SourceView if i have config pass "sourceview" or "gtksourceview2"?
Can you explain the difference between "sourceview" and
"gtksourceview2"?

Thank you very much!

  -- Andy

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

Re: [Haskell-cafe] How to build sourceview depend for gtk2hs?

[Brandon S. Allbery KF8NH]

On Mar 3, 2009, at 16:52 , Andy Stewart wrote:

* sourceview : no
* gtksourceview2 : yes



I'm pretty sure you can have only one or the other, not both; as such  
you want gtksourceview2 if you have both.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
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] How to build sourceview depend for gtk2hs?

[Andy Stewart]

Hi all,

I use Debian testing.

I have install GHC 6.10.1 binary package.

When i use "autoreconf && ./configure --enable-docs" to config gtk2hs

**
* Configuration completed successfully.   
* 
* The following packages will be built:   
* 
* glib   : yes
* gtk: yes  
* gio: yes  
* glade  : yes 
* cairo  : yes
* svgcairo   : yes 
* gtkglext   : yes 
* gconf  : yes
* sourceview : no   
* gtksourceview2 : yes   
* mozembed   : yes 
* soegtk : yes  
* gnomevfs   : yes 
* gstreamer  : yes
* documentation  : yes   
* 
* Now do "(g)make" followed by "(g)make install"
**

But "sourceview" is not pass, have anyone successful?

I have install below packages:

libglade2-dev libgtksourceview-dev
libgconf2-dev librsvg2-dev libgstreamer-plugins-base0.10-dev
libgstreamer0.10-dev libgtkglext1-dev libgnomevfs2-dev xulrunner-dev

So i need install which depend package to fix above problem?
Thanks!

Below is the detail config information.

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for style of include used by make... GNU
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... none
checking how to run the C preprocessor... gcc -E
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking for ar... /usr/bin/ar
checking for ld... /usr/bin/ld
checking for basename... /usr/bin/basename
checking for grep that handles long lines and -e... /bin/grep
checking for gzip... /bin/gzip
checking for a sed that does not truncate output... /bin/sed
checking for cut... /usr/bin/cut
checking for tar... /bin/tar
checking for touch... /usr/bin/touch
checking for ranlib... ranlib
checking for xargs... /usr/bin/xargs
checking for ghc... /usr/local/bin/ghc
checking version of GHC... 6.10.1
checking for ghc-pkg... /usr/local/bin/ghc-pkg
checking whether to build deprecated bindings... yes
checking whether to build deprecated packages (gnomevfs, sourceview)... yes
checking for the GHC package "base"... yes, version 4.0.0.0
checking for the GHC package "haskell98"... yes, version 1.0.1.0
checking for the GHC package "mtl"... yes, version 1.1.0.2
checking for the GHC package "bytestring"... yes, version 0.9.1.4
checking for the GHC package "containers"... yes, version 0.2.0.0
checking for the GHC package "array"... yes, version 0.2.0.0
checking for the GHC package "old-time"... yes, version 1.0.0.1
checking for the GHC package "pretty"... yes, version 1.0.1.0
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for GLIB... yes
checking for GTK... yes
checking whether to build gtk package... yes
checking for GIO... yes
checking whether to build gio package... yes
checking for LIBGLADE... yes
checking whether to build glade package... yes
checking for GCONF... yes
checking whether to build gconf package... yes
checking for GTKSOURCEVIEW2... yes
checking whether to build gtksourceview2 package... yes
checking whether to build sourceview package... no
checking for MOZILLA_MOZEMBED... yes
checking whether to build mozembed package... yes
checking for SEAMONKEY_MOZEMBED... no
checking whether to build mozembed package... no
checking for FIREFOX_MOZEMBED... no
checking whether to build mozembed package... no
checking for XULRUNNER_MOZEMBED... no
checking whether to build mozembed package... no
checking for CAIRO... yes
checking whether to build cairo package... yes
checking for SVGCAIRO... yes
checking whether to build svgcairo package... yes
checking for GTKGLEXT... yes
checking whether to build gtkglext package... yes
checking for GNOMEVFS... yes
checking whether to build gnomevfs package... yes
checking for GSTREAMER... yes
checking whether to build gstreamer package... yes
checking for hsc2hs... /usr/local/bin/hsc2hs
chec

[Haskell-cafe] Relying on GCC as the hsc2hs C compiler

[John Van Enk]

While working on my new bindings project (using hsc2hs) I came across the
__alignof__() statement available in GNU's C compiler. As it turns out,
having this computed for me in Storable instances using something like this
would be great:

instance Storable Foo where

sizeOf _ = #{const sizeof(CFoo)}
alignment _ = #{const __alignof__(CFoo)}

Can I rely on hsc2hs using GCC? How many people will hate me if I depend on
GCC-specific extensions?

Legal? Acceptable? Infuriating?

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

Re: [Haskell-cafe] Threading and Mullticore Computation

[Dušan Kolář]

Hello,

 IMO, the conclusion about instant cache misses due to several threads 
sharing memory and/or performing large memory consumption is very highly 
probable, especially on Intel CPUs with shared L2 cache.


 I have several examples, where threading means significant time 
consumption increase ( =  * ). My 
personal conclusion - use linear recursive functions only (so that they 
could be optimized), Int instead of Integer, if possible, no data 
structure traversal (unless such a structure is very small, L2 caches 
are several MBs only). Such a way cache misses are minimized for 
both/all threads. Moreover, OS needs some time instantly (=> cache 
refill/misses), thus, I've devoted one core for OS, others for 
computation (quad core), which brings certain improvement and more 
accurate measurements.


 Regards

   Dusan

Bulat Ziganshin wrote:

Hello Andrew,

Tuesday, March 3, 2009, 9:21:42 PM, you wrote:

  

I just tried it with GHC 6.10.1. Two capabilities is still slower. (See
attachments. Compiled with -O2 -threaded.)



i don't think so:

  Total time4.88s  (  5.14s elapsed)

  Total time7.08s  (  4.69s elapsed)

so with 1 thread wall clock time is 5 seconds, with 2 thread wall time
is 4.7 seconds

cpu time spent increased with 2 threads - this indicates that you
either use hyperthreaded/SMT-capable cpu or speed is limited by memory
access operations

so, my conclusion - this benchmark limited by memory latencies so it
cannot be efficiently multithreaded


  


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

Re: [Haskell-cafe] Theory about uncurried functions

[Hans Aberg]

On 3 Mar 2009, at 10:43, Peter Verswyvelen wrote:


Lambda calculus is a nice theory in which every function always has
one input and one output. Functions with multiple arguments can be
simulated because functions are first class and hence a function can
"return" a function. Multiple outputs cannot be done, one must embed
these outputs in some data type, e.g. using a tuple, or one must use
continuation passing style.

Now, does a similar theory exist of functions that always have one
input and one output, but these inputs and outputs are *always*
tuples? Or maybe this does not make any sense?


I think most of the replies have already described it, but the  
Church's lambda-calculus is just a minimal theory describing a way to  
construct functions, which turns out to be quite general, including  
all algorithms. The first lambda-calculus he describes in his book  
does not even include the constant functions - for some reason it is  
convenient.


So if you want to have more, just add it. That is why functional  
computer languages like Haskell can exist.


As for currying, it builds on the fact that in the category of sets  
(but others may not have it) one has a natural equivalence (arguments  
can also be functions)

  psi: Hom(A x B, C) --> Hom(A, Hom(B, C))
 f   |-> (a |-> (b |-> f(a, b)))
((a, b) |-> g(a)(b)) <-|  g
So it simply means that set-theoretic products can be rewritten into  
iterated functions. (Strictly speaking, currying involves a choice of  
natural equivalence psi.)


In axiomatic set theory, it is common to construct tuplets (i.e., set- 
theoretic products) so that (x) = x, (x_1, ..., x_n) = ((x_1, ...,  
x_(n-1), x_n), and one might set () to the empty set (so that, for  
example, the real R^0 has only one point). The recursive formula has  
slipped into functional languages. Pure math, unless there are special  
requirements, uses naive set theory in which that recursion formula  
would not be used: in computer lingo, it corresponds to the  
implementation (axiomatic set theory), and is not part of the  
interface (naive set theory).


By contrast, in lists, [x] is not the same as x. (If S is a set, the  
set of lists with elements from S is the free monoid on S.)


But you might view f() as passing the object () to f, f(x) passes x to  
f, and f(x_1, ..., x_n) passes (x_1, ..., x_n) to f.


So the only addition needed is to add the objects (x_1, ..., x_n), n =  
0, 1, 2, ..., to your language. You can still curry the functions if  
you like to - a convention, just as already noted.


  Hans Aberg


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

Re: [Haskell-cafe] Threading and Mullticore Computation

[Andrew Coppin]

Bulat Ziganshin wrote:

Hello Andrew,

Tuesday, March 3, 2009, 9:21:42 PM, you wrote:

  

I just tried it with GHC 6.10.1. Two capabilities is still slower. (See
attachments. Compiled with -O2 -threaded.)



i don't think so:

  Total time4.88s  (  5.14s elapsed)

  Total time7.08s  (  4.69s elapsed)
  


Damnit. Foiled again!

It turns out Process Explorer is reporting CPU time, not wall time. 
Sorry about that...


(This is the second time I've tripped over that one. There doesn't seem 
to be a way to get it to report wall time either, unfortunately.)



so with 1 thread wall clock time is 5 seconds, with 2 thread wall time
is 4.7 seconds
  


So a small speedup then.


so, my conclusion - this benchmark limited by memory latencies so it
cannot be efficiently multithreaded
  


Probably.

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

Re: Re[2]: [Haskell-cafe] Threading and Mullticore Computation

[Svein Ove Aas]

So, apparently the 6.10.1 code runs amiss of this bug:
http://hackage.haskell.org/trac/ghc/ticket/2747

I'll be upgrading to HEAD now. If no-one else gets around to it first,
I'll probably post some more benchmarks afterwards.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re[2]: [Haskell-cafe] Threading and Mullticore Computation

[Bulat Ziganshin]

Hello Andrew,

Tuesday, March 3, 2009, 9:21:42 PM, you wrote:

> I just tried it with GHC 6.10.1. Two capabilities is still slower. (See
> attachments. Compiled with -O2 -threaded.)

i don't think so:

  Total time4.88s  (  5.14s elapsed)

  Total time7.08s  (  4.69s elapsed)

so with 1 thread wall clock time is 5 seconds, with 2 thread wall time
is 4.7 seconds

cpu time spent increased with 2 threads - this indicates that you
either use hyperthreaded/SMT-capable cpu or speed is limited by memory
access operations

so, my conclusion - this benchmark limited by memory latencies so it
cannot be efficiently multithreaded


-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

Re: [Haskell-cafe] Threading and Mullticore Computation

[Don Stewart]

andrewcoppin:
> Svein Ove Aas wrote:
>> For what it's worth, I tried it myself on 6.10.. details follow, but
>> overall impression is that while you lose some time to overhead, it's
>> still 50% faster than unthreaded.

On a quad core, ghc 6.10 snapshot from today:

Single threaded

whirlpool$  ghc-6.10.1.20090302 -O2 A.hs --make -fforce-recomp
[1 of 1] Compiling Main ( A.hs, A.o )
Linking A ...
whirlpool$ time ./A   
"Task2 done!"
"Task1 done!"
400024900
./A  3.99s user 0.01s system 99% cpu 4.001 total


-threaded, with various N

whirlpool$ ghc-6.10.1.20090302 -O2 A.hs -threaded --make 
[1 of 1] Compiling Main ( A.hs, A.o )
Linking A ...

N=1

  whirlpool$ time ./A +RTS -N1 -sstderr
./A +RTS -N1 -sstderr 
"Task2 done!"
"Task1 done!"
590836900

   6,468,629,288 bytes allocated in the heap
 128,647,752 bytes copied during GC
   1,996,320 bytes maximum residency (563 sample(s))
 426,512 bytes maximum slop
   7 MB total memory in use (1 MB lost due to fragmentation)

  %GC time  61.0%  (62.1% elapsed)
^

  Alloc rate2,699,611,953 bytes per MUT second

  Productivity  39.0% of total user, 39.8% of total elapsed

./A +RTS -N1 -sstderr  6.14s user 0.06s system 102% cpu 6.016 total  

So 61% of time spent in GC.

N=2

whirlpool$ time ./A +RTS -N2 -sstderr  
./A +RTS -N2 -sstderr 
"Task2 done!"
"Task1 done!"
636039700

   6,511,269,512 bytes allocated in the heap
   3,684,592 bytes copied during GC
   1,566,800 bytes maximum residency (3 sample(s))
  34,496 bytes maximum slop
   5 MB total memory in use (1 MB lost due to fragmentation)

  %GC time  43.1%  (63.5% elapsed)

  Alloc rate1,384,112,532 bytes per MUT second

  Productivity  56.9% of total user, 82.8% of total elapsed

./A +RTS -N2 -sstderr  8.26s user 0.09s system 146% cpu 5.681 total

Getting rid of the space leaky version of fac:

whirlpool$ time ./A +RTS -N2 -H50M -sstderr 
./A +RTS -N2 -H50M -sstderr 
"Task1 done!"
"Task2 done!"
570035500

   6,512,828,504 bytes allocated in the heap
   1,224,488 bytes copied during GC
   6,656 bytes maximum residency (1 sample(s))
 116,136 bytes maximum slop
  50 MB total memory in use (1 MB lost due to fragmentation)

  %GC time  60.6%  (76.4% elapsed)

  Alloc rate2,778,330,289 bytes per MUT second

  Productivity  39.4% of total user, 49.5% of total elapsed

./A +RTS -N2 -H50M -sstderr  6.30s user 0.42s system 141% cpu 4.737 total

I'm not sure there's anything weird going on here, other than just naive
implementations of factorial making my cores hot.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Theory about uncurried functions

[Achim Schneider]

Peter Verswyvelen  wrote:

> Lambda calculus is a nice theory in which every function always has
> one input and one output. Functions with multiple arguments can be
> simulated because functions are first class and hence a function can
> "return" a function. Multiple outputs cannot be done, one must embed
> these outputs in some data type, e.g. using a tuple, or one must use
> continuation passing style.
> 
Both input- and output currying are completely orthogonal, for a
sufficiently bent definition of orthogonal:

forall f :: (a, b) -> c exists g :: a -> b -> c

"likewise":

forall f :: a -> (b, c) exists (g :: a -> c, h :: a -> c)


This is, of course, abstract nonsense[1]: Usually, splitting a function
with multiple retvals into two is just a crime against efficiency, if
not clarity. I doubt any compiler could be decisive enough to get
Sufficiently Smart in this context.

> Now, does a similar theory exist of functions that always have one
> input and one output, but these inputs and outputs are *always*
> tuples? Or maybe this does not make any sense?
>
I fear it doesn't, at least if the functions are allowed to be passed
and return tuples containing bottom or unit, as you'd be left with
syntactically awkward versions of single-argument functions, or unary
tuples, whatever. 

Generally speaking, functions are more fundamental than product
types[2]:

cons :: a -> b -> ((a -> b -> c) -> c)
cons a b m = m a b

car :: ((a -> b -> a) -> c) -> c)
car z = z (\p q -> p)

cdr :: ((a -> b -> b) -> c) -> c)
cdr z = z (\p q -> q)

...as a comparison, try to define eval and apply in terms of tuples.

OTOH, you might be thinking of things like applicative functors, which
are product types[2] and can't (necessarily) be escaped from, and not
collapsed, either, as would be the case with monads. These are things
that are described in terms of a theory, not a theory themselves,
though. The important notion is that inside a specific functor, one
part of its type always stays the same (or it wouldn't be that functor
anymore... duh.)

So, to conclude: You aren't likely to find any fundamental theory
restricting inputs and outputs to tuples, but you are going to find
fundamental theories that enable you to say very interesting things
about functions which have their inputs and outputs restricted to
arbitrary types, be it sums or products.


[1] Specifically, distilled from
http://golem.ph.utexas.edu/category/2008/03/computer_scientists_needed_now.html
, which is a _very_ good and enlightening read

[2] Stolen straight from Exercise 2.4 in the Wizard Book

[3] Of a type tag and a value. Stop nitpicking. Tagged lists spoiled me.

-- 
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.


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

Re: [Haskell-cafe] Threading and Mullticore Computation

[Andrew Coppin]

Svein Ove Aas wrote:

For what it's worth, I tried it myself on 6.10.. details follow, but
overall impression is that while you lose some time to overhead, it's
still 50% faster than unthreaded.
  


Damn. Somebody beat me to it. :-)


While trying to optimize it, I ran "./test +RTS -N2 -H64m -M64m"; the
program promptly ate all my memory, invoking the OOM killer and
messing up my system something fierce. This has to be a bug.
  


I should point out that approximately 50% of the time, the -N2 version 
exits with "Cores1: out of memory" rather than running to completion. 
The -N1 version never does this.


I hadn't looked at RAM usage, but it does appear that both programs 
use... rather a lot of this. (Measurable in gigabytes.) Space leak, 
anyone? (Presumably in fac or fac'.)


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

Re: [Haskell-cafe] Threading and Mullticore Computation

[Svein Ove Aas]

I feel the need to point something out here.

Both for me and Andrew, the program tops out at allocating ~22MB of
memory - in total, over its whole run.

Why, then, is max heap size over a gigabyte?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Threading and Mullticore Computation

[Andrew Coppin]

Brandon S. Allbery KF8NH wrote:

On 2009 Mar 3, at 12:54, mwin...@brocku.ca wrote:
I am using GHC 6.8.3. The -O2 option made both runs faster but the 2 
core run
is still much slower that the 1 core version. Will switching to 6.10 
make the difference?



If GC contention is the issue, it should.


I just tried it with GHC 6.10.1. Two capabilities is still slower. (See 
attachments. Compiled with -O2 -threaded.)


In both cases, GC time is miniscule.


 [("GHC RTS", "Yes")
 ,("GHC version", "6.10.1")
 ,("RTS way", "rts_thr")
 ,("Host platform", "i386-unknown-mingw32")
 ,("Build platform", "i386-unknown-mingw32")
 ,("Target platform", "i386-unknown-mingw32")
 ,("Compiler unregisterised", "NO")
 ,("Tables next to code", "YES")
 ]
Cores1 +RTS -N1 -s 
  16,918,324 bytes allocated in the heap
   1,055,836 bytes copied during GC
   1,005,356 bytes maximum residency (1 sample(s))
  29,760 bytes maximum slop
1260 MB total memory in use (112 MB lost due to fragmentation)

  Generation 0:32 collections, 0 parallel,  0.03s,  0.03s elapsed
  Generation 1: 1 collections, 0 parallel,  0.00s,  0.00s elapsed

  Task  0 (worker) :  MUT time:   2.53s  (  5.11s elapsed)
  GC  time:   0.02s  (  0.02s elapsed)

  Task  1 (worker) :  MUT time:   0.00s  (  5.11s elapsed)
  GC  time:   0.00s  (  0.00s elapsed)

  Task  2 (worker) :  MUT time:   2.30s  (  5.11s elapsed)
  GC  time:   0.02s  (  0.02s elapsed)

  INIT  time0.02s  (  0.00s elapsed)
  MUT   time4.83s  (  5.11s elapsed)
  GCtime0.03s  (  0.03s elapsed)
  EXIT  time0.00s  (  0.00s elapsed)
  Total time4.88s  (  5.14s elapsed)

  %GC time   0.6%  (0.6% elapsed)

  Alloc rate3,492,815 bytes per MUT second

  Productivity  99.0% of total user, 93.9% of total elapsed

recordMutableGen_sync: 0
gc_alloc_block_sync: 0
whitehole_spin: 0
gen[0].steps[0].sync_todo: 0
gen[0].steps[0].sync_large_objects: 0
gen[0].steps[1].sync_todo: 0
gen[0].steps[1].sync_large_objects: 0
gen[1].steps[0].sync_todo: 0
gen[1].steps[0].sync_large_objects: 0
Cores1 +RTS -N2 -s 
  16,926,532 bytes allocated in the heap
   1,243,560 bytes copied during GC
 794,980 bytes maximum residency (2 sample(s))
  12,012 bytes maximum slop
1927 MB total memory in use (160 MB lost due to fragmentation)

  Generation 0:23 collections, 8 parallel,  0.00s,  0.00s elapsed
  Generation 1: 2 collections, 0 parallel,  0.02s,  0.02s elapsed

  Parallel GC work balance: 1.00 (1267 / 1267, ideal 2)

  Task  0 (worker) :  MUT time:   0.00s  (  0.00s elapsed)
  GC  time:   0.00s  (  0.00s elapsed)

  Task  1 (worker) :  MUT time:   3.63s  (  4.67s elapsed)
  GC  time:   0.00s  (  0.00s elapsed)

  Task  2 (worker) :  MUT time:   0.00s  (  4.67s elapsed)
  GC  time:   0.00s  (  0.00s elapsed)

  Task  3 (worker) :  MUT time:   3.42s  (  4.67s elapsed)
  GC  time:   0.02s  (  0.02s elapsed)

  Task  4 (worker) :  MUT time:   0.00s  (  4.67s elapsed)
  GC  time:   0.00s  (  0.00s elapsed)

  INIT  time0.02s  (  0.00s elapsed)
  MUT   time7.05s  (  4.67s elapsed)
  GCtime0.02s  (  0.02s elapsed)
  EXIT  time0.00s  (  0.00s elapsed)
  Total time7.08s  (  4.69s elapsed)

  %GC time   0.2%  (0.3% elapsed)

  Alloc rate2,396,677 bytes per MUT second

  Productivity  99.6% of total user, 150.3% of total elapsed

recordMutableGen_sync: 0
gc_alloc_block_sync: 0
whitehole_spin: 0
gen[0].steps[0].sync_todo: 0
gen[0].steps[0].sync_large_objects: 0
gen[0].steps[1].sync_todo: 0
gen[0].steps[1].sync_large_objects: 0
gen[1].steps[0].sync_todo: 0
gen[1].steps[0].sync_large_objects: 0
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Threading and Mullticore Computation

[Svein Ove Aas]

On Tue, Mar 3, 2009 at 6:54 PM,   wrote:
> I am using GHC 6.8.3. The -O2 option made both runs faster but the 2 core run
> is still much slower that the 1 core version. Will switching to 6.10 make the 
> difference?
>
There are a lot of improvements; it's certainly worth a try.

For what it's worth, I tried it myself on 6.10.. details follow, but
overall impression is that while you lose some time to overhead, it's
still 50% faster than unthreaded.

While trying to optimize it, I ran "./test +RTS -N2 -H64m -M64m"; the
program promptly ate all my memory, invoking the OOM killer and
messing up my system something fierce. This has to be a bug.

GC time only accounts for 10% of the time used, but as I read these,
the parallell GC didn't do any good.

..I'm stumped.

 time ./test +RTS -N1 -s 
"Task1 done!"
"Task2 done!"
57500
  22,712,520 bytes allocated in the heap
   2,982,440 bytes copied during GC
   1,983,288 bytes maximum residency (2 sample(s))
  30,208 bytes maximum slop
 636 MB total memory in use (58 MB lost due to fragmentation)

  Generation 0:42 collections, 0 parallel,  0.12s,  0.13s elapsed
  Generation 1: 2 collections, 0 parallel,  0.00s,  0.01s elapsed

  Task  0 (worker) :  MUT time:   2.85s  (  6.09s elapsed)
  GC  time:   0.07s  (  0.08s elapsed)

  Task  1 (worker) :  MUT time:   0.00s  (  6.09s elapsed)
  GC  time:   0.00s  (  0.00s elapsed)

  Task  2 (worker) :  MUT time:   2.66s  (  6.09s elapsed)
  GC  time:   0.05s  (  0.06s elapsed)

  INIT  time0.00s  (  0.00s elapsed)
  MUT   time4.78s  (  6.09s elapsed)
  GCtime0.12s  (  0.14s elapsed)
  EXIT  time0.00s  (  0.00s elapsed)
  Total time4.81s  (  6.23s elapsed)

  %GC time   2.5%  (2.3% elapsed)

  Alloc rate4,842,754 bytes per MUT second

  Productivity  97.5% of total user, 75.3% of total elapsed

recordMutableGen_sync: 0
gc_alloc_block_sync: 0
whitehole_spin: 0
gen[0].steps[0].sync_todo: 0
gen[0].steps[0].sync_large_objects: 0
gen[0].steps[1].sync_todo: 0
gen[0].steps[1].sync_large_objects: 0
gen[1].steps[0].sync_todo: 0
gen[1].steps[0].sync_large_objects: 0

real0m6.319s
user0m4.810s
sys 0m0.920s


 time ./test +RTS -N2 -s 
"Task2 done!"
"Task1 done!"
68600
  22,734,040 bytes allocated in the heap
   2,926,160 bytes copied during GC
   1,976,240 bytes maximum residency (2 sample(s))
 117,584 bytes maximum slop
1234 MB total memory in use (107 MB lost due to fragmentation)

  Generation 0:32 collections,13 parallel,  0.47s,  0.43s elapsed
  Generation 1: 2 collections, 0 parallel,  0.01s,  0.01s elapsed

  Parallel GC work balance: 1.00 (4188 / 4188, ideal 2)

  Task  0 (worker) :  MUT time:   0.00s  (  0.00s elapsed)
  GC  time:   0.00s  (  0.00s elapsed)

  Task  1 (worker) :  MUT time:   0.00s  (  0.00s elapsed)
  GC  time:   0.00s  (  0.00s elapsed)

  Task  2 (worker) :  MUT time:   3.10s  (  3.82s elapsed)
  GC  time:   0.09s  (  0.05s elapsed)

  Task  3 (worker) :  MUT time:   2.96s  (  3.82s elapsed)
  GC  time:   0.39s  (  0.39s elapsed)

  Task  4 (worker) :  MUT time:   0.00s  (  3.82s elapsed)
  GC  time:   0.00s  (  0.00s elapsed)

  INIT  time0.00s  (  0.00s elapsed)
  MUT   time5.23s  (  3.82s elapsed)
  GCtime0.48s  (  0.44s elapsed)
  EXIT  time0.01s  (  0.00s elapsed)
  Total time5.72s  (  4.26s elapsed)

  %GC time   8.4%  (10.4% elapsed)

  Alloc rate4,338,557 bytes per MUT second

  Productivity  91.6% of total user, 123.0% of total elapsed

recordMutableGen_sync: 0
gc_alloc_block_sync: 0
whitehole_spin: 0
gen[0].steps[0].sync_todo: 0
gen[0].steps[0].sync_large_objects: 0
gen[0].steps[1].sync_todo: 0
gen[0].steps[1].sync_large_objects: 0
gen[1].steps[0].sync_todo: 0
gen[1].steps[0].sync_large_objects: 0

real0m4.345s
user0m5.680s
sys 0m1.250s
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Threading and Mullticore Computation

[Brandon S. Allbery KF8NH]

On 2009 Mar 3, at 12:54, mwin...@brocku.ca wrote:
I am using GHC 6.8.3. The -O2 option made both runs faster but the 2  
core run
is still much slower that the 1 core version. Will switching to 6.10  
make the difference?



If GC contention is the issue, it should.

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Threading and Mullticore Computation

[mwinter]

I am using GHC 6.8.3. The -O2 option made both runs faster but the 2 core run
is still much slower that the 1 core version. Will switching to 6.10 make the 
difference?

On 3 Mar 2009 at 18:46, Svein Ove Aas wrote:

> On Tue, Mar 3, 2009 at 6:41 PM, Don Stewart  wrote:
> > allbery:
> >> On 2009 Mar 3, at 12:31, mwin...@brocku.ca wrote:
> >>> In both runs the same computations are done (sequentially resp.
> >>> parallel), so the gc should be the same. But still using 2 cores is
> >>> much slower than using 1 core (same program - no communication).
> >>
> >> The same GCs are done, but GC has to be done on a single core
> >> (currently; parallel GC is in development) so you will see a lot more
> >> lock contention when the GC kicks in.
> >>
> >
> > Assuming he is using GHC 6.10, the parallel GC is enabled by default
> > when you use -Nn where n > 1. That's is -N4 will use -g4   (4 cores to
> > collect). So GC should be the same or a little faster.
> >
> Further, GHC (6.10 at least) uses one allocation area per thread,
> meaning there's no contention on allocation.
>
> I'd echo the request to try it with -O2, though.
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe


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

Re: [Haskell-cafe] Threading and Mullticore Computation

[Svein Ove Aas]

On Tue, Mar 3, 2009 at 6:41 PM, Don Stewart  wrote:
> allbery:
>> On 2009 Mar 3, at 12:31, mwin...@brocku.ca wrote:
>>> In both runs the same computations are done (sequentially resp.
>>> parallel), so the gc should be the same. But still using 2 cores is
>>> much slower than using 1 core (same program - no communication).
>>
>> The same GCs are done, but GC has to be done on a single core
>> (currently; parallel GC is in development) so you will see a lot more
>> lock contention when the GC kicks in.
>>
>
> Assuming he is using GHC 6.10, the parallel GC is enabled by default
> when you use -Nn where n > 1. That's is -N4 will use -g4   (4 cores to
> collect). So GC should be the same or a little faster.
>
Further, GHC (6.10 at least) uses one allocation area per thread,
meaning there's no contention on allocation.

I'd echo the request to try it with -O2, though.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Threading and Mullticore Computation

[Don Stewart]

allbery:
> On 2009 Mar 3, at 12:31, mwin...@brocku.ca wrote:
>> In both runs the same computations are done (sequentially resp.
>> parallel), so the gc should be the same. But still using 2 cores is
>> much slower than using 1 core (same program - no communication).
>
> The same GCs are done, but GC has to be done on a single core  
> (currently; parallel GC is in development) so you will see a lot more  
> lock contention when the GC kicks in.
>

Assuming he is using GHC 6.10, the parallel GC is enabled by default
when you use -Nn where n > 1. That's is -N4 will use -g4   (4 cores to
collect). So GC should be the same or a little faster.

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

Re: [Haskell-cafe] Threading and Mullticore Computation

[Don Stewart]

mwinter:
> Hi,
> 
> I tried a get into concurrent Haskell using multiple cores. The program below
> creates 2 task in different threads, executes them, synchronizes the threads
> using MVar () and calculates the time needed. 
> 
> import System.CPUTime
> import Control.Concurrent
> import Control.Concurrent.MVar
> 
> myTask1 = do
> return $! fac 6
> print "Task1 done!"
>   where fac 0 = 1
> fac n = n * fac (n-1)
>  
> myTask2 = do
> return $! fac' 6 1 1
> print "Task2 done!"
>   where fac' n m p = if  m>n then p else fac'  n (m+1) (m*p)
> 
> main = do
>  mvar <- newEmptyMVar
>  pico1 <- getCPUTime
>  forkIO (myTask1 >> putMVar mvar ())
>  myTask2
>  takeMVar mvar
>  pico2 <- getCPUTime
>  print (pico2 - pico1)
> 
> 
> I compiled the code using
> $ ghc FirstFork.hs -threaded
> and executed it by
> $ main +RTS -N1   resp.   $ main +RTS -N2
> I use GHC 6.8.3 on Vista with an Intel Dual Core processor. Instead of getting
> a speed up when using 2 cores I get as significant slow down, even though 
> there
> is no sharing in my code above (at least none I am aware of. BTW, that was
> reason
> that I use 2 different local factorial functions). On my computer the 1-core
> version
> takes about 8.3sec and the 2-core version 12.8sec. When I increase the numbers
> from 6 to 10 the time difference gets even worse (30sec vs 51 sec). 
> Can
> anybody give me an idea what I am doing wrong?


If you just want to check that your machine can do multicore, here's the
"hello world" I've been using:

import Control.Parallel

main = a `par` b `par` c `pseq` print (a + b + c)
where
a = ack 3 10
b = fac 42
c = fib 34

fac 0 = 1
fac n = n * fac (n-1)

ack 0 n = n+1
ack m 0 = ack (m-1) 1
ack m n = ack (m-1) (ack m (n-1))

fib 0 = 0
fib 1 = 1
fib n = fib (n-1) + fib (n-2)

To be run as:

$ ghc -O2 -threaded --make hello.hs 
[1 of 1] Compiling Main ( hello.hs, hello.o )
Linking hello ...

$ time ./hello +RTS -N2 
1405006117752879898543142606244511569936384005711076
./hello +RTS -N2  2.29s user 0.01s system 152% cpu 1.505 total
  

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

Re: [Haskell-cafe] DSLs with {in,}equalities

[Andrew Wagner]

Err, I was actually talking about the thread subject, where he actually has
the word "{in,}equalities", short for "inequalities and equalities" (more or
less). AFAIK, that's unix notation.

On Tue, Mar 3, 2009 at 12:36 PM, Brandon S. Allbery KF8NH <
allb...@ece.cmu.edu> wrote:

> On 2009 Mar 3, at 12:25, Andrew Wagner wrote:
>
> Not to hijack the thread, but I thought I was the only one that used unix
> notation for statements like {in,}equalities. I like it!
>
>
> It's actually closer to Windows notation with the bracket on both sides
> (and I actually considered making it %<% but to me that looks more
> cluttered, plus the S-curve in $ can be a mnemonic for "symbolic" for those
> who don't live their lives on Unix).
>
> --
> brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
> system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
> electrical and computer engineering, carnegie mellon universityKF8NH
>
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re[2]: [Haskell-cafe] Threading and Mullticore Computation

[Bulat Ziganshin]

Hello mwinter,

Tuesday, March 3, 2009, 8:31:12 PM, you wrote:

not same :)  when you perform two computations at the same time,
you have 2x more memory allocated that means that each GC will need
more time. and don't forget that GC is single-threaded

> In both runs the same computations are done (sequentially resp.
> parallel), so the gc should be the same. But still using 2 cores is
> much slower than using 1 core (same program - no communication).

> On 3 Mar 2009 at 20:21, Bulat Ziganshin wrote:

>> Hello mwinter,
>> 
>> Tuesday, March 3, 2009, 8:09:21 PM, you wrote:
>> 
>> >anybody give me an idea what I am doing wrong?
>> 
>> 1. add -O2 to compile command
>> 2. add +RTS -s to run commands
>> 
>> your program execution time may be dominated by GCs
>> 
>> 
>> -- 
>> Best regards,
>>  Bulatmailto:bulat.zigans...@gmail.com


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


-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

Re: [Haskell-cafe] Threading and Mullticore Computation

[Brandon S. Allbery KF8NH]

On 2009 Mar 3, at 12:31, mwin...@brocku.ca wrote:

In both runs the same computations are done (sequentially resp.
parallel), so the gc should be the same. But still using 2 cores is
much slower than using 1 core (same program - no communication).


The same GCs are done, but GC has to be done on a single core  
(currently; parallel GC is in development) so you will see a lot more  
lock contention when the GC kicks in.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] DSLs with {in,}equalities

[Brandon S. Allbery KF8NH]

On 2009 Mar 3, at 12:25, Andrew Wagner wrote:
Not to hijack the thread, but I thought I was the only one that used  
unix notation for statements like {in,}equalities. I like it!


It's actually closer to Windows notation with the bracket on both  
sides (and I actually considered making it %<% but to me that looks  
more cluttered, plus the S-curve in $ can be a mnemonic for "symbolic"  
for those who don't live their lives on Unix).


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Threading and Mullticore Computation

[mwinter]

It gets a bit faster in general but the problem remains. I have two
threads in both runs, once I use 1 core and then 2 cores. The second
run is much slower.

On 3 Mar 2009 at 17:32, Sebastian Sylvan wrote:

> 
> 
> 
> On Tue, Mar 3, 2009 at 5:31 PM,  wrote:
> In both runs the same computations are done (sequentially resp.
> parallel), so the gc should be the same. But still using 2 cores is
> much slower than using 1 core (same program - no communication). 
> 
> Might there not be contention in the allocator/GC that's worsened by having 
> two threads? 
> What happens with -O2?
> --
> Sebastian Sylvan
> +44(0)7857-300802
> UIN: 44640862 
> 


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

Re: [Haskell-cafe] Threading and Mullticore Computation

[Sebastian Sylvan]

On Tue, Mar 3, 2009 at 5:31 PM,  wrote:

> In both runs the same computations are done (sequentially resp.
> parallel), so the gc should be the same. But still using 2 cores is
> much slower than using 1 core (same program - no communication).


Might there not be contention in the allocator/GC that's worsened by having
two threads?
What happens with -O2?
-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Threading and Mullticore Computation

[mwinter]

In both runs the same computations are done (sequentially resp.
parallel), so the gc should be the same. But still using 2 cores is
much slower than using 1 core (same program - no communication).

On 3 Mar 2009 at 20:21, Bulat Ziganshin wrote:

> Hello mwinter,
> 
> Tuesday, March 3, 2009, 8:09:21 PM, you wrote:
> 
> >anybody give me an idea what I am doing wrong?
> 
> 1. add -O2 to compile command
> 2. add +RTS -s to run commands
> 
> your program execution time may be dominated by GCs
> 
> 
> -- 
> Best regards,
>  Bulatmailto:bulat.zigans...@gmail.com


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

Re: [Haskell-cafe] monadic MapReduce

[Tim Newsham]

How about this. Is there a reason why I can't
replace the variables b and c in the type signature of mapReduce with with (IO 
b')
and (IO c'). b and c  can be any types.

mapReduce :: Strategy (IO b')-- evaluation strategy for mapping
  -> (a -> IO b')  -- map function
  -> Strategy (IO c')-- evaluation strategy for reduction
  -> ([IO b'] -> (IO c'))-- reduce function
  -> [a]   -- list to map over
  -> (IO c')

Just remember to wrap all values back in the IO monad.


Remember, the idea of map-reduce is to provide a very restrictive
programming interface so that you have a lot of flexibility in
your execution strategy.  If you start loosening the interface
you will still be able to execute the program, but you may
not be able to perform all the great optimizations you want to
perform.  For example, if you are using IO actions that are
stateful, what are the semantics?  Can one map action affect
other map actions?  Does this imply an ordering of the map functions?
Does this imply they all run on the same machine or at least have
state communicated between the machines on which they run?

The austere interface precludes any of these issues, and therein
lies the beauty.


Anish


Btw. I prefer the sawzall formulation over the map-reduce formulation.
A sawzall program just specifies how to map some data to a monoid
and the system is free to mappend the monoid values in whatever order
it wants (by applying associativity).

Tim Newsham
http://www.thenewsh.com/~newsham/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] DSLs with {in,}equalities

[Andrew Wagner]

Not to hijack the thread, but I thought I was the only one that used unix
notation for statements like {in,}equalities. I like it!

On Mon, Mar 2, 2009 at 11:13 PM, Andrew Hunter  wrote:

> Several times now I've had to define an EDSL for working with
> (vaguely) numeric expressions.  For stuff like 2*X+Y, this is easy,
> looking pretty much like:
>
> > data Expr = Const Integer | Plus Expr Expr | Times Expr Expr
> >
> > instance Num Expr where
> > fromInterger = Const
> > (+) = Plus
> > (*) = Times
>
> &c.  This lets me get a perfectly nice AST, which is what I want.
> When I want to be able to express and work with inequalities and
> equalities, this breaks.  Suppose I want to write 2*X + Y < 3.  I
> either have to:
>
> a) Hide Prelude.(<) and define a simple < that builds the AST term I want.
> b) Come up with a new symbol for it that doesn't look totally awful.
>
> Neither of these work decently well.  Hiding Eq and Ord operators,
> which is what I effectively have to do for a), is pretty much a
> nonstarter--we'll have to use them too much for that to be practical.
>
> On the other hand, b) works...but is about as ugly as it gets.  We
> have lots and lots of symbols that are already taken for important
> purposes that are syntactically "near" <,<=,==, and the like: << and
> >> and >>= for monads, >>> for arrows, etc.  There...are not good
> choices that I know of for the symbols that don't defeat the purpose
> of making a nice clean EDSL for expressions; I might as well use 3*X +
> Y `lessthan` 3, which is just not cool.
>
> Does anyone know of a good solution, here?  Are there good
> substitutions for all the six operators that are important
> (<,>,>=,<=,==,/=), that are close enough to be pretty-looking but not
> used for other important modules?
>
> Better yet, though a little harder, is there a nice type trick I'm not
> thinking of?  This works for Num methods but not for Ord methods
> because:
>
> (+) :: (Num a) => a -> a -> a
> (<) :: (Ord a) => a -> a -> Bool
>
> i.e. the return type of comparisons is totally fixed.  I don't suppose
> there's a good way to...well, I don't know what the *right* answer is,
> but maybe define a new typeclass with a more flexible type for < that
> lets both standard types return Bool and my expressions return Expr?
> Any good solution would be appreciated.
>
> Thanks,
> AHH
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Threading and Mullticore Computation

[Bulat Ziganshin]

Hello mwinter,

Tuesday, March 3, 2009, 8:09:21 PM, you wrote:

>anybody give me an idea what I am doing wrong?

1. add -O2 to compile command
2. add +RTS -s to run commands

your program execution time may be dominated by GCs


-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

Re: [Haskell-cafe] possible memory leak in uvector 0.1.0.3

[Manlio Perillo]

Claus Reinke ha scritto:
I split the string in lines, then map some functions on each line to 
parse the data, and finally calling toU, for converting to an UArr.


Just to make sure (code fragments or, better, reduced examples
would make it easier to see what the discussion is about): are you 
forcing the UArr to be constructed before putting it into the Map?


parse handle =
  contents <- S.hGetContents handle
  let v =  map singleton' $ ratings contents
  let m = foldl1' (unionWith appendU) v
  v `seq` return $! m

  where
-- Build a Map with a single movie rating
singleton' :: (Word32, Word8) -> MovieRatings
singleton' (id, rate) =
  singleton (fromIntegral $ id) (singletonU $ pairS (id, rate))


That helps to make things clearer, I think. One issue is
the nature of Maps (strict in keys, non-strict in values).

- neither singleton nor unionWith are strict in the Map values, so
   nothing here forces the evaluation of rate or constructionof UArr



But, as I have written, in one of my tests I also tried rnf to force 
evaluation:

rnf v `seq` rnf m `seq` return m

where:

instance NFData a => NFData (Data.IntMap.IntMap a) where
rnf = rnf . Data.IntMap.toList


Isn't this sufficient?


[...]
- seq on a list only forces the first node of the list ((:),[],_|_),
   so (v `seq`) isn't likely to help much. Also, you probably
   do not want to force the whole list of singletons before
   builing the Map, you want the singletons to be constructedand 
consumed incrementally.




Right, thanks.




type Rating = Word32 :*: Word8
type MovieRatings = IntMap (UArr Rating) -- UArr from uvector


A standard trick to keep Map values evaluated by construction
is to make the availability of keys dependent on their values, eg
(singleton key) $! value. That won't help with unionWith and
the appendUs, but it should allow the source string references
to be dropped early, as the singletons are constructed.



Tried; but, even using union instead of unionWith, the memory grows fast 
as before.



Just to check if the culprit is IntMap, isn't possible to write a test 
program that build a big IntMap (UArr Int) ?


Right now I don't have the time.



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

Re: [Haskell-cafe] DSLs with {in,}equalities

[Brandon S. Allbery KF8NH]

On 2009 Mar 2, at 23:13, Andrew Hunter wrote:
a) Hide Prelude.(<) and define a simple < that builds the AST term I  
want.

b) Come up with a new symbol for it that doesn't look totally awful.


I guess aesthetics differ; I'd use e.g. $<$, where the $ (to me, from  
other contexts) means "symbolic".


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Theory about uncurried functions

[Luke Palmer]

On Tue, Mar 3, 2009 at 2:43 AM, Peter Verswyvelen  wrote:

> Lambda calculus is a nice theory in which every function always has
> one input and one output. Functions with multiple arguments can be
> simulated because functions are first class and hence a function can
> "return" a function. Multiple outputs cannot be done, one must embed
> these outputs in some data type, e.g. using a tuple, or one must use
> continuation passing style.
>
> Now, does a similar theory exist of functions that always have one
> input and one output, but these inputs and outputs are *always*
> tuples? Or maybe this does not make any sense?


Well, this is not quite an answer to your question, but the curried multiple
arguments convention in Haskell is exactly that: a convention.  For example,
in ML, most functions which take multiple arguments take them in the form of
a tuple.  They could just as well be curried, but the culture prefers
tuples.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Threading and Mullticore Computation

[mwinter]

Hi,

I tried a get into concurrent Haskell using multiple cores. The program below
creates 2 task in different threads, executes them, synchronizes the threads
using MVar () and calculates the time needed.  

import System.CPUTime
import Control.Concurrent
import Control.Concurrent.MVar

myTask1 = do
return $! fac 6
print "Task1 done!"
  where fac 0 = 1
fac n = n * fac (n-1)
  
myTask2 = do
return $! fac' 6 1 1
print "Task2 done!"
  where fac' n m p = if  m>n then p else fac'  n (m+1) (m*p)

main = do
 mvar <- newEmptyMVar
 pico1 <- getCPUTime
 forkIO (myTask1 >> putMVar mvar ())
 myTask2
 takeMVar mvar
 pico2 <- getCPUTime
 print (pico2 - pico1)
 

I compiled the code using 
$ ghc FirstFork.hs -threaded
and executed it by
$ main +RTS -N1   resp.   $ main +RTS -N2
I use GHC 6.8.3 on Vista with an Intel Dual Core processor. Instead of getting
a speed up when using 2 cores I get as significant slow down, even though there 
is no sharing in my code above (at least none I am aware of. BTW, that was 
reason 
that I use 2 different local factorial functions). On my computer the 1-core 
version 
takes about 8.3sec and the 2-core version 12.8sec. When I increase the numbers 
from 6 to 10 the time difference gets even worse (30sec vs 51 sec). Can 
anybody give me an idea what I am doing wrong?

Thanks,
Michael



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

Re: Re[Haskell-cafe] [2]: interaction between ghci and cudaBLAS library

[Simon Beaumont]

Simon Beaumont wrote:
> 
> 
> Bulat Ziganshin-2 wrote:
>> 
>> Hello Don,
>> 
>> Tuesday, March 3, 2009, 5:22:46 AM, you wrote:
>> 
>>> GHCi doesn't use the threaded runtime though.  So given that:
>> 
>> Don, afair ghci compiled using threaded runtime since 6.6:
>> 
>> Prelude> :m Control.Concurrent
>> Prelude Control.Concurrent> rtsSupportsBoundThreads
>> True
>> 
> 
> That's what I thought - the problem seems to be with the interaction
> between ghci threads (there are four OS threads running on my machine).  I
> read the conc-ffi paper by Simon Marlow, Simon Peyton-Jones and Wolfgang
> Thaller and whilst that explained the situation regarding bound threads
> (and indeed how to ensure running a bunch of actions within the same
> thread context - which gave me some hope), I am still no wiser as to what
> is going on here and how it can be fixed. It at all.
> 
> 

BTW if I wrap a forkOS around this I get control back in the ghci - which
confirms the threadedness of that at least but still the ffi call blocks.
I'm going to take a closer look inside with gdb again, this feels like some
kind of deadlock. Given that in the conc-ffi paper this kind of interaction
was anticipated we are not outside the design envelope of ghc(i) so there
must be a way to solve this. 



-- 
View this message in context: 
http://www.nabble.com/interaction-between-ghci-and-cudaBLAS-library-tp22300813p22311236.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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

Re: Re[Haskell-cafe] [2]: interaction between ghci and cudaBLAS library

[Simon Beaumont]

Bulat Ziganshin-2 wrote:
> 
> Hello Don,
> 
> Tuesday, March 3, 2009, 5:22:46 AM, you wrote:
> 
>> GHCi doesn't use the threaded runtime though.  So given that:
> 
> Don, afair ghci compiled using threaded runtime since 6.6:
> 
> Prelude> :m Control.Concurrent
> Prelude Control.Concurrent> rtsSupportsBoundThreads
> True
> 

That's what I thought - the problem seems to be with the interaction between
ghci threads (there are four OS threads running on my machine).  I read the
conc-ffi paper by Simon Marlow, Simon Peyton-Jones and Wolfgang Thaller and
whilst that explained the situation regarding bound threads (and indeed how
to ensure running a bunch of actions within the same thread context - which
gave me some hope), I am still no wiser as to what is going on here and how
it can be fixed. It at all.



-- 
View this message in context: 
http://www.nabble.com/interaction-between-ghci-and-cudaBLAS-library-tp22300813p22310841.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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

Re: [Haskell-cafe] possible memory leak in uvector 0.1.0.3

[Claus Reinke]

I split the string in lines, then map some functions on each line to 
parse the data, and finally calling toU, for converting to an UArr.


Just to make sure (code fragments or, better, reduced examples
would make it easier to see what the discussion is about): are you 
forcing the UArr to be constructed before putting it into the Map?


parse handle =
  contents <- S.hGetContents handle
  let v =  map singleton' $ ratings contents
  let m = foldl1' (unionWith appendU) v
  v `seq` return $! m

  where
-- Build a Map with a single movie rating
singleton' :: (Word32, Word8) -> MovieRatings
singleton' (id, rate) =
  singleton (fromIntegral $ id) (singletonU $ pairS (id, rate))


That helps to make things clearer, I think. One issue is
the nature of Maps (strict in keys, non-strict in values).

- neither singleton nor unionWith are strict in the Map values, so
   nothing here forces the evaluation of rate or construction 
   of UArr


   Prelude Data.IntMap> (unionWith (++) (singleton 1 undefined) (singleton 2 
undefined)) `seq` ()
   ()

- singletonU is strict, but that only means that it will evaluate its
   parameter if it is evaluated itself (which it isn't, because 
   singleton isn't strict)


- seq on a list only forces the first node of the list ((:),[],_|_),
   so (v `seq`) isn't likely to help much. Also, you probably
   do not want to force the whole list of singletons before
   builing the Map, you want the singletons to be constructed 
   and consumed incrementally.


- forcing a Map doesn't force any of the values, nor does
   it force more than the top-level node of whatever the
   internal Map representation is, so (return $! m) isn't much
   help, either (by nature of unionWith and foldl1', it'll force 
   all keys before it can say anything much about the Map,

   but the values remain untouched, burried further under
   unevaluated (++)s)


type Rating = Word32 :*: Word8
type MovieRatings = IntMap (UArr Rating) -- UArr from uvector


A standard trick to keep Map values evaluated by construction
is to make the availability of keys dependent on their values, eg
(singleton key) $! value. That won't help with unionWith and
the appendUs, but it should allow the source string references
to be dropped early, as the singletons are constructed.

Hth,
Claus

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

Re: [Haskell-cafe] possible memory leak in uvector 0.1.0.3

[Manlio Perillo]

Daniel Fischer ha scritto:

Am Dienstag, 3. März 2009 15:35 schrieb Manlio Perillo:

Claus Reinke ha scritto:

At first guess it sounds like you're holding onto too much, if not the
whole stream perhaps bits within each chunk.

It is possible.

I split the string in lines, then map some functions on each line to
parse the data, and finally calling toU, for converting to an UArr.

Just to make sure (code fragments or, better, reduced examples
would make it easier to see what the discussion is about): are you
forcing the UArr to be constructed before putting it into the Map?

parse handle =
   contents <- S.hGetContents handle
   let v =  map singleton' $ ratings contents
   let m = foldl1' (unionWith appendU) v
   v `seq` return $! m


The (v `seq` ) is completely useless.
Maybe 
	(size m) `seq` return m

would help?



In one of my tests I did:

  rnf v `seq` rnf m `seq` return m

Memory usage was the same


-- XXX these are missing from uvector package
instance (NFData a, NFData b) => NFData (a :*: b) where
-- NOTE: (:*:) is already strict
rnf (a :*: b) = a `seq` b `seq` ()

instance NFData a => NFData (UArr a) where
-- NOTE: UArr is already strict
rnf array = array `seq` ()


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

Re[2]: [Haskell-cafe] possible memory leak in uvector 0.1.0.3

[Bulat Ziganshin]

Hello Daniel,

Tuesday, March 3, 2009, 5:47:36 PM, you wrote:

>>let v =  map singleton' $ ratings contents
>>let m = foldl1' (unionWith appendU) v
>>v `seq` return $! m

> The (v `seq` ) is completely useless.
> Maybe 
> (size m) `seq` return m
> would help?

i suggest
   return $! length v
   return $! size m

(if size really scans tree instead of using stored value :)

-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

Re[2]: [Haskell-cafe] possible memory leak in uvector 0.1.0.3

[Bulat Ziganshin]

Hello Manlio,

Tuesday, March 3, 2009, 5:35:33 PM, you wrote:

> There are 100,000,000 ratings, so I create 100,000,000 arrays containing
> only one element.

every array needs ~30 bytes - it's a minimal memory block ghc can
alloc for variable-sized objects. multiple this by 3 to account for
copying GC behavior


-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

Re: [Haskell-cafe] possible memory leak in uvector 0.1.0.3

[Daniel Fischer]

Am Dienstag, 3. März 2009 15:35 schrieb Manlio Perillo:
> Claus Reinke ha scritto:
> >>> At first guess it sounds like you're holding onto too much, if not the
> >>> whole stream perhaps bits within each chunk.
> >>
> >> It is possible.
> >>
> >> I split the string in lines, then map some functions on each line to
> >> parse the data, and finally calling toU, for converting to an UArr.
> >
> > Just to make sure (code fragments or, better, reduced examples
> > would make it easier to see what the discussion is about): are you
> > forcing the UArr to be constructed before putting it into the Map?
>
> parse handle =
>contents <- S.hGetContents handle
>let v =  map singleton' $ ratings contents
>let m = foldl1' (unionWith appendU) v
>v `seq` return $! m

The (v `seq` ) is completely useless.
Maybe 
(size m) `seq` return m
would help?

>
>where
>  -- Build a Map with a single movie rating
>  singleton' :: (Word32, Word8) -> MovieRatings
>  singleton' (id, rate) =
>singleton (fromIntegral $ id) (singletonU $ pairS (id, rate))

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

Re: [Haskell-cafe] possible memory leak in uvector 0.1.0.3

[Manlio Perillo]

Claus Reinke ha scritto:

At first guess it sounds like you're holding onto too much, if not the
whole stream perhaps bits within each chunk. 


It is possible.

I split the string in lines, then map some functions on each line to 
parse the data, and finally calling toU, for converting to an UArr.


Just to make sure (code fragments or, better, reduced examples
would make it easier to see what the discussion is about): are you 
forcing the UArr to be constructed before putting it into the Map?




parse handle =
  contents <- S.hGetContents handle
  let v =  map singleton' $ ratings contents
  let m = foldl1' (unionWith appendU) v
  v `seq` return $! m

  where
-- Build a Map with a single movie rating
singleton' :: (Word32, Word8) -> MovieRatings
singleton' (id, rate) =
  singleton (fromIntegral $ id) (singletonU $ pairS (id, rate))

This function gets called over each file, with

r <- mapM parse' [1..17770]
let movieRatings = foldl1' (unionWith appendU) r



The `ratings` function parse each line of the file, and return a tuple.
For each line of the file I build an IntMap, then merge them together;
The IntMaps, are then further merged in the main function.

NOTE that the memory usage is the same if I remove array concatenation.


There are 100,000,000 ratings, so I create 100,000,000 arrays containing 
only one element.

However, memory usage is 1 GB just after 800 files.


The data type is:

type Rating = Word32 :*: Word8
type MovieRatings = IntMap (UArr Rating) -- UArr from uvector


Code is here: http://haskell.mperillo.ath.cx/netflix-0.0.1.tar.gz
but it is an old version (where I used lazy ByteString).



Thanks  Manlio Perillo


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

Re: [Haskell-cafe] Theory about uncurried functions

[Derek Elkins]

On Tue, 2009-03-03 at 10:43 +0100, Peter Verswyvelen wrote:
> Lambda calculus is a nice theory in which every function always has
> one input and one output. Functions with multiple arguments can be
> simulated because functions are first class and hence a function can
> "return" a function. Multiple outputs cannot be done, one must embed
> these outputs in some data type, e.g. using a tuple, or one must use
> continuation passing style.
> 
> Now, does a similar theory exist of functions that always have one
> input and one output, but these inputs and outputs are *always*
> tuples? Or maybe this does not make any sense?

There's the kappa calculus and also the related Freyd categories which
are related to arrows.  Theres also the theory induced by cartesian
categories or the theory induced by (symmetric) monoidal categories
(which are strengthenings of Freyd categories).

You could probably also formalize such a language yourself.

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

Re: [Haskell-cafe] ANNOUNCE: Extensible and Modular Generics for theMasses: emgm-0.3

[Sean Leather]

> Due to a problem with the template-haskell package and Cabal, you
>> cannot cabal-install the emgm package with GHC 6.8. However, take
>> heart! EMGM works very well with GHC 6.8. You merely have to download
>> the tar.gz package from Hackage yourself, build it, and install it.
>>
>
> I thought I had seen you mention a workaround for that issue, but
> if not, perhaps you might want to add your experience to
>
>   http://hackage.haskell.org/trac/hackage/ticket/326
>   Cabal should support Cabal-version-dependent Setup.hs
>

I thought I had worked around it, too. Unfortunately, I can only test once I
upload it to Hackage. Once I had, I discovered it wasn't fixed, yet. :-/

It's a problem with cabal-install/Cabal dealing with the lack of version
dependencies in template-haskell. Even though I have template-haskell >= 2.2
in my build-depends, cabal-install insists on trying to install 2.3, which
of course fails when you're using GHC 6.8.

Perhaps my problem cannot be fixed within the Setup.lhs? Maybe
cabal-install/Cabal is resolving dependencies solely based on the .cabal
file? I don't know.

There's a sketched hack-around at the end, using Setup.hs only to call to
> separate Setup-version.hs files, to circumvent Cabal API
> instabilities. Not nice, but perhaps better than to bypass Cabal
> alltogether? One would also have to pass parameters, and the
> Process API has changed in the meantime.., which I why I still
> think Cabal itself should simply be able to pick cabal-versioned
> configuration and setup files, if they exist.
>

I like the hack in that ticket. Very nice. ;) Though it apparently fails for
multiple versions of Cabal. I just checked my system and it produced:

$ ghc-pkg field Cabal version
version: 1.6.0.1
version: 1.6.0.2

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

Re: [Haskell-cafe] possible memory leak in uvector 0.1.0.3

[Claus Reinke]

At first guess it sounds like you're holding onto too much, if not the
whole stream perhaps bits within each chunk. 


It is possible.

I split the string in lines, then map some functions on each line to 
parse the data, and finally calling toU, for converting to an UArr.


Just to make sure (code fragments or, better, reduced examples
would make it easier to see what the discussion is about): are you 
forcing the UArr to be constructed before putting it into the Map?


Claus

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

Re: [Haskell-cafe] ANNOUNCE: Extensible and Modular Generics for theMasses: emgm-0.3

[Claus Reinke]

Due to a problem with the template-haskell package and Cabal, you
cannot cabal-install the emgm package with GHC 6.8. However, take
heart! EMGM works very well with GHC 6.8. You merely have to download
the tar.gz package from Hackage yourself, build it, and install it.


I thought I had seen you mention a workaround for that issue, but
if not, perhaps you might want to add your experience to

   http://hackage.haskell.org/trac/hackage/ticket/326
   Cabal should support Cabal-version-dependent Setup.hs

There's a sketched hack-around at the end, using Setup.hs only 
to call to separate Setup-version.hs files, to circumvent Cabal API

instabilities. Not nice, but perhaps better than to bypass Cabal
alltogether? One would also have to pass parameters, and the
Process API has changed in the meantime.., which I why I still
think Cabal itself should simply be able to pick cabal-versioned 
configuration and setup files, if they exist.


Claus

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

Re: [Haskell-cafe] possible memory leak in uvector 0.1.0.3

[Kenneth Hoste]

On Mar 3, 2009, at 11:10 , Manlio Perillo wrote:


Manlio Perillo ha scritto:

[...]
The other program, with a lot of array concatenations, still eats  
a lot  of memory...


Concatenating arrays generally copies data. Which uses memory.

Of course, but why the garbage collector does not "release" this  
temporary used memory?

Note that I'm using the -F1 flag with the RST.
Maybe it is a problem with IntMap, when there are a lot of keys?


It *is* a problem with IntMap.
I have changed the program to not use any array concatenation, and  
it still requires a lot of memory.



Does esist a data structure that is able to store something like  
480189 keys with efficient memory usage?


I ran into the same problem when I first organized the IntMap to use  
user IDs as keys...


The problem is the huge amount of keys, and the small UArrays as values.

The overhead of both the IntMap and the UArray data types is just way  
too big with 480k different keys...


I never looked into it thoroughly, but if you look at the definition  
of IntMap, each key causes several words

of overhead, along with one word or so for each UArray.

K.

--

Kenneth Hoste
Paris research group - ELIS - Ghent University, Belgium
email: kenneth.ho...@elis.ugent.be
website: http://www.elis.ugent.be/~kehoste
blog: http://boegel.kejo.be

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

Re: [Haskell-cafe] Re: Left fold enumerator - a real pearl overlooked?

[John A. De Goes]

Lazy IO is a complete disaster for "interactive IO", such as network  
and process IO. Moreover, it's somewhat of a failure even for non- 
interactive IO such as the use case you described, because it's very  
easy for partial evaluation to lead to unclosed files and lazy  
evaluation to lead to delayed resource acquisition. I can imagine a  
few use cases that might benefit from it, but the evidence suggests  
that most developers trying to solve "real world" problems work extra  
hard to get their programs working properly with lazy IO.


Elsewhere, laziness can be a real boon, so I don't understand your  
question, "Why have laziness in Haskell at all?"


Regards,

John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration

http://www.n-brain.net|877-376-2724 x 101

On Mar 2, 2009, at 6:03 PM, Henning Thielemann wrote:



On Mon, 2 Mar 2009, John Lato wrote:


Hello,

I am not a super-geek (at least, not compared to others on this  
list),

but I'll take a try at this anyway.  The benefits of iteratees mostly
depend on differences between lazy and strict IO (see ch. 7 of Real
World Haskell for more on this).


Maybe a good text for
  http://www.haskell.org/haskellwiki/Enumerator_and_iteratee
?

While I think that the Iteratee pattern has benefits, I suspect that  
it can't be combined with regular lazy functions, e.g. of type [a] - 
> [a]. Say I have a chain of functions: read a file, parse it into a  
tag soup, parse that into an XML tree, transform that tree, format  
that into a string, write that to a file, and all of these functions  
are written in a lazy way, which is currently considered good style,  
I can't use them in conjunction with iteratees. This means, almost  
all Haskell libraries have to be rewritten or extended from lazy  
style to iteratee style. The question for me is then: Why having  
laziness in Haskell at all? Or at least, why having laziness by  
default, why not having laziness annotation instead of strictness  
annotation.


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


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

Re: [Haskell-cafe] possible memory leak in uvector 0.1.0.3

[Manlio Perillo]

Duncan Coutts ha scritto:

On Tue, 2009-03-03 at 02:12 +0100, Manlio Perillo wrote:

Hi.

In the "help optimizing memory usage for a program" I discovered some 
interesting things:



1) Using lazy ByteStrings to read files it not a good choice, since the
garbage collector is not able to proper garbage cleanup.

Running with -F1 RTS flag, however, keeps memory usage down.


It is certainly possible to have proper garbage cleanup. I can write
programs using lazy ByteStrings that process many megabytes of data and
yet run in 1Mb of heap space.

At first guess it sounds like you're holding onto too much, if not the
whole stream perhaps bits within each chunk. 


It is possible.

I split the string in lines, then map some functions on each line to 
parse the data, and finally calling toU, for converting to an UArr.


> [...]


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

Re: [Haskell-cafe] DSLs with {in,}equalities

[John A. De Goes]

Workarounds for the lack of linguistic overloading. :-)

Regards,

John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration

http://www.n-brain.net|877-376-2724 x 101

On Mar 3, 2009, at 12:52 AM, Lennart Augustsson wrote:


I often hide the Prelude and import my own Prelude which reexports the
old Prelude, but with these changes.
It's still not ideal, by far.

 -- Lennart

class Boolean b where
   false, true :: b
   (&&), (||) :: b -> b -> b
   not :: b -> b

instance Boolean Bool where
   false = False
   true = True
   (&&) = (P.&&)
   (||) = (P.||)
   not = P.not

class (Boolean b) => Eq a b where
   (==), (/=) :: a -> a -> b
   x /= y  =  not (x == y)

instance (P.Eq a) => Eq a Bool where
   (==) = (P.==)
   (/=) = (P./=)

class (Eq a b) => Ord a b where
   (<), (<=), (>), (>=) :: a -> a -> b

instance (P.Ord a) => Ord a Bool where
   (<)  = (P.<)
   (<=) = (P.<=)
   (>)  = (P.>)
   (>=) = (P.>=)

class (Boolean b) => Conditional a b where
   (?) :: b -> (a, a) -> a

instance Conditional a Bool where
   c ? (t, e) = if c then t else e


On Tue, Mar 3, 2009 at 4:13 AM, Andrew Hunter   
wrote:

Several times now I've had to define an EDSL for working with
(vaguely) numeric expressions.  For stuff like 2*X+Y, this is easy,
looking pretty much like:


data Expr = Const Integer | Plus Expr Expr | Times Expr Expr

instance Num Expr where
fromInterger = Const
(+) = Plus
(*) = Times


&c.  This lets me get a perfectly nice AST, which is what I want.
When I want to be able to express and work with inequalities and
equalities, this breaks.  Suppose I want to write 2*X + Y < 3.  I
either have to:

a) Hide Prelude.(<) and define a simple < that builds the AST term  
I want.

b) Come up with a new symbol for it that doesn't look totally awful.

Neither of these work decently well.  Hiding Eq and Ord operators,
which is what I effectively have to do for a), is pretty much a
nonstarter--we'll have to use them too much for that to be practical.

On the other hand, b) works...but is about as ugly as it gets.  We
have lots and lots of symbols that are already taken for important
purposes that are syntactically "near" <,<=,==, and the like: << and

and >>= for monads, >>> for arrows, etc.  There...are not good

choices that I know of for the symbols that don't defeat the purpose
of making a nice clean EDSL for expressions; I might as well use  
3*X +

Y `lessthan` 3, which is just not cool.

Does anyone know of a good solution, here?  Are there good
substitutions for all the six operators that are important
(<,>,>=,<=,==,/=), that are close enough to be pretty-looking but not
used for other important modules?

Better yet, though a little harder, is there a nice type trick I'm  
not

thinking of?  This works for Num methods but not for Ord methods
because:

(+) :: (Num a) => a -> a -> a
(<) :: (Ord a) => a -> a -> Bool

i.e. the return type of comparisons is totally fixed.  I don't  
suppose
there's a good way to...well, I don't know what the *right* answer  
is,

but maybe define a new typeclass with a more flexible type for < that
lets both standard types return Bool and my expressions return Expr?
Any good solution would be appreciated.

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


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



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

[Haskell-cafe] ANNOUNCE: Extensible and Modular Generics for the Masses: emgm-0.3

[Sean Leather]

==
Extensible and Modular Generics for the Masses
==

Extensible and Modular Generics for the Masses (EMGM) is a library for
generic programming in Haskell using type classes and a
sum-of-products view.

---
Updates
---

emgm-0.3 is the third major release, and it arrives a little over a
month after emgm-0.2.

Deriving is now greatly improved! Due to recent reports from users, we
realized the current implementation just wasn't going to cut it. EMGM
already supports a wide range of datatypes, so why not make the
deriving code support just as many. Hopefully, it works well for you.
Please let us know if your datatype is not supported.

There are several new functions in the EMGM family. These include:
cast (a type-safe, configurable, generic cast) and everywhere and
everywhere' (functions similar to those of the same name in SYB that
apply a transformation everywhere a certain type is found).

---
Changes
---

Changes from emgm-0.2 include:

*  Improved deriving can now handle datatype collections like this one:

  http://www.haskell.org/pipermail/generics/2009-February/000429.html

*  cast function

> cast :: Rep (Map a) b => a -> b

*  everywhere and everywhere'

> everywhere :: Rep (Everywhere a) b => (a -> a) -> b -> b
> everywhere' :: Rep (Everywhere' a) b => (a -> a) -> b -> b

They both perform transformations on a-values in a b-value. The former
does them bottom-up, the latter top-down. The names come from similar
functions in SYB that use rank-2 types. Note the difference.

> everywhere :: (forall a. Data a => a -> a) -> forall a. Data a => a -> a
> everywhere' :: (forall a. Data a => a -> a) -> forall a. Data a => a -> a


Known Issues


Due to a problem with the template-haskell package and Cabal, you
cannot cabal-install the emgm package with GHC 6.8. However, take
heart! EMGM works very well with GHC 6.8. You merely have to download
the tar.gz package from Hackage yourself, build it, and install it.
Since it doesn't require any dependencies beyond what comes with GHC,
installation is a breeze!

---
General Information
---

Visit the home page:

 http://www.cs.uu.nl/wiki/GenericProgramming/EMGM


General Features


The primary features of EMGM include:

*  Datatype-generic programming using sum-of-product views
*  Large collection of ready-to-use generic functions
*  Included support for standard datatypes: lists, Maybe, tuples
*  Easy to add support for new datatypes
*  Type classes make writing new functions straightforward in a
structurally inductive style
*  Generic functions are extensible with ad-hoc cases for arbitrary datatypes
*  Good performance of generic functions

The features of this distribution include:

*  The API is thoroughly documented with Haddock
*  Fully tested with QuickCheck and HUnit
*  Program coverage ensures that all useful code has been touched by tests
*  Tested on both Mac and Windows systems


Requirements


EMGM has the following requirements:

*  GHC 6.8.1 - It has been tested with versions 6.8.3 and 6.10.1
*  Cabal library 1.2.1 - It has been tested with versions 1.2.4.0 and 1.6.0.1.

-
Download & Source
-

Use caball-install:

 cabal install emgm

Get the package:

 http://hackage.haskell.org/cgi-bin/hackage-scripts/package/emgm

Check out the current source with Subversion:

 svn checkout https://svn.cs.uu.nl:12443/repos/dgp-haskell/EMGM/trunk

Or view it online:

  https://svn.cs.uu.nl:12443/viewvc/dgp-haskell/EMGM/trunk/


Examples


Check out the examples:

 https://svn.cs.uu.nl:12443/viewvc/dgp-haskell/EMGM/trunk/examples/

--
Bugs & Support
--

Report issues or request features:

  http://code.google.com/p/emgm/issues/list

Discuss EMGM with the authors, maintainers, and other interested persons:

 http://www.haskell.org/mailman/listinfo/generics

---
Credits
---

The research for EMGM originated with Ralf Hinze. It was extended with
work by Bruno Oliveira and Andres Löh. More details of the library
functionality were explored by Alexey Rodriguez. We are very grateful
to all of these people for the foundation on which this library was
built.

The current authors and maintainers of EMGM are:

*  Sean Leather
*  José Pedro Magalhães
*  Alexey Rodriguez
*  Andres Löh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] possible memory leak in uvector 0.1.0.3

[Duncan Coutts]

On Tue, 2009-03-03 at 02:12 +0100, Manlio Perillo wrote:
> Hi.
> 
> In the "help optimizing memory usage for a program" I discovered some 
> interesting things:
> 
> 
> 1) Using lazy ByteStrings to read files it not a good choice, since the
> garbage collector is not able to proper garbage cleanup.
> 
> Running with -F1 RTS flag, however, keeps memory usage down.

It is certainly possible to have proper garbage cleanup. I can write
programs using lazy ByteStrings that process many megabytes of data and
yet run in 1Mb of heap space.

At first guess it sounds like you're holding onto too much, if not the
whole stream perhaps bits within each chunk. Each chunk read from the
file is 64k big and keeping any substring will force the whole chunk to
be retained. If you're only keeping a fraction of each chunk you can use
the ByteString.Lazy.copy function to make a deep copy and let the
original 64k chunk get collected.

Duncan

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

Re: [Haskell-cafe] Difficulties in accessing inner elements of data types

[Neil Mitchell]

Hi David,

What you are wanting to do is query and transform a reasonably large
AST. Fortunately there are solutions, generic programming should do
exactly what you want without too much hassle. I'd personally
recommend taking a look at the Uniplate library, starting by reading
the Haskell Workshop 2007 paper (its an academic paper, but for you
the  really useful stuff is in Section 2 which is more tutorial style)
- http://www-users.cs.york.ac.uk/~ndm/uniplate/

I'm sure I could solve your particular queries using Uniplate, but
I'll leave it for you to take a look and figure out. If you can't
figure out how to do it after reading section 2 of the paper mail back
and I'll take a closer look.

Thanks

Neil

2009/3/3 David Miani :
> Hi,
> I'm working on a Haskell library for interacting with emacs org files. For
> those that do not know, an org file is a structured outline style file that
> has nested headings, text, tables and other elements. For example:
>
> * Heading 1
> Some text, more text. This is a subelement of Heading 1
> 1. You can also have list
> 1. and nested lists
> 2. more...
>
> ** Nested Heading (subelement of Heading 1)
> text... (subelement of Nested Heading)
>
> ** Another level 2 heading (subelement of Heading 1)
> | Desc | Value |
> |---+--|
> | Table | You can also have tables in the file |
> | another | row |
> | seperator | you can have seps as well, eg |
> |---+--|
>
> * Another top level heading
> There are many more features, see orgmode.org
>
> My library enables read and write access to a subset of this format (eg
> lists aren't parsed atm).
>
> The data structures used for writing are:
>
> data OrgFile = OrgFile [OrgFileElement]
> data OrgFileElement = Table OrgTable
> | Paragraph String
> | Heading OrgHeading
>
> -- heading level, title, subelements
> data OrgHeading = OrgHeading Int String [OrgFileElement]
>
> data OrgTable = OrgTable [OrgTableRow]
>
> data OrgTableRow = OrgTableRow [String] | OrgTableRowSep
>
>
> To write a file you contruct a OrgFile out of those elements, and pass it to
> a writeOrgFile func. Eg:
>
> writeOrg $ OrgFile [Heading (OrgHeading 1 "h1" [Paragraph "str"])]
> would produce:
> * h1
> str
>
> I was going to use the same data structures for reading an org file, but it
> quickly became apparent that this would not be suitable, as you needed the
> position of the file of an element to be able to report errors. Eg if you
> needed to report an error that a number was expected, the message "'cat' is
> not a number" is not very useful, but "Line 2031: 'cat' is not a number" is.
> So the data structures I used were:
>
> data FilePosition = FilePosition Line Column
>
> data WithPos a = WithPos {
> filePos :: FilePosition,
> innerValue :: a
> }
>
> data OrgTableP = OrgTableP [WithPos OrgTableRow]
>
> data OrgFileElementP = TableP OrgTableP
> | ParagraphP String
> | HeadingP OrgHeadingP
>
> data OrgHeadingP = OrgHeadingP Int String [WithPos OrgFileElementP]
>
> data OrgFileP = OrgFileP [WithPos OrgFileElementP]
>
>
> Finally there is a function readOrg, which takes a string, and returns an
> OrgTableP.
>
>
> Now, this all works as expected (files are correctly being parsed and
> written), however I am having a lot of trouble trying to come up with a
> decent API to work with this. While writing an OrgFile is fairly easy,
> reading (and accessing inner parts) of an org file is very tedious, and
> modifying them is horrendous.
>
> For example, to read the description line for the project named "Project14"
> in the file:
>
> * 2007 Projects
> ** Project 1
> Description: 1
> Tags: None
> ** Project 2
> Tags: asdf,fdsa
> Description: hello
> * 2008 Projects
> * 2009 Projects
> ** Project14
> Tags: RightProject
> Description: we want this
>
> requires the code:
>
> type ErrorS = String
> listToEither str [] = Left str
> listToEither _ (x:_) = Right x
>
> get14 :: OrgFileP -> Either ErrorS String
> get14 (OrgFileP elements) = getDesc =<< (getRightProject . concatProjects)
> elements where
> concatProjects :: [WithPos OrgFileElementP] -> [OrgHeadingP]
> concatProjects [] = []
> concatProjects ((WithPos _ (HeadingP h)) : rest) = h : concatProjects rest
> concatProjects (_ : rest) = concatProjects rest
>
> getRightProject :: [OrgHeadingP] -> Either ErrorS OrgHeadingP
> getRightProject = listToEither "Couldn't find project14" .
> filter (\(OrgHeadingP _ name _) -> name == "Project14")
>
> getDesc :: OrgHeadingP -> Either ErrorS String
> getDesc (OrgHeadingP _ _ children) =
> case filter paragraphWithDesc (map innerValue children) of
> [] -> Left $ show (filePos $ head children) ++
> ": Couldn't find desc in project"
> ((ParagraphP str):_) -> Right str
> _ -> error "should not be possible"
>
> paragraphWithDesc :: OrgFileElementP -> Bool
> paragraphWithDesc (ParagraphP str) = str =~ "Description"
> paragraphWithDesc _ = False
>
>
> If you think that is bad, try writing a function that a

Re: [Haskell-cafe] possible memory leak in uvector 0.1.0.3

[Manlio Perillo]

Peter Verswyvelen ha scritto:

Does esist a data structure that is able to store something like 480189 keys
with efficient memory usage?


What is the range of your keys - do they use the full 32-bit of Int -
and what type are the values?



From Netflix Prize documentation:
CustomerIDs range from 1 to 2649429, with gaps. There are 480189 users.


The values are UArr (Word32 :*: Word 8), from uvector package.



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

[Haskell-cafe] Difficulties in accessing inner elements of data types

[David Miani]

Hi,
I'm working on a Haskell library for interacting with emacs org files. For 
those that do not know, an org file is a structured outline style file that 
has nested headings, text, tables and other elements. For example:

* Heading 1
Some text, more text. This is a subelement of Heading 1
1. You can also have list
   1. and nested lists
   2. more...

** Nested Heading (subelement of Heading 1)
text... (subelement of Nested Heading)

** Another level 2 heading (subelement of Heading 1)
| Desc  | Value|
|---+--|
| Table | You can also have tables in the file |
| another   | row  |
| seperator | you can have seps as well, eg|
|---+--|

* Another top level heading
There are many more features, see orgmode.org

My library enables read and write access to a subset of this format (eg lists 
aren't parsed atm). 

The data structures used for writing are:

data OrgFile = OrgFile [OrgFileElement]
data OrgFileElement = Table OrgTable
 | Paragraph String
 | Heading OrgHeading

-- heading level, title, subelements
data OrgHeading = OrgHeading Int String [OrgFileElement]

data OrgTable = OrgTable [OrgTableRow]

data OrgTableRow = OrgTableRow [String] | OrgTableRowSep 


To write a file you contruct a OrgFile out of those elements, and pass it to a 
writeOrgFile func. Eg:

writeOrg $ OrgFile [Heading (OrgHeading 1 "h1" [Paragraph "str"])]
would produce:
* h1
str

I was going to use the same data structures for reading an org file, but it 
quickly became apparent that this would not be suitable, as you needed the 
position of the file of an element to be able to report errors. Eg if you 
needed to report an error that a number was expected, the message "'cat' is 
not a number" is not very useful, but "Line 2031: 'cat' is not a number" is. 
So the data structures I used were:

data FilePosition = FilePosition Line Column

data WithPos a = WithPos {
filePos :: FilePosition,
innerValue :: a
}

data OrgTableP = OrgTableP [WithPos OrgTableRow]

data OrgFileElementP = TableP OrgTableP
 | ParagraphP String
 | HeadingP OrgHeadingP

data OrgHeadingP = OrgHeadingP Int String [WithPos OrgFileElementP]

data OrgFileP = OrgFileP [WithPos OrgFileElementP]


Finally there is a function readOrg, which takes a string, and returns an 
OrgTableP.


Now, this all works as expected (files are correctly being parsed and 
written), however I am having a lot of trouble trying to come up with a decent 
API to work with this. While writing an OrgFile is fairly easy, reading (and 
accessing inner parts) of an org file is very tedious, and modifying them is 
horrendous.

For example, to read the description line for the project named "Project14" in 
the file:

* 2007 Projects
** Project 1
Description: 1
Tags: None
** Project 2
Tags: asdf,fdsa
Description: hello
* 2008 Projects
* 2009 Projects
** Project14
Tags: RightProject
Description: we want this

requires the code:

type ErrorS = String
listToEither str [] = Left str
listToEither _ (x:_) = Right x

get14 :: OrgFileP -> Either ErrorS String
get14 (OrgFileP elements) = getDesc =<< (getRightProject . concatProjects) 
elements where
concatProjects :: [WithPos OrgFileElementP] -> [OrgHeadingP]
concatProjects [] = []
concatProjects ((WithPos _ (HeadingP h)) : rest) = h : concatProjects rest
concatProjects (_ : rest) = concatProjects rest

getRightProject :: [OrgHeadingP] -> Either ErrorS OrgHeadingP
getRightProject  = listToEither "Couldn't find project14" .
   filter (\(OrgHeadingP _ name _) -> name == "Project14")

getDesc :: OrgHeadingP -> Either ErrorS String
getDesc (OrgHeadingP _ _ children) =
case filter paragraphWithDesc (map innerValue children) of
  [] -> Left $ show (filePos $ head children) ++ 
   ": Couldn't find desc in project"
  ((ParagraphP str):_) -> Right str
  _ -> error "should not be possible"

paragraphWithDesc :: OrgFileElementP -> Bool
paragraphWithDesc (ParagraphP str) = str =~ "Description"
paragraphWithDesc _ = False


If you think that is bad, try writing a function that adds the Tag "Hard" to 
Project2 :(

What I really need is a DSL that would allow sql like queries on an OrgFileP. 
For example:
select (anyHeading `next`
headingWithName "Project14" `withFailMsg` "couldn't find p14" `next`
paragraphMatchingRegex "Description" `withFailMsg` "no desc")
   org `output` paragraphText

would return a String
OR
select (anyHeading `next` headingWithName "Project2" `next`
paragraphMatchingRegex "Tag:") org `modify` paragraphText (++ ",Hard")

would return an OrgFile, with the new Hard tag added.

However, I don't know if this is even possible, how to do it, or if there is a 
bett

Re[2]: [Haskell-cafe] possible memory leak in uvector 0.1.0.3

[Bulat Ziganshin]

Hello Manlio,

Tuesday, March 3, 2009, 1:10:48 PM, you wrote:

> It *is* a problem with IntMap.
> I have changed the program to not use any array concatenation, and it 
> still requires a lot of memory.

it may be problem with something else. in particular, check that
you don't have lazy thunks stored instead of values

> Does esist a data structure that is able to store something like 480189
> keys with efficient memory usage?

data.hashtable. at least, i can calculate its memory usage - it should
be less than 100 bytes per key even with collecting GC. plus memory
required for values

...but intmap should be the same. i still think that you have unforced
thunks stored in map

-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

Re: [Haskell-cafe] possible memory leak in uvector 0.1.0.3

[Peter Verswyvelen]

> Does esist a data structure that is able to store something like 480189 keys
> with efficient memory usage?

What is the range of your keys - do they use the full 32-bit of Int -
and what type are the values?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] possible memory leak in uvector 0.1.0.3

[Daniel Fischer]

Am Dienstag, 3. März 2009 11:10 schrieb Manlio Perillo:
> Manlio Perillo ha scritto:
> > [...]
> >
> >>> The other program, with a lot of array concatenations, still eats a
> >>> lot  of memory...
> >>
> >> Concatenating arrays generally copies data. Which uses memory.
> >
> > Of course, but why the garbage collector does not "release" this
> > temporary used memory?
> > Note that I'm using the -F1 flag with the RST.
> >
> > Maybe it is a problem with IntMap, when there are a lot of keys?
>
> It *is* a problem with IntMap.
> I have changed the program to not use any array concatenation, and it
> still requires a lot of memory.
>
>
> Does esist a data structure that is able to store something like 480189
> keys with efficient memory usage?
>

An array?
Might be complicated to write fast code, but the memory overhead should be 
small.

>
> Thanks  Manlio Perillo

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

Re: [Haskell-cafe] possible memory leak in uvector 0.1.0.3

[Manlio Perillo]

Manlio Perillo ha scritto:

[...]
The other program, with a lot of array concatenations, still eats a 
lot  of memory...


Concatenating arrays generally copies data. Which uses memory.



Of course, but why the garbage collector does not "release" this 
temporary used memory?

Note that I'm using the -F1 flag with the RST.

Maybe it is a problem with IntMap, when there are a lot of keys?



It *is* a problem with IntMap.
I have changed the program to not use any array concatenation, and it 
still requires a lot of memory.



Does esist a data structure that is able to store something like 480189 
keys with efficient memory usage?



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

Re[2]: [Haskell-cafe] interaction between ghci and cudaBLAS library

[Bulat Ziganshin]

Hello Don,

Tuesday, March 3, 2009, 5:22:46 AM, you wrote:

> GHCi doesn't use the threaded runtime though.  So given that:

Don, afair ghci compiled using threaded runtime since 6.6:

Prelude> :m Control.Concurrent
Prelude Control.Concurrent> rtsSupportsBoundThreads
True

-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

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

[Haskell-cafe] Theory about uncurried functions

[Peter Verswyvelen]

Lambda calculus is a nice theory in which every function always has
one input and one output. Functions with multiple arguments can be
simulated because functions are first class and hence a function can
"return" a function. Multiple outputs cannot be done, one must embed
these outputs in some data type, e.g. using a tuple, or one must use
continuation passing style.

Now, does a similar theory exist of functions that always have one
input and one output, but these inputs and outputs are *always*
tuples? Or maybe this does not make any sense?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe