- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Semantics of ForeignPtr Finalizers
by Antoine Latter 19 Jun '11

19 Jun '11

Sending to the list as well. On Jun 19, 2011 9:58 AM, "Antoine Latter" <aslatter(a)gmail.com> wrote: > On Jun 19, 2011 7:49 AM, "Bas van Dijk" <v.dijk.bas(a)gmail.com> wrote: >> >> On 19 June 2011 14:13, wren ng thornton <wren(a)freegeek.org> wrote: >> > The documentation claims that >> > the finalizers are run only once the ForeignPtr becomes unreachable, > which >> > implies that keeping the ForeignPtr is sufficient to keep the foreign >> > object alive. >> >> Right, that was also my thinking when designing the usb library. What >> made me doubt this was the implementation of storable vectors: >> >> > http://hackage.haskell.org/packages/archive/vector/0.7.1/doc/html/src/Data-… >> >> Note that a storable vector stores both a foreign pointer and a >> pointer (presumably so that you don't need to add an offset to the >> pointer, inside the foreign pointer, each time you use it): >> >> data Vector a = Vector !(Ptr a) !Int !(ForeignPtr a) >> >> Now, if we follow the above semantics we don't need to call >> withForeignPtr when we need to read the memory because the foreign >> pointer is referenced by the vector. >> However the vector library still calls withForeignPtr. For example: >> >> basicUnsafeIndexM (Vector p _ fp) i = return >> . unsafeInlineIO >> $ withForeignPtr fp $ \_ -> >> peekElemOff p i >> >> So is the withForeignPtr redundant so that this function can be >> rewritten to just: >> >> basicUnsafeIndexM (Vector p _ _) i = return >> . unsafeInlineIO >> peekElemOff p i >> > > I'd be afraid of optimizations getting ride of the constructor, and since > I'm not using all of the fields I would no longer have a reference to the > foreign ptr. > > Since withForeignPtr touches the foreign pointer the optimizations won't > make it go away no matter how it transfoms the function. > > Antoine > >> Regards, >> >> Bas >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1

Re: [Haskell-cafe] Semantics of ForeignPtr Finalizers
by wren ng thornton 19 Jun '11

19 Jun '11

On 6/19/11 3:52 AM, Bas van Dijk wrote: > Hello, > I have a question about the semantics of finalizers of ForeignPtrs: If an in scope value has a reference to a ForeignPtr is the foreign object always kept alive, even if that reference is not used? Or do I always need to wrap each computation, which needs to have the foreign object alive, inside withForeignPtr? I know that the Ptr obtained by withForeignPtr will _not_ keep the foreign object alive (though withForeignPtr itself will be sure to keep it alive until the function using the Ptr exits). For instance, this shows up with ByteStrings if you try to save the Ptr somewhere and then use it after withForeignPtr exits. I believe that ForeignPtr itself does promise to keep the foreign object alive, since it's what holds the finalizers. The documentation claims that the finalizers are run only once the ForeignPtr becomes unreachable, which implies that keeping the ForeignPtr is sufficient to keep the foreign object alive. I haven't used ForeignPtr for truly foreign objects, only for pseudo-foreign objects like ByteString, but in my experience just having the ForeignPtr is enough to keep the target alive. -- Live well, ~wren

2 1

Semantics of ForeignPtr Finalizers
by Bas van Dijk 19 Jun '11

19 Jun '11

Hello, I have a question about the semantics of finalizers of ForeignPtrs: If an in scope value has a reference to a ForeignPtr is the foreign object always kept alive, even if that reference is not used? Or do I always need to wrap each computation, which needs to have the foreign object alive, inside withForeignPtr? To make my question more concrete, I will give a simplified example from my usb library (a high-level binding to the libusb C library): https://github.com/basvandijk/usb To use the library you first need to initialize libusb which will yield a context: newtype Ctx = Ctx {getCtxFrgnPtr ∷ (ForeignPtr C'libusb_context)} When you're finished with libusb you need to exit the library. This is done automatically using a ForeignPtr: newCtx ∷ IO Ctx newCtx = mask_ $ do ctxPtr ← libusb_init Ctx <$> newForeignPtr p'libusb_exit ctxPtr where libusb_init ∷ IO (Ptr C'libusb_context) libusb_init = alloca $ \ctxPtrPtr → do handleUSBException $ c'libusb_init ctxPtrPtr peek ctxPtrPtr I provide a handy internal utility function for accessing the pointer to the context: withCtxPtr ∷ Ctx → (Ptr C'libusb_context → IO α) → IO α withCtxPtr = withForeignPtr ∘ getCtxFrgnPtr Because this function uses withForeignPtr it's guaranteed that the context is kep alive during the duration of the given function. For example, in the following, it is guaranteed that c'libusb_set_debug is always given a live context: setDebug ∷ Ctx → Verbosity → IO () setDebug ctx verbosity = withCtxPtr ctx $ \ctxPtr → c'libusb_set_debug ctxPtr $ genFromEnum verbosity There are also types which are derived from a context. For example: getDevices ∷ Ctx → IO [Device] is a function which given a context returns a list of USB devices currently attached to your system. The requirement is that when you need to use a device the context has to be kept alive. Therefor I keep a reference to the context inside the device: data Device = Device { getCtx ∷ !Ctx , getDevFrgnPtr ∷ !(ForeignPtr C'libusb_device) , deviceDesc ∷ !DeviceDesc } The idea is that as long as you have a reference to a device you also keep the context alive because the device references the context. (Note that a device, in turn, also contains a ForeignPtr) getDevices ∷ Ctx → IO [Device] getDevices ctx = ... where mkDev ∷ Ptr C'libusb_device → IO Device mkDev devPtr = liftA2 (Device ctx) (newForeignPtr p'libusb_unref_device devPtr) (getDeviceDesc devPtr) Again I provide a handy internal utility function for accessing the pointer to a device: withDevicePtr ∷ Device → (Ptr C'libusb_device → IO α) → IO α withDevicePtr = withForeignPtr ∘ getDevFrgnPtr And now my question. Is it guaranteed that when the device is in scope the context is always kept alive? For example, is the context kept alive in the following: openDevice ∷ Device → IO DeviceHandle openDevice dev = withDevicePtr dev $ \devPtr → alloca $ \devHndlPtrPtr → do handleUSBException $ c'libusb_open devPtr devHndlPtrPtr DeviceHandle dev <$> peek devHndlPtrPtr Or do I also need to call withCtxPtr inside withDevicePtr as such: withDevicePtr (Device ctx devFP _) f = withCtxPtr ctx $ \_ → withForeignPtr devFP f Thanks, Bas

1 0

Re: [Haskell-cafe] Data Type Inheritance ala OO - Inheritence -- howto best in Haskell ?
by David Barbour 17 Jun '11

17 Jun '11

Look into Oleg's HList (heterogeneous list) and OOHaskell http://homepages.cwi.nl/~ralf/HList/ http://homepages.cwi.nl/~ralf/OOHaskell/ On Thu, Jun 16, 2011 at 5:08 AM, kaffeepause73 <kaffeepause73(a)yahoo.de>wrote: > Dear all, > > I'm created a timeSignal datatype as container around a "Vector Double" > data > type (see simple code below) and subsequently started to instanciate Num & > Eq to be able to perform operations on it. Additionally I want store ifno > like an index, time information and eventually an inheritence log (the log > is not yet in there). > > As I will in the end need up to 10 different datatypes, however using > slightly different content (time signal, single value, distribution, ...) I > ask myself, how I could define a super data-type with sub-data-types to > inherit, but then also overload certain functions (like u would do in OO). > > What is best way in haskell to achieve this ? (I'm unsure wether haskell > classes are what I'm looking for) > > Cheers Phil > > ########## Code below > > import qualified Data.Vector.Unboxed as V > > data TimeSig = TimeSig Int Double (V.Vector Double) -- signal Index > timeStep > data > > getVect :: TimeSig -> (V.Vector Double) > getVect (TimeSig idx dt vect)= vect > > getIdx :: TimeSig -> Int > getIdx (TimeSig idx dt vect) = idx > > getdt :: TimeSig -> Double > getdt (TimeSig idx dt vect) = dt > > pzipWith :: (Double -> Double -> Double) -> TimeSig -> TimeSig -> TimeSig > pzipWith f p1 p2 = TimeSig idx dt vect > where > vect = V.zipWith f (getVect p1) (getVect p2) > idx = getIdx p1 > dt = getdt p1 > > pmap :: (Double -> Double) -> TimeSig -> TimeSig > pmap f p = TimeSig (getIdx p) (getdt p) (V.map f (getVect p)) > > instance Num TimeSig > where > (+) p1 p2 = pzipWith (+) p1 p2 > (-) p1 p2 = pzipWith (-) p1 p2 > negate p1 = pmap negate p1 > abs p1 = pmap abs p1 > (*) p1 p2 = pzipWith (*) p1 p2 > > instance Eq TimeSig where > (==) p1 p2 = (==) (getVect p1) (getVect p2) > > > instance Show TimeSig where > show (TimeSig idx dt vect) = "TimeSignal Nr: " ++ show idx ++ " dt: " ++ > show dt ++ " val:" ++ show vect > > > > main = do > > let p = TimeSig 5 0.1 (V.fromList [0..10::Double]) > putStrLn (show p) > putStrLn (show (p+p)) > > -- > View this message in context: > http://haskell.1045720.n5.nabble.com/Data-Type-Inheritance-ala-OO-Inheriten… > Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

4 4

ANNOUNCE: Groundhog-0.0.1.1, a database connectivity library
by Boris Lykah 17 Jun '11

17 Jun '11

Hi, everyone! I am happy to announce a new persistence library, Groundhog. http://hackage.haskell.org/package/groundhog http://hackage.haskell.org/package/groundhog-sqlite Groundhog does mapping between datatypes and database like Persistent in Haskell or Hibernate in Java and makes dealing with database very easy. The API is inspired by Persistent, a great framework by Michael Snoyman, from which I used some ideas and code. At first I wanted to enhance Persistent, but many useful ideas don't fit into its design. Groundhog offers features I wanted to see in a modern Haskell database library. My intent was to create a package which you can plug into your existing project and it would just work. So it does not require defining datatypes using its own mechanisms (quasiquotation, XML, etc). You can use your own types defined anywhere. The restrictions on type structure are very mild. Groundhog uses data families and GADTs and they did not play nicely together until GHC 7, so GHC 6.12.x and earlier is not supported. Currently there is support only for Sqlite but I hope to add more backends soon. Sqlite backend is based on direct-sqlite package by Dan Knapp. I modified it to improve performance and provide better error messages. Now it is bundled with groundhog-sqlite but I hope to merge it with direct-sqlite. On simple datatypes performance is ~2.5 times higher compared to Persistent. Some of this gain is achieved because of Sqlite specific optimisations, but I expect to see high performance on other backends as well. In fact, it could be even faster. I sacrificed ~30% of backend-independent performance for flexibility when I chose DbPersist to be a monad transformer instead of sticking with IO and replaced direct mentions of DbPersist with Monad m in PersistBackend. Features: * Persists datatypes defined in an ordinary way * Supports fields of user-defined types * Supports polymorphic datatypes and datatypes with several constructors * Basic support for lists and tuples * Type safety * Migration from an empty schema * Powerful expression DSL for use in queries * Execution of arbitrary queries * High performance Plans (in priority order): * Add more backends, particularly PostgreSQL * Allow migration when data definition changes * Add Persistent-like quasiquotation syntax Here is an example from the documentation: {-# LANGUAGE GADTs, TypeFamilies, TemplateHaskell #-} import Control.Monad.IO.Class(liftIO) import Database.Groundhog.TH import Database.Groundhog.Sqlite data Customer a = Customer {customerName :: String, details :: a} deriving Show data Item = ProductItem {productName :: String, quantity :: Int, customer :: Customer String} | ServiceItem {serviceName :: String, deliveryAddress :: String, servicePrice :: Int} deriving Show deriveEntity ''Customer $ Just $ do setConstructor 'Customer $ do setConstraints [("NameConstraint", ["customerName"])] deriveEntity ''Item Nothing main = withSqliteConn ":memory:" $ runSqliteConn $ do -- Customer is also migrated because Item contains it runMigration silentMigrationLogger $ migrate (undefined :: Item) let john = Customer "John Doe" "Phone: 01234567" johnKey <- insert john -- John is inserted only once because of the name constraint insert $ ProductItem "Apples" 5 john insert $ ProductItem "Melon" 2 john insert $ ServiceItem "Taxi" "Elm Street" 50 insert $ ProductItem "Melon" 6 (Customer "Jack Smith" "Don't let him pay by check") -- bonus melon for all large melon orders update [QuantityField =. toArith QuantityField + 1] (ProductNameField ==. "Melon" &&. QuantityField >. (5 :: Int)) productsForJohn <- select (CustomerField ==. johnKey) [] 0 0 liftIO $ putStrLn $ "Products for John: " ++ show productsForJohn -- check bonus melon <- select (ProductNameField ==. "Melon") [Desc QuantityField] 0 0 liftIO $ putStrLn $ "Melon orders: " ++ show melon Currently Hackage cannot build it due to technical issues (as Dons assumed several packages it depends on are not exposed), but you can install it with cabal. It is still very early beta and it may have some bugs. I am very interested to hear your feedback. Thanks, Boris Lykah

1 0

ANNOUNCE: doctest-0.3.0
by Simon Hengel 17 Jun '11

17 Jun '11

I just uploaded a new version of doctest[1] to Hackage. WHAT IS doctest? ================ doctest is a port of Python's doctest[2] to Haskell. It can be used to verify, that examples in Haddock comments[3] do still work. This also provides you with a simple mechanism to write unit test, without the burden of maintaining a dedicated test suite. A basic example of usage is at [4]. WHAT'S NEW IN THIS VERSION? =========================== It is now possible to intersperse comments between a longer, continuing example. All examples within the same comment now share a namespace. The following now works : -- | Calculate Fibonacci number of given 'Num'. -- -- First let's set `n` to ten: -- -- >>> let n = 10 -- -- And now calculate the 10th Fibonacci number: -- -- >>> fib n -- 55 fib :: Integer -> Integer fib 0 = 0 fib 1 = 1 fib n = fib (n - 1) + fib (n - 2) Thanks to Sakari Jokinen for this contribution! In addition I changed the name from DocTest to doctest. I think using all lower-case package names is a good thing. And as we will use doctest as a library in the near future, this was the last chance for this change. Cheers, Simon [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/doctest [2] http://docs.python.org/library/doctest.html [3] http://www.haskell.org/haddock/doc/html/ch03s08.html#id566093 [4] http://haskell.org/haskellwiki/DocTest

4 4

Simple CSV parser?
by Dmitri O.Kondratiev 17 Jun '11

17 Jun '11

Hi, This time I am looking for a simple CSV parser that supports commas and quotes. I have no time now to learn Parsec, so I hope to find something simple and easy to use. Thanks!

5 14

type signature of parsec functions and how to warp them up.
by 吴兴博 17 Jun '11

17 Jun '11

I have some different parsers of Parsec to use in a project, and I want to make a warp function to make the testing easy. here is some of my body of parser : they all has type of "parsecT ***" stringSet :: ParsecT String u Identity [String] intSet :: ParsecT String u Identity [Integer] tupleSet :: ParsecT String u Identity [(String, String)] all of the returned type are instance of 'Show'. then I write these warp function: ------------------ import System.IO import Data.Functor.Identity (Identity) import Text.Parsec.Prim (ParsecT, runParserT, parse, Stream) runIOParse :: (Show a) => ParsecT String u Identity a -> String -> IO () runIOParse pa fn = do inh <- openFile fn ReadMode outh <- openFile (fn ++ ".parseout") WriteMode instr <- hGetContents inh let result = show $ parse pa fn instr hPutStr outh result hClose inh hClose outh ------------------- > :l RunParse.hs ------------------- RunParse.hs:12:31: Could not deduce (u ~ ()) from the context (Show a) bound by the type signature for runIOParse :: Show a => ParsecT String u Identity a -> String -> IO () at RunParse.hs:(7,1)-(15,15) `u' is a rigid type variable bound by the type signature for runIOParse :: Show a => ParsecT String u Identity a -> String -> IO () at RunParse.hs:7:1 Expected type: Text.Parsec.Prim.Parsec String () a Actual type: ParsecT String u Identity a In the first argument of `parse', namely `pa' In the second argument of `($)', namely `parse pa fn instr' Failed, modules loaded: none. ------------------- then I modify the type signature of 'runIOParse': runIOParse :: (Show a) => ParsecT String () Identity a -> String -> IO () then load again > :l RunParse.hs ------------------- RunParse.hs:12:25: Could not deduce (Stream String Identity t0) arising from a use of `parse' from the context (Show a) bound by the type signature for runIOParse :: Show a => ParsecT String () Identity a -> String -> IO () at RunParse.hs:(7,1)-(15,15) Possible fix: add (Stream String Identity t0) to the context of the type signature for runIOParse :: Show a => ParsecT String () Identity a -> String -> IO () or add an instance declaration for (Stream String Identity t0) In the second argument of `($)', namely `parse pa fn instr' In the expression: show $ parse pa fn instr In an equation for `result': result = show $ parse pa fn instr Failed, modules loaded: none. ------------------- I also tried some 'possible fix' in the information, but it still failed to pass the compiler. Main Question: **** How can I warp a parsec function interface for do the IO test with different 'ParsecT String u Identity a'? -- ---------------- 吴兴博 Wu Xingbo

3 5

Haskell: The Craft of Functional Programming 3rd ed is out.
by KC 16 Jun '11

16 Jun '11

http://www.haskellcraft.com/craft3e/Home.html -- -- Regards, KC

1 0

Can one drop GHC 7.0.4 into the Haskell Platform or does the platform need to be updated?
by KC 16 Jun '11

16 Jun '11

-- -- Regards, KC

1 0