Re: [racket-users] Re: How do I debug this performance problem?

[Ben Greenman]

> I've noticed that Typed Racket adds seemingly unnecessary chaperones when
> the Any type is involved, but maybe they are necessary for some reason? The
> following code tries to create a chaperone that I don't think is necessary.
>
> #lang racket
>
> (module m typed/racket
>   (provide f)
>   (: f (-> Any Any))
>   (define (f x) x))
> (require 'm)
>
> (struct s (a b) #:transparent #:authentic)
> (f (s 1 2))
>
> Is there a reason for the chaperone? Should I report this and similar
> situations as Github issues?

Typed Racket uses Any chaperones to protect its values from untyped
code. For example, if typed code sent a vector to untyped, then the
Any chaperone would prevent `vector-set!`s

I agree the chaperone isn't necessary in your example because `f`
never receives a typed value. I also can't think of a way to use an
un-chaperoned version of `f` to break type soundness ... so maybe
there is a general principle here, about how a typed function creates
an Any result, that TR could learn.

If you have ideas and/or more examples, then yes please open an issue.

-- 
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/CAFUu9R772b608dSGMgatukR%2BtaaSZokDaTKxek_n%3D4bhfczrgg%40mail.gmail.com.

[racket-users] Re: How do I debug this performance problem?

[Ryan Kramer]

It turns out that a chaperone introduced at the typed-untyped boundary was 
causing a certain important function to run at least 20x slower. I've added 
prop:authentic to all my structs and am updating the code so that Typed 
Racket no longer tries to create chaperones.

I've noticed that Typed Racket adds seemingly unnecessary chaperones when 
the Any type is involved, but maybe they are necessary for some reason? The 
following code tries to create a chaperone that I don't think is necessary.

#lang racket

(module m typed/racket
  (provide f)
  (: f (-> Any Any))
  (define (f x) x))
(require 'm)

(struct s (a b) #:transparent #:authentic)
(f (s 1 2))

Is there a reason for the chaperone? Should I report this and similar 
situations as Github issues?
On Sunday, April 4, 2021 at 7:11:02 PM UTC-5 Ryan Kramer wrote:

> I either forgot or never learned that the profile functionality is 
> available programmatically. And `create-sampler` can track a single thread 
> which is exactly what I want (the UI thread). The profile results are 
> surprising, but at least I have some ideas to try now.
>
> On Sunday, April 4, 2021 at 12:55:32 PM UTC-5 Ryan Kramer wrote:
>
>> I am working on prototyping a video game. I have a function `state->pict` 
>> that takes a game state and creates a pict to be drawn on a canvas. When I 
>> `time` this function I get nice low numbers like "cpu time: 0 real time: 2 
>> gc time: 0"
>>
>> The problem occurs when I am running a networked multiplayer game. The 
>> size and complexity of the state remains the same (a "state" represents 
>> only one player's state). But the mere presence of other threads doing 
>> network IO somehow slows down `state->pict` which is strange because it is 
>> a pure function. I get timing results like "cpu time: 78 real time: 71 gc 
>> time: 0". If I stop the network activity mid-game, after a few seconds it 
>> will start running quickly again.
>>
>> This makes me think that other threads are interrupting state->pict and 
>> that this interruption is being captured by `time`. Is that plausible?
>>
>> Do I need to use a separate place for the network request/response queue? 
>> Right now, I am just using `thread` like this:
>>
>> ; (-> request (evtof response))
>> (define/public (sendrq rq)
>>   (let ([result (box #f)])
>> (wrap-evt (thread (lambda () (set-box! result (send/recv rq
>>   (lambda args (unbox result)
>>
>> There is one other area that concerns me: I am using `read` on the 
>> input-port returned by `tcp-connect`. I was hoping that `read` would yield 
>> while it is waiting for the datum to arrive on the port, but maybe it spins 
>> instead which would explain the elevated CPU usage.
>>
>> I tried `raco profile my-game.rkt` but that only profiles the time it 
>> takes to show the initial frame. Is there some other technique I can use to 
>> profile the game while it is running?
>>
>> Thanks in advance for any suggestions.
>>
>

-- 
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/c4a87899-25c1-4095-b3d7-309007386ffen%40googlegroups.com.

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

[Dexter Lagan]

  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.

 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? The raco demod 
option seemed to do miracles on previous versions, but never worked on 
gracket / gui programs for me.

  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.

Happy Easter!

Dex

On Monday, April 5, 2021 at 3:18:21 PM UTC+2 Matthew Flatt wrote:

> The archive size is misleading for two reasons:
>
> * the Northwestern snapshots include a lot more overall content by
> including tests, and
>
> * compression on the installer counteracts the mistake where the
> content of ".zo" files is not individually compressed; uncompressed
> individual ".zo" files end up compressing better as a group.
>
> A new build is ready just now, where DrRacket starts and the size is
> changed (i.e., download size is moderately bigger, unpacked size is
> much smaller).
>
> At Mon, 5 Apr 2021 03:24:42 -0700 (PDT), Dexter Lagan wrote:
> > Looks like it's the opposite. At the moment Utah's is half the size. 
> I'll 
> > install the current Utah's and compare generated executables with 8.0 
> > release.
> > 
> > Utah:
> > [image: Utah.png]
> > 
> > Northwestern:
> > [image: North.png]
> > 
> > On Monday, April 5, 2021 at 11:42:46 AM UTC+2 Dexter Lagan wrote:
> > 
> > > Hi Matthew,
> > >
> > > It is indeed the one from Utah. I’ll give the other one a try and 
> report 
> > > back. Thanks for looking into this!
> > >
> > > Dex 
> > >
> > >
> > >
> > > On Sunday, April 4, 2021 at 8:32:00 PM UTC+2 Matthew Flatt wrote:
> > >
> > >> Hi Dex, 
> > >>
> > >> Are you using a snapshot build from the Utah site --- as opposed to a 
> > >> snapshot for Northwestern or some other build? 
> > >>
> > >> I see that the Utah site's compiled code is twice as big as the 
> > >> Northwestern site's compiled code. It looks like the build process 
> for 
> > >> Racket at Utah (via Visual Studio) misconfigures the "should compiled 
> > >> code be compressed?" flag, while the build process used at 
> Northwestern 
> > >> (via MinGW) configures that setting correctly. The distribution 
> builds 
> > >> are made in the same way as the Northwestern snapshots. 
> > >>
> > >> I'll fix the compilation path that the Utah snapshot uses, but it 
> would 
> > >> be good to know whether that could be the problem. 
> > >>
> > >> Thanks, 
> > >> Matthew 
> > >>
> > >> At Sun, 4 Apr 2021 02:19:28 -0700 (PDT), Dexter Lagan wrote: 
> > >> > I updated to current again, and executable file size has nearly 
> doubled 
> > >> > again (120MB vs 70MB). I'd be curious to know if startup time 
> wouldn't 
> > >> be 
> > >> > affected by file IO at this point. I'm using 7.9 BC 32 bits in 
> > >> production 
> > >> > atm, since it produces the smallest executables (12 MB!). 
> > >> > 
> > >> > Dex 
> > >> > 
> > >> > On Wednesday, March 3, 2021 at 8:07:00 PM UTC+1 Dexter Lagan wrote: 
> > >> > 
> > >> > > Hello there, 
> > >> > > 
> > >> > > Two things: 
> > >> > > 
> > >> > > - I noticed a doubling of executable file sizes (from 30MB to 
> 70MB 
> > >> for 
> > >> > > racket/gui with embedded libs, Windows) between Racket 7.9 
> (non-CS) 
> > >> and 
> > >> > > Racket 8.0 (CS). Because of this, startup times from network 
> drives 
> > >> also 
> > >> > > doubled (from 5 to 10s for gui programs when using CS). I had to 
> > >> revert to 
> > >> > > 7.9 non-CS for now; 
> > >> > > 
> > >> > > - Because of this, I have been trying to reduce file sizes to a 
> > >> minimum. I 
> > >> > > tried replacing racket/gui by a minimal list of requires to no 
> avail. 
> > >> I 
> > >> > > tried using the raco demod function to demodularize, but it seems 
> to 
> > >> be 
> > >> > > broken on recent version of Racket (anything beyond hello world 
> will 
> > >> quit 
> > >> > > prematurely, racket/gui programs won't run at all). I tried 
> GitHub - 
> > >> > > bluerider/flattener: Source Code Level Flattener for PLT Racket 
> > >> > >  without success (seems 
> > >> broken as 
> > >> > > well). I also tried compressing executables with UPX, but it also 
> > >> breaks 
> > >> > > them. 
> > >> > > 
> > >> > > Does anybody know of a way to reduce final Racket executable file 
> > >> sizes 
> > >> > > / flatten / demodularize while keeping gui functionality ? 
> > >> > > 
> > >> > > Dex 
> > >> > > 
> > >> > 
> > >> > -- 
> > >> > You received this message because you are 

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

[Dexter Lagan]

Fantastic. Thanks for the info and the new build! Can’t wait to give it a test 
drive.

Dex


From: Matthew Flatt 
Sent: Monday, April 5, 2021 3:18:17 PM
To: Dexter Lagan 
Cc: Racket Users 
Subject: Re: [racket-users] Re: Executable file size and raco demod

The archive size is misleading for two reasons:

 * the Northwestern snapshots include a lot more overall content by
   including tests, and

 * compression on the installer counteracts the mistake where the
   content of ".zo" files is not individually compressed; uncompressed
   individual ".zo" files end up compressing better as a group.

A new build is ready just now, where DrRacket starts and the size is
changed (i.e., download size is moderately bigger, unpacked size is
much smaller).

At Mon, 5 Apr 2021 03:24:42 -0700 (PDT), Dexter Lagan wrote:
> Looks like it's the opposite. At the moment Utah's is half the size. I'll
> install the current Utah's and compare generated executables with 8.0
> release.
>
> Utah:
> [image: Utah.png]
>
> Northwestern:
> [image: North.png]
>
> On Monday, April 5, 2021 at 11:42:46 AM UTC+2 Dexter Lagan wrote:
>
> > Hi Matthew,
> >
> >   It is indeed the one from Utah. I’ll give the other one a try and report
> > back. Thanks for looking into this!
> >
> > Dex
> >
> >
> >
> > On Sunday, April 4, 2021 at 8:32:00 PM UTC+2 Matthew Flatt wrote:
> >
> >> Hi Dex,
> >>
> >> Are you using a snapshot build from the Utah site --- as opposed to a
> >> snapshot for Northwestern or some other build?
> >>
> >> I see that the Utah site's compiled code is twice as big as the
> >> Northwestern site's compiled code. It looks like the build process for
> >> Racket at Utah (via Visual Studio) misconfigures the "should compiled
> >> code be compressed?" flag, while the build process used at Northwestern
> >> (via MinGW) configures that setting correctly. The distribution builds
> >> are made in the same way as the Northwestern snapshots.
> >>
> >> I'll fix the compilation path that the Utah snapshot uses, but it would
> >> be good to know whether that could be the problem.
> >>
> >> Thanks,
> >> Matthew
> >>
> >> At Sun, 4 Apr 2021 02:19:28 -0700 (PDT), Dexter Lagan wrote:
> >> > I updated to current again, and executable file size has nearly doubled
> >> > again (120MB vs 70MB). I'd be curious to know if startup time wouldn't
> >> be
> >> > affected by file IO at this point. I'm using 7.9 BC 32 bits in
> >> production
> >> > atm, since it produces the smallest executables (12 MB!).
> >> >
> >> > Dex
> >> >
> >> > On Wednesday, March 3, 2021 at 8:07:00 PM UTC+1 Dexter Lagan wrote:
> >> >
> >> > > Hello there,
> >> > >
> >> > > Two things:
> >> > >
> >> > > - I noticed a doubling of executable file sizes (from 30MB to 70MB
> >> for
> >> > > racket/gui with embedded libs, Windows) between Racket 7.9 (non-CS)
> >> and
> >> > > Racket 8.0 (CS). Because of this, startup times from network drives
> >> also
> >> > > doubled (from 5 to 10s for gui programs when using CS). I had to
> >> revert to
> >> > > 7.9 non-CS for now;
> >> > >
> >> > > - Because of this, I have been trying to reduce file sizes to a
> >> minimum. I
> >> > > tried replacing racket/gui by a minimal list of requires to no avail.
> >> I
> >> > > tried using the raco demod function to demodularize, but it seems to
> >> be
> >> > > broken on recent version of Racket (anything beyond hello world will
> >> quit
> >> > > prematurely, racket/gui programs won't run at all). I tried GitHub -
> >> > > bluerider/flattener: Source Code Level Flattener for PLT Racket
> >> > >  without success (seems
> >> broken as
> >> > > well). I also tried compressing executables with UPX, but it also
> >> breaks
> >> > > them.
> >> > >
> >> > > Does anybody know of a way to reduce final Racket executable file
> >> sizes
> >> > > / flatten / demodularize while keeping gui functionality ?
> >> > >
> >> > > Dex
> >> > >
> >> >
> >> > --
> >> > 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...@googlegroups.com.
> >> > To view this discussion on the web visit
> >> >
> >>
> https://groups.google.com/d/msgid/racket-users/a2a14107-01fb-4f36-b6e1-c02498f35
> >> > 7adn%40googlegroups.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/5e33921f-c751-40b5-89bc-fadc01bda
> 506n%40googlegroups.com.
>
>
> --
> [image/png "Utah.png"] [~/Desktop & open] [~/Temp & open]
> .
>
>
> 

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

[Matthew Flatt]

The archive size is misleading for two reasons:

 * the Northwestern snapshots include a lot more overall content by
   including tests, and

 * compression on the installer counteracts the mistake where the
   content of ".zo" files is not individually compressed; uncompressed
   individual ".zo" files end up compressing better as a group.

A new build is ready just now, where DrRacket starts and the size is
changed (i.e., download size is moderately bigger, unpacked size is
much smaller).

At Mon, 5 Apr 2021 03:24:42 -0700 (PDT), Dexter Lagan wrote:
> Looks like it's the opposite. At the moment Utah's is half the size. I'll 
> install the current Utah's and compare generated executables with 8.0 
> release.
> 
> Utah:
> [image: Utah.png]
> 
> Northwestern:
> [image: North.png]
> 
> On Monday, April 5, 2021 at 11:42:46 AM UTC+2 Dexter Lagan wrote:
> 
> > Hi Matthew,
> >
> >   It is indeed the one from Utah. I’ll give the other one a try and report 
> > back. Thanks for looking into this!
> >
> > Dex 
> >
> >
> >
> > On Sunday, April 4, 2021 at 8:32:00 PM UTC+2 Matthew Flatt wrote:
> >
> >> Hi Dex, 
> >>
> >> Are you using a snapshot build from the Utah site --- as opposed to a 
> >> snapshot for Northwestern or some other build? 
> >>
> >> I see that the Utah site's compiled code is twice as big as the 
> >> Northwestern site's compiled code. It looks like the build process for 
> >> Racket at Utah (via Visual Studio) misconfigures the "should compiled 
> >> code be compressed?" flag, while the build process used at Northwestern 
> >> (via MinGW) configures that setting correctly. The distribution builds 
> >> are made in the same way as the Northwestern snapshots. 
> >>
> >> I'll fix the compilation path that the Utah snapshot uses, but it would 
> >> be good to know whether that could be the problem. 
> >>
> >> Thanks, 
> >> Matthew 
> >>
> >> At Sun, 4 Apr 2021 02:19:28 -0700 (PDT), Dexter Lagan wrote: 
> >> > I updated to current again, and executable file size has nearly doubled 
> >> > again (120MB vs 70MB). I'd be curious to know if startup time wouldn't 
> >> be 
> >> > affected by file IO at this point. I'm using 7.9 BC 32 bits in 
> >> production 
> >> > atm, since it produces the smallest executables (12 MB!). 
> >> > 
> >> > Dex 
> >> > 
> >> > On Wednesday, March 3, 2021 at 8:07:00 PM UTC+1 Dexter Lagan wrote: 
> >> > 
> >> > > Hello there, 
> >> > > 
> >> > > Two things: 
> >> > > 
> >> > > - I noticed a doubling of executable file sizes (from 30MB to 70MB 
> >> for 
> >> > > racket/gui with embedded libs, Windows) between Racket 7.9 (non-CS) 
> >> and 
> >> > > Racket 8.0 (CS). Because of this, startup times from network drives 
> >> also 
> >> > > doubled (from 5 to 10s for gui programs when using CS). I had to 
> >> revert to 
> >> > > 7.9 non-CS for now; 
> >> > > 
> >> > > - Because of this, I have been trying to reduce file sizes to a 
> >> minimum. I 
> >> > > tried replacing racket/gui by a minimal list of requires to no avail. 
> >> I 
> >> > > tried using the raco demod function to demodularize, but it seems to 
> >> be 
> >> > > broken on recent version of Racket (anything beyond hello world will 
> >> quit 
> >> > > prematurely, racket/gui programs won't run at all). I tried GitHub - 
> >> > > bluerider/flattener: Source Code Level Flattener for PLT Racket 
> >> > >  without success (seems 
> >> broken as 
> >> > > well). I also tried compressing executables with UPX, but it also 
> >> breaks 
> >> > > them. 
> >> > > 
> >> > > Does anybody know of a way to reduce final Racket executable file 
> >> sizes 
> >> > > / flatten / demodularize while keeping gui functionality ? 
> >> > > 
> >> > > Dex 
> >> > > 
> >> > 
> >> > -- 
> >> > 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...@googlegroups.com. 
> >> > To view this discussion on the web visit 
> >> > 
> >> 
> https://groups.google.com/d/msgid/racket-users/a2a14107-01fb-4f36-b6e1-c02498f35
>  
> >> > 7adn%40googlegroups.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/5e33921f-c751-40b5-89bc-fadc01bda
> 506n%40googlegroups.com.
> 
> 
> --
> [image/png "Utah.png"] [~/Desktop & open] [~/Temp & open]
> .
> 
> 
> --
> [image/png "North.png"] [~/Desktop & open] [~/Temp & open]
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Racket 

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

[Bruce O'Neel]

Hi,  
  
I stumbled over that error too.  Apparently Mathew said it would be fixed in 
the next build.  
  
cheers  
  
bruce  
  
  
  

> Windows 10   
> Snapshot: 20210404-725710e**  
>    Windows  
>    [64-bit 
> x64](https://www.cs.utah.edu/plt/snapshots/current/installers/racket-8.0.0.13-x86_64-win32-cs.exe)**
>   
> Dex  
> On Monday, April 5, 2021 at 12:54:24 PM UTC+2 Dexter Lagan wrote:  
> --  
>  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](mailto:racket-users+unsubscr...@googlegroups.com).
>   
>  To view this discussion on the web visit .
  

-- 
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/1617620658-4594ff36d175173d728a46ec4caf3abe%40pckswarms.ch.

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

[Dexter Lagan]

Windows 10
Snapshot: 20210404-725710e
   Windows
  64-bit x64 


Dex
On Monday, April 5, 2021 at 12:54:24 PM UTC+2 Dexter Lagan wrote:

> Upon opening DrRacket on 8.0.0.13, Utah build:
>
> ptr-set!: cannot install value into non-atomic memory
>   value: #
>   destination: #
>   context...:
>C:\Program Files\Racket-8.0.0.13\collects\ffi\unsafe.rkt:1468:4: loop
>body of "C:\Program 
> Files\Racket-8.0.0.13\share\pkgs\gui-lib\mred\private\gdi.rkt"
>
> [Exited. Close box or Ctrl-C closes the console.]
>
> Dex
> On Monday, April 5, 2021 at 12:24:42 PM UTC+2 Dexter Lagan wrote:
>
>> Looks like it's the opposite. At the moment Utah's is half the size. I'll 
>> install the current Utah's and compare generated executables with 8.0 
>> release.
>>
>> Utah:
>> [image: Utah.png]
>>
>> Northwestern:
>> [image: North.png]
>>
>> On Monday, April 5, 2021 at 11:42:46 AM UTC+2 Dexter Lagan wrote:
>>
>>> Hi Matthew,
>>>
>>>   It is indeed the one from Utah. I’ll give the other one a try and 
>>> report back. Thanks for looking into this!
>>>
>>> Dex 
>>>
>>>
>>>
>>> On Sunday, April 4, 2021 at 8:32:00 PM UTC+2 Matthew Flatt wrote:
>>>
 Hi Dex, 

 Are you using a snapshot build from the Utah site --- as opposed to a 
 snapshot for Northwestern or some other build? 

 I see that the Utah site's compiled code is twice as big as the 
 Northwestern site's compiled code. It looks like the build process for 
 Racket at Utah (via Visual Studio) misconfigures the "should compiled 
 code be compressed?" flag, while the build process used at Northwestern 
 (via MinGW) configures that setting correctly. The distribution builds 
 are made in the same way as the Northwestern snapshots. 

 I'll fix the compilation path that the Utah snapshot uses, but it would 
 be good to know whether that could be the problem. 

 Thanks, 
 Matthew 

 At Sun, 4 Apr 2021 02:19:28 -0700 (PDT), Dexter Lagan wrote: 
 > I updated to current again, and executable file size has nearly 
 doubled 
 > again (120MB vs 70MB). I'd be curious to know if startup time 
 wouldn't be 
 > affected by file IO at this point. I'm using 7.9 BC 32 bits in 
 production 
 > atm, since it produces the smallest executables (12 MB!). 
 > 
 > Dex 
 > 
 > On Wednesday, March 3, 2021 at 8:07:00 PM UTC+1 Dexter Lagan wrote: 
 > 
 > > Hello there, 
 > > 
 > > Two things: 
 > > 
 > > - I noticed a doubling of executable file sizes (from 30MB to 70MB 
 for 
 > > racket/gui with embedded libs, Windows) between Racket 7.9 (non-CS) 
 and 
 > > Racket 8.0 (CS). Because of this, startup times from network drives 
 also 
 > > doubled (from 5 to 10s for gui programs when using CS). I had to 
 revert to 
 > > 7.9 non-CS for now; 
 > > 
 > > - Because of this, I have been trying to reduce file sizes to a 
 minimum. I 
 > > tried replacing racket/gui by a minimal list of requires to no 
 avail. I 
 > > tried using the raco demod function to demodularize, but it seems 
 to be 
 > > broken on recent version of Racket (anything beyond hello world 
 will quit 
 > > prematurely, racket/gui programs won't run at all). I tried GitHub 
 - 
 > > bluerider/flattener: Source Code Level Flattener for PLT Racket 
 > >  without success (seems 
 broken as 
 > > well). I also tried compressing executables with UPX, but it also 
 breaks 
 > > them. 
 > > 
 > > Does anybody know of a way to reduce final Racket executable file 
 sizes 
 > > / flatten / demodularize while keeping gui functionality ? 
 > > 
 > > Dex 
 > > 
 > 
 > -- 
 > 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...@googlegroups.com. 
 > To view this discussion on the web visit 
 > 
 https://groups.google.com/d/msgid/racket-users/a2a14107-01fb-4f36-b6e1-c02498f35
  
 > 7adn%40googlegroups.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/a2ad2c17-64f6-4ace-b9c2-531ad9f43f64n%40googlegroups.com.

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

[Dexter Lagan]

Upon opening DrRacket on 8.0.0.13, Utah build:

ptr-set!: cannot install value into non-atomic memory
  value: #
  destination: #
  context...:
   C:\Program Files\Racket-8.0.0.13\collects\ffi\unsafe.rkt:1468:4: loop
   body of "C:\Program 
Files\Racket-8.0.0.13\share\pkgs\gui-lib\mred\private\gdi.rkt"

[Exited. Close box or Ctrl-C closes the console.]

Dex
On Monday, April 5, 2021 at 12:24:42 PM UTC+2 Dexter Lagan wrote:

> Looks like it's the opposite. At the moment Utah's is half the size. I'll 
> install the current Utah's and compare generated executables with 8.0 
> release.
>
> Utah:
> [image: Utah.png]
>
> Northwestern:
> [image: North.png]
>
> On Monday, April 5, 2021 at 11:42:46 AM UTC+2 Dexter Lagan wrote:
>
>> Hi Matthew,
>>
>>   It is indeed the one from Utah. I’ll give the other one a try and 
>> report back. Thanks for looking into this!
>>
>> Dex 
>>
>>
>>
>> On Sunday, April 4, 2021 at 8:32:00 PM UTC+2 Matthew Flatt wrote:
>>
>>> Hi Dex, 
>>>
>>> Are you using a snapshot build from the Utah site --- as opposed to a 
>>> snapshot for Northwestern or some other build? 
>>>
>>> I see that the Utah site's compiled code is twice as big as the 
>>> Northwestern site's compiled code. It looks like the build process for 
>>> Racket at Utah (via Visual Studio) misconfigures the "should compiled 
>>> code be compressed?" flag, while the build process used at Northwestern 
>>> (via MinGW) configures that setting correctly. The distribution builds 
>>> are made in the same way as the Northwestern snapshots. 
>>>
>>> I'll fix the compilation path that the Utah snapshot uses, but it would 
>>> be good to know whether that could be the problem. 
>>>
>>> Thanks, 
>>> Matthew 
>>>
>>> At Sun, 4 Apr 2021 02:19:28 -0700 (PDT), Dexter Lagan wrote: 
>>> > I updated to current again, and executable file size has nearly 
>>> doubled 
>>> > again (120MB vs 70MB). I'd be curious to know if startup time wouldn't 
>>> be 
>>> > affected by file IO at this point. I'm using 7.9 BC 32 bits in 
>>> production 
>>> > atm, since it produces the smallest executables (12 MB!). 
>>> > 
>>> > Dex 
>>> > 
>>> > On Wednesday, March 3, 2021 at 8:07:00 PM UTC+1 Dexter Lagan wrote: 
>>> > 
>>> > > Hello there, 
>>> > > 
>>> > > Two things: 
>>> > > 
>>> > > - I noticed a doubling of executable file sizes (from 30MB to 70MB 
>>> for 
>>> > > racket/gui with embedded libs, Windows) between Racket 7.9 (non-CS) 
>>> and 
>>> > > Racket 8.0 (CS). Because of this, startup times from network drives 
>>> also 
>>> > > doubled (from 5 to 10s for gui programs when using CS). I had to 
>>> revert to 
>>> > > 7.9 non-CS for now; 
>>> > > 
>>> > > - Because of this, I have been trying to reduce file sizes to a 
>>> minimum. I 
>>> > > tried replacing racket/gui by a minimal list of requires to no 
>>> avail. I 
>>> > > tried using the raco demod function to demodularize, but it seems to 
>>> be 
>>> > > broken on recent version of Racket (anything beyond hello world will 
>>> quit 
>>> > > prematurely, racket/gui programs won't run at all). I tried GitHub - 
>>> > > bluerider/flattener: Source Code Level Flattener for PLT Racket 
>>> > >  without success (seems 
>>> broken as 
>>> > > well). I also tried compressing executables with UPX, but it also 
>>> breaks 
>>> > > them. 
>>> > > 
>>> > > Does anybody know of a way to reduce final Racket executable file 
>>> sizes 
>>> > > / flatten / demodularize while keeping gui functionality ? 
>>> > > 
>>> > > Dex 
>>> > > 
>>> > 
>>> > -- 
>>> > 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...@googlegroups.com. 
>>> > To view this discussion on the web visit 
>>> > 
>>> https://groups.google.com/d/msgid/racket-users/a2a14107-01fb-4f36-b6e1-c02498f35
>>>  
>>> > 7adn%40googlegroups.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/90466c8d-a260-46a1-bd9f-5f0d2056141fn%40googlegroups.com.

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

[Dexter Lagan]

Looks like it's the opposite. At the moment Utah's is half the size. I'll 
install the current Utah's and compare generated executables with 8.0 
release.

Utah:
[image: Utah.png]

Northwestern:
[image: North.png]

On Monday, April 5, 2021 at 11:42:46 AM UTC+2 Dexter Lagan wrote:

> Hi Matthew,
>
>   It is indeed the one from Utah. I’ll give the other one a try and report 
> back. Thanks for looking into this!
>
> Dex 
>
>
>
> On Sunday, April 4, 2021 at 8:32:00 PM UTC+2 Matthew Flatt wrote:
>
>> Hi Dex, 
>>
>> Are you using a snapshot build from the Utah site --- as opposed to a 
>> snapshot for Northwestern or some other build? 
>>
>> I see that the Utah site's compiled code is twice as big as the 
>> Northwestern site's compiled code. It looks like the build process for 
>> Racket at Utah (via Visual Studio) misconfigures the "should compiled 
>> code be compressed?" flag, while the build process used at Northwestern 
>> (via MinGW) configures that setting correctly. The distribution builds 
>> are made in the same way as the Northwestern snapshots. 
>>
>> I'll fix the compilation path that the Utah snapshot uses, but it would 
>> be good to know whether that could be the problem. 
>>
>> Thanks, 
>> Matthew 
>>
>> At Sun, 4 Apr 2021 02:19:28 -0700 (PDT), Dexter Lagan wrote: 
>> > I updated to current again, and executable file size has nearly doubled 
>> > again (120MB vs 70MB). I'd be curious to know if startup time wouldn't 
>> be 
>> > affected by file IO at this point. I'm using 7.9 BC 32 bits in 
>> production 
>> > atm, since it produces the smallest executables (12 MB!). 
>> > 
>> > Dex 
>> > 
>> > On Wednesday, March 3, 2021 at 8:07:00 PM UTC+1 Dexter Lagan wrote: 
>> > 
>> > > Hello there, 
>> > > 
>> > > Two things: 
>> > > 
>> > > - I noticed a doubling of executable file sizes (from 30MB to 70MB 
>> for 
>> > > racket/gui with embedded libs, Windows) between Racket 7.9 (non-CS) 
>> and 
>> > > Racket 8.0 (CS). Because of this, startup times from network drives 
>> also 
>> > > doubled (from 5 to 10s for gui programs when using CS). I had to 
>> revert to 
>> > > 7.9 non-CS for now; 
>> > > 
>> > > - Because of this, I have been trying to reduce file sizes to a 
>> minimum. I 
>> > > tried replacing racket/gui by a minimal list of requires to no avail. 
>> I 
>> > > tried using the raco demod function to demodularize, but it seems to 
>> be 
>> > > broken on recent version of Racket (anything beyond hello world will 
>> quit 
>> > > prematurely, racket/gui programs won't run at all). I tried GitHub - 
>> > > bluerider/flattener: Source Code Level Flattener for PLT Racket 
>> > >  without success (seems 
>> broken as 
>> > > well). I also tried compressing executables with UPX, but it also 
>> breaks 
>> > > them. 
>> > > 
>> > > Does anybody know of a way to reduce final Racket executable file 
>> sizes 
>> > > / flatten / demodularize while keeping gui functionality ? 
>> > > 
>> > > Dex 
>> > > 
>> > 
>> > -- 
>> > 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...@googlegroups.com. 
>> > To view this discussion on the web visit 
>> > 
>> https://groups.google.com/d/msgid/racket-users/a2a14107-01fb-4f36-b6e1-c02498f35
>>  
>> > 7adn%40googlegroups.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/5e33921f-c751-40b5-89bc-fadc01bda506n%40googlegroups.com.

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

[Dexter Lagan]

Hi Matthew,

  It is indeed the one from Utah. I’ll give the other one a try and report 
back. Thanks for looking into this!

Dex 



On Sunday, April 4, 2021 at 8:32:00 PM UTC+2 Matthew Flatt wrote:

> Hi Dex,
>
> Are you using a snapshot build from the Utah site --- as opposed to a
> snapshot for Northwestern or some other build?
>
> I see that the Utah site's compiled code is twice as big as the
> Northwestern site's compiled code. It looks like the build process for
> Racket at Utah (via Visual Studio) misconfigures the "should compiled
> code be compressed?" flag, while the build process used at Northwestern
> (via MinGW) configures that setting correctly. The distribution builds
> are made in the same way as the Northwestern snapshots.
>
> I'll fix the compilation path that the Utah snapshot uses, but it would
> be good to know whether that could be the problem.
>
> Thanks,
> Matthew
>
> At Sun, 4 Apr 2021 02:19:28 -0700 (PDT), Dexter Lagan wrote:
> > I updated to current again, and executable file size has nearly doubled 
> > again (120MB vs 70MB). I'd be curious to know if startup time wouldn't 
> be 
> > affected by file IO at this point. I'm using 7.9 BC 32 bits in 
> production 
> > atm, since it produces the smallest executables (12 MB!).
> > 
> > Dex
> > 
> > On Wednesday, March 3, 2021 at 8:07:00 PM UTC+1 Dexter Lagan wrote:
> > 
> > > Hello there,
> > >
> > > Two things:
> > >
> > > - I noticed a doubling of executable file sizes (from 30MB to 70MB for 
> > > racket/gui with embedded libs, Windows) between Racket 7.9 (non-CS) 
> and 
> > > Racket 8.0 (CS). Because of this, startup times from network drives 
> also 
> > > doubled (from 5 to 10s for gui programs when using CS). I had to 
> revert to 
> > > 7.9 non-CS for now;
> > >
> > > - Because of this, I have been trying to reduce file sizes to a 
> minimum. I 
> > > tried replacing racket/gui by a minimal list of requires to no avail. 
> I 
> > > tried using the raco demod function to demodularize, but it seems to 
> be 
> > > broken on recent version of Racket (anything beyond hello world will 
> quit 
> > > prematurely, racket/gui programs won't run at all). I tried GitHub - 
> > > bluerider/flattener: Source Code Level Flattener for PLT Racket 
> > >  without success (seems 
> broken as 
> > > well). I also tried compressing executables with UPX, but it also 
> breaks 
> > > them.
> > >
> > > Does anybody know of a way to reduce final Racket executable file 
> sizes 
> > > / flatten / demodularize while keeping gui functionality ?
> > >
> > > Dex
> > >
> > 
> > -- 
> > 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...@googlegroups.com.
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/racket-users/a2a14107-01fb-4f36-b6e1-c02498f35
> > 7adn%40googlegroups.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/633d97eb-c0be-4f18-a9b0-6f99cde54a35n%40googlegroups.com.