Also, I caught a seg-fault yesterday, after having left a DrRacket 7.9 BC open for a couple of days on a basic servlet. I'll see if happens again with 8.0.0.x while I use it.
Dex On Wednesday, April 7, 2021 at 11:08:00 PM UTC+2 Dexter Lagan wrote: > I updated window.rkt, and it fixed the scrolling problem. It's exactly > as it was with 7.9. Thanks! > One last thing, I noticed that a small window appears top-left corner of > the screen before the full DrRacket window opens since 8.0.0.1x : > > [image: small-window.PNG] > > I had trouble capturing it, as it only appears a few seconds. > > Cheers, > > Dex > > On Wednesday, April 7, 2021 at 12:24:13 PM UTC+2 Dexter Lagan wrote: > >> Thanks for the info, I'll try updating window.rkt and report back. >> >> What surprises me is that scrolling by keeping the mouse button down >> while hovering on the scrollbar is fast and smooth, while using a >> two-finger gesture is erratic and choppy (on top of the direction-change >> delay). I wonder if there would be a way to map the scrolling gesture >> (which might be bound to the mouse wheel handler), to the scrollbar >> instead. If one could do this, the scrolling would smooth no matter which >> input device is used. >> >> When it comes to executable file size, I understand that there's a >> balance between file loading time and decompression time. >> Intuitively, for local machines - especially with today's NVMe's - it >> would make sense to generate larger files, with less compression for best >> overall performance. However, as soon as one runs an executable file from a >> network drive (say, over 100Mbits ethernet), file size might be directly >> correlated to startup time, accounting for network transfer time. I don't >> know if these ideas are in consideration, and I understand you have other >> priorities. I'm available to help with benchmarks, debugging and any other >> task you might find useful. >> >> As always, I greatly appreciate you taking the time to answer with such >> detail and care. >> >> Dex >> >> On Wed, Apr 7, 2021 at 1:54 AM Matthew Flatt <[email protected]> wrote: >> >>> At Mon, 5 Apr 2021 14:29:22 -0700 (PDT), Dexter Lagan wrote: >>> > I installed the latest build, and it does start. Generated >>> executable is >>> > 80MB vs 32MB for 7.9 BC, about 10MB more than 8.0 release. >>> >>> That difference is again related to the compilation paths, but this >>> time the likely result is that the v8.1 release will be larger in the >>> way you saw here. >>> >>> In the cross-compilation path that the release builds use, there was an >>> unintended layer of compression. (I noticed the size difference before, >>> but had not yet investigated.) Checking that again, if the extra layer >>> is used, the 10% or so savings in file size causes a 5% decompression >>> slowdown for loading. Compressing just the code, meanwhile, makes load >>> times faster on machines that I tried. So, I think the current >>> (non-cross) default is still the best choice for most situations, and >>> I'll adjust cross-compilation to match. >>> >>> We can make the extra layer of compression an option for someone who >>> needs to minimize file size. But a more relevant effect may be the >>> existing configure-time option to compress boot files... >>> >>> >>> Compressing embedded boot files would save 30 MB, which would make a >>> big difference in your case. Compressed boot files take 20-40ms longer >>> to load on a typical machine, which is significant relative to the >>> minimal load time, but it's very little time in many situations. >>> >>> Boot-file compression was already an option for the `configure` way of >>> building on Unix (but the option had rotted; now fixed). I've updated >>> the MSVC build to recognize a `PLT_BOOTFILE_COMPRESS` environment >>> variable to enable boot-file compression when building that way. So, it >>> will be easier to build Racket with compressed boot files --- but you >>> would have to build Racket yourself. >>> >>> It may be that compressed boot files make sense as the default on >>> Windows. I'm starting to lean in that direction, but I'm not sure, and >>> I haven't changed the default for now. >>> >>> > I understand that there's a difference between bytecode and compiled >>> > binary size with CS, but I'm not certain if we're talking about the >>> Racket >>> > distribution itself, or generated executables. Is there any hope to >>> > eventually get closer to BC's executable size with CS? >>> >>> Compressing boot files brings the size of the Racket CS executable/DLL >>> itself closer to Racket BC --- more like a factor of 2 instead of a >>> factor of 10 --- and that turns out to be almost half of the size in >>> your case. But the more code you add in terms of embedded ".zo" files, >>> the more the size difference will approach a factor of 2 overall; I >>> don't see a route to big improvements there. >>> >>> > The raco demod option seemed to do miracles on previous versions, but >>> > never worked on gracket / gui programs for me. >>> >>> Restoring `raco demod` has been on my list, and I may get to that soon, >>> but probably not before v8.1. It may be possible to improve `raco >>> demod` to support `dynamic-require`d pieces like the platform-specific >>> backends in `racket/gui`. >>> >>> > Also, somehow touchpad scrolling has degraded since 7.9 BC (which >>> was >>> > decent, and even had momentum). If I scroll downwards, then upwards, >>> it >>> > keeps going down for another 1 second before switching direction, and >>> > momentum is no longer simulated. If I use the scrollbar, it scrolls >>> fast >>> > and smooth, with no direction problem. >>> >>> I don't know what happened there. Version 8.0 included a change for >>> handling scroll-wheel events, but I don't think that's the same kind of >>> event as touchpad scrolling. You could try changing `(* wheel-scale >>> amt)` in "share/pkgs/gui-lib/mred/private/wx/win32/window.rkt" back to >>> just `amt` to make sure that change isn't the reason. >>> >> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/5a8a5e07-695a-4ee5-a0e7-132c81cfec78n%40googlegroups.com.
