[plt-scheme] frtime slowing down
I'm not sure I know what you mean by "leave circles hanging around".
'Integral' is based on real time, so if there's a long GC pause,
objects will seem to stop for a moment, then suddenly skip away.
There should still never be more than five circles on the screen at a
time; it's just that some of them may manage to travel farther than
they would if there hadn't been a GC. To avoid this, you can use a
different version of 'integral', defined something like this:
(define (my-integral v)
(collect-b (changes milliseconds) 0 (lambda (_ s) (+ s (value-now v)))))
Note that this will also change more slowly than the built-in
'integral', since 'milliseconds' doesn't actually change every
millisecond (it's set to 20ms by default). So to approximate the old
behavior (without the skips), you could say (* 20 (value-now v))
instead of (value-now v).
Unfortunately, if you use this definition instead of the built-in
'integral', then I think you'll need to put that (collect-garbage)
call back in, or it will leak behaviors and eventually choke. I have
a better fix in the works, which should plug the leak without the need
for an explicit GC there, and that should help to reduce the long GC
pauses. I should be able to check that into trunk later today, and I
can send you a patch for 372 if necessary.
Greg
On Sun, Mar 23, 2008 at 5:57 AM, Dave Griffiths <dave at pawfal.org> wrote:
> I think it's related to the garbage collector but there is something
> else too. Does the example I posted for animation.ss work ok for you
> though?
>
> Here, it seems to leave circles hanging around after a collection - if
> you slow down the metro it's easier to see.
>
> I have a workaround where I comment out the (garbage-collect) on line
> 891 of frp-core.ss - this works better, with constant CPU usage, but
> still has the effect of leaving circles when a garbage collect is called
> from elsewhere.
>
> cheers,
>
> dave
>
>
>
> On Sat, 2008-03-22 at 19:02 -0400, Gregory Cooper wrote:
> > Is it still doing the same thing as before (getting increasingly
> > slow), or are there just occasional long garbage-collection pauses?
> > The former should be fixed, but if it's the latter, then v4 isn't
> > going to fix it (and I doubt there's any simple fix).
> >
> > On Sat, Mar 22, 2008 at 6:39 PM, Dave Griffiths <dave at pawfal.org> wrote:
> > > That works, but I'm getting big glitchy slowdowns - time to upgrade :)
> > >
> > >
> > >
> > > On Sat, 2008-03-22 at 18:17 -0400, Gregory Cooper wrote:
> > > > You should run
> > > >
> > > > bin/setup-plt -l frtime
> > > >
> > > > On Sat, Mar 22, 2008 at 6:14 PM, Dave Griffiths <dave at pawfal.org> wrote:
> > > > > Hi Greg,
> > > > >
> > > > > Do I need to recompile stuff too? Not sure how to do that...
> > > > > I get:
> > > > >
> > > > > compile: variable not provided (directly or indirectly and at the
> > > > > expected position) from module:
> > > > > |,/usr/local/lib/plt/collects/frtime/frp-core| in: super-lift
> > > > >
> > > > > Don't spend too much time on this, I should probably start working on v4
> > > > > anyway.
> > > > >
> > > > >
> > > > >
> > > > > On Sat, 2008-03-22 at 13:37 -0400, Gregory Cooper wrote:
> > > > > > Hi Dave,
> > > > > >
> > > > > > I'm attaching a diff for v372, which you should be able to apply by
> > > > > > going into collects/frtime and running:
> > > > > >
> > > > > > patch -p0 <ftfix372.diff
> > > > > >
> > > > > > At some point you'll probably want to upgrade to v4, since it has
> > > > > > quite a few improvements over 372.
> > > > > >
> > > > > > Let me know if this doesn't work.
> > > > > >
> > > > > > Cheers,
> > > > > > Greg
> > > > > >
> > > > > > On Sat, Mar 22, 2008 at 5:11 AM, Dave Griffiths <dave at pawfal.org> wrote:
> > > > > > > Thanks! - is there a way I can retrofit the fix into 372, or will it be
> > > > > > > best for me to upgrade to v4?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, 2008-03-21 at 23:19 -0400, Gregory Cooper wrote:
> > > > > > > > Hi Dave,
> > > > > > > >
> > > > > > > > This was a bug. Thanks for pointing me at it; it should be fixed in
> > > > > > > > svn now. Let me know if you still encounter any such problems.
> > > > > > > >
> > > > > > > > Greg
> > > > > > > >
> > > > > > > > On Fri, Mar 21, 2008 at 7:49 PM, Dave Griffiths <dave at pawfal.org> wrote:
> > > > > > > > > Hi Greg, all,
> > > > > > > > >
> > > > > > > > > Why does the following code slowly use more and more cpu? I'm assuming
> > > > > > > > > that although visually the circles are being removed, something remains
> > > > > > > > > which is getting processed.
> > > > > > > > >
> > > > > > > > > (require (lib "animation.ss" "frtime"))
> > > > > > > > >
> > > > > > > > > (define (metro tick)
> > > > > > > > > (let ((tick (floor (* tick 1000))))
> > > > > > > > > (when-e (> (modulo (floor milliseconds) tick) (/ tick 2)))))
> > > > > > > > >
> > > > > > > > > (define (truncate-list lst count)
> > > > > > > > > (cond
> > > > > > > > > ((zero? count) '())
> > > > > > > > > ((null? lst) '())
> > > > > > > > > (else (cons (car lst) (truncate-list (cdr lst) (- count 1))))))
> > > > > > > > >
> > > > > > > > > (display-shapes
> > > > > > > > > (list
> > > > > > > > > (collect-b
> > > > > > > > > (metro 0.1) '()
> > > > > > > > > (lambda (e lst)
> > > > > > > > > (cons (make-circle (make-posn 50 (+ 50 (integral 0.2))) 10 "red")
> > > > > > > > > (truncate-list lst 4))))))
> > > > > > > > >
> > > > > > > > > cheers,
> > > > > > > > >
> > > > > > > > > dave
> > > > > > > > >
> > > > > > > > > _________________________________________________
> > > > > > > > > For list-related administrative tasks:
> > > > > > > > > http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >
> > >
>
>
![[logo]](/logo.png){kind=logo}