long-running processes, FP and user feedback

On Tue, Dec 13, 2011 at 12:32 PM, Tim P <tim.pigden@optrak.com> wrote:

Our software is involved in optimisation (as in Operations Research).
Some optimisation processes take a long time and users like to know
something is going on - and if it goes through several stages they
like to know which stage its at and how many things it's processed.
Right now in our non-fp world this is done by maintaining status
variables and having the user thread call in with a synchronised
method to see what's happening and displaying that on the UI thread.
How, if at all, is this sort of thing dealt with in the FP world? Are
there standard patterns? I realise that we're essentially looking to
have a side-effect - i.e. to let the user know something is going on
and the system hasn't just gone to sleep, crashed or got itself a
problem that is going to take 7 hours to complete.

I'm not really going to answer the FP-part of your question, because writing to the graphics memory is a side effect anyway.

But your problem I'd definitely model with Actors, so the job itself can publish progress as messages to an actor that updates the UI/logs progress whatnot.

Cheers,
√
 

Tim

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

Le Tuesday 13 Dec 2011 à 12:39:39 (+0100), √iktor Ҡlang a écrit :
> On Tue, Dec 13, 2011 at 12:32 PM, Tim P <[1]tim.pigden@optrak.com>
> wrote:
>
> Our software is involved in optimisation (as in Operations
> Research).
> Some optimisation processes take a long time and users like to know
> something is going on - and if it goes through several stages they
> like to know which stage its at and how many things it's processed.
> Right now in our non-fp world this is done by maintaining status
> variables and having the user thread call in with a synchronised
> method to see what's happening and displaying that on the UI thread.
> How, if at all, is this sort of thing dealt with in the FP world?
> Are
> there standard patterns? I realise that we're essentially looking to
> have a side-effect - i.e. to let the user know something is going on
> and the system hasn't just gone to sleep, crashed or got itself a
> problem that is going to take 7 hours to complete.
>
> I'm not really going to answer the FP-part of your question, because
> writing to the graphics memory is a side effect anyway.
> But your problem I'd definitely model with Actors, so the job itself
> can publish progress as messages to an actor that updates the UI/logs
> progress whatnot.

On the purely functional side of things, though not in Scala, I tend to
like the following abstractions: Lwt or Async monad for modeling threads
using so-called futures; React for functional reactive programming.

http://ocsigen.org/lwt/#!http://ocsigen.org/lwt/manual/
http://ocaml.janestreet.com/?q=node/100
http://erratique.ch/software/react

There are other similar libraries for other FP languages. As for Scala,
the most canonical way to do things seems to be actors. But I guess the
above qualifies as "design patterns" or "standard patterns".

Hi Tim,
This is one of those cases where I'd be looking for a pragmatic solution rather than an FP-pure one. As long as the ''how far I've got" state is clearly identified as being external to the FP, and is fully encapsulated, I see no problem with having your FP-pure code updating the state and your imperative UI code reading the state. This could be implemented using reactive programming, an actor, a thread-safe queue, a Stream, or some hand-rolled synchronized flags - it really is up to you. I don't know of a widely-accepted FP design pattern for exposing the dynamic state of a running computation.
Matthew

On 13 December 2011 11:32, Tim P <tim.pigden@optrak.com> wrote:

Our software is involved in optimisation (as in Operations Research).
Some optimisation processes take a long time and users like to know
something is going on - and if it goes through several stages they
like to know which stage its at and how many things it's processed.
Right now in our non-fp world this is done by maintaining status
variables and having the user thread call in with a synchronised
method to see what's happening and displaying that on the UI thread.
How, if at all, is this sort of thing dealt with in the FP world? Are
there standard patterns? I realise that we're essentially looking to
have a side-effect - i.e. to let the user know something is going on
and the system hasn't just gone to sleep, crashed or got itself a
problem that is going to take 7 hours to complete.

Tim

--
Dr Matthew PocockIntegrative Bioinformatics Group, School of Computing Science, Newcastle Universitymailto: turingatemyhamster@gmail.com gchat: turingatemyhamster@gmail.commsn: matthew_pocock@yahoo.co.uk irc.freenode.net: drdozerskype: matthew.pococktel: (0191) 2566550mob: +447535664143

sometimes, side effects make sense

-------- Original-Nachricht --------
> Datum: Tue, 13 Dec 2011 13:42:10 +0000
> Von: Matthew Pocock
> An: Tim P , scala-user
> Betreff: Re: [scala-user] long-running processes, FP and user feedback

> Hi Tim,
>
> This is one of those cases where I'd be looking for a pragmatic solution
> rather than an FP-pure one. As long as the ''how far I've got" state is
> clearly identified as being external to the FP, and is fully encapsulated,
> I see no problem with having your FP-pure code updating the state and your
> imperative UI code reading the state. This could be implemented using
> reactive programming, an actor, a thread-safe queue, a Stream, or some
> hand-rolled synchronized flags - it really is up to you. I don't know of a
> widely-accepted FP design pattern for exposing the dynamic state of a
> running computation.
>
> Matthew
>
> On 13 December 2011 11:32, Tim P wrote:
>
> > Our software is involved in optimisation (as in Operations Research).
> > Some optimisation processes take a long time and users like to know
> > something is going on - and if it goes through several stages they
> > like to know which stage its at and how many things it's processed.
> > Right now in our non-fp world this is done by maintaining status
> > variables and having the user thread call in with a synchronised
> > method to see what's happening and displaying that on the UI thread.
> > How, if at all, is this sort of thing dealt with in the FP world? Are
> > there standard patterns? I realise that we're essentially looking to
> > have a side-effect - i.e. to let the user know something is going on
> > and the system hasn't just gone to sleep, crashed or got itself a
> > problem that is going to take 7 hours to complete.
> >
> > Tim
> >
>
>
>