- Haskell-Cafe - Haskell.org

Memory usage when passing arrays in state
by Tobias Olausson 04 Mar '09

04 Mar '09

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 == 13000000 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 13000000 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 tobsan(a)gmail.com

4 5

How to build sourceview depend for gtk2hs?
by Andy Stewart 03 Mar '09

03 Mar '09

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 checking for happy... /usr/local/bin/happy checking version of happy... 1.18.2 checking for alex... /usr/local/bin/alex checking for haddock... /usr/local/bin/haddock checking version of haddock... 2.4.1 configure: creating ./config.status config.status: creating Makefile config.status: creating gtk2hs.spec config.status: creating mk/chsDepend config.status: creating mk/link-splitobjs.sh config.status: creating mk/fix-package-conf.sh config.status: creating docs/prologue.txt config.status: creating glib/glib.package.conf config.status: creating glib/glib.cabal config.status: creating gtk/gtk.package.conf config.status: creating gtk/gtk.cabal config.status: creating gio/gio.package.conf config.status: creating gio/gio.cabal config.status: creating glade/glade.package.conf config.status: creating glade/glade.cabal config.status: creating gconf/gconf.package.conf config.status: creating gconf/gconf.cabal config.status: creating sourceview/sourceview.package.conf config.status: creating sourceview/sourceview.cabal config.status: creating gtksourceview2/gtksourceview2.package.conf config.status: creating gtksourceview2/gtksourceview2.cabal config.status: creating mozembed/mozembed.package.conf config.status: creating mozembed/mozembed.cabal config.status: creating cairo/cairo.package.conf config.status: creating cairo/cairo.cabal config.status: creating svgcairo/svgcairo.package.conf config.status: creating svgcairo/svgcairo.cabal config.status: creating gtkglext/gtkglext.package.conf config.status: creating gtkglext/gtkglext.cabal config.status: creating soegtk/soegtk.package.conf config.status: creating soegtk/soegtk.cabal config.status: creating gnomevfs/gnomevfs.package.conf config.status: creating gnomevfs/gnomevfs.cabal config.status: creating gstreamer/gstreamer.package.conf config.status: creating gstreamer/gstreamer.cabal config.status: creating gtk2hs-config.h config.status: gtk2hs-config.h is unchanged config.status: executing depfiles commands config.status: executing default commands ************************************************** * 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" ************************************************** -- Andy

2 3

Relying on GCC as the hsc2hs C compiler
by John Van Enk 03 Mar '09

03 Mar '09

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

1 0

Threading and Mullticore Computation
by mwinter＠brocku.ca 03 Mar '09

03 Mar '09

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 60000 print "Task1 done!" where fac 0 = 1 fac n = n * fac (n-1) myTask2 = do return $! fac' 60000 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 60000 to 100000 the time difference gets even worse (30sec vs 51 sec). Can anybody give me an idea what I am doing wrong? Thanks, Michael

8 20

interaction between ghci and cudaBLAS library
by Simon Beaumont 03 Mar '09

03 Mar '09

In my efforts to integrate this library into Haskell (I am working on OS X 10.5.6 with ghc-6.10.1 and CUDA 2.0) I am getting a bad interaction between the threads in ghci - when I call the library init function via the FFI, ghci will block in __semwait_signal. Of course if I build an executable which I guess has only one thread then all is well. AFAIK the CUDA library is re-entrant (or threadsafe) in that it will initialize a device context for each thread that calls it. I guess that might be part of the problem. Certainly there is a call to _pthread_getspecific in that library. This is show stopper for me as I want to use GHCI to call blas routines on the device (this lends itself very nicely to a monadic approach - leaving the matrices on the device until we are done applying sequential computations - and only then bringing them back into the "real" world). Since there is this association between the device context and the calling thread - is there a way to get a handle on the threading in ghci? (or just have a single thread) But why are we blocking? I would have expected completion or is ghci smart enough to prevent any non-deterministic behaviour that the current setup would entail? Any ideas or suggestions of how to proceed with this? The final work should it be successful will be offered to the community as a basis for doing high performance linear algebra on CUDA devices as well as get my haskell up to speed as a side effect :) -- View this message in context: http://www.nabble.com/interaction-between-ghci-and-cudaBLAS-library-tp22300… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

3 6

ANNOUNCE: Extensible and Modular Generics for the Masses: emgm-0.3
by Sean Leather 03 Mar '09

03 Mar '09

============================================== 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

2 2

Hidden module?
by Cristiano Paris 03 Mar '09

03 Mar '09

Cabalising hsc2hc I get (this is actually from manually building the package): --- [paris@bagend hsc2hs-0.67.20061107]$ runghc Setup.hs build Preprocessing executables for hsc2hs-0.67.20061107... Building hsc2hs-0.67.20061107... Main.hs:32:7: Could not find module `System.Process': it is a member of package process-1.0.1.0, which is hidden [paris@bagend hsc2hs-0.67.20061107]$ which I cannot understand. Please help! --- Cristiano

5 7

Cabal and `main-is` field
by Manlio Perillo 02 Mar '09

02 Mar '09

Hi. I have started to use Cabal for a small project where I have to build several executables. The project layout is something like this: / bin/ a.hs b.hs src/ X.hs Y.hs The Cabal configuration file is something like: executable a build-depends: haskell98, base, ... main-is: a.hs hs-source-dirs: src bin other-modules: X This is perfectly reasonable, but it is odd, IMHO. I don't understand why `main-is` is relative to `hs-source-dirs`. What is the rationale? After all, there is only one executable that can be specified in the `executable` block. The configuration file should be, instead (IMHO, of course): executable a build-depends: haskell98, base, ... main-is: bin/a.hs hs-source-dirs: src other-modules: X Another "problem" I have noted, is that if I specify `main-is` field two times, no error is reported. Simply, Cabal uses the last directive. One last thing: is it possible to define "macros" in Cabal? In my package, I have n executables, that have many dependencies in common. I would like to avoid having to repeat the same dependencies for each executable block. Thanks Manlio Perillo

4 7

ANNOUNCE: text and text-icu, fast and comprehensive Unicode support using stream fusion
by Bryan O'Sullivan 02 Mar '09

02 Mar '09

On behalf of the Data.Text team, I am delighted to announce the release of preview versions of two new packages: text 0.1 Fast, packed Unicode text support, using a modern stream fusion framework. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/text text-icu 0.1 Augments text with comprehensive character set conversion support and normalization (and soon more), via bindings to the ICU library. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/text-icu These packages fill out critical pieces of functionality for the Haskell platform, without compromising on either performance or safety. We are referring to these as *preview* releases because although the text package in particular has been quite heavily tested, it has not been thoroughly tuned, and we have not yet implemented a chunked lazy text representation suitable for streaming gigabytes of data. The APIs are pretty conventional, but are still subject to change. If you want to contribute, please get copies of the source trees from here: darcs get http://code.haskell.org/text darcs get http://darcs.serpentine.com/text-icu Please send bug reports and patches to your friendly Data.Text team: Tom Harper <rtharper(a)aftereternity.co.uk> Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> Bryan O'Sullivan <bos(a)serpentine.com>

4 9

Left fold enumerator - a real pearl overlooked?
by Gü?nther Schmidt 02 Mar '09

02 Mar '09

Hi all, in the last few months I was looking for haskell database library, eventually settling for HDBC (thanks John btw). Takusen also caught my eye although I even failed installing it. Nevertheless a particular property of takusen, left-fold-enumerator, also sparked my interest and I tried to follow it up. I had the impression this is something of relevance but something that is not mentioned or made use of often. There are actually only a few references on the net and most of those by one person only, Oleg. There was one post from John Goerzen about Haskell HTTP libraries in which he hinted using left-fold enumerators. Anyway what I'm saying is that the whole topic is somewhat off the radar of the larger haskell community, how come, or am I merely overestimating its relevance and usefulness? Günther

4 4