- Haskell-Cafe - Haskell.org

FFI and modifying haskell memory
by Joel Reymont 21 Oct '05

21 Oct '05

Folks, I stumbled upon this when binding the Zlib library and want to make sure I'm doing this right. foreign import ccall unsafe "uncompress" uncompress_ :: Ptr Word8 -> Ptr CULong -> Ptr Word8 -> CULong -> IO CInt You give this function the address of your size as second argument and it updates size for you. basic uncompress(char* buf, unsigned long *size, ...) for you. Is it correct that I need to allocate a chunk of 4 bytes to be passed into C and updated there and then need to peek my value from that chunk of memory? I thought StablePtr would give me the address of a Haskell value but it gives me an offset into some table instead. Thanks, Joel -- http://wagerlabs.com/

1 0

Re: [Haskell-cafe] Regular Expressions without GADTs
by oleg＠pobox.com 21 Oct '05

21 Oct '05

Conor McBride wrote: > Neither Oleg nor Bruno translated my code; they threw away my > structurally recursive on-the-fly automaton and wrote combinator parsers > instead. That's why there's no existential, etc. The suggestion that > removing the GADT simplifies the code would be better substantiated if > like was compared with like. ... > I'm sure the program I actually wrote can be expressed with the type > class trick, just by cutting up my functions and pasting the bits into > individual instances; the use of the existential is still available. I > don't immediately see how to code this up in Bruno's style, but that > doesn't mean it can't be done. Still, it might be worth comparing like > with like. Please see the enclosed code. It is still in Haskell98 -- and works in Hugs. > I suspect that once you start producing values with the > relevant properties (as I do) rather than just consuming them (as Oleg > and Bruno do), the GADT method might work out a little neater. Actually, the code is pretty much your original code, with downcased identifiers. It faithfully implements that parser division approach. Still, there are no existentials. I wouldn't say that GADT code is so much different. Perhaps the code below is a bit neater due to the absence of existentials, `case' statements, and local type annotations. {-- Haskell98! --} module RegExps where import Monad newtype Zero = Zero Zero -- Zero type in Haskell 98 -- Bruno.Oliveira's type class class RegExp g where zero :: g tok Zero one :: g tok () check :: (tok -> Bool) -> g tok tok plus :: g tok a -> g tok b -> g tok (Either a b) mult :: g tok a -> g tok b -> g tok (a,b) star :: g tok a -> g tok [a] data Parse tok t = Parse { empty :: Maybe t , divide :: tok -> Parse tok t} parse :: Parse tok a -> [tok] -> Maybe a parse p [] = empty p parse p (t:ts) = parse (divide p t) ts liftP f p = Parse{empty = liftM f (empty p), divide = \tok -> liftP f (divide p tok)} liftP2 mf p1 p2 = Parse{empty = mf (empty p1) (empty p2), divide = \tok -> liftP2 mf (divide p1 tok) (divide p2 tok)} lsum x y = (liftM Left x) `mplus` (liftM Right y) lprod x y = liftM2 (,) x y -- Conor McBride's parser division algorithm instance RegExp Parse where zero = Parse mzero (\_ -> zero) one = Parse (return ()) (\_ -> liftP (const ()) zero) check p = Parse mzero (\t -> if p t then liftP (const t) one else liftP (const t) zero) plus r1 r2 = Parse (lsum (empty r1) (empty r2)) (\t -> plus (divide r1 t) (divide r2 t)) mult r1 r2 = Parse (lprod (empty r1) (empty r2)) (\t -> let (q1,q2) = (divide r1 t, divide r2 t) lp x1 = liftP (either id ((,) x1)) in maybe (mult q1 r2) (\x1 -> lp x1 (plus (mult q1 r2) q2)) (empty r1)) star r = Parse (return []) (\t-> liftP (uncurry (:)) (mult (divide r t) (star r))) p1 :: RegExp g => g Char ([Char], [Char]) p1 = mult (star (check (== 'a'))) (star (check (== 'b'))) testp = parse (star (mult (star (check (== 'a'))) (star (check (== 'b'))))) "abaabaaabbbb" {- *RX> testp Just [("a","b"),("aa","b"),("aaa","bbbb")] -} testc = parse (star one) "abracadabra" -- Parsing the list of integers ieven = even :: Int->Bool iodd = odd :: Int->Bool p2 :: RegExp g => g Int (Either (Int, (Int, [Int])) (Int, [Int])) p2 = plus (mult (check iodd) (mult (check iodd) (star (check ieven)))) (mult (check ieven) (star (check iodd))) test2 = parse (star p2) [1::Int,1,2,3,3,4]

4 4

RE: [Haskell-cafe] Re: "getServiceEntry: does not exist" on Windows
by Simon Marlow 21 Oct '05

21 Oct '05

Please try the updated installer for 6.4.1. I believe this is caused by the same bug in the dynamic linker that was fixed in the update. At least, I can reproduce your bug with the 6.4.1 installation I have, but not with a fresh build. Cheers, Simon On 21 October 2005 13:20, Joel Reymont wrote: > Folks, ideas on this? It's a major showstopper for me since it > prevents me from deploying the Haskell app for my customer :(. > > Thanks, Joel > > On Oct 19, 2005, at 5:06 PM, Joel Reymont wrote: > >> This fails also but the C call to getprotobyname succeeds. >> >> Prelude> Network.BSD.getProtocolByName "tcp" >> *** Exception: getServiceEntry: does not exist (no such service >> entry) >> >> On Oct 19, 2005, at 4:51 PM, Joel Reymont wrote: >> >> >>> I checked my Windows protocol file in system32/drivers/etc and it >>> has >>> >>> tcp 6 TCP # Transmission control protocol >>> >>> Still, I get the following: >>> >>> Prelude> Network.BSD.getProtocolNumber "tcp" >>> *** Exception: getServiceEntry: does not exist (no such service >>> entry) >>> >> >> -- >> http://wagerlabs.com/

1 0

"getServiceEntry: does not exist" on Windows
by Joel Reymont 21 Oct '05

21 Oct '05

Folks, I have a silly Windows issue: *** Exception: getServiceEntry: does not exist (no such service entry) I connect thusly and don't see myself using any services. I also do not have this issue on Mac OSX. Any ideas? I googled for this issue but don't even know if there's a protocols file on Windows, much less where it is and why "tcp" might not be there :-). connect :: HostName -> Int -> IO Handle connect h p = connectTo h $ PortNumber $ fromIntegral p main = withSocketsDo $ do connect "10.0.0.1" 15667 Thanks, Joel -- http://wagerlabs.com/

1 4

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