Reactive updates coming soon בע"ה

All the changes sound very interesting, thanks for continuing with the project!

Diego

On Sun, Jan 8, 2012 at 1:25 AM, Naftoli Gugenheim wrote:
> Recently I've been working on some significant additions and changes to
> reactive, with G-d's help. They should hit github soon but first I want to
> give a heads up and get feedback.
>
> 1. DeltaSeq
> First, a major, breaking change in reactive-core, regarding increment
> updates, a.k.a. SeqSignal. In the past, the way this worked was that if you
> wrote
> val s1 = BufferSignal(1, 2, 3)
> val s2 = s1 map (n => {n})
>
> you would get a SeqSignal[Int], which has an EventStream[SeqDelta[Int,Int]],
> which allows you to only handle changes to the list rather than the whole
> thing at a time. In conjuction with reactive-web's Repeater, you can then
> easily and efficiently map a list of data to html content.
>
> This is the major issue:
> First of all, is that the backing Seq, TransformedSeq, was not written so
> well. For instance, the function passed to map would be called on every
> change for every item in the list, as well as for the deltas. This is
> particularly an issue if the function causes side effects (which
> reactive-web is not yet free of).
> Secondly, take this scenario:
> mySeqSignal.map(xs => if(xs.length>10) xs.filter(_ < 10) else xs.filter(_ >
> 10))
>
> The way map(x => SeqSignal) worked was a bit magical: Pass a TransformedSeq
> to the function so it returns a TransformedSeq, and have the TransformedSeq
> transform future deltas according to the operation it represents (filter in
> the above case). Clearly since we don't know if it will be the same
> operation in the future (over 10 or under 10?), we must always run the whole
> function. Cleverly computing the deltas then becomes pretty pointless. So
> the inefficiency in the first point is baked in.
>
> Also, flatMap(x => SeqSignal) returned a SeqSignal, but the implementation
> didn't really work (at this point I'm not sure it makes any sense) so I
> ended up falling back to diffing the two values, making it pointless (you
> can do this yourself with the SeqSignal.apply factory).
>
> The new way is this:
> Signal.map and .flatMap always returns a plain Signal. If you want a smart,
> efficient transformation of deltas, you do this:
> mySeqSignal.now.filter(_ < 10).signal
>
> That's it. There's no way to change the transformation on the fly now. The
> transformed (i.e. filtered) seq computes its contents in a lazy val based on
> the transformed deltas, so it should be very efficient.
> If you need to change operations then you need it to diff the values, so
> just write SeqSignal(myPlainSignal.map(xs => if(xs.length>10)xs.filter(_<10)
> else xs.filter(_>10))).
>
> The new version of TransformedSeq is called DeltaSeq. TransformedSeq was
> removed.
>
>
> 2. Widgets
> A new subpackage in reactive-web for higher-level widgets that combine
> smaller building blocks into useful packages. Currently this includes
> Messages, a simple way to give modeless, closeable popups. The provided css
> (you must include it manually) overlays them translucently over the page,
> stacked vertically. Also being worked on with G-d's help are a table view
> with sortable headers, a table editor (extends the table view) with
> undo/redo and "unsaved changes" feedback (hopefully soon, paginating and
> filtering), and (perhaps in the web package) simple access to common
> editors, and visual validity and modified feedback.
>
>
>
> 3. Javascript Functions
> Now reactive-web's type-safe Javascript DSL includes the function statement,
> and supports function literals containing statements (currently only unary
> functions, if you need more just ask):
>
> Function statement, custom named:
>        object myFunc extends Function({ x: $[JsNumber] =>
>         If(x > 10) {
>           window alert "Greater"
>         } Else {
>           window alert "Small"
>         }
>       })
>       myFunc(10)
> Autogenerated name (requires a Page):
>         val myFunc2 = Function({ x: $[JsNumber] => Return(x > 10) })
>
> Function literals (anonymous functions):
>     { x: $[JsNumber] =>
>       If(x > 10) {
>         window alert "Greater"
>       } Else {
>         window alert "Small"
>       }
>     }.$
>
>
> 4. Improved Javascript Assignments
> You can now write to properties of JsStub objects. So for instance you can
> write
> window.onbeforeunload := {x: $[JsObj] => /* see above on function literals
> */ }
> window.onbeforeunload happens to be provided with the library. Here's how
> you can set it up for any javascript API:
> trait obj extends JsStub {
>   val prop: Assignable[JsNumber]
> }
> val obj = $$[obj]
> Javascript {
>   obj.prop := 25
> }
> You can also assign values to arrays or object/maps:
> Javascript {
>   val evt = JsVar[JsTypes.JsObj]()
>   evt.get("returnValue") := reply
> }
>
>
> 5. Signal.flatMap(x => EventStream): EventStream
> You can now pass an EventStream-returning function to Signal.flatMap,
> returning an EventStream. So e.g.:
> val v = Var(x)
> val c: EventStream[Unit] = mouseClicks // hypothetical
> val fm: EventStream[X] = for(v0 <- v; c0 <- c) yield v0  // whenever there's
> a click, fire the current setting
>
>
> 6. Signal.foldLeft
> Signal now has foldLeft, just like EventStream, allowing you take the past
> into account.
>
>
> --
> Lift, the simply functional web framework: http://liftweb.net
> Code: http://github.com/lift
> Discussion: http://groups.google.com/group/liftweb
> Stuck? Help us help you:
> https://www.assembla.com/wiki/show/liftweb/Posting_example_code

This project sounds really good. Could you tell a bit about performance
/ various leak-like issues that FRP can face?

Thanks!

On 2012-01-08 00:25:25 -0600, Naftoli Gugenheim said:

> Recently I've been working on some significant additions and changes to
> reactive, with G-d's help. They should hit github soon but first I want
> to give a heads up and get feedback.
>
> 1. DeltaSeq
> First, a major, breaking change in reactive-core, regarding increment
> updates, a.k.a. SeqSignal. In the past, the way this worked was that if
> you wrote
> val s1 = BufferSignal(1, 2, 3)
> val s2 = s1 map (n => {n})
>
> you would get a SeqSignal[Int], which has an
> EventStream[SeqDelta[Int,Int]], which allows you to only handle changes
> to the list rather than the whole thing at a time. In conjuction with
> reactive-web's Repeater, you can then easily and efficiently map a list
> of data to html content.
>
> This is the major issue:
> First of all, is that the backing Seq, TransformedSeq, was not written
> so well. For instance, the function passed to map would be called on
> every change for every item in the list, as well as for the deltas.
> This is particularly an issue if the function causes side effects
> (which reactive-web is not yet free of).
> Secondly, take this scenario:
> mySeqSignal.map(xs => if(xs.length>10) xs.filter(_ < 10) else
> xs.filter(_ > 10))
>
> The way map(x => SeqSignal) worked was a bit magical: Pass a
> TransformedSeq to the function so it returns a TransformedSeq, and have
> the TransformedSeq transform future deltas according to the operation
> it represents (filter in the above case). Clearly since we don't know
> if it will be the same operation in the future (over 10 or under 10?),
> we must always run the whole function. Cleverly computing the deltas
> then becomes pretty pointless. So the inefficiency in the first point
> is baked in.
>
> Also, flatMap(x => SeqSignal) returned a SeqSignal, but the
> implementation didn't really work (at this point I'm not sure it makes
> any sense) so I ended up falling back to diffing the two values, making
> it pointless (you can do this yourself with the SeqSignal.apply
> factory).
>
> The new way is this:
> Signal.map and .flatMap always returns a plain Signal. If you want a
> smart, efficient transformation of deltas, you do this:
> mySeqSignal.now.filter(_ < 10).signal
>
> That's it. There's no way to change the transformation on the fly now.
> The transformed (i.e. filtered) seq computes its contents in a lazy val
> based on the transformed deltas, so it should be very efficient.
> If you need to change operations then you need it to diff the values,
> so just write SeqSignal(myPlainSignal.map(xs =>
> if(xs.length>10)xs.filter(_<10) else xs.filter(_>10))).
>
> The new version of TransformedSeq is called DeltaSeq. TransformedSeq
> was removed.
>
>
> 2. Widgets
> A new subpackage in reactive-web for higher-level widgets that combine
> smaller building blocks into useful packages. Currently this includes
> Messages, a simple way to give modeless, closeable popups. The provided
> css (you must include it manually) overlays them translucently over the
> page, stacked vertically. Also being worked on with G-d's help are a
> table view with sortable headers, a table editor (extends the table
> view) with undo/redo and "unsaved changes" feedback (hopefully soon,
> paginating and filtering), and (perhaps in the web package) simple
> access to common editors, and visual validity and modified feedback.
>
>
>
> 3. Javascript Functions
> Now reactive-web's type-safe Javascript DSL includes the function
> statement, and supports function literals containing statements
> (currently only unary functions, if you need more just ask):
>
> Function statement, custom named:
>        object myFunc extends Function({ x: $[JsNumber] =>
>         If(x > 10) {
>           window alert "Greater"
>         } Else {
>           window alert "Small"
>         }
>       })
>       myFunc(10)
> Autogenerated name (requires a Page):
>         val myFunc2 = Function({ x: $[JsNumber] => Return(x > 10) })
>
> Function literals (anonymous functions):
>     { x: $[JsNumber] =>
>       If(x > 10) {
>         window alert "Greater"
>       } Else {
>         window alert "Small"
>       }
>     }.$
>
>
> 4. Improved Javascript Assignments
> You can now write to properties of JsStub objects. So for instance you
> can write
> window.onbeforeunload := {x: $[JsObj] => /* see above on function literals */ }
> window.onbeforeunload happens to be provided with the library. Here's
> how you can set it up for any javascript API:
> trait obj extends JsStub {
>   val prop: Assignable[JsNumber]
> }
> val obj = $$[obj]
> Javascript {
>   obj.prop := 25
> }
> You can also assign values to arrays or object/maps:
> Javascript {
>   val evt = JsVar[JsTypes.JsObj]()
>   evt.get("returnValue") := reply
> }
>
>
> 5. Signal.flatMap(x => EventStream): EventStream
> You can now pass an EventStream-returning function to Signal.flatMap,
> returning an EventStream. So e.g.:
> val v = Var(x)
> val c: EventStream[Unit] = mouseClicks // hypothetical
> val fm: EventStream[X] = for(v0 <- v; c0 <- c) yield v0  // whenever
> there's a click, fire the current setting
>
>
> 6. Signal.foldLeft
> Signal now has foldLeft, just like EventStream, allowing you take the
> past into account.
>
>
>

This project sounds really good. Could you tell a bit about performance / various leak-like issues that FRP can face?

Thanks!

On 2012-01-08 00:25:25 -0600, Naftoli Gugenheim said:

Recently I've been working on some significant additions and changes to reactive, with G-d's help. They should hit github soon but first I want to give a heads up and get feedback.

1. DeltaSeq
First, a major, breaking change in reactive-core, regarding increment updates, a.k.a. SeqSignal. In the past, the way this worked was that if you wrote
val s1 = BufferSignal(1, 2, 3)
val s2 = s1 map (n => <div>{n}</div>)

you would get a SeqSignal[Int], which has an EventStream[SeqDelta[Int,Int]], which allows you to only handle changes to the list rather than the whole thing at a time. In conjuction with reactive-web's Repeater, you can then easily and efficiently map a list of data to html content.

This is the major issue:
First of all, is that the backing Seq, TransformedSeq, was not written so well. For instance, the function passed to map would be called on every change for every item in the list, as well as for the deltas. This is particularly an issue if the function causes side effects (which reactive-web is not yet free of).
Secondly, take this scenario:
mySeqSignal.map(xs => if(xs.length>10) xs.filter(_ < 10) else xs.filter(_ > 10))

The way map(x => SeqSignal) worked was a bit magical: Pass a TransformedSeq to the function so it returns a TransformedSeq, and have the TransformedSeq transform future deltas according to the operation it represents (filter in the above case). Clearly since we don't know if it will be the same operation in the future (over 10 or under 10?), we must always run the whole function. Cleverly computing the deltas then becomes pretty pointless. So the inefficiency in the first point is baked in.

Also, flatMap(x => SeqSignal) returned a SeqSignal, but the implementation didn't really work (at this point I'm not sure it makes any sense) so I ended up falling back to diffing the two values, making it pointless (you can do this yourself with the SeqSignal.apply factory).

The new way is this:
Signal.map and .flatMap always returns a plain Signal. If you want a smart, efficient transformation of deltas, you do this:
mySeqSignal.now.filter(_ < 10).signal

That's it. There's no way to change the transformation on the fly now. The transformed (i.e. filtered) seq computes its contents in a lazy val based on the transformed deltas, so it should be very efficient.
If you need to change operations then you need it to diff the values, so just write SeqSignal(myPlainSignal.map(xs => if(xs.length>10)xs.filter(_<10) else xs.filter(_>10))).

The new version of TransformedSeq is called DeltaSeq. TransformedSeq was removed.


2. Widgets
A new subpackage in reactive-web for higher-level widgets that combine smaller building blocks into useful packages. Currently this includes Messages, a simple way to give modeless, closeable popups. The provided css (you must include it manually) overlays them translucently over the page, stacked vertically. Also being worked on with G-d's help are a table view with sortable headers, a table editor (extends the table view) with undo/redo and "unsaved changes" feedback (hopefully soon, paginating and filtering), and (perhaps in the web package) simple access to common editors, and visual validity and modified feedback.



3. Javascript Functions
Now reactive-web's type-safe Javascript DSL includes the function statement, and supports function literals containing statements (currently only unary functions, if you need more just ask):

Function statement, custom named:
       object myFunc extends Function({ x: $[JsNumber] =>
        If(x > 10) {
          window alert "Greater"
        } Else {
          window alert "Small"
        }
      })
      myFunc(10)
Autogenerated name (requires a Page):
        val myFunc2 = Function({ x: $[JsNumber] => Return(x > 10) })

Function literals (anonymous functions):
    { x: $[JsNumber] =>
      If(x > 10) {
        window alert "Greater"
      } Else {
        window alert "Small"
      }
    }.$


4. Improved Javascript Assignments
You can now write to properties of JsStub objects. So for instance you can write
window.onbeforeunload := {x: $[JsObj] => /* see above on function literals */ }
window.onbeforeunload happens to be provided with the library. Here's how you can set it up for any javascript API:
trait obj extends JsStub {
  val prop: Assignable[JsNumber]
}
val obj = $$[obj]
Javascript {
  obj.prop := 25
}
You can also assign values to arrays or object/maps:
Javascript {
  val evt = JsVar[JsTypes.JsObj]()
  evt.get("returnValue") := reply
}


5. Signal.flatMap(x => EventStream): EventStream
You can now pass an EventStream-returning function to Signal.flatMap, returning an EventStream. So e.g.:
val v = Var(x)
val c: EventStream[Unit] = mouseClicks // hypothetical
val fm: EventStream[X] = for(v0 <- v; c0 <- c) yield v0  // whenever there's a click, fire the current setting


6. Signal.foldLeft
Signal now has foldLeft, just like EventStream, allowing you take the past into account.

All the changes sound very interesting, thanks for continuing with the project!

 Diego

On Sun, Jan 8, 2012 at 1:25 AM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:
> Recently I've been working on some significant additions and changes to
> reactive, with G-d's help. They should hit github soon but first I want to
> give a heads up and get feedback.
>
> 1. DeltaSeq
> First, a major, breaking change in reactive-core, regarding increment
> updates, a.k.a. SeqSignal. In the past, the way this worked was that if you
> wrote
> val s1 = BufferSignal(1, 2, 3)
> val s2 = s1 map (n => <div>{n}</div>)
>
> you would get a SeqSignal[Int], which has an EventStream[SeqDelta[Int,Int]],
> which allows you to only handle changes to the list rather than the whole
> thing at a time. In conjuction with reactive-web's Repeater, you can then
> easily and efficiently map a list of data to html content.
>
> This is the major issue:
> First of all, is that the backing Seq, TransformedSeq, was not written so
> well. For instance, the function passed to map would be called on every
> change for every item in the list, as well as for the deltas. This is
> particularly an issue if the function causes side effects (which
> reactive-web is not yet free of).
> Secondly, take this scenario:
> mySeqSignal.map(xs => if(xs.length>10) xs.filter(_ < 10) else xs.filter(_ >
> 10))
>
> The way map(x => SeqSignal) worked was a bit magical: Pass a TransformedSeq
> to the function so it returns a TransformedSeq, and have the TransformedSeq
> transform future deltas according to the operation it represents (filter in
> the above case). Clearly since we don't know if it will be the same
> operation in the future (over 10 or under 10?), we must always run the whole
> function. Cleverly computing the deltas then becomes pretty pointless. So
> the inefficiency in the first point is baked in.
>
> Also, flatMap(x => SeqSignal) returned a SeqSignal, but the implementation
> didn't really work (at this point I'm not sure it makes any sense) so I
> ended up falling back to diffing the two values, making it pointless (you
> can do this yourself with the SeqSignal.apply factory).
>
> The new way is this:
> Signal.map and .flatMap always returns a plain Signal. If you want a smart,
> efficient transformation of deltas, you do this:
> mySeqSignal.now.filter(_ < 10).signal
>
> That's it. There's no way to change the transformation on the fly now. The
> transformed (i.e. filtered) seq computes its contents in a lazy val based on
> the transformed deltas, so it should be very efficient.
> If you need to change operations then you need it to diff the values, so
> just write SeqSignal(myPlainSignal.map(xs => if(xs.length>10)xs.filter(_<10)
> else xs.filter(_>10))).
>
> The new version of TransformedSeq is called DeltaSeq. TransformedSeq was
> removed.
>
>
> 2. Widgets
> A new subpackage in reactive-web for higher-level widgets that combine
> smaller building blocks into useful packages. Currently this includes
> Messages, a simple way to give modeless, closeable popups. The provided css
> (you must include it manually) overlays them translucently over the page,
> stacked vertically. Also being worked on with G-d's help are a table view
> with sortable headers, a table editor (extends the table view) with
> undo/redo and "unsaved changes" feedback (hopefully soon, paginating and
> filtering), and (perhaps in the web package) simple access to common
> editors, and visual validity and modified feedback.
>
>
>
> 3. Javascript Functions
> Now reactive-web's type-safe Javascript DSL includes the function statement,
> and supports function literals containing statements (currently only unary
> functions, if you need more just ask):
>
> Function statement, custom named:
>        object myFunc extends Function({ x: $[JsNumber] =>
>         If(x > 10) {
>           window alert "Greater"
>         } Else {
>           window alert "Small"
>         }
>       })
>       myFunc(10)
> Autogenerated name (requires a Page):
>         val myFunc2 = Function({ x: $[JsNumber] => Return(x > 10) })
>
> Function literals (anonymous functions):
>     { x: $[JsNumber] =>
>       If(x > 10) {
>         window alert "Greater"
>       } Else {
>         window alert "Small"
>       }
>     }.$
>
>
> 4. Improved Javascript Assignments
> You can now write to properties of JsStub objects. So for instance you can
> write
> window.onbeforeunload := {x: $[JsObj] => /* see above on function literals
> */ }
> window.onbeforeunload happens to be provided with the library. Here's how
> you can set it up for any javascript API:
> trait obj extends JsStub {
>   val prop: Assignable[JsNumber]
> }
> val obj = $$[obj]
> Javascript {
>   obj.prop := 25
> }
> You can also assign values to arrays or object/maps:
> Javascript {
>   val evt = JsVar[JsTypes.JsObj]()
>   evt.get("returnValue") := reply
> }
>
>
> 5. Signal.flatMap(x => EventStream): EventStream
> You can now pass an EventStream-returning function to Signal.flatMap,
> returning an EventStream. So e.g.:
> val v = Var(x)
> val c: EventStream[Unit] = mouseClicks // hypothetical
> val fm: EventStream[X] = for(v0 <- v; c0 <- c) yield v0  // whenever there's
> a click, fire the current setting
>
>
> 6. Signal.foldLeft
> Signal now has foldLeft, just like EventStream, allowing you take the past
> into account.
>
>
> --
> Lift, the simply functional web framework: http://liftweb.net
> Code: http://github.com/lift
> Discussion: http://groups.google.com/group/liftweb
> Stuck? Help us help you:
> https://www.assembla.com/wiki/show/liftweb/Posting_example_code



--
Diego Medina
Web Developer
diego@fmpwizard.com
http://www.fmpwizard.com

    /*
     * takeWhile and dropWhile both see a sequence as divided into a prefix of elements that pass a predicate, and the remaining elements,
     * beginning with the first element that fails the predicate. (It makes no difference whether subsequent elements pass it or fail it.)
     * The difference is that takeWhile returns the prefix, and dropWhile returns the remaining elements.
     * 
     * Edits can occur within the prefix specified by the predicate, at its border, or outside it.
     * At its border means either removing the first element failing the predicate, inserting a new element at its index, or updating the value at its index.
     * 
     * In the case of takeWhile, an edit occurring at the first element for which the predicate fails
     * can cause any number of elements to be included, if the element that will now follow the current prefix will pass the predicate.
     * In the case of dropWhile, it can cause any number of elements to be removed, if the element that will now follow the
     * prefix will pass the predicate.
     * 
     * An edit more than one past the end of the prefix has no effect in the case of takeWhile; in the case of dropWhile, that edit is
     * applied after translating it (i - prefixLength).
     * 
     * A remove, or insert or update whose new element passes the predicate, that occurs before the end of the prefix, has no effect in the case of dropWhile;
     * in the case of takeWhile, it can be applied directly.
     * 
     * An insert or update within the prefix, whose new element fails the predicate, in the case of takeWhile is not applied,
     * and subsequent elements are removed, as the prefix has been shortened.
     * In the case of dropWhile, it and subsequent elements are inserted; since the prefix has been shortened, the set of remaining elements has expanded.
     * 
     * prefixLength: The number of elements in a row at the beginning of the parent sequence that pass the predicate. Consequently, the first index
     * that is either outside of the parent sequence or whose element fails the predicate.
     * 
     */
    def updatedFromParent(parentUpdated: DeltaSeq[T]): PrefixWhile[T] = new PrefixWhile[T](parentUpdated, prev.take, prev.p.asInstanceOf[T => Boolean]) {
      override lazy val (fromDelta, predValues, underlying) = {
        val buf = prev.toList.toBuffer
        val ds = new ArrayBuffer[SeqDelta[T, T]]
        var prdVals = prev.predValues
        def calcPrefixLength = {
          def loop(n: Int, s: Stream[(T, Boolean)]): Int = if (s.isEmpty || !s.head._2) n else loop(n + 1, s.tail)
          loop(0, prdVals)
        }
        var prefixLength = calcPrefixLength
        def applyDelta(d: SingleDelta[T, T]): Unit = {
          val oldPrefixLength = prefixLength
          d match {
            case Include(i, e) =>
              val v = p(e)
              prdVals = prdVals.patch(i, List(e -> v), 0)


              if (i < prefixLength) {
                if (v) prefixLength += 1 else prefixLength = i
              } else if (v && i == prefixLength) {
                prefixLength = calcPrefixLength
              }


              if (!take || v) {
                if (take && v && i <= prefixLength && i <= buf.length) {
                  ds += Include(i, e)
                  buf.insert(i, e)
                } else if (!take && i >= prefixLength) {
                  val j = i - prefixLength
                  println("Applying original Include at "+j)
                  ds += Include(j, e)
                  buf.insert(j, e)
                }
              }


              if (prefixLength > oldPrefixLength) for (j <- oldPrefixLength + 1 until prefixLength) {
                if (take && j <= buf.length) {
                  ds += Include(j, prdVals(j)._1)
                  buf.insert(j, prdVals(j)._1)
                } else if (!take && j < buf.length) {
                  ds += Remove(0, prdVals(oldPrefixLength)._1)
                  buf.remove(0)
                }
              }
              else if (prefixLength < oldPrefixLength) for (j <- prefixLength until oldPrefixLength) {
                println("j: "+j)
                if (take && prefixLength < buf.length) {
                  ds += Remove(prefixLength, prdVals(j)._1)
                  buf.remove(prefixLength)
                } else if (!take && j - prefixLength <= buf.length) {
                  ds += Include(j - prefixLength + 1, prdVals(j + 1)._1)
                  buf.insert(j - prefixLength + 1, prdVals(j + 1)._1)
                }
              }


            case Remove(i, o) =>
              prdVals = prdVals.patch(i, Nil, 1)
              if (i < prefixLength)
                prefixLength -= 1
              else if (i == prefixLength)
                prefixLength = calcPrefixLength


              if (take && i <= prefixLength && i < buf.length) {
                ds += Remove(i, o)
                buf.remove(i)
              } else if (!take && i >= prefixLength) {
                val j = i - prefixLength max 0
                if (j < buf.length) {
                  println("Applying original Remove at "+j)
                  ds += Remove(j, o)
                  buf.remove(j)
                }
              }


              if (prefixLength > oldPrefixLength) for (j <- oldPrefixLength until prefixLength) {
                if (take && j <= buf.length && (prdVals isDefinedAt j)) {
                  ds += Include(j, prdVals(j)._1)
                  buf.insert(j, prdVals(j)._1)
                } else if (!take && buf.nonEmpty && (prdVals isDefinedAt j)) {
                  ds += Remove(0, prdVals(j)._1)
                  buf.remove(0)
                }
              }
              else if (prefixLength < oldPrefixLength) {
                for (j <- (if (take) prefixLength else prefixLength) until oldPrefixLength) {
                  println("j: "+j)
                  if (take && j < buf.length && (prdVals isDefinedAt j)) {
                    ds += Remove(prefixLength, prdVals(j)._1)
                    buf.remove(prefixLength)
                  } else if (!take && j - prefixLength <= buf.length && (prdVals isDefinedAt j + 1)) {
                    ds += Include(j - prefixLength, prdVals(j + 1)._1)
                    buf.insert(j - prefixLength, prdVals(j + 1)._1)
                  }
                }
              }


            case Update(i, o, e) =>
              applyDelta(Remove(i, o))
              applyDelta(Include(i, o))
          }
        }
        println("prev.parent: "+prev.parent)
        println("parentUpdated: "+parentUpdated)
        println("take: "+take)
        SeqDelta flatten List(parentUpdated.fromDelta) foreach { d =>
          println("Delta: "+d)
          println(">prdVals: "+prdVals)
          println(">prefixLength: "+prefixLength)
          println(">buf: "+buf)
          println(">ds: "+ds)
          applyDelta(d)
          println("<prdVals: "+prdVals)
          println("<prefixLength: "+prefixLength)
          println("<buf: "+buf)
          println("<ds: "+ds)
        }
        (Batch(ds: _*), prdVals, buf.toSeq)
      }
    }
  }

On 2012-01-12 01:55:17 -0600, Naftoli Gugenheim said:

Can you be specific?

Have not used it yet, but just recall some older writings about memory leaks in early FRP implementations.

I haven't benchmarked anything but in general it doesn't do anything too fancy that I'd expect it to have performance issues. Ultimately it's a bunch of thin wrappers around the imperative way of doing things.

I believe the not-yet-published DeltaSeq (a rewrite of TransformedSeq, used from SeqSignal) may need some tuning though (right now it needs a bug fixed, actually --- that's why it's not published yet).

What do you mean by leaks? If you mean memory leak I copied Ingo's technique of using WeakRefernences and Observing reference-holders, so that shouldn't be a problem.

Otherwise, can you be more specific? Is there a project that you're considering using it for that's performance sensitive --- if you elaborate I may do a better job at ruling out your concern. :)

On Mon, Jan 9, 2012 at 11:23 AM, Sophie <itsme213@hotmail.com> wrote:

This project sounds really good. Could you tell a bit about performance / various leak-like issues that FRP can face?

Thanks!

On Thu, Jan 12, 2012 at 8:55 AM, Naftoli Gugenheim wrote:
> What do you mean by leaks? If you mean memory leak I copied Ingo's technique
> of using WeakRefernences and Observing reference-holders, so that shouldn't
> be a problem.

See e.g.

http://c2.com/cgi/wiki?FunctionalReactiveProgramming

about what is called a leak in FRP. I can also remember some academic
paper which had quite some information about leaks and about remedies
but I can't recall which one it was.

In any case, it makes sense to listen to Conal Elliot and try to learn
from his experiences:

e.g. http://conal.net/blog/posts/why-classic-frp-does-not-fit-interactive-beh...

On 2012-01-12 01:55:17 -0600, Naftoli Gugenheim said:

> Can you be specific?

http://conal.net/blog/tag/functional-reactive-programming says quite a
bit about these, including "leaks". Hth.

> I haven't benchmarked anything but in general it doesn't do anything
> too fancy that I'd expect it to have performance issues. Ultimately
> it's a bunch of thin wrappers around the imperative way of doing things.
> I believe the not-yet-published DeltaSeq (a rewrite of TransformedSeq,
> used from SeqSignal) may need some tuning though (right now it needs a
> bug fixed, actually --- that's why it's not published yet).
>
> What do you mean by leaks? If you mean memory leak I copied Ingo's
> technique of using WeakRefernences and Observing reference-holders, so
> that shouldn't be a problem.
>
> Otherwise, can you be more specific? Is there a project that you're
> considering using it for that's performance sensitive --- if you
> elaborate I may do a better job at ruling out your concern. :)
>
>
> On Mon, Jan 9, 2012 at 11:23 AM, Sophie wrote:
> This project sounds really good. Could you tell a bit about performance
> / various leak-like issues that FRP can face?
>
> Thanks!
>
> On 2012-01-08 00:25:25 -0600, Naftoli Gugenheim said:

On 2012-01-12 01:55:17 -0600, Naftoli Gugenheim said:

Can you be specific?

http://conal.net/blog/tag/functional-reactive-programming says quite a bit about these, including "leaks". Hth.

I haven't benchmarked anything but in general it doesn't do anything too fancy that I'd expect it to have performance issues. Ultimately it's a bunch of thin wrappers around the imperative way of doing things.
I believe the not-yet-published DeltaSeq (a rewrite of TransformedSeq, used from SeqSignal) may need some tuning though (right now it needs a bug fixed, actually --- that's why it's not published yet).

What do you mean by leaks? If you mean memory leak I copied Ingo's technique of using WeakRefernences and Observing reference-holders, so that shouldn't be a problem.

Otherwise, can you be more specific? Is there a project that you're considering using it for that's performance sensitive --- if you elaborate I may do a better job at ruling out your concern. :)


On Mon, Jan 9, 2012 at 11:23 AM, Sophie <itsme213@hotmail.com> wrote:
This project sounds really good. Could you tell a bit about performance / various leak-like issues that FRP can face?

Thanks!

On 2012-01-08 00:25:25 -0600, Naftoli Gugenheim said:

Another requirement of the algorithm that I don't think I mentioned is that it must generate the deltas relative to the dropWhile of the previous parent.

With G-d's help, I was finally able to fix dropWhile and get the tests to pass. For some reason although they all pass on 2.8.1 and 2.9.1, on 2.9.0-1 there are some failures, so until that's looked into I disabled cross building to 2.9.0-1.
When the build finishes all the updates I mentioned in the OP should be published and available, except for most of #2 Widgets -- only Messages is already in the repository. There should be a demo of it on the site when cloudbees finishes, at http://www.reactive-web.co.cc/widgets/Messages.

Hi Naftoli,
About the first method name "mergeAll", could it be named "sequence" as an analogy to what Scalaz offers for a list of Applicatives: http://stackoverflow.com/questions/6750609/list-of-options-equivalent-of-sequence-in-scala?
Eric.