- Haskell-Cafe - Haskell.org

pool, persistent, persistent-sqlite: Space leak
by Ertugrul Soeylemez 03 Apr '11

03 Apr '11

Hello Michael, hello fellow Haskellers, there seems to be a space leak in either 'pool', 'persistent' or 'persistent-sqlite'. From the behaviour I suspect the bug to be in 'pool'. When I run a transaction in an infinite loop, my program keeps eating more and more memory, even if the transaction itself doesn't do anything: forever $ runSqlPool (return ()) pool This doesn't happen for non-pooled connections, i.e. the following code runs in constant space as expected: forever $ runSqlConn (return ()) conn Versions are pool-0.0.1, persistent-0.4.2, persistent-sqlite-0.4.0. It happens for both file and in-memory databases. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/

2 2

darcs repo browser
by Radoslav Dorcik 02 Apr '11

02 Apr '11

Hi, there is one haskell web application based on happstack for viewing foreign darcs repos exposed only on pure HTTP servers. I need that for checking status of some repositories when I don't have access to darcs binary/shell... maybe it can be useful for somebody else too. Service is running on following URL: http://handra.rampa.sk/dawb/changes See more comments on http://rampa.sk/static/dawb.html Regarding RSS feeds - Please send me a note If you find the hourly cron job I run on some repos to produce feeds too expensive for your server resources. It does not obey robots.txt file yet. Regards, Rado

3 2

Re: [Haskell-cafe] Asynchronous Arrows need Type Specialization - Help!
by Paul L 02 Apr '11

02 Apr '11

Sorry, forgot to CC the list. I wonder why Gmail doesn't default to reply-all. On Fri, Apr 1, 2011 at 9:48 PM, David Barbour <dmbarbour(a)gmail.com> wrote: > > If we ignore the 'delay' primitive (which lifts latency into program > logic), my model does meet all the arrow laws. Nonetheless, the issues > of physical synchronization still apply. It's important to recognize > that the Arrow Laws do not describe non-functional properties, such as > time-space performance. Well, when you throw the time stamp into the value domain, and according to your previous calculation of time stamps, (a1 *** a2) >>> first a3 will produce different result than (a1 >>> a3) *** a2. This is in direct conflict to arrow laws. Arrows by themselves do not impose physical synchronization. They are very often used to model computations about synchronous data streams, but that is a very different concept. >> In the actual implementation of such lifting (perhaps over multiple >> type classes), the calculation of the time stamp can be made precise. > > Indeed. And it is precisely the greater of the input timestamps. ;-) This is because you are using a single number as timestamp. Define your timestamp type differently, you'll get a different opinion. For example, you can use a pair of time stamps for pairs, and nested time stamps for nested values. -- Regards, Paul Liu

2 1

Setting up cabal on EC2
by Lyndon Maydwell 02 Apr '11

02 Apr '11

Hi all. I'm having some issues setting up cabal on EC2. I've installed ghc 7.0.2, however, the bootstrap.sh script for cabal-install is complaining about missing dependencies: > Linking Setup ... > Configuring Cabal-1.8.0.2... > Setup: At least the following dependencies are missing: > base >=4 && <3 && >=1 && <5, filepath >=1 && <1.2 > Setup: At least the following dependencies are missing: base >=4 && <3 && >=1 && <5, filepath >=1 && <1.2 ghc-pkg tells me that I have base and filepath installed: > /usr/local/lib/ghc-7.0.2/package.conf.d > base-4.3.1.0 > /usr/local/lib/ghc-7.0.2/package.conf.d > filepath-1.2.0.0 Could there be an environment variable I need to set somewhere?

2 4

Re: [Haskell-cafe] [Haskell-beginners] how to modify show for a list of certain types
by Markus Läll 02 Apr '11

02 Apr '11

Check out "unlines"! On Sat, Apr 2, 2011 at 4:32 PM, Manfred Lotz <manfred.lotz(a)arcor.de> wrote: > Hi there, > I have a list of say type Record which I write to a file and > read back from the file if required. > > The list's content is a single line in the file it doesn't matter how > many records the list contains. > > I would like to modify show for type Record in a way that show does > work like the normal show but additionally adds a newline at the end of > the string. > > I'm a bit lost how to do that. Any idea? > > > -- > Manfred > > > > _______________________________________________ > Beginners mailing list > Beginners(a)haskell.org > http://www.haskell.org/mailman/listinfo/beginners >

1 0

Multi agent system
by Yves Parès 02 Apr '11

02 Apr '11

Hello, For the purpose of a simple game, I'm looking for a simple way to get agents communicating with each other, with agents possibly running on different threads: Basically, an agent is Agent :: * -> *, since it is parameterized with the type of messages it can receive, and can make two basic operations: fetch, which gives it the messages in its mailbox and send, which sends a message a to an Agent a Given that haskell threads are lightweight, is it reasonable to lauch a thread per agent and then implement fetch and send through Chans? It will be simple to implement and to use, but if I have, say, two hundreds of really dumb (sorry, *reactive *^^) agents, like ants, I will have to launch as many threads. I could use a neater abstraction than IO to model agents (FRP is perfect for that), but I would loose the benefits of concurrent programming (or I won't be able to keep things simple).

2 1

Fwd: using IO monad in Iteratee
by Dmitry Olshansky 02 Apr '11

02 Apr '11

---------- Forwarded message ---------- From: Dmitry Olshansky <olshanskydr(a)gmail.com> Date: 2011/4/2 Subject: Re: [Haskell-cafe] using IO monad in Iteratee To: wren ng thornton <wren(a)freegeek.org> Well, in my case I can use probably withBinaryFile fn (\h-> run $ enumHandle h ...) 2011/4/2 wren ng thornton <wren(a)freegeek.org> > On 4/1/11 3:59 PM, Dmitry Olshansky wrote: > >> But enumFile use IO monad instead of MonadIO class. >> [...] >> >> Is it possible to change enumFile to using MonadIO class? >> > > Unless its changed significantly since I looked at it last (which it may > well have), it's not possible. The problem is that what we'd really need is > lowerIO :: m a -> IO a for the m in question; liftIO goes the wrong way. Of > course, getting a lowerIO with the right semantics will be tricky for most > monads. > > -- > Live well, > ~wren > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

Asynchronous Arrows need Type Specialization - Help!
by David Barbour 02 Apr '11

02 Apr '11

I was giving Control.Arrow a try for a reactive programming system. The arrows are agents that communicate by sending and returning time-varying state. Different agents may live in different 'vats' (event-driven threads) to roughly model distributed computing. For the most part, the state varies asynchronously - i.e. a file updates at a different rate than the mouse position. Anyhow, I ran into a problem: The (***) and (&&&) operations, as specified in Control.Arrow, are inherently synchronization points. Ideally one could do something like: (a1 *** a2) >>> first a3 and the output from a1 would be piped directly as input to a3, without touching a2. However, arrows also allow: (a1 *** a2) >>> arr f And, in this case, the current state of a1 and a2 must be combined into a stream of pairs so that f may be mapped over the stream. Obtaining both streams at a single place (a single vat) and time is a synchronizing operation. The synchronization operations are severely undermining the intended scalability and performance of this agent abstraction. Now, I believe I could make it work if I could somehow specialize the arrow type with aparametric structure... A (b,b') (c,c') = A b c = But I've not been able to make the Haskell type system happy with this. Type families allow some specialization, but they don't allow ambiguity or defaults. Given the 'arr' function, I must be able to instantiate an A involving any type at all. Today I explored an alternative version of Control.Arrow, using an opaque product type specialized to the arrow, but I still bumped into the issue of specializing the arrow type for this. I don't see how GADTs would help. I've been stuck on this for a couple weeks now. Ideas would be appreciated.

4 3

Re: [Haskell-cafe] Asynchronous Arrows need Type Specialization - Help!
by Paul L 02 Apr '11

02 Apr '11

Thanks for the elaboration. I now have a much better understanding. FIrst of all, I agree that the system model as you laid out do not fit into the arrows abstraction with respect to the set of arrow laws. Then the choice is whether to shape the arrows to fit your model, or shape your model to fit arrows. You chose the former. But one thing I want to be clear is that the arrows abstraction didn't impose the kind of strictness to your model, your system design did. If you would like to consider the second approach, I have a few suggestions: 1. Enable a lazy evaluation strategy over a distributed system. This can be done by passing place holders between agents, and only fill them (either by sending over data or request-by-demand) when value is fully computed. There could be other alternatives, but I'm not familiar with the set of literatures in this particular area. Maybe somebody else could give pointers. 2. Statically schedule data availability and delivery from producer to consumer. I'm not sure what kind of application you try to model, but this would limit the scope to dataflow that can be statically analyzed before program runs. On the other hand, the limitation also bring benefits because we can be smart about whether to move data or to move computation. To do this properly requires a solution to the pure function problem. For the pure function example you gave: > let f = \ (fileState, queryResult) -> combineResponses in > (a1 *** a2) >>> arr f Didn't you just mention that you want to tag along the time stamp to the values? So fileState is really a lifted value over a plain file state, and so is queryResult. This means the combineResponse function is also a lifted function. In the actual implementation of such lifting (perhaps over multiple type classes), the calculation of the time stamp can be made precise. Only difficulty I see here is that we may need to lift time stamped values over tuples. A single Int value wouldn't suffice as the type for time stamp because it has to take the max of time stamps of the tuple elements (what is exactly what you are criticizing). It may require some type level magic, but I am quite positive that difficulties can be overcome. Regards, Paul Liu On Fri, Apr 1, 2011 at 6:00 PM, David Barbour <dmbarbour(a)gmail.com> wrote: > On Fri, Apr 1, 2011 at 2:57 PM, Paul L <ninegua(a)gmail.com> wrote: >> I now understand where you are coming from, but I don't quite get your >> motivation to develop new classes for arrows. Tupling is Haskell is of >> course very lazy, it does not evaluate any of its element. > > Assume three machines: Alice, Bob, and Charlie. Bob owns resource a1, > and Charlie owns resource a3. Bob and Charlie do not know about one > another. Alice runs 'a1 >>> a3' with some initial inputs. For an > 'efficient' implementation, I need the output from a1 to propagate > directly as input to a3, directly from Bob to Charlie - do not pass > Alice, do not waste precious bandwidth and latency. > > Now extend the example just a bit: > > (a1 *** a2) >>> first a3 > > Naively, Alice might take the outputs from a1 and a2 and build a tuple > (r1,r2), then promptly split the tuple back up and send r1 to Charlie. > But this wastes a lot of time and bandwidth and CPU bringing r1 and r2 > together onto Alice's machine. It doesn't matter that Alice never > looks at r1 herself... the fact that she even 'touches' the r1 > variable is killing performance and requires physical synchronization. > In short, laziness doesn't help here. What does help is optimizing > the above into ((a1 >>> a3) *** a2). > > I could go into even more reasons. (I.e. I'm actually using streams, > not simple values, so tupling and untupling is closer to zipping and > unzipping.) But I think the above argument is sufficient by itself. > > My model is designed for efficient, scalable, open, distributed > programming. I currently model distributed machines each as a thread > with an event-loop. But this is a proof-of-concept implementation: I'm > unwilling to 'cheat' by using any techniques that could not > efficiently and securely be implemented for a real open distributed > system. > >> >> As for the spatial and logical concepts, don't you think they are >> over-specifying what is really necessary for your system model? > > I do not believe I've overspecified. > > But I've also avoided explaining the full model. That sort of > explanation really requires a conference paper with a lot of > motivating examples, and it was not my intent to use Haskell-cafe as a > forum. > >> >> So I guess what I'm having trouble with is your arr f example. If f is >> sufficiently lazy, it does not evaluate the elements in its input >> tuple at all. Most pure functions we use to wire up arrows are like >> this: arr fst, arr snd, arr swap, arr (\x -> (x, x)), etc. > > For simple data plumbing that never needs to touch the input, I > currently suggest specialized arrows: > aconst :: c -> a b c > > afst :: a (b,c) b > asnd :: a (b,c) c > adup :: a b (b,b) > aswap :: a (b,c) (c,b) > > aleft :: a b (Either b c) > aright :: a c (Either b c) > amerge :: a (Either b b) b > amirror :: a (Either b c) (Either c b) > > Potentially, RULES pragmas could also convert from 'arr fst' to a > particular implementation of 'afst', though I'd not recommend RULES at > the typeclass level after having been hurt by those in Control.Arrow. > >> >> I also don't quite follow your example of passing a time stamp >> together with value. > > Logically, a 'future' is just a time-stamp paired with a value. > > let f = \ (fileState, queryResult) -> combineResponses in > (a1 *** a2) >>> arr f > > Here, 'arr f' is opaque to my implementation. I cannot look inside 'f' > and decide whether or not it needs both fileState and queryResult, or > just one of them, or none (const). So I must somehow wait for both > fileState and queryResult to be available before I can evaluate > combineResponses. How long do I wait? Well, until the last response is > available. > > In the reactive context, you don't really have futures, but you still > have latency before resource state becomes available, and must wait to > combine results. > >> >> If you are getting unwanted results, it is perhaps due to wrong >> computation, rather than the composition to a pure functions. >> Maybe you want to give a specific example of "f". > > Regards, > > David > -- Regards, Paul Liu

1 0

Missing MaybeT MonadFix instance
by Job Vranish 02 Apr '11

02 Apr '11

Is there a particular reason that the transformers<http://hackage.haskell.org/packages/archive/transformers/latest/doc/html/Co…>version of the MaybeT monad does not have a MonadFix instance? It seems like the following instance would be suitable: instance (MonadFix m) => MonadFix (MaybeT m) where mfix f = MaybeT $ mfix $ \a -> runMaybeT $ f $ case a of Just a -> a Nothing -> error "mfix MaybeT: Nothing" I don't think it's possible to hit the error case: In order to terminate f cannot be strict so it must return a value without evaluating its input. If f returns a Nothing, then you have your return value and you're done. If f returns a Just, then we don't hit the error case. - Job

1 0