[racket-users] Re: canvas% mouse event handling difference in Racket CS?
On Saturday, May 22, 2021 at 12:42:30 PM UTC+8 schle...@gmail.com wrote: > Maybe someone has a clever solution to collapse the calls to refresh less > manually. > I experienced a similar problem as you, where I have to refresh a canvas on a mouse event and the paint method is somewhat slow (it does have a lot of drawing to do in my case, so I expect it to be slow). I am not sure if this is a regression in the draw performance, but it seems that the canvas% will un `on-paint` for each `refresh` call it receives (unless I am missing something). This means that sending a refresh on mouse events will result in many unnecessary redraws of the canvas. Not sure if my solution is "clever", but it involves setting a flag on the first refresh and only clearing after the draw operation is completed. The internal state is still updated for each mouse event, but refresh is only called on the canvas if the flag is not set (that is if there is no outstanding refresh call). This way, there is no unnecessary delay for the refresh, and the on-paint always draws the latest version of the internal state, which may have been updated several times between the time refresh was initially called. Also, if you choose to use a timer% object, you don't need to create one each time, they can be reused. Alex. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/d11b15d0-4546-47ce-bb4b-5d2c7cf1eaa1n%40googlegroups.com.
[racket-users] Re: canvas% mouse event handling difference in Racket CS?
The difference between 23ms and 50ms was that the memoization wasn't doing its job. I removed some calls to get-brush and set-brush, only calling set-brush when the color changes. (only writing the value not reading it) Specialized a function that returned an ignored argument, to not calculate that argument. With that I got to 10-19 ms, together with the debounce it now is very snappy again, so I am satisfied. The debounce often collapses 10-30 mouse-events/on-paint calls into one. The code could be changed to precompute more stuff (needing more memory) or only redraw the region close to the cursor, but that would take to much programmer time for now. schle...@gmail.com schrieb am Samstag, 22. Mai 2021 um 06:42:30 UTC+2: > I tested with Racket v7.8 bc and it was also slow. > I also tested it with a year old version of my code and added similar > `time` calls around the drawing code > and it behaved like the recent version redrawing for all the mouse events, > only difference is that the on-paint takes around 23ms instead of 50ms. > So the older code takes half the time. > So maybe the debounce is the right solution, because I can't find a > version where something similar happens automatically. > > I also wonder why the drawing has gotten so slow, maybe the memoization in > the app fails somewhere and it repeatedly tries to load data from the > sqlite db. > Is the debounce the "right" way to do this? > Maybe someone has a clever solution to collapse the calls to refresh less > manually. > I was under the impression refresh was doing that automatically but maybe > at a different granularity that isn't working for my app/wanted performance. > > Now I also tested old app code with new racket and the draw is around 23ms > there too. > So the extra slowness seems to be a problem in the application logic > introduced in the new code. > And it seems that it just made it slow enough to make me notice that a > debounce is useful for snappier user-feedback. > > So the next step for me is to look at the differences between the old and > new code. > > schle...@gmail.com schrieb am Samstag, 22. Mai 2021 um 05:37:32 UTC+2: > >> I have a racket gui app that uses a canvas% with overridden on-event and >> on-paint methods. >> When the user hovers over drawn elements the on-paint is called via (send >> this refresh) >> to display the element under the cursor with a selection/outline. >> >> Recently I noticed that this has gotten extremely slow. >> It seems to me this might be a difference between BC and CS, but I >> haven't checked with different versions in depth yet. (just from the >> behavior/performance I remember it had in the past) >> >> In the past a call to (send this refresh) seemed to be processed >> concurrently in regard to on-event. >> Now it seems like the first (send this refresh) eagerly triggers the >> on-paint and this on-paint somehow blocks the processing of on-event until >> the on-paint is finished, after that 1 more mouse event is processed >> re-triggering the on-paint. >> Effectively redrawing for every mouse event, causing the app to draw old >> uninteresting frames (because the mouse events aren't processed fast enough >> and only the last position is interesting for me). >> >> Currently I have implemented a workaround: >> (define (oneoff-timer interval thk) >> (new timer% >>[notify-callback thk] >>[interval interval] >>[just-once? #t])) >> >> (define (debounce interval thk) >> (define timer #f) >> (define (fire) >> (set! timer #f) >> (thk)) >> (define (trigger) >> (unless timer >> (set! timer (oneoff-timer interval fire >> trigger) >> >> ;; within the canvas impl >> (define dirty! (debounce 50 (thunk (send this refresh >> ;; within on-event calling (dirty!) instead of (send this refresh) >> directly >> ;; this effectively waits at least 50 ms before trying to refresh thus >> allowing most on-event >> ;; calls to complete before on-paint is executed the first/next time, >> thus only drawing the last frame or a few in-between frames if the mouse is >> moved for a long time >> >> I may try to construct a minimal example, but wanted to put the info out >> there, because the behavior seems so different from before. >> >> Tested version: Racket v8.1 [cs] linux >> >> Simon >> > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/24a60d43-227f-4988-9eb6-5841e7ab9bc3n%40googlegroups.com.
[racket-users] Re: canvas% mouse event handling difference in Racket CS?
I tested with Racket v7.8 bc and it was also slow. I also tested it with a year old version of my code and added similar `time` calls around the drawing code and it behaved like the recent version redrawing for all the mouse events, only difference is that the on-paint takes around 23ms instead of 50ms. So the older code takes half the time. So maybe the debounce is the right solution, because I can't find a version where something similar happens automatically. I also wonder why the drawing has gotten so slow, maybe the memoization in the app fails somewhere and it repeatedly tries to load data from the sqlite db. Is the debounce the "right" way to do this? Maybe someone has a clever solution to collapse the calls to refresh less manually. I was under the impression refresh was doing that automatically but maybe at a different granularity that isn't working for my app/wanted performance. Now I also tested old app code with new racket and the draw is around 23ms there too. So the extra slowness seems to be a problem in the application logic introduced in the new code. And it seems that it just made it slow enough to make me notice that a debounce is useful for snappier user-feedback. So the next step for me is to look at the differences between the old and new code. schle...@gmail.com schrieb am Samstag, 22. Mai 2021 um 05:37:32 UTC+2: > I have a racket gui app that uses a canvas% with overridden on-event and > on-paint methods. > When the user hovers over drawn elements the on-paint is called via (send > this refresh) > to display the element under the cursor with a selection/outline. > > Recently I noticed that this has gotten extremely slow. > It seems to me this might be a difference between BC and CS, but I haven't > checked with different versions in depth yet. (just from the > behavior/performance I remember it had in the past) > > In the past a call to (send this refresh) seemed to be processed > concurrently in regard to on-event. > Now it seems like the first (send this refresh) eagerly triggers the > on-paint and this on-paint somehow blocks the processing of on-event until > the on-paint is finished, after that 1 more mouse event is processed > re-triggering the on-paint. > Effectively redrawing for every mouse event, causing the app to draw old > uninteresting frames (because the mouse events aren't processed fast enough > and only the last position is interesting for me). > > Currently I have implemented a workaround: > (define (oneoff-timer interval thk) > (new timer% >[notify-callback thk] >[interval interval] >[just-once? #t])) > > (define (debounce interval thk) > (define timer #f) > (define (fire) > (set! timer #f) > (thk)) > (define (trigger) > (unless timer > (set! timer (oneoff-timer interval fire > trigger) > > ;; within the canvas impl > (define dirty! (debounce 50 (thunk (send this refresh > ;; within on-event calling (dirty!) instead of (send this refresh) directly > ;; this effectively waits at least 50 ms before trying to refresh thus > allowing most on-event > ;; calls to complete before on-paint is executed the first/next time, thus > only drawing the last frame or a few in-between frames if the mouse is > moved for a long time > > I may try to construct a minimal example, but wanted to put the info out > there, because the behavior seems so different from before. > > Tested version: Racket v8.1 [cs] linux > > Simon > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/81fd2264-4806-4e93-8424-f63deb114e1en%40googlegroups.com.
[racket-users] canvas% mouse event handling difference in Racket CS?
I have a racket gui app that uses a canvas% with overridden on-event and on-paint methods. When the user hovers over drawn elements the on-paint is called via (send this refresh) to display the element under the cursor with a selection/outline. Recently I noticed that this has gotten extremely slow. It seems to me this might be a difference between BC and CS, but I haven't checked with different versions in depth yet. (just from the behavior/performance I remember it had in the past) In the past a call to (send this refresh) seemed to be processed concurrently in regard to on-event. Now it seems like the first (send this refresh) eagerly triggers the on-paint and this on-paint somehow blocks the processing of on-event until the on-paint is finished, after that 1 more mouse event is processed re-triggering the on-paint. Effectively redrawing for every mouse event, causing the app to draw old uninteresting frames (because the mouse events aren't processed fast enough and only the last position is interesting for me). Currently I have implemented a workaround: (define (oneoff-timer interval thk) (new timer% [notify-callback thk] [interval interval] [just-once? #t])) (define (debounce interval thk) (define timer #f) (define (fire) (set! timer #f) (thk)) (define (trigger) (unless timer (set! timer (oneoff-timer interval fire trigger) ;; within the canvas impl (define dirty! (debounce 50 (thunk (send this refresh ;; within on-event calling (dirty!) instead of (send this refresh) directly ;; this effectively waits at least 50 ms before trying to refresh thus allowing most on-event ;; calls to complete before on-paint is executed the first/next time, thus only drawing the last frame or a few in-between frames if the mouse is moved for a long time I may try to construct a minimal example, but wanted to put the info out there, because the behavior seems so different from before. Tested version: Racket v8.1 [cs] linux Simon -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/9298249c-3d3d-4f1f-a18d-945ea7d1e34en%40googlegroups.com.
Re: [racket-users] how to convert encoded path to something build-path can use?
Thanks! We were previously manually processing the files from current-library-collection-links, but using `links` saves ~100 lines of code. On Fri, May 21, 2021 at 11:50 AM Matthew Flatt wrote: > > Yes, the format changed in that commit. > > The `decode-link-path` function is not meant to be public, although it > could be exposed. But for an approach that works now and with older > versions, the API you want is `links` from `setup/link`, possibly like > this: > > (links #:file (find-links-file) #:with-path? #t) > (links #:file (find-links-file) #:root? #t) > > > At Fri, 21 May 2021 11:33:41 -0400, Stephen Chang wrote: > > Hi, > > > > It seems that, since 8.1, the format of paths in links.rktd has changed? > > > > Are there new API fns that deal with this new kind of encoded path? Or > > what is the recommended way to process them? > > > > Something like this? (Is this `decode-link-path` public? I couldnt find it) > > https://github.com/racket/racket/commit/2ac7e21ad422ee322daa4a7e0db318f9b72b6c48 > > #diff-51453f6da842dc20af8fe776f54ec99dd15f4f8b7e9e73cd5d45cdeb96e40ef6R49-R52 > > > > I used to pass the paths directly to `build-path` but now it no longer > > works. Here's an example error: > > > > build-path: contract violation > > expected: (or/c path-string? path-for-some-system? 'up 'same) > > given: '(up up #"pkgs" #"racket-lib") > > > > Any recommendations would be appreciated. Thanks! > > Steve > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/20210521095016.3e9%40sirmail.smtps.cs.utah.edu. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAFfiA1Jf2po6sYq2dDqv-eVHiFFYDSzUpxj_kKJnjQEYqobNqw%40mail.gmail.com.
[racket-users] How to write a program to catch every SIGINT and print "hello"
I wanted to understand a limitation of the repl of the rash package (github issue https://github.com/willghatch/racket-rash/issues/78) as well as in the racket repl, i guess, and see if i could do a quick hack to get something working. Anyway, i just wanted to catch SIGINT without using something like the `unix-signals` package from Tony Garnock-Jones. I just did this: ``` (module blah racket (let loop () (define (read k) (with-handlers ([exn:break? (λ (e) (display "=BREAK=") (k #f))]) (k (read-line (display "> ") (let ([result (call/cc read)]) (when result (display result)) (newline) (loop ``` 1) It catches all breaks and my program won't quit =). Is there a way to discern if the break is a SIGINT so i can continue only on that signal and abort otherwise? I guess, should i just check that it's not a exn:break:terminate or exn:break:hang-up, or... ? 2) Are there any glaring mistakes in what i wrote other than the problems of (1)? Any good way to do this? Nate -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/20A87695-C978-435A-9D6B-182B7D565D96%40manicmind.earth.
Re: [racket-users] Freenode -> libera.chat
There is some strangeness with the freenode situation. Andrew Lee posted a pdf publicly and is talking about it right now on this thread if you haven't seen it: https://news.ycombinator.com/item?id=27234542 Nate > On May 20, 2021, at 2:30 PM, Stephen De Gabrielle > wrote: > > I don’t use IRC much/ever - but in the event the irc links need to change > from freenode, links are present in the following places: > > 1. Homepage > 2. https://racket-lang.org/irc-chat.html > 3. Wiki - github > 4. Reddit - mod access required > > Current text: #racket IRC on freenode.net > Replacement text: #racket IRC on irc.libera.chat > > Current link: https://webchat.freenode.net/#racket > Replacement link: https://kiwiirc.com/nextclient/irc.libera.chat/#racket > (Thanks to Tony Garnock-Jones ) > > > S. > > > On Thu, 20 May 2021 at 14:16, Tony Garnock-Jones > wrote: > https://web.archive.org/web/20210520002957/http://kline.sh/ is a good > starting point. > > On 20 May 2021, 15:12, at 15:12, David Storrs wrote: > >What happened with Freenode? > > > >On Thu, May 20, 2021 at 8:12 AM Tony Garnock-Jones < > >to...@leastfixedpoint.com> wrote: > > > >> On 5/20/21 1:28 PM, Paulo Matos wrote: > >> > Tony Garnock-Jones writes: > >> >> With the recent damage to the Freenode IRC network, a new > >`#racket` has > >> >> been founded on irc.libera.chat. > >> > > >> > Is this to become the canonical IRC chat room for Racket? > >> > >> ¯\_(ツ)_/¯ > >> > >> I'd be in favour of moving off Freenode, myself. > >> > >> What would need updating? Presumably little more than the following: > >> > >>- https://racket-lang.org/irc-chat.html > >> > >> ? Is freenode mentioned anywhere else? > >> > >> Cheers, > >>Tony > >> > >> -- > >> You received this message because you are subscribed to the Google > >Groups > >> "Racket Users" group. > >> To unsubscribe from this group and stop receiving emails from it, > >send an > >> email to racket-users+unsubscr...@googlegroups.com. > >> To view this discussion on the web visit > >> > >https://groups.google.com/d/msgid/racket-users/4956afef-9ef6-cf9d-d2ce-61d83d3780ec%40leastfixedpoint.com > >> . > >> > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/1fe52f10-762a-483c-b4fc-ea35e3cb0aa8%40leastfixedpoint.com. > -- > > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/CAGHj7-%2B180mERTwmRAroKKepSnWMVOxPHcm0-X2EvXK0v6eAMA%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/B1BEEED9-F282-429E-B50B-18AB487A77FA%40manicmind.earth.
Re: [racket-users] how to convert encoded path to something build-path can use?
Yes, the format changed in that commit. The `decode-link-path` function is not meant to be public, although it could be exposed. But for an approach that works now and with older versions, the API you want is `links` from `setup/link`, possibly like this: (links #:file (find-links-file) #:with-path? #t) (links #:file (find-links-file) #:root? #t) At Fri, 21 May 2021 11:33:41 -0400, Stephen Chang wrote: > Hi, > > It seems that, since 8.1, the format of paths in links.rktd has changed? > > Are there new API fns that deal with this new kind of encoded path? Or > what is the recommended way to process them? > > Something like this? (Is this `decode-link-path` public? I couldnt find it) > https://github.com/racket/racket/commit/2ac7e21ad422ee322daa4a7e0db318f9b72b6c48 > #diff-51453f6da842dc20af8fe776f54ec99dd15f4f8b7e9e73cd5d45cdeb96e40ef6R49-R52 > > I used to pass the paths directly to `build-path` but now it no longer > works. Here's an example error: > > build-path: contract violation > expected: (or/c path-string? path-for-some-system? 'up 'same) > given: '(up up #"pkgs" #"racket-lib") > > Any recommendations would be appreciated. Thanks! > Steve -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/20210521095016.3e9%40sirmail.smtps.cs.utah.edu.
[racket-users] how to convert encoded path to something build-path can use?
Hi, It seems that, since 8.1, the format of paths in links.rktd has changed? Are there new API fns that deal with this new kind of encoded path? Or what is the recommended way to process them? Something like this? (Is this `decode-link-path` public? I couldnt find it) https://github.com/racket/racket/commit/2ac7e21ad422ee322daa4a7e0db318f9b72b6c48#diff-51453f6da842dc20af8fe776f54ec99dd15f4f8b7e9e73cd5d45cdeb96e40ef6R49-R52 I used to pass the paths directly to `build-path` but now it no longer works. Here's an example error: build-path: contract violation expected: (or/c path-string? path-for-some-system? 'up 'same) given: '(up up #"pkgs" #"racket-lib") Any recommendations would be appreciated. Thanks! Steve -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAFfiA1J%3DZ%2BoKNi1-OP7YmRYyttNSamBaHxsMZntd9mxOJCKJGA%40mail.gmail.com.
Re: [racket-users] Is there a good Racket DSL alternative to Image Magick?
I was there and, as I remember it, there was a presentation on something else where this was mentioned. IIRC, the topic was Language Oriented Programming and there was a discussion about how much complexity is okay when you are programmatically generating DSL code. The presenter mentioned PostScript as an example of a DSL where very complex code is often machine generated. Then there was more discussion about postscript and related things you can do with Racket. Maybe that's what you were thinking about. James On May 11, 2021, at 11:03 AM, Sage Gerard wrote: > I hope that has what Robert is looking for, but I don't recognize that > speech. In fact, I have a false memory, because I'm not finding the speech > I'm looking for on https://con.racket-lang.org/2018/#speakers > > On 5/11/21 10:19 AM, Bruce O'Neel wrote: >> This might be it. >> >> (seventh RacketCon): Leif Andersen -- Movies as Programs: The Story of a >> Racket - YouTube >> >> >> >> >> >> 11 May 2021 15:30 Sage Gerard wrote: >> I don't know of one off hand, but I believe RacketCon 2018 (?) included a >> presenter that showed a PostScript-like DSL for designers and artists. If >> pict not cover your needs, maybe dig into the presentations? >> Failing that, can you show what you'd hope the syntax would look like? That >> would probably help point you in the right direction, >> On 5/11/21 9:26 AM, Robert Haisfield wrote: >>> I have to do a bunch of .jpg and .png image resizings and was looking for a >>> programmatic way to do it. Is their a Racket DSL for this? -- >>> You received this message because you are subscribed to the Google Groups >>> "Racket Users" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to racket-users+unsubscr...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/racket-users/0d576c32-7d4d-4944-9cbc-c12f04406fccn%40googlegroups.com. >> -- ~slg -- >> You received this message because you are subscribed to the Google Groups >> "Racket Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to racket-users+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/racket-users/6e3aacdc-015b-2484-3bee-0c08e3fb612d%40sagegerard.com. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Racket Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to racket-users+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/racket-users/1620742795-01b81de5d6862fd390ec60605ee3bc9d%40pckswarms.ch. > -- > ~slg > > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/c911fc49-034e-7159-8a14-7fc5466122b0%40sagegerard.com. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/7C14FDFA-B9B8-431E-9801-569240EC15A6%40biomantica.com.
