[Haskell-cafe] Freeing dependent resources
Hello, Haskellers.
I am working on HDBI and I faced with the problem.
There is an error when I close SQlite database, "unable to close due to
unfinalized statements or unfinished backups".
This problems occurs when there is some not finalized statements related to
this database.
So, I must protect the user from this error and garantee the finalisation
of all the statements BEFORE the disconnection from
the database.
There is naive implementation of weak child list inherited from HDBC
https://github.com/s9gf4ult/hdbi/blob/master/Database/HDBI/DriverUtils.hs
Here you can see that ChildList is just MVar to list of weak pointers.
Every time when the statement is created the new weak pointer prepended to
this list.
Every time when statement becomes not reachable the weak pointer becomes
empty and it's finalizer is scheduled to execute in parralel thread.
The finalizer finishes the statement, so if finalizer is executed the
statement is finished.
Before the actual call of disconnection the 'disconnect' method performs
'closeAllChildren'.
Call of 'closeAllChildren' performs finishing of just not empty weak
pointers, because the finishing of not reachable statements is imposible.
You can see the implementation here
https://github.com/s9gf4ult/hdbi-sqlite/blob/master/Database/HDBI/SQlite/Implementation.hs#L80
https://github.com/s9gf4ult/hdbi-sqlite/blob/master/Database/HDBI/SQlite/Implementation.hs#L117
and here is the simplest code which cause an error
{-# LANGUAGE
OverloadedStrings
#-}
module Main where
import System.Mem
import Database.HDBI.SQlite
import Database.HDBI
perf c = do
runRaw c "create table integers (val)"
s <- prepare c "select * from integers"
return ()
main = do
c <- connectSqlite3 ":memory:"
perf c
performGC
disconnect c
If you remove 'performGC' error not occurs, because the weak pointer in
ChildList is still not empty and
'finish' is performed in 'closeAllChildren'.
The problem occures when the statement becomes not reachable and weak
pointer becomes empty,
but finalizer is not performed yet, because the finalizer performed in
parralel thread according to
https://www.google.ru/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CC8QFjAA&url=http%3A%2F%2Fcommunity.haskell.org%2F~simonmar%2Fpapers%2Fweak.pdf&ei=vRALUvrELaaS4ASH_oCQCw&usg=AFQjCNEWQtRfh5ei7J_Qd-VDVMq0ied0KQ&sig2=nsvzz4FXB_4dWp75CU6gzg
The naive solution is to make 'closeAllChildren' to wait until all
finalizers is completely performed. But how ?
Maybe you have the better solution to garantee that all statements are
finished before the database disconnecting ?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] more gtk help
On Tue, Aug 13, 2013 at 10:45 PM, wrote: > fooBar = > do putStrLn "foo" >return True > > so then I thought, aha!, all I need to do is understand the type of > "return True" and all will be revealed to me. Well, it's this: > > Control.Monad.Trans.Reader.ReaderT >(GHC.Ptr.Ptr Gtk.EExpose) IO Bool > > just like the error message says. > > Still don't know what that's supposed to be. I'm having trouble tracking > down > > Control.Monad.Trans.Reader.ReaderT > In this case, all you need to know is the Control.Monad.Trans part and the IO underneath; this tells you that you can use `lift` and possibly `liftIO` to get at the IO. fooBar = do liftIO $ putStrLn "foo" return True If `liftIO` complains about a missing MonadIO instance, file a bug :) but you can also get there by using `lift` to reach it; in this case you only need it once, but for more deeply nested transformers you may need it multiple times (e.g. `lift . lift . lift $ putStrLn "foo"` for a stack of 3 transformers over IO). -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] more gtk help
On Mon, 12 Aug 2013 14:50:43 +0100 Claude Heiland-Allen wrote: > Hi Brian, > > On 12/08/13 03:52, bri...@aracnet.com wrote: > ... > > Couldn't match expected type > ... > > Gtk.on Gtk.exposeEvent glCanvas $ \ _ -> putStrLn "foo" > ... > > I looked up the type of Gtk.on and exposeEvent : > ... > > on > > :: object > > -> Signal object callback -> callback -> IO (ConnectId object) > ... > > I think you have the arguments flipped, try: > > Gtk.on glCanvas Gtk.exposeEvent $ \_ -> ... > > > As for explaining the types - as I understand it, you have an object and > a callback, and the Signal associates the object with the callback for a > specific event type. The type variables occur more than once in the > whole type for safety: the right type of callback must be provided for > the event type, and the object must support the event type too. > > This works _ <- Gtk.on glCanvas Gtk.exposeEvent $ return True but not this: _ <- Gtk.on glCanvas Gtk.exposeEvent fooBar where fooBar = do putStrLn "foo" return True so then I thought, aha!, all I need to do is understand the type of "return True" and all will be revealed to me. Well, it's this: Control.Monad.Trans.Reader.ReaderT (GHC.Ptr.Ptr Gtk.EExpose) IO Bool just like the error message says. Still don't know what that's supposed to be. I'm having trouble tracking down Control.Monad.Trans.Reader.ReaderT ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: hspec-smallcheck - SmallCheck support for the Hspec testing framework
Hi, I'm glad to announce SmallCheck support [1] for the Hspec testing framework. A tiny example on how to use it is here: https://github.com/hspec/hspec-smallcheck/blob/master/example/Spec.hs More documentation for Hspec is here: http://hspec.github.io/ Cheers, Simon [1] http://hackage.haskell.org/package/hspec-smallcheck ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Reminder: today is the deadline for HIW talk proposals (Haskell Implementor's Workshop)
If you would like to give a talk pertaining to Haskell implementation (including libraries). Please submit a short abstract below. See you in Boston! -Ryan * Call for Talks* ACM SIGPLAN Haskell Implementors' Workshop http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2013 Boston, USA, September 22th, 2013 The workshop will be held in conjunction with ICFP 2013 http://www.icfpconference.org/icfp2013/ Important dates Proposal Deadline: 13th August2013 (by midnight, any timezone) Notification: 27th August2013 Workshop: 22th September 2013 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
On 06.08.2013 10:46, Adam Gundry wrote:
On 06/08/13 06:14, J. Stutterheim wrote:
Suppose we now have the opportunity to change the name of the
`return` function in Monad, what would be a "better" name for it?
(for some definition of better)
Rather than proposing a different name, I'm going to challenge the
premise of your question. Perhaps it would be better if `return` had no
name at all. Consider the following:
return f `ap` s `ap` t
f <$> s <*> t
do { sv <- s
; tv <- t
; return (f sv tv) }
Indeed, I wished the 0-ary case would be more alike to the unary and
binary case, cf.
return f0
f1 <$> a1
f2 <$> a1 <*> a2
What is needed is a nice syntax for "idiom brackets".
These are all different ways of spelling
f s t
plus the necessary applicative or monadic bureaucracy. But why couldn't
we write just the plain application, and let the type system deal with
the plumbing of effects?
I would not think this is practically possible. For instance, if
f :: a -> b -> c
then it could be a binary function or a unary function in the context
monad reading from a, thus, application
f x
is ambiguous or too sensitive, especially with type inference.
I realise that this may be too open a research area for your project...
--
Andreas Abel <>< Du bist der geliebte Mensch.
Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY
andreas.a...@ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some philosophy (Was: Alternative name for return)
On 09.08.2013 17:44, Jerzy Karczmarczuk wrote: "Indiscrete Thoughts" by Gian-Carlo Rota, published by Birkhäuser in 1997. Available on the Web. For download or to buy? [This looks very interesting...] -- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.a...@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Diagrams and GTK
Hi Claude, Cairo is thread safe* so you could render the whole thing (if it isn't super huge dimensions) to an image surface in the background thread, then displaying could be a matter of copying the correct part (for scrolling) of the surface to the DrawingArea. Yes, I think I will try this solution when I come back to the problem (currently there are tons of other work to do). Thanks! lg, Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: libxkbcommon bindings
There's a lot of work nowadays towards replacing the X11 infrastructure. Notably, wayland intends to replace some of the functionality that X.Org now provides, and it uses libxkbcommon to replace the X11 XKB.h keyboard event parsing code (actually it is not a dependency, but it is the de facto standard). I think it would be great if haskell supports these new libraries as soon as they are being used, which is why I wrote haskell FFI bindings for libxkbcommon. Partly because I am not exactly an experienced haskell developer, and partly because I am unsure how users will use libxkbcommon, at this point haskell-xkbcommon is rather thin. I intend to add a layer of code that makes this look more haskelly based on your feedback. Hence, feedback is MOST welcome in any area, be it code style, documentation, or API preferences. I did not upload haskell-xkbcommon to hackage yet - should I at this stage? https://github.com/tulcod/haskell-xkbcommon PS: If this turns out to be a success, I'd like to develop wayland bindings as well, so if you have anything to say about that feel free to contact me. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
