Re: [Haskell-cafe] Online haskell course
In case you haven't seen it, there is an intro to Haskell video series by Erik Meijer on Channel9. There aren't any graded assignments or anything like that, but I found it to be excellent without those. [1] http://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-Functional-Programming-Fundamentals/Lecture-Series-Erik-Meijer-Functional-Programming-Fundamentals-Chapter-1 On Wed, Oct 24, 2012 at 10:59 AM, wrote: > Anyone know of a similar course to the coursera scala one for haskell ? > > https://www.coursera.org/course/progfun > > Quite interesting online course that has graded assignments. > > Anything similar or anyone considering doing something similar for > haskell ? > > Thanks > Graham > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] acid-state audit trail
Ok, cool. Any idea if you can get a list of events, or can you just get the latest state? Thanks, Rich On Oct 19, 2012 3:53 AM, "Neil Davies" wrote: > The history is there until you "archive" (move a checkpoint out into a > separate directory) it and then delete the archive yourself. > > the checkpointing just reduces the recovery time (i.e creates a fixed > point in time), if you were to keep all the checkpoint/archives then you > would have the complete history > > Neil > > On 19 Oct 2012, at 06:18, Richard Wallace > wrote: > > > Hey all, > > > > I've been looking at acid-state as a possible storage backend for an > > application. It looks like it fits my needs pretty damn well, but one > > thing that I'm curious about is if it is possible to get a list of > > "update events". You can obviously query for the current state, but > > it's not immediately apparent if you can see the history of your > > values state. This is useful in some things, like providing audit > > trails and debugging. As well as being able to re-create state in a > > different form. > > > > I was also curious if the createCheckpoint function eliminates the > > state history or does it just create a snapshot, it's not apparent > > from the docs. > > > > Thanks, > > Rich > > > > ___ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] acid-state audit trail
Hey all, I've been looking at acid-state as a possible storage backend for an application. It looks like it fits my needs pretty damn well, but one thing that I'm curious about is if it is possible to get a list of "update events". You can obviously query for the current state, but it's not immediately apparent if you can see the history of your values state. This is useful in some things, like providing audit trails and debugging. As well as being able to re-create state in a different form. I was also curious if the createCheckpoint function eliminates the state history or does it just create a snapshot, it's not apparent from the docs. Thanks, Rich ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Getting started with Shake
Hey all, I'm going to be working on a webapp in Haskell in the upcoming months and am thinking Shake would be a good fit - I'll need to do js, css, and probably some graphics processing as part of the build and would like to use Shake to automate deployment. I'm not entirely sure how to get started with Shake. I've used to make, jam, maven, sbt and other build tools in the past. All of these keep a build configuration in the project and use that to build the project. In sbt, which is most like Shake, the build configuration is written in Scala and compiled by sbt when you run the build. The result of the compilation is saved and reused unless it detects that the build source files changed. With shake I'm not sure exactly how to get started. Should I have a separate project where I create the build system for the webapp? Or can I setup something similar to sbt? Also, how do I handle dependencies with shake? cabal will pull in packages from hackage and do the needful, is there anything in shake to do the same? If not, how is it normally done? Thanks, Rich ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hellno - a somewhat different approach to tackling cabal hell
I like the approach so far. But hellno itself seems to have several
dependencies itself. So installing with cabal pulls these in as
"fixed" libraries ("text", "mtl", "transformers", and "parsec"). Any
plans to make these not have to be fixed? Or is there a trick I'm
missing?
On Sun, Sep 2, 2012 at 11:25 AM, Danny B wrote:
> Like many of us, I've suffered from cabal dependency hell and sought relief.
>
> I wasn't exactly happy with sandboxes - because using per-project ones
> meant package duplication and shared sandboxes suffer from the same
> issues as the GHC package database itself, i.e. reinstalls can break
> other projects, etc. So I wrote hellno, which is so named because that's
> the expression one makes when seeing cabal hell suddenly manifest itself
> and that's also the expression one makes upon encountering yet ANOTHER
> cabal wrapper.
>
> To quote the README:
>> Generally, with hellno you'll get the same result as for blowing away your
>> user
>> package database and doing a nice clean install but without having to
>> recompile
>> everything and with ability to easily revert back and change between
>> projects.
>
> Hellno works by keeping all the compiled packages to itself in a
> database, so that when you ask it to bring in the dependencies of a
> project, it will use the precompiled packages if available or install
> the deps and save them for later reuse.
>
> Hellno puts symlinks in the user package database pointing to packages
> in its storage to make them visible. Mutating the user db is hardly
> elegant, although shouldn't result in much trouble.
>
> It's been working fine for me, so I figured it may be useful to others.
> You can get hellno from GitHub:
> https://github.com/db81/hellno
>
> I don't mean to say that sandboxing is inherently bad or should not be
> used, but I guess it's better to consider more than one way.
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Is ListT a valid MonadPlus?
It appears to me that the MonadPlus instance for ListT breaks the following MonadPlus law m >> mzero = mzero I've tried with every implementation of ListT I could find - the one in mtl, transformers, List, even "ListT done right" and it's alternative. They all seem to violate the above law. Following is a ghci session that shows this with the mtl impl. Prelude> import Control.Monad.List Prelude Control.Monad.List> let nt = ListT Nothing :: ListT Maybe Int Prelude Control.Monad.List> let e = mzero :: ListT Maybe Int Prelude Control.Monad.List> runListT nt Nothing Prelude Control.Monad.List> runListT e Just [] Prelude Control.Monad.List> runListT $ nt >> e Nothing According to the MonadPlus law above, that last line should evaluate to `Just []`. So is ListT a valid MonadPlus? Or am I missing something? If not, can a valid MonadPlus instance for ListT be written? I've tried a few things and come up short. Thanks, Rich ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] External system connections
Alright, I'll have to think on this some more but I think we're speaking the same language now - and what's more I even understand it! Thanks again for all your help, Rich On Sun, Jul 10, 2011 at 6:46 PM, Brandon Allbery wrote: > On Sun, Jul 10, 2011 at 20:19, Richard Wallace > wrote: >> On Sun, Jul 10, 2011 at 4:38 PM, Brandon Allbery wrote: >> Ok, I can see that. Though I was thinking that the worker threads >> would send the request back to the dispatcher by way of the same Chan >> the dispatcher reads requests from. Obviously I was thinking the >> dispatcher would use the original token to filter requests in the >> Chan. If I understand what you are talking about, the dispatcher >> would do the token renewal in a separate thread, continuing to process > > The same Chan is used to send a request; the thread processing token > renewal might or might not be otherwise a normal worker thread, but > it's separated out as a Maybe ThreadId instead of being in a pool, > because (a) there can only be zero or one of them, and (b) if it's not > Nothing then the dispatcher thread accepts only token renewals. (This > actually requires either multiple Chans or something more complex than > a normal Chan, since you can't filter a Chan based on the type of > message.) You also need some way to block the sender, which suggests > that a message written down a Chan must include an MVar which will be > signaled when the operation is complete. This suggests to me > something along the lines of > >> data WorkRequest = SOAPData ... (MVar Bool) >> | TokenRequest Token (MVar Token) >> -- | ReadyForWork (MVar WorkRequest) > > where the requestor allocates an MVar, writes it as part of the > WorkRequest, and then does a takeMVar to wait for the response. The > dispatcher reads WorkRequests, dispatches any it can to available > workers, and queues the rest internally; if it's a TokenRequest then > it's queued separately and all SOAPData requests get queued regardless > of whether there are free workers. When the single token processor > returns, all entries in the TokenRequest queue get awakened (putMVar > threadMVar newToken) and normal processing of the standard request > queue resumes. > > Or you can see if the pool hackage handles the ugly details here > automatically; I haven't looked. > >> If the pool is of threads, how do you start the threads? How do you >> submit work to the threads? The only way I know of in Haskell of >> creating threads to do work is forkIO. That takes a function and runs >> to completion. Would a worker thread just be one that loops forever > > Yes; the dispatcher keeps a list of workers, which are forkIO-d > threads that are waiting on an MVar or Chan for work to do. When they > receive something, they go off and do it, write the result into > another MVar or Chan which was specified in the request, and go back > to waiting on the initial MVar/Chan for something to do. If the list > is shorter than the maximum, more workers are forkIO-d to fill it as > needed; if longer, idle workers are sent "shut down" requests. (The > latter is "polite" handling of program shutdown, and also allows for > the pool size to be modified dynamically if needed.) I think doing > this right also requires that a worker that's ready for more work > explicitly check in, so the dispatcher knows it's available; that > could be handled by an additional WorkRequest type (see commented-out > line above, where a worker that's ready to handle another request > passes its input MVar to the dispatcher)... but there may be better > ways; I have some grasp of concurrency, but my Haskell library fu is > still somewhat weak. Hopefully someone else will jump in if > appropriate. > > (You can see how quickly this becomes complex, though; if the canned > solution does what you need, you might want to avoid reinventing this > particular wheel unless you're doing it for educational purposes.) > > -- > brandon s allbery allber...@gmail.com > wandering unix systems administrator (available) (412) 475-9364 vm/sms > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] External system connections
On Sun, Jul 10, 2011 at 4:38 PM, Brandon Allbery wrote: > One of the reasons to send the request back to the dispatcher instead > of doing it inline is so that the dispatcher can note that a renewal > request is already in flight (which it needs to know anyway, so it can > block other requests) and wake all threads waiting on it when it's > done, instead of having multiple renewals in flight. > Ok, I can see that. Though I was thinking that the worker threads would send the request back to the dispatcher by way of the same Chan the dispatcher reads requests from. Obviously I was thinking the dispatcher would use the original token to filter requests in the Chan. If I understand what you are talking about, the dispatcher would do the token renewal in a separate thread, continuing to process it's incoming Chan while that is going on, accumulating incoming requests somewhere, perhaps in another Chan. Then, when the token renewal is complete, the dispatcher stops forwarding incoming requests to the secondary Chan, processes the accumulated requests using the new token, and, when done with those, the switches back to processing the incoming Chan. Is that something like what you had in mind, or did I make it more complicated than necessary? > The point of a pool is so (a) you can throttle it in special cases, > such as when you need to renew the token, and (b) so you don't find > yourself juggling a couple thousand threads if things get unexpectedly > busy (or buggy). You can limit the pool to something sensible > (probably something like 4 during development and debugging so things > can't get too out of hand) and increased later; plus, the pool manager > will provide the primitives to deal with managing shared resources > (such as your token) within the pool. > Hmm. I'm still not entirely seeing it and I think the problem is just my lack of knowledge of Haskell concurrency. If the pool is of threads, how do you start the threads? How do you submit work to the threads? The only way I know of in Haskell of creating threads to do work is forkIO. That takes a function and runs to completion. Would a worker thread just be one that loops forever and checks a MVar for something to do? So the pool would really consist of (MVar, ThreadId) pairs. When we speak of getting a thread out of a pool and giving it work to do, are we really talking about sticking a value in an MVar that the thread is blocking on, waiting for data to be available to do something with, so that it can go and do some work? And when we are done with the thread we return it to the pool? Rich P.S. Thanks for talking me through this! I'm learning a ton about concurrency in Haskell. > -- > brandon s allbery allber...@gmail.com > wandering unix systems administrator (available) (412) 475-9364 vm/sms > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] External system connections
On Sun, Jul 10, 2011 at 2:54 PM, Brandon Allbery wrote: > On Sun, Jul 10, 2011 at 17:34, Richard Wallace > wrote: >> Rather than a single separate thread that makes requests I was hoping to >> make several soap requests concurrently, rather than have them be made >> serially. I would only want to block other threads making soap request if >> one of them returns a response indicating the token they were using is no >> longer valid. > > Is there one shared token, or one per requesting thread, or some other > arrangement? There should be one shared token. > In either case, separation of concerns makes me think > the token handling belongs on the other end: a thread writes a > request down a Chan, a queue dispatcher thread reads it if there are > available workers and the token is available (with callers blocking > otherwise), dispatcher sends request to available worker. If the > worker finds the token is invalid, it calls back in to the dispatcher > with a token renewal request, which causes anything else that needs > that token to block as above, and itself blocks until a valid token is > returned. Ahhh... I see. That sounds like a much better plan. It also keeps the fact that the token is "mutable" confined to a single thread, the dispatcher thread. One thing I'd have to be careful to handle is iIf multiple worker threads find that the token is now invalid. In that case they would all send the token renewal request to the dispatcher and they would each try and do the re-auth. To avoid that, part of the token renewal request could be the used token. When the dispatcher does the token renewal, it checks if the used token is the same as the current token. If so, it does the token renewal. If not, it dispatches to the SOAP worker thread with the new token. > Another advantage of this is that adding more workers is > done in an obvious place (the queuer thread). > > That said, I still don't know enough details to say if that token > management implementation actually makes sense. I'd still go with the > worker/queuer thread setup, which is I think what you were pointed to > (the pool hackage). > Ok, I still don't see how the Pool package helps. I had assumed the pooled resource would be the token, so the size of the pool would be 1. Now that I rethink it, it seems like you are suggesting the resource is the worker threads. Is that right? When I read what you were talking about above with the dispatcher thread I had thought it would use forkIO to start the worker threads. The worker threads would read from a Chan that the dispatcher wrote to.In that way, the dispatcher doesn't have to worry about worker threads being available. Am I misunderstanding something? Thanks, Rich > -- > brandon s allbery allber...@gmail.com > wandering unix systems administrator (available) (412) 475-9364 vm/sms > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] External system connections
Hello all, I'm trying to understand how to properly structure a connection to an external system. I'm writing an application that processes requests (it's an IRC bot - ya, I've looked at lambabot but it's a bit beyond my current understanding and I'm really trying to learn this stuff and find the best way to do that is to write it myself) and sends requests to an external system, via SOAP. The SOAP requests should be sent on separate threads. The SOAP server requires an initial request for authentication be made to obtain a token used on subsequent requests. There are three ways I can structure this. One is to do the authentication with the SOAP server when the application starts up and just use that token for all subsequent requests. This will fall over if the token times out and I'd have to restart the application. Another way is to do authenticate with the server and get a new token for each request. This is obviously really inefficient. What I'd like to do is something a bit smarter. When a request to the SOAP server is to be made, if we have a token then we try and use it. If it fails, we reauthenticate and get a new token. When establishing a new token, other threads trying to send SOAP requests should block until a new token is available. There are other conditions that should be handled - such as an exponential back-off when the SOAP server can't be reached - but I feel like reestablishing the authentication token is really the key concern here. Unfortunately, I have no idea right now how to write this in Haskell. Any pointers would be awesome. Thanks! Rich ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lambdabot plugin system description
Awesome, thanks! That looks really useful. On Fri, Jul 1, 2011 at 7:45 PM, Don Stewart wrote: > In fact there is! > > Plugging Haskell In. André Pang, Don Stewart, Sean Seefried, and > Manuel M. T. Chakravarty. In Proceedings of the ACM SIGPLAN Workshop > on Haskell, pages 10-21. ACM Press, 2004 > > http://www.cse.unsw.edu.au/~dons/papers/hs-plugins.pdf > > And > > Dynamic Applications From the Ground Up. Don Stewart and Manuel M. T. > Chakravarty. In Proceedings of the ACM SIGPLAN Workshop on Haskell, > pages 27-38. ACM Press, 2005 > > http://www.cse.unsw.edu.au/~dons/papers/yi.pdf > > -- Don > > On Fri, Jul 1, 2011 at 7:43 PM, Richard Wallace > wrote: >> Hey all, >> >> I'm curious if there are any papers or anything else describing the >> plugin system in Lambdabot. If not I'll dig through the code, but my >> Haskell isn't yet that strong so a higher level introduction would be >> very helpful. >> >> Thanks, >> Rich >> >> ___ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Lambdabot plugin system description
Hey all, I'm curious if there are any papers or anything else describing the plugin system in Lambdabot. If not I'll dig through the code, but my Haskell isn't yet that strong so a higher level introduction would be very helpful. Thanks, Rich ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
