Re: [racket-users] Re: Executable file size and raco demod

[Matthew Flatt]

At Sat, 10 Apr 2021 17:26:21 +, Dexter Lagan wrote:
>   By default it’s set to ‘one. 

But for an editor, this line changes it to 'integer:

https://github.com/racket/gui/blob/master/gui-lib/mred/private/wxme/editor-canvas.rkt#L237

Or, at least, it should --- and it does in my installation, which I
checked by logging inside `gen-wheels`. That's why I'm confused that
changing the default would do anything.

-- 
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/20210410123531.2b3%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Re: Executable file size and raco demod

[Dexter Lagan]

Yes I’m scrolling in DrRacket. Somehow the scrolling behaviour is different 
between using the scroll bar, and the mouse wheel or touchpad. I think it’s 
using a different behaviour on these input devices. I could not find anything 
in the Windows event defs however.

Dex


From: Matthew Flatt 
Sent: Saturday, April 10, 2021 7:13:34 PM
To: Dexter Lagan 
Cc: Racket Users 
Subject: Re: [racket-users] Re: Executable file size and raco demod

Are you scrolling in DrRacket's editor or in some other application?

I'm surprised that change to the initial value of `wheel-steps-mode`
has an effect, but maybe my confusion is that I'm thinking of DrRacket.
An editor canvas calls `set-wheel-steps-mode` in its constructor to set
the mode to 'integer, so scrolling in DrRacket is using 'integer mode.
But the default of 'one is meant to keep scrolling behavior the way it
used to be for other windows, including a plain canvas, unless a
program requests otherwise by calling `wheel-event-mode` on the window.

The definition of `WHEEL_DELTA` shouldn't change, since that's a
Windows constant. It's interesting that reducing the scaling of wheel
steps makes scrolling behave better for you, though, and I'm not clear
on why.

At Sat, 10 Apr 2021 04:24:36 -0700 (PDT), Dexter Lagan wrote:
>   So in conclusion, only two changes required:
>
> In const.rkt:
> (define WHEEL_DELTA 120)
> to
> (define WHEEL_DELTA 30)
>
> In Window.rkt:
> (define wheel-steps-mode 'one)
> to
> (define wheel-steps-mode 'integer)
>
>   The change to const.rkt may affect a lot more code, I'll let you decide
> if this change should be left local to gen-wheels.
> It fixes the direction change delay, as well as slow/erratic scrolling on
> the Thinkpad's trackpoint.
>
> Dex
> On Saturday, April 10, 2021 at 12:54:33 PM UTC+2 Dexter Lagan wrote:
>
> >   One precision: this work for Racket 8.0 BC release. There might have
> > been changes made to current.
> > DrRacket feels as smooth as Sublime Text with this change, a completely
> > different experience. I'd like to make a proper commit if somebody held my
> > hand to do so.
> >
> > Dex
> >
> > On Saturday, April 10, 2021 at 12:44:44 PM UTC+2 Dexter Lagan wrote:
> >
> >> Hi again,
> >>
> >>   After playing around with the gen-wheels procedure and comparing its
> >> code with the WM_HSCROLL handling, I was able to get fast, accurate and
> >> smooth scrolling for both mouse and touchpad by switching the
> >> wheel-steps-mode to 'integer and reducing WHEEL_DELTA by a factor of 4.
> >> Here's the updated code :
> >>
> >> 
> >>   (define wheel-steps-mode 'integer)
> >>   (define/public (get-wheel-steps-mode) wheel-steps-mode)
> >>   (define/public (set-wheel-steps-mode mode) (set! wheel-steps-mode mode))
> >>
> >>   (define/private (gen-wheels w msg lParam amt down up)
> >> (define AUG_WHEEL_DELTA (/ WHEEL_DELTA 4))
> >> (let loop ([amt amt])
> >>   (cond
> >> [((abs amt) . < . AUG_WHEEL_DELTA)
> >>  (case wheel-steps-mode
> >>[(one integer) amt]
> >>[(fraction)
> >> (unless (zero? amt)
> >>   (do-key w msg down lParam #f #f void (/ amt (exact->inexact
> >> AUG_WHEEL_DELTA
> >> 0.0])]
> >> [(negative? amt)
> >>  (case wheel-steps-mode
> >>[(one)
> >> (do-key w msg down lParam #f #f void 1.0)
> >> (loop (+ amt AUG_WHEEL_DELTA))]
> >>[(integer)
> >> (define steps (quotient (- amt) AUG_WHEEL_DELTA))
> >> (do-key w msg down lParam #f #f void (exact->inexact steps))
> >> (loop (+ amt (* steps AUG_WHEEL_DELTA)))]
> >>[else
> >> (do-key w msg down lParam #f #f void (/ (- amt)
> >> (exact->inexact AUG_WHEEL_DELTA)))
> >> 0.0])]
> >> [else
> >>  (case wheel-steps-mode
> >>[(one)
> >> (do-key w msg up lParam #f #f void 1.0)
> >> (loop (- amt AUG_WHEEL_DELTA))]
> >>[(integer)
> >> (define steps (quotient amt AUG_WHEEL_DELTA))
> >> (do-key w msg up lParam #f #f void (exact->inexact steps))
> >> (loop (- amt (* steps AUG_WHEEL_DELTA)))]
> >>[else
> >> (do-key w msg up lParam #f #f void (/ amt (exact->inexact
> >> AUG_WHEEL_DELTA)))
> >> 0.0])])))
> >> 
> >>
> >> On Wednesday, April 7, 2021 at 1:54:24 AM UTC+2 Matthew Flatt 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 wa

Re: [racket-users] Re: Executable file size and raco demod

[Dexter Lagan]

  By default it’s set to ‘one. When set to ‘one, it’s having trouble detecting 
direction switch (up/down), especially when using touchpad or track point. The 
mouse wheel also feels sluggish. Once set to ‘integer, direction switches 
correctly and accurately, but scrolling is very slow on all input devices. 
Reducing the delta fixes this and makes it scroll identically to a browser or 
other editors. Momentum works as well. Considering there’s win32 in une path, 
is this limited to Windows?

Dex


From: Matthew Flatt 
Sent: Saturday, April 10, 2021 7:22:40 PM
To: Dexter Lagan 
Cc: Racket Users 
Subject: Re: [racket-users] Re: Executable file size and raco demod

At Sat, 10 Apr 2021 03:52:47 -0700 (PDT), Dexter Lagan wrote:
> DrRacket feels

I see that you did say DrRacket, so I remain puzzled. Are you seeing a
value other than 'integer when `gen-wheels` is called in a stock v8.0?


Matthew

-- 
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/DM6PR08MB3946ED0174C614F4005C1BDEFC729%40DM6PR08MB3946.namprd08.prod.outlook.com.

Re: [racket-users] Re: Executable file size and raco demod

[Matthew Flatt]

At Sat, 10 Apr 2021 03:52:47 -0700 (PDT), Dexter Lagan wrote:
> DrRacket feels 

I see that you did say DrRacket, so I remain puzzled. Are you seeing a
value other than 'integer when `gen-wheels` is called in a stock v8.0?


Matthew

-- 
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/20210410112240.2e%40sirmail.smtps.cs.utah.edu.

Re: [racket-users] Re: Executable file size and raco demod

[Matthew Flatt]

Are you scrolling in DrRacket's editor or in some other application?

I'm surprised that change to the initial value of `wheel-steps-mode`
has an effect, but maybe my confusion is that I'm thinking of DrRacket.
An editor canvas calls `set-wheel-steps-mode` in its constructor to set
the mode to 'integer, so scrolling in DrRacket is using 'integer mode.
But the default of 'one is meant to keep scrolling behavior the way it
used to be for other windows, including a plain canvas, unless a
program requests otherwise by calling `wheel-event-mode` on the window.

The definition of `WHEEL_DELTA` shouldn't change, since that's a
Windows constant. It's interesting that reducing the scaling of wheel
steps makes scrolling behave better for you, though, and I'm not clear
on why.

At Sat, 10 Apr 2021 04:24:36 -0700 (PDT), Dexter Lagan wrote:
>   So in conclusion, only two changes required:
> 
> In const.rkt:
> (define WHEEL_DELTA 120)
> to
> (define WHEEL_DELTA 30)
> 
> In Window.rkt:
> (define wheel-steps-mode 'one)
> to
> (define wheel-steps-mode 'integer)
> 
>   The change to const.rkt may affect a lot more code, I'll let you decide 
> if this change should be left local to gen-wheels.
> It fixes the direction change delay, as well as slow/erratic scrolling on 
> the Thinkpad's trackpoint.
> 
> Dex
> On Saturday, April 10, 2021 at 12:54:33 PM UTC+2 Dexter Lagan wrote:
> 
> >   One precision: this work for Racket 8.0 BC release. There might have 
> > been changes made to current.
> > DrRacket feels as smooth as Sublime Text with this change, a completely 
> > different experience. I'd like to make a proper commit if somebody held my 
> > hand to do so.
> >
> > Dex
> >
> > On Saturday, April 10, 2021 at 12:44:44 PM UTC+2 Dexter Lagan wrote:
> >
> >> Hi again,
> >>
> >>   After playing around with the gen-wheels procedure and comparing its 
> >> code with the WM_HSCROLL handling, I was able to get fast, accurate and 
> >> smooth scrolling for both mouse and touchpad by switching the 
> >> wheel-steps-mode to 'integer and reducing WHEEL_DELTA by a factor of 4. 
> >> Here's the updated code :
> >>
> >> 
> >>   (define wheel-steps-mode 'integer)
> >>   (define/public (get-wheel-steps-mode) wheel-steps-mode)
> >>   (define/public (set-wheel-steps-mode mode) (set! wheel-steps-mode mode))
> >>
> >>   (define/private (gen-wheels w msg lParam amt down up)
> >> (define AUG_WHEEL_DELTA (/ WHEEL_DELTA 4))
> >> (let loop ([amt amt])
> >>   (cond
> >> [((abs amt) . < . AUG_WHEEL_DELTA)
> >>  (case wheel-steps-mode
> >>[(one integer) amt]
> >>[(fraction)
> >> (unless (zero? amt)
> >>   (do-key w msg down lParam #f #f void (/ amt (exact->inexact 
> >> AUG_WHEEL_DELTA
> >> 0.0])]
> >> [(negative? amt)
> >>  (case wheel-steps-mode
> >>[(one)
> >> (do-key w msg down lParam #f #f void 1.0)
> >> (loop (+ amt AUG_WHEEL_DELTA))]
> >>[(integer)
> >> (define steps (quotient (- amt) AUG_WHEEL_DELTA))
> >> (do-key w msg down lParam #f #f void (exact->inexact steps))
> >> (loop (+ amt (* steps AUG_WHEEL_DELTA)))]
> >>[else
> >> (do-key w msg down lParam #f #f void (/ (- amt) 
> >> (exact->inexact AUG_WHEEL_DELTA)))
> >> 0.0])]
> >> [else
> >>  (case wheel-steps-mode
> >>[(one)
> >> (do-key w msg up lParam #f #f void 1.0)
> >> (loop (- amt AUG_WHEEL_DELTA))]
> >>[(integer)
> >> (define steps (quotient amt AUG_WHEEL_DELTA))
> >> (do-key w msg up lParam #f #f void (exact->inexact steps))
> >> (loop (- amt (* steps AUG_WHEEL_DELTA)))]
> >>[else
> >> (do-key w msg up lParam #f #f void (/ amt (exact->inexact 
> >> AUG_WHEEL_DELTA)))
> >> 0.0])])))
> >> 
> >>
> >> On Wednesday, April 7, 2021 at 1:54:24 AM UTC+2 Matthew Flatt 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 sit

[racket-users] Strange problem with racket/gui

[Dominik Pantůček]

Hello Racketeers,

with GUI widgets tree like:

vertical-panel%
  vertical-pane%
vertical-pane%
  horizontal-pane%
text-field%
  horizontal-pane%
  horizontal-pane%
message%
vertical-pane%
  slider%

After pressing  when the text-field% has focus, the text-field%
loses and slider% gets focus. The following exception is raised though:

send: no such method
  method name: on-tab-in
  class name: wx-make-horizontal/vertical-panel%
  context...:
   /usr/share/racket/collects/racket/private/class-internal.rkt:4663:0:
obj-error
   /usr/share/racket/pkgs/gui-lib/mred/private/wxtop.rkt:546:61
   /usr/share/racket/collects/racket/private/more-scheme.rkt:148:2:
call-with-break-parameterization
   /usr/share/racket/pkgs/gui-lib/mred/private/wxtop.rkt:453:8:
handle-traverse-key method in make-top-container%
   /usr/share/racket/collects/ffi/unsafe/atomic.rkt:73:13
   /usr/share/racket/collects/racket/private/more-scheme.rkt:148:2:
call-with-break-parameterization
   /usr/share/racket/collects/ffi/unsafe/atomic.rkt:73:13
   /usr/share/racket/pkgs/gui-lib/mred/private/wx/gtk/window.rkt:836:4:
call-pre-on-char method in window%
   [repeats 3 more times]
   /usr/share/racket/pkgs/gui-lib/mred/private/wx/gtk/window.rkt:816:4:
dispatch-on-char method in window%
   /usr/share/racket/pkgs/gui-lib/mred/private/wx/common/queue.rkt:435:6
   /usr/share/racket/pkgs/gui-lib/mred/private/wx/common/queue.rkt:486:32
   /usr/share/racket/pkgs/gui-lib/mred/private/wx/common/queue.rkt:634:3


Does it ring a bell to anyone?

Welcome to Racket v8.0 [cs].
Linux telperion 5.4.0-70-generic #78-Ubuntu SMP Fri Mar 19 13:29:52 UTC
2021 x86_64 x86_64 x86_64 GNU/Linux


It is 20.04 Ubuntu LTS.


Without further investigation, it looks like some rather obscure bug
deep in pane/panel impelmentation.


Cheers,
Dominik

-- 
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/11ce8b5e-2ead-413f-6d4a-a3b38ddf6fa0%40trustica.cz.

Re: [racket-users] Re: Executable file size and raco demod

[Dexter Lagan]

  So in conclusion, only two changes required:

In const.rkt:
(define WHEEL_DELTA 120)
to
(define WHEEL_DELTA 30)

In Window.rkt:
(define wheel-steps-mode 'one)
to
(define wheel-steps-mode 'integer)

  The change to const.rkt may affect a lot more code, I'll let you decide 
if this change should be left local to gen-wheels.
It fixes the direction change delay, as well as slow/erratic scrolling on 
the Thinkpad's trackpoint.

Dex
On Saturday, April 10, 2021 at 12:54:33 PM UTC+2 Dexter Lagan wrote:

>   One precision: this work for Racket 8.0 BC release. There might have 
> been changes made to current.
> DrRacket feels as smooth as Sublime Text with this change, a completely 
> different experience. I'd like to make a proper commit if somebody held my 
> hand to do so.
>
> Dex
>
> On Saturday, April 10, 2021 at 12:44:44 PM UTC+2 Dexter Lagan wrote:
>
>> Hi again,
>>
>>   After playing around with the gen-wheels procedure and comparing its 
>> code with the WM_HSCROLL handling, I was able to get fast, accurate and 
>> smooth scrolling for both mouse and touchpad by switching the 
>> wheel-steps-mode to 'integer and reducing WHEEL_DELTA by a factor of 4. 
>> Here's the updated code :
>>
>> 
>>   (define wheel-steps-mode 'integer)
>>   (define/public (get-wheel-steps-mode) wheel-steps-mode)
>>   (define/public (set-wheel-steps-mode mode) (set! wheel-steps-mode mode))
>>
>>   (define/private (gen-wheels w msg lParam amt down up)
>> (define AUG_WHEEL_DELTA (/ WHEEL_DELTA 4))
>> (let loop ([amt amt])
>>   (cond
>> [((abs amt) . < . AUG_WHEEL_DELTA)
>>  (case wheel-steps-mode
>>[(one integer) amt]
>>[(fraction)
>> (unless (zero? amt)
>>   (do-key w msg down lParam #f #f void (/ amt (exact->inexact 
>> AUG_WHEEL_DELTA
>> 0.0])]
>> [(negative? amt)
>>  (case wheel-steps-mode
>>[(one)
>> (do-key w msg down lParam #f #f void 1.0)
>> (loop (+ amt AUG_WHEEL_DELTA))]
>>[(integer)
>> (define steps (quotient (- amt) AUG_WHEEL_DELTA))
>> (do-key w msg down lParam #f #f void (exact->inexact steps))
>> (loop (+ amt (* steps AUG_WHEEL_DELTA)))]
>>[else
>> (do-key w msg down lParam #f #f void (/ (- amt) 
>> (exact->inexact AUG_WHEEL_DELTA)))
>> 0.0])]
>> [else
>>  (case wheel-steps-mode
>>[(one)
>> (do-key w msg up lParam #f #f void 1.0)
>> (loop (- amt AUG_WHEEL_DELTA))]
>>[(integer)
>> (define steps (quotient amt AUG_WHEEL_DELTA))
>> (do-key w msg up lParam #f #f void (exact->inexact steps))
>> (loop (- amt (* steps AUG_WHEEL_DELTA)))]
>>[else
>> (do-key w msg up lParam #f #f void (/ amt (exact->inexact 
>> AUG_WHEEL_DELTA)))
>> 0.0])])))
>> 
>>
>> On Wednesday, April 7, 2021 at 1:54:24 AM UTC+2 Matthew Flatt 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 s

Re: [racket-users] Re: Executable file size and raco demod

[Dexter Lagan]

  One precision: this work for Racket 8.0 BC release. There might have been 
changes made to current.
DrRacket feels as smooth as Sublime Text with this change, a completely 
different experience. I'd like to make a proper commit if somebody held my 
hand to do so.

Dex

On Saturday, April 10, 2021 at 12:44:44 PM UTC+2 Dexter Lagan wrote:

> Hi again,
>
>   After playing around with the gen-wheels procedure and comparing its 
> code with the WM_HSCROLL handling, I was able to get fast, accurate and 
> smooth scrolling for both mouse and touchpad by switching the 
> wheel-steps-mode to 'integer and reducing WHEEL_DELTA by a factor of 4. 
> Here's the updated code :
>
> 
>   (define wheel-steps-mode 'integer)
>   (define/public (get-wheel-steps-mode) wheel-steps-mode)
>   (define/public (set-wheel-steps-mode mode) (set! wheel-steps-mode mode))
>
>   (define/private (gen-wheels w msg lParam amt down up)
> (define AUG_WHEEL_DELTA (/ WHEEL_DELTA 4))
> (let loop ([amt amt])
>   (cond
> [((abs amt) . < . AUG_WHEEL_DELTA)
>  (case wheel-steps-mode
>[(one integer) amt]
>[(fraction)
> (unless (zero? amt)
>   (do-key w msg down lParam #f #f void (/ amt (exact->inexact 
> AUG_WHEEL_DELTA
> 0.0])]
> [(negative? amt)
>  (case wheel-steps-mode
>[(one)
> (do-key w msg down lParam #f #f void 1.0)
> (loop (+ amt AUG_WHEEL_DELTA))]
>[(integer)
> (define steps (quotient (- amt) AUG_WHEEL_DELTA))
> (do-key w msg down lParam #f #f void (exact->inexact steps))
> (loop (+ amt (* steps AUG_WHEEL_DELTA)))]
>[else
> (do-key w msg down lParam #f #f void (/ (- amt) 
> (exact->inexact AUG_WHEEL_DELTA)))
> 0.0])]
> [else
>  (case wheel-steps-mode
>[(one)
> (do-key w msg up lParam #f #f void 1.0)
> (loop (- amt AUG_WHEEL_DELTA))]
>[(integer)
> (define steps (quotient amt AUG_WHEEL_DELTA))
> (do-key w msg up lParam #f #f void (exact->inexact steps))
> (loop (- amt (* steps AUG_WHEEL_DELTA)))]
>[else
> (do-key w msg up lParam #f #f void (/ amt (exact->inexact 
> AUG_WHEEL_DELTA)))
> 0.0])])))
> 
>
> On Wednesday, April 7, 2021 at 1:54:24 AM UTC+2 Matthew Flatt 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 t

Re: [racket-users] Re: Executable file size and raco demod

[Dexter Lagan]

  One precision: this works for Racket 8.0 BC release, I'm note sure 
current has had changes to this code.
DrRacket feels as fast and smooth as Sublime Text with this change, a 
completely different experience. I'd like to make a proper commit if 
somebody could hold my hand on github.

Dex

On Saturday, April 10, 2021 at 12:44:44 PM UTC+2 Dexter Lagan wrote:

> Hi again,
>
>   After playing around with the gen-wheels procedure and comparing its 
> code with the WM_HSCROLL handling, I was able to get fast, accurate and 
> smooth scrolling for both mouse and touchpad by switching the 
> wheel-steps-mode to 'integer and reducing WHEEL_DELTA by a factor of 4. 
> Here's the updated code :
>
> 
>   (define wheel-steps-mode 'integer)
>   (define/public (get-wheel-steps-mode) wheel-steps-mode)
>   (define/public (set-wheel-steps-mode mode) (set! wheel-steps-mode mode))
>
>   (define/private (gen-wheels w msg lParam amt down up)
> (define AUG_WHEEL_DELTA (/ WHEEL_DELTA 4))
> (let loop ([amt amt])
>   (cond
> [((abs amt) . < . AUG_WHEEL_DELTA)
>  (case wheel-steps-mode
>[(one integer) amt]
>[(fraction)
> (unless (zero? amt)
>   (do-key w msg down lParam #f #f void (/ amt (exact->inexact 
> AUG_WHEEL_DELTA
> 0.0])]
> [(negative? amt)
>  (case wheel-steps-mode
>[(one)
> (do-key w msg down lParam #f #f void 1.0)
> (loop (+ amt AUG_WHEEL_DELTA))]
>[(integer)
> (define steps (quotient (- amt) AUG_WHEEL_DELTA))
> (do-key w msg down lParam #f #f void (exact->inexact steps))
> (loop (+ amt (* steps AUG_WHEEL_DELTA)))]
>[else
> (do-key w msg down lParam #f #f void (/ (- amt) 
> (exact->inexact AUG_WHEEL_DELTA)))
> 0.0])]
> [else
>  (case wheel-steps-mode
>[(one)
> (do-key w msg up lParam #f #f void 1.0)
> (loop (- amt AUG_WHEEL_DELTA))]
>[(integer)
> (define steps (quotient amt AUG_WHEEL_DELTA))
> (do-key w msg up lParam #f #f void (exact->inexact steps))
> (loop (- amt (* steps AUG_WHEEL_DELTA)))]
>[else
> (do-key w msg up lParam #f #f void (/ amt (exact->inexact 
> AUG_WHEEL_DELTA)))
> 0.0])])))
> 
>
> On Wednesday, April 7, 2021 at 1:54:24 AM UTC+2 Matthew Flatt 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 

Re: [racket-users] How to recover whitespace from syntax->string

[jackh...@gmail.com]

I had to build something for this 
 
in my Resyntax project. My takeaways were:

   - There's no substitute for just reading the file. If you have a 
   `syntax-original?` subform, you can use the srcloc information to read the 
   exact original text that was in the source file. This not only preserves 
   whitespace more accurately than `syntax->string`, it also preserves 
   comments, which is something that `syntax->string` fundamentally cannot do.
   - For non-original syntax, such as that synthetic "comments" bit you're 
   inserting programmatically, just ignore the source locations completely. 
   They refer to the source location of where it occurs in your 
   program-manipulating-program, which is completely unrelated to the 
   positions of the original syntax. The `syntax->string` form doesn't handle 
   it well when some subforms are original and some aren't, or when subforms 
   are from different sources.
   - It's handy to have a way to communicate explicit formatting. I did 
   this by having a special NEWLINE form that my code could shove into the 
   syntax object before rendering it to a string, to tell the formatter where 
   to insert line breaks.
   - If you just rely on `syntax-original?` to preserve 
   whitespace/comments, you'll miss the whitespace and comments *between* 
   original syntax objects. I dealt with this by having an `(ORIGINAL-SPLICE 
   original-syntax ...)` form that I used to tell the formatter that not only 
   are all of these syntax objects original, but the entire sequence is 
   unchanged from the input program. That allows the formatter to copy the 
   source file text from the start of the first syntax object all the way to 
   the end of the last one, preserving any whitespace and comments in between 
   them.
   

On Friday, April 9, 2021 at 4:22:31 PM UTC-7 Jeff Henrikson wrote:

> It turns out that I have more trouble with printing whitespace from 
> syntax.  Consider this:
>
> (require racket)
> (require syntax/to-string)
>
> (define (syntax-on-lines-v1 xs)
>   (define (iter fin ys)
> (let ((y (read-syntax "" fin)))
>   (if (eof-object? y)
>   (reverse ys)
>   (iter fin (cons y ys)
>   (if (null? xs)
>   '()
>   (let* ((fout (open-output-string))
>  (_ (for* ((x xs))
>   (writeln x fout)))
>  (_ (close-output-port fout))
>  (fin (open-input-string (get-output-string fout
> (port-count-lines! fin)
> (iter fin '()
>
> The basic case works:
>
> ;; ex1
> (let* ((xs '("collected" "from" "separate" "lines"))
>(ys (syntax-on-lines xs)))
>   (syntax->string 
>#`(#,@ys)))
> ;; "\"collected\"\n\"from\"\n\"separate\"\n\"lines\""
>
> But I need to decorate a number of constant items, such as:
>
> ;; ex2
> (let* ((xs '("collected" "from" "separate" "lines"))
>(ys (syntax-on-lines xs)))
>   (syntax->string 
>#`(comment #,@ys)))
> ;; "comment\"collected\"\"from\"\"separate\"\"lines\""
>
> In ex2, the loss of line breaks seems to stem from lack of srcloc info on 
> the first token.  However, I don't understand just what's necessary to keep 
> things moving along.  If I populate the first token only with 
> quasisyntax/loc as follows, I get my EOLs:
>
> ;; ex3
> (let* ((xs '("collected" "from" "separate" "lines"))
>(ys (syntax-on-lines xs))
>(zs (cons (quasisyntax/loc (car ys) "comments") ys)))
>   (syntax->string 
>#`(#,@zs)))
> ;; "\"comments\"\"collected\"\n\"from\"\n\"separate\"\n\"lines\""
>
> But that's quite inconvenient if I have a bunch of stuff to decorate.  If 
> I try to do the more convenient outside position for quasisyntax/loc, my 
> EOL data seems to get overwritten:
>
> ;; ex4
> (let* ((xs '("collected" "from" "separate" "lines"))
>(ys (syntax-on-lines xs)))
>   (syntax->string (quasisyntax/loc (car ys) ("comments" #,@ys
> ;; "\"comments\"\"collected\"\"from\"\"separate\"\"lines\""
>
> Is there a way to do something like ex4, where I can add a number of new 
> constant tokens, but without overwriting the EOL data?
>
> Thanks in advance,
>
>
> Jeff Henrikson
>
>
> On 4/9/21 9:57 AM, Jeff Henrikson wrote:
>
> Laurent,
>
> Thank you very much.  It probably would have taken me a long time on my 
> own to think of the possibility that the port was at fault.
>
>
> Jeff
>
>
> On 4/9/21 4:29 AM, Laurent wrote:
>
> You need to enable line/character counting with `port-count-lines!`:
>
> #lang racket
> (require syntax/to-string)
>
> (define in (open-input-string "(comment\n  \"hello world\"\n  line)"))
> (port-count-lines! in)
> (syntax->string (read-syntax "mystring" in))
>
> ; -> "comment\n \"hello world\"\n line"
>
> On Fri, Apr 9, 2021 at 2:10 AM Jeff Henrikson  wrote:
>
>> Racket users,
>>
>> I’m trying to read a scheme file, decorate a bit of window dressing 
>> around the edges, and write the expressions to a new fil

Re: [racket-users] Re: Executable file size and raco demod

[Dexter Lagan]

Hi again,

  After playing around with the gen-wheels procedure and comparing its code 
with the WM_HSCROLL handling, I was able to get fast, accurate and smooth 
scrolling for both mouse and touchpad by switching the wheel-steps-mode to 
'integer and reducing WHEEL_DELTA by a factor of 4. Here's the updated code 
:


  (define wheel-steps-mode 'integer)
  (define/public (get-wheel-steps-mode) wheel-steps-mode)
  (define/public (set-wheel-steps-mode mode) (set! wheel-steps-mode mode))

  (define/private (gen-wheels w msg lParam amt down up)
(define AUG_WHEEL_DELTA (/ WHEEL_DELTA 4))
(let loop ([amt amt])
  (cond
[((abs amt) . < . AUG_WHEEL_DELTA)
 (case wheel-steps-mode
   [(one integer) amt]
   [(fraction)
(unless (zero? amt)
  (do-key w msg down lParam #f #f void (/ amt (exact->inexact 
AUG_WHEEL_DELTA
0.0])]
[(negative? amt)
 (case wheel-steps-mode
   [(one)
(do-key w msg down lParam #f #f void 1.0)
(loop (+ amt AUG_WHEEL_DELTA))]
   [(integer)
(define steps (quotient (- amt) AUG_WHEEL_DELTA))
(do-key w msg down lParam #f #f void (exact->inexact steps))
(loop (+ amt (* steps AUG_WHEEL_DELTA)))]
   [else
(do-key w msg down lParam #f #f void (/ (- amt) (exact->inexact 
AUG_WHEEL_DELTA)))
0.0])]
[else
 (case wheel-steps-mode
   [(one)
(do-key w msg up lParam #f #f void 1.0)
(loop (- amt AUG_WHEEL_DELTA))]
   [(integer)
(define steps (quotient amt AUG_WHEEL_DELTA))
(do-key w msg up lParam #f #f void (exact->inexact steps))
(loop (- amt (* steps AUG_WHEEL_DELTA)))]
   [else
(do-key w msg up lParam #f #f void (/ amt (exact->inexact 
AUG_WHEEL_DELTA)))
0.0])])))


On Wednesday, April 7, 2021 at 1:54:24 AM UTC+2 Matthew Flatt 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 pla

Re: [racket-users] Re: Executable file size and raco demod

[Dexter Lagan]

FYI I ended up going to 8.0 BC 32 bits to get the smallest executables for 
production, while still evaluating current.
I partially fixed my scrolling problem by replacing   
(* wheel-scale amt)
by
(/ (* wheel-scale amt) 2)
in share/pkgs/gui-lib/mred/private/wx/win32/window.rkt.

  There still is a small delay in the direction change while scrolling, but 
it isn't nearly as objectionnable as it was with * amt.

Cheers,

Dex
On Wednesday, April 7, 2021 at 1:54:24 AM UTC+2 Matthew Flatt 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 racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/f40328a9-1f65-4154-8a52-85dd510df2d0n%40googlegroups.com.