- Haskell-Cafe - Haskell.org

RE: [Haskell-cafe] FPS lib
by Simon Marlow 21 Oct '05

21 Oct '05

On 21 October 2005 02:36, John Meacham wrote: > I think a lot of benefit can be had by making ForeignPtr a product > type rather than a union one. being able to unbox it in constructors > and opening it to CPR analysis is key for tight inner loop code which > pointers will most definitly be involved in. Actually this is what we did, and why the benchmarks go a lot faster with GHC 6.5 compared to 6.4.x. Cheers, Simon

1 0

Re[2]: [Haskell] Read Instances for Data.Map and Data.Set
by Bulat Ziganshin 21 Oct '05

21 Oct '05

Hello Johannes, Friday, October 21, 2005, 11:42:55 AM, you wrote: JW> I'd like to repeat my earlier point that it would be better JW> if the user of the type can decide whether he wants JW> some predefined Show/Read instances or roll his own. JW> http://www.haskell.org/pipermail/libraries/2005-March/003496.html long standing sight...... parameterized modules will be a good solution for all those problems. or ability to hide/import class instances, not only plain functions: import Data.Map hiding (Show(Map)) -- Best regards, Bulat mailto:bulatz@HotPOP.com

1 0

RE: [Haskell-cafe] FPS lib
by Simon Marlow 21 Oct '05

21 Oct '05

[ oops, I meant to send this yesterday but it didn't go out for some reason ] On 18 October 2005 12:40, Krasimir Angelov wrote: > ForeignPtr requires more memory. Each ForeignPtr has > ForeignPtrContents structure attached. In the ForeignPtrContents there > is one IORef. Each finalizer adds one Weak# object in the heap. The > IORef is a reference to a list of finalizers, so each new finalizer > adds a new CONS cell. The finalizers require additional steps in GC > time. I haven't tried to measure the difference between ForeignPtr and > ByteArray# based implementations but it seems to me that the latter > might be better. Of course it will be GHC specific. > mmap is valuable only for large string. Typically only when someone > wants to read the entire file in the memory. For this case a special > data structure might be provided. We can assume that in the packed string case, most of the packed strings will be allocated in Haskell, and will therefore be represented by a ForeignPtr with a ByteArray# inside - therefore no finalizer, no Weak# object, and no cons cells. It is a shame that we need the IORef, but I'm wondering whether we should have a special kind of ForeignPtr to which you can't add any more finalizers (ie. addForeignPtrFinalizer would fail) to optimise this case. We never need to add any finalizers to packed strings created in Haskell. Also, the IORefs will interact badly with generational GC, so we should really get rid of them. If we eliminated the IORef, then the difference between ByteArray and ForeignPtr would be one word, i.e. negligible. I think the flexibility is worth it. Also, I bet that you won't find any useful benchmarks in which the difference is significant Cheers, Simon

2 1

Template Haskell -- Bug?
by Gracjan Polak 20 Oct '05

20 Oct '05

Hi, Could somebody try to compile these two files *TWICE*? GHC dumps core at me. I don't know if it is something about me, or something more general :) I'd like to know a bit more, before I bother anybody from devel team. Log: $ ghc --make THTest1.hs Chasing modules from: THTest1.hs Compiling THTest1TH ( ./THTest1TH.hs, ./THTest1TH.o ) Compiling THTest1 ( THTest1.hs, THTest1.o ) THTest1.hs:10:4: `incrSelf' is not a (visible) method of class `IncrSelf' $ ghc --make THTest1.hs Chasing modules from: THTest1.hs Skipping THTest1TH ( ./THTest1TH.hs, ./THTest1TH.o ) Compiling THTest1 ( THTest1.hs, THTest1.o ) Loading package base-1.0 ... linking ... done. Loading package haskell98-1.0 ... linking ... done. Loading package template-haskell-1.0 ... linking ... done. (here core dump, aka 0xc00000001) First of all, I do not understand the error in first compilation. Second, core dump is not nice :) My config: Windows XP Home, $ ghc -v Glasgow Haskell Compiler, Version 6.4, for Haskell 98, compiled by GHC version 6.2.2 Using package config file: c:\ghc\ghc-6.4\package.conf Using package config file: C:\Documents and Settings\gracjan\Application Data\ghc/i386-mingw32-6.4/package.conf Default windows package as taken from www.haskell.org. -- Gracjan {-# OPTIONS -fglasgow-exts -fth -fallow-undecidable-instances #-} module THTest1TH ( instanceIncrSelfTuple, IncrSelf(..) ) where import Control.Monad import Data.Maybe import Language.Haskell.TH class IncrSelf a where incrSelf :: a -> a instance Num a => IncrSelf a where incrSelf x = x + 1 sel' :: Int -> Int -> ExpQ sel' i n = lamE [pat] rhs where pat = tupP (map varP as) rhs = varE (as !! (i - 1)) as = map mkName [ ("a__" ++ show j) | j <- [1..n] ] instanceIncrSelfTuple :: Int -> Q [Dec] instanceIncrSelfTuple n = do decs <- qOfDecs let listOfDecQ = map return decs conIncrSelf = conT ''IncrSelf name_a = mkName "a" name_b = mkName "b" name_c = mkName "c" var_a = varT name_a var_b = varT name_b var_c = varT name_c dec <- instanceD (sequence [appT conIncrSelf var_a,appT conIncrSelf var_b]) (appT conIncrSelf (appT (appT (tupleT 2) var_a ) var_b ) ) listOfDecQ return [dec] where qOfDecs = [d| incrSelf value = let value1 = maybe Nothing (Just . fst) value value2 = maybe Nothing (Just . snd) value in error "adfasf" -- (incrSelf value1, incrSelf value2) |] {-# OPTIONS -fglasgow-exts -fth -fallow-undecidable-instances #-} module THTest1 where import THTest1TH instance IncrSelf String where incrSelf x = x ++ "x" $(instanceIncrSelfTuple 2)

2 1

Zlib bindings
by Joel Reymont 20 Oct '05

20 Oct '05

Folks, Are there any zlib bindings for Haskell? The docs for HDirect mention the examples directory with the bindings but I cannot find the examples directory in the source distro. The MissingH code works with gzipped files apparently but not with memory buffers. Thanks, Joel -- http://wagerlabs.com/

7 10

RE: [Haskell-cafe] FPS lib
by Simon Marlow 20 Oct '05

20 Oct '05

On 18 October 2005 10:08, Krasimir Angelov wrote: > I am curious why FPS is implemented on top of ForeignPtr. ByteArray# > based implementation should be faster and more space efficient. Actually there's not much difference between ForeignPtr and ByteArray#, at least in GHC 6.5+ where we optimised the ForeignPtr implementation. Furthermore ForeignPtr is much more useful, because you can create a ForeignPtr from a Ptr, and you can pass a ForeignPtr to C code portably (i.e. not using GHC extensions). ForeignPtr is essential if you want to make packed strings from eg. mmap()'d memory. Also, a ForeignPtr allocated using mallocForeignPtr *is* a ByteArray#. My PackedString library (which DonS is currently merging with FPS) uses ForeignPtr and gets pretty good performance. withForeignPtr compiles to almost nothing at all: the touch# becomes visible to GHC and compiles to no code. I needed to inline unsafePerformIO to get the best results, though (not always safe, but in this case it's ok). Cheers, Simon

5 13

Re: [Haskell] Read Instances for Data.Map and Data.Set
by dons＠cse.unsw.edu.au 20 Oct '05

20 Oct '05

mai99dgf: > Hi folks, > > I was really annoyed by the fact that for Data.Map and Data.Set are no Read > instances declared, but Show instances are! I believe there should be some > kind of unwritten rule that in the standart lib the Show and Read instances > come pairwise and are fully compatible. There are some things that are Showable, but would be wrong to be Readable. Dynamics come to mind. That's not the case with Map, though :) (moved to haskell-cafe@ just in case :) -- Don

1 0

RE: [Haskell-cafe] FPS lib
by Simon Marlow 20 Oct '05

20 Oct '05

On 18 October 2005 21:04, John Meacham wrote: > On Tue, Oct 18, 2005 at 10:39:24AM +0300, Einar Karttunen wrote: >> On 18.10 10:44, Bulat Ziganshin wrote: >>> 2) as i say you before, i need to sort filenames in windows fashion >>> (case-ignoring), so if you will include case-ignoring comparision >>> operators - i will be glad >> >> Case ignoring comparisons make only sense on characters - not on >> bytes. And fps is ignoring character set conversion issues. I think >> the proper way is to provide a layer on top of (and separate from) >> fps that does conversion into character strings where things like >> case make sense. > > My FastString library always stores everything as UTF8 to good effect. > I have some nice fast unboxed UTF8 character folding routines in there > too which you might want to grab if you go the UTF8 route. (which I > recommend highly). > > http://repetae.net/john/repos/jhc/PackedString.hs I believe I stole your UTF-8 code for my Data.PackedString.UTF8 version (which Don uploaded here http://www.cse.unsw.edu.au/~dons/packedstring.tar.gz) It might be slightly modified though; in my version I wanted to support foldr/build optimisation of things like (pack (map f xs)) and (unpack s ++ t). IIRC I got it working for unpack, but not for pack. Cheers, Simon

2 1

Parsec vs ReadP
by Sebastian Sylvan 20 Oct '05

20 Oct '05

Can anyone briefly compare these two parsing-libraries? In short, which one is better? /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862

3 2

RE: [Haskell-cafe] Prebuilt FPS for Windows
by Simon Marlow 19 Oct '05

19 Oct '05

On 18 October 2005 17:01, Joel Reymont wrote: > Since I cannot build Data.FastPackedString on Windows (ghc crashes) > and it's the only library I really depend on, would someone have a > pre-built version or let me know how I can build it without Cabal? A workaround for that crashing problem is to compile the Setup.lhs script using GHC first, and then run it: $ ghc --make Setup.lhs -o setup $ ./setup configure etc. > On a related note, Haskell tools for Windows (happy, alex) come with > extra files (templates). Where are these to be placed? On Windows, they are placed in the same folder as the executable. Cheers, Simon

1 0