Re: the end of the [racket-users] mailing list and the migration to Discourse as a forum for Racket

[Dexter Lagan]

  Correct! Same feeling here.

Sir Wexler please do explain yourself.

Have a great day!

Dex

> On Nov 23, 2021, at 11:38 AM, kamist...@gmail.com  
> wrote:
> 
> 
> I searched for "Etan Wexler" on google groups and found other older messages, 
> but they seem more normal, human written.
> But I can't quite decide whether this latest message is human art, or maybe 
> ai art / an ai or a bot conversing.
> 
> What I find strange is the repetitions within the text, but that might be an 
> "intentional" choice, whether human or AI.
> Interestingly Discourse is mistyped as Discursive, I didn't know that word as 
> non-native speaker, it means to digress / "to wander from the subject" and 
> the text seems to do that.
> So that could both be a human using irony or an AI seeing it as an prompt to 
> do that.
> 
> While the message reminds me of early videos I saw about GPT-2 and AI 
> generated texts, within the context of the other messages I am not really 
> sure.
> The earlier messages make me think, the text is written by a human that likes 
> word puzzles and experimenting with different styles of expression, without 
> leaving an explanation of what is actually meant. 
> I guess we are reaching a point were we can't be sure anymore whether there 
> is a human typing anymore.
> I also wonder whether all captchas are completely useless by now.
> 
> At least videos like this make me think that is the case:
> OpenAI GPT-3 - Good At Almost Everything! 烙
> https://www.youtube.com/watch?v=_x9AwxfjxvE
> 
> I guess we will have to wait and see, whether there will be other messages.
> 
> Simon
> 
> dexte...@gmail.com schrieb am Dienstag, 23. November 2021 um 09:12:25 UTC+1:
>>   This is by far the strangest message I've ever read about Racket. It comes 
>> a close second to that all-caps spam we get constantly on the mailing list! 
>> I'd pay good money to know what's written between the lines. It sounds like 
>> really, really passive-aggressive.
>> 
>> Dex
>> 
>>> On Monday, November 22, 2021 at 3:55:08 PM UTC+1 johnbclements wrote:
>>> I’m … super confused by this message. Did I miss something? I feel like 
>>> this message has a subtext that I’m completely missing. 
>>> 
>>> John 
>>> 
>>> > On Nov 22, 2021, at 08:06, Etan Wexler  wrote: 
>>> > 
>>> > The stewards of Racket have decided that it’s time to give up on the 
>>> > mailing list (that is, racket-users, to which this message is a 
>>> > contribution). The stewards of Racket have designated another forum for 
>>> > Racket as the successor to racket-users. This other forum for discussing 
>>> > Racket has as its basis the software named “Discourse”, which is 
>>> > open‐source. Enlisting is prerequisite to contributing to the Discursive 
>>> > forum for Racket. Enlisting is prerequisite to receiving as Internet mail 
>>> > the contributions to the Discursive forum for Racket. The stewards of 
>>> > Racket have published a facility for enlisting as a participant in the 
>>> > Discursive forum for Racket. 
>>> > 
>>> 
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Racket Users" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/racket-users/RnIAQnZpvh0/unsubscribe.
> To unsubscribe from this group and all its topics, 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/bef44030-ad55-44b2-ab39-ae82df9bf95fn%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/AF966284-866C-4A7A-AFA3-DCD3A66B2FD1%40gmail.com.

Re: the end of the [racket-users] mailing list and the migration to Discourse as a forum for Racket

[Dexter Lagan]

  This is by far the strangest message I've ever read about Racket. It 
comes a close second to that all-caps spam we get constantly on the mailing 
list! I'd pay good money to know what's written between the lines. It 
sounds like really, really passive-aggressive.

Dex

On Monday, November 22, 2021 at 3:55:08 PM UTC+1 johnbclements wrote:

> I’m … super confused by this message. Did I miss something? I feel like 
> this message has a subtext that I’m completely missing.
>
> John
>
> > On Nov 22, 2021, at 08:06, Etan Wexler  wrote:
> > 
> > The stewards of Racket have decided that it’s time to give up on the 
> mailing list (that is, racket-users, to which this message is a 
> contribution). The stewards of Racket have designated another forum for 
> Racket as the successor to racket-users. This other forum for discussing 
> Racket has as its basis the software named “Discourse”, which is 
> open‐source. Enlisting is prerequisite to contributing to the Discursive 
> forum for Racket. Enlisting is prerequisite to receiving as Internet mail 
> the contributions to the Discursive forum for Racket. The stewards of 
> Racket have published a facility for enlisting as a participant in the 
> Discursive forum for Racket.
> > 
>
>

-- 
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/5c08b767-e837-4af4-89e0-7f859d4fc454n%40googlegroups.com.

[racket-users] Bootstrap on Racket

[Dexter Lagan]

Hi again,

  I've been working on porting my Newstrap Web framework from newLISP to 
Racket. I got most of it done and am about to start work on a router. 
Here's what I got so far:

DexterLagan/rap: Combination of Racket and Bootstrap, RAP is a Web 
framework aiming to produce good-looking pages with ease. (github.com) 


based on Newsrap:

DexterLagan/newstrap: A fast, lightweight web framework written in newLISP. 
(github.com) 

  Does anybody know if something similar already exists? I looked around 
but couldn't find anything production-ready (in Racket). I just want to 
know if I'm wasting my time reinventing the wheel, or if there's value in 
having a bunch of macros generate Bootstrap code. My first goal would be to 
have a static site generator going, followed by a fully-featured framework 
for production use.

Any and all feedback would help me greatly!

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/473170ba-624a-4339-b499-9e936765603cn%40googlegroups.com.

[racket-users] 'compiled' binary still depending on libs?

[Dexter Lagan]

Hi folks,

  I'm getting a strange dependency problem when attempting to run my 
Invoicer binary on systems with corrupted or missing Racket libs. For 
example, if I attempt to run the compiled binary (with embedded DLLs, 
Windows 10 x64) on a system which has Racket installed, but missing Gregor, 
I get an error claiming the gregor package is missing. Yet I was under the 
impression that compiling to binary for distribution, especially with 
embedded DLLs, would not require ANY libs installed. Is there a reason for 
this?

Here's the program in question:
DexterLagan/invoicer: A dead-simple, easy-to-use minimalist billing 
application. (github.com) 

Thanks in advance!

Dexter

-- 
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/def841e9-ffe4-4ded-96ca-fd78baa5105an%40googlegroups.com.

Re: [racket-users] Doc pages search engine difficulties

[Dexter Lagan]

  Thank you very much for the thorough explanation. It makes sense. I’ll be 
sharing the cheat sheet with my coworkers. It sure is a good starting point.

Dex

> On Aug 17, 2021, at 9:40 PM, Jens Axel Søgaard  wrote:
> 
> 
>> Den tir. 17. aug. 2021 kl. 16.34 skrev Dexter Lagan :
> 
>> Hello there,
>> 
>>   I'm trying to teach one of my coworkers how to search for function names 
>> in the Racket manual, and I'm having serious problems finding very simple 
>> things, such as the function to display the file browser dialog (get-file). 
>> I know most function names by heart but my coworker isn't that fortunate. I 
>> see I'm not the only one, as per these Stack Overflow answers.
>> 
>>   Does anybody know why the search engine doesn't seem to index page 
>> contents other than exact function names and titles?
>> 
>>   I understand search engines aren't trivial matters, but I'm thinking that 
>> finding very basic Racket functions would be crucial for beginners. If 
>> somebody could point me to the search engine repo, I'd love to have a look.
> 
> Full text search is possible to add - but it would require some changes to 
> the current setup.
> 
> One goal of the documentation system is that you can use the documentation on 
> your own computer without any internet access.
> When you enter a search term, a piece of JavaScript runs directly on your 
> computer without any queries sent to a server.
> In order for this to work there needs to be a prebuilt index in which the 
> search term an be looked up. 
> This index is built by `raco setup`. For each function/macro definition in 
> the documentation an entry is added to the index
> with associated information (which module is defined in etc.). 
> 
> If you use the search page at docs.racket-lang.org the index will be 
> downloaded to your computer first.
> Currently the index (the file name is plt-index.js )  has a size around 12 
> MB. 
> 
> If full text search is to be added the index would be considerably larger - 
> which means the index can no longer
> be downloaded. The actual search then needs to take place on the web-server. 
> 
> Could a standard full text indexer be used? Maybe - but most likely it will 
> be necessary to build a custom one.
> Standard indexers stem words ("apple" and "apples" are indexed as the same 
> word). They also filter out
> punctuation such as  - . ? / etc. This in turn makes it difficult to search 
> for identifiers.
> 
> The compromise today is that we have precise search among the identifiers and 
> keywords marked as
> imported by the documentation writers. If full text search is needed, then 
> Google is the place to look.
> 
> Back in the day before the current documentation search - it was possible to 
> make a custom Google 
> backed search page that only indexed a certain set of sites. It worked 
> "okay", but not great.
> The current system works much better.
> 
> That said, I understand that the amount of documentation has grown to such a 
> size, that it can 
> be difficult for newcomers to navigate. Maybe "cheat sheets" such as 
> 
>  https://docs.racket-lang.org/racket-cheat/index.html
> 
> could be added to some sections in order to give an overview of what's 
> available?
> 
> /Jens Axel
> 

-- 
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/6DFD2012-B618-4329-9E6B-7F171B0C6B89%40gmail.com.

[racket-users] Doc pages search engine difficulties

[Dexter Lagan]

Hello there,

  I'm trying to teach one of my coworkers how to search for function names 
in the Racket manual, and I'm having serious problems finding very simple 
things, such as the function to display the file browser dialog (get-file). 
I know most function names by heart but my coworker isn't that fortunate. I 
see I'm not the only one, as per these 

 
Stack Overflow answers.

  Does anybody know why the search engine doesn't seem to index page 
contents other than exact function names and titles?

  I understand search engines aren't trivial matters, but I'm thinking that 
finding very basic Racket functions would be crucial for beginners. If 
somebody could point me to the search engine repo, I'd love to have a look.

Thanks in advance!

Dexter

-- 
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/377da13a-dafe-4558-b21c-f71cd8238a93n%40googlegroups.com.

[racket-users] Re: Racket v8.1

[Dexter Lagan]

Hello sir,

 Thank you ! My name is actually Dexter Santucci. Apologies for the 
confusion. My email address isn't telling.

Cheers!

Dexter

On Wednesday, May 5, 2021 at 6:39:22 PM UTC+2 johnbclements wrote:

> --
> Racket version 8.1 is now available from
>
> https://racket-lang.org/
>
>
> - DrRacket tabs can be dragged, and have new close buttons.
>
> - Racket CS supports cross-compilation using `raco exe`.
>
> - Racket CS supports Android on 32-bit and 64-bit ARM processors.
>
> - The database library supports running queries in OS threads.
>
> - Check-Syntax arrows correctly identify the definition site of
> identifiers with contracts.
>
> - Racket CS performance has improved for structure predicates and
> accessors
>
> - Racket CS is faster at multiplying extremely large numbers and
> dividing large integers.
>
> - Racket CS allows callbacks to raise exceptions if they are annotated
> with `#:callback-exns?`.
>
> - New ephemeron hash tables simplify the implementation of tables where
> keys can refer to values.
>
> - Typed Racket supports for/foldr.
>
> - The stepper works for #lang htdp/*sl.
>
> - Struct signatures work for the ASL teaching language.
>
> The following people contributed to this release:
>
> Alex Harsányi, Alex Knauth, Alexander Shopov, Alexis King, Andrew
> Mauer-Oats, Anish Athalye, Ben Greenman, Bert De Ketelaere, Bob Burger,
> Bogdan Popa, Brian Adkins, Cameron Moy, David Van Horn, Dexter Lagan,
> Dominik Pantůček, Fred Fu, Greg Hendershott, Gustavo Massaccesi, Hazel
> Levine, Ismael Luceno, Jack Firth, Jarhmander, John Clements, Jörgen
> Brandt, Laurent Orseau, Lazerbeak12345, Matthew Flatt, Matthias
> Felleisen, Micah Cantor, Mike Sperber, Noah Ma, Patrick McCarty, Paulo
> Matos, Pavel Panchekha, Philip McGrath, Philippe Meunier, R. Kent
> Dybvig, Robby Findler, Ryan Culpepper, Ryan Kramer, Sam Tobin-Hochstadt,
> Sergiu Ivanov, Shu-Hung You, Sorawee Porncharoenwase, Stephen De
> Gabrielle, William J. Bowman, bmitc, xxyzz, yjqww6, and ymdarake
>
> Feedback Welcome
> --
>
>

-- 
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/e8e8ecff-79ad-4c33-ab37-6d98ca18baa7n%40googlegroups.com.

[racket-users] Tiny improvement to be made to pkgs.racket-lang.org

[Dexter Lagan]

Hi folks,

  I posted my first package the other day (that eyesore of Cobalt 2 theme). 
My repo has a 'main' branch instead of 'master'. pkgs.racket-lang.org 
didn't display any error when I clicked on the 'Save Changes' button. It 
simply went back to the package list, as if nothing had happened. At first, 
I thought the package had been accepted, and it's only after listing my 
packages that I noticed it hadn't. I fixed the branch name and submitted it 
again, this time it displayed the package info page.

  It'd be nice to display at least some form of error if the package isn't 
valid. Say, "this repo has no master branch, try again".

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/04c7c2b8-9708-4f76-bf1d-3b6df5689ecbn%40googlegroups.com.

[racket-users] Cobalt 2 color theme for DrRacket

[Dexter Lagan]

  Just made this, since it looks like nobody made it just yet. My favorite 
code colors. I use them in sublime, vim and now DrRacket.

[image: screenshot.png]

  I posted it to the catalog, we'll see if it get published :)

DexterLagan/cobalt2-theme 

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/2313cdc6-12e9-4584-86d0-f372e409e7aan%40googlegroups.com.

Re: [racket-users] Wheel / touchpad / trackpoint accuracy/speed scrolling fix for DrRacket

[Dexter Lagan]

Yes! Thank you.

Dex


From: Matthew Flatt 
Sent: Friday, April 16, 2021 3:26:19 PM
To: Dexter Lagan 
Cc: Racket Users 
Subject: Re: [racket-users] Wheel / touchpad / trackpoint accuracy/speed 
scrolling fix for DrRacket

Oh, I think I finally get it.

The problem is that the leftover amount is returned by `gen-wheels`.
With scaling by `wheel-scale`, the returned leftover has been scaled
--- but when the leftover is passed back to `gen-wheels` later, it gets
scaled again.

Applying the scale to `WHEEL_DELTA` instead of `amt` solves the
problem, because then the returned leftover amount is on the same scale
as the argument amount.

Thanks for working through this, and I'll push this change!

At Fri, 16 Apr 2021 01:23:16 -0700 (PDT), Dexter Lagan wrote:
> Hi Matt,
>
>   This works because when amt is smaller than WHEEL_DELTA, the amt value is
> used directly, see first branch of the cond :
>
> (cond
>  * [((abs amt) . < . WHEEL_DELTA_S)*
>(case wheel-steps-mode
>  [(one integer) amt]
>  [(fraction)
>   (unless (zero? amt)
> (do-key w msg down lParam #f #f void (/ amt
> (exact->inexact WHEEL_DELTA_S
>   0.0])]
>
>   I logged the values with and without the fix. In both cases, I scrolled
> slowly down  :
>
> WHEEL_DELTA_S:120
> wheel-scale:4
> amt:-8
>
> WHEEL_DELTA_S:120
> wheel-scale:4
> amt:-40
>
> WHEEL_DELTA_S:120
> wheel-scale:4
> amt:-168
>
> WHEEL_DELTA_S:120
> wheel-scale:4
> amt:-48
>
> WHEEL_DELTA_S:120
> wheel-scale:4
> amt:-200
>
> WHEEL_DELTA_S:120
> wheel-scale:4
> amt:-80
>
> WHEEL_DELTA_S:120
> wheel-scale:4
> amt:-332
>
> WHEEL_DELTA_S:120
> wheel-scale:4
> amt:-92
>
> WHEEL_DELTA_S:120
> wheel-scale:4
> amt:-376
>
>   Amt is often larger than WHEEL_DELTA. After applying the changes
> (dividing WHEEL-DELTA and removing the wheel-scale mul) :
>
> WHEEL_DELTA_S:30
> wheel-scale:4
> amt:-2
>
> WHEEL_DELTA_S:30
> wheel-scale:4
> amt:-4
>
> WHEEL_DELTA_S:30
> wheel-scale:4
> amt:-6
>
> WHEEL_DELTA_S:30
> wheel-scale:4
> amt:-8
>
> WHEEL_DELTA_S:30
> wheel-scale:4
> amt:-11
>
> WHEEL_DELTA_S:30
> wheel-scale:4
> amt:-13
>
> WHEEL_DELTA_S:30
> wheel-scale:4
> amt:-15
>
> WHEEL_DELTA_S:30
> wheel-scale:4
> amt:-17
>
> WHEEL_DELTA_S:30
> wheel-scale:4
> amt:-19
>
> WHEEL_DELTA_S:30
> wheel-scale:4
> amt:-22
>
>
> Amt is never above WHEEL_DELTA, which triggers only the first branch of the
> cond. The amt value is used with no adjustment, hense the precise behaviour.
>
> Dex
>
> On Thursday, April 15, 2021 at 1:49:53 PM UTC+2 Matthew Flatt wrote:
>
> > Thanks for this summary! But I remain puzzled...
> >
> > As I understand it, `wheel-scale` ends up being 4 on your machine. So
> > removing the multiplication by `wheel-scale` means that `amt` is 1/4 of
> > what it used to be. But `amt` is effectively always divided by
> > `WHEEL_DELTA`, which you've also divided by 4 in switching to
> > `WHEEL_DELTA_S`.
> >
> > It seems like those factors of 1/4 would cancel out. Do the numbers
> > passed to `do-key` end up being different in some way that I'm missing?
> >
> > Matthew
> >
> > At Mon, 12 Apr 2021 04:13:16 -0700 (PDT), Dexter Lagan wrote:
> > > I started a new thread as the original topic no longer matched.
> > > I installed 8.1.0.2 x64 CS and enabled logging in gen-wheels. Matt was
> > > right: wheel-steps-mode is indeed set to 'integer while gen-wheels runs
> > in
> > > DrRacket's editor. The only two changes required to get smooth/accurate
> > > scrolling on touchpad gestures and trackpoint are therefore:
> > >
> > > In share\pkgs\gui-lib\mred\private\wx\win32\window.rkt's gen-wheels
> > private
> > > method:
> > >
> > > (let loop ([amt (* wheel-scale amt)])
> > > to
> > > (let loop ([amt amt])
> > >
> > > and reduce WHEEL_DELTA by a factor of 4, such as gen-wheels looks like:
> > >
> > > (define/private (gen-wheels w msg lParam amt down up)
> > > (define WHEEL_DELTA_S (/ WHEEL_DELTA 4))
> > > (let loop ([amt amt])
> > > (cond
> > > [((abs amt) . < . WHEEL_DELTA_S)
> > > (case wheel-steps-mode
> > > [(one integer) amt]
> > > [(fraction)
> > > (unless (zero? amt)
> > > (do-key w msg down lParam #f #f void (/ amt (exact->inexact
> > > WHEEL_DELTA_S
> > > 0.0])]
> > > [(negative? a

Re: [racket-users] Wheel / touchpad / trackpoint accuracy/speed scrolling fix for DrRacket

[Dexter Lagan]

Hi Matt,

  This works because when amt is smaller than WHEEL_DELTA, the amt value is 
used directly, see first branch of the cond :

(cond
 * [((abs amt) . < . WHEEL_DELTA_S)*
   (case wheel-steps-mode
 [(one integer) amt]
 [(fraction)
  (unless (zero? amt)
(do-key w msg down lParam #f #f void (/ amt 
(exact->inexact WHEEL_DELTA_S
  0.0])]

  I logged the values with and without the fix. In both cases, I scrolled 
slowly down  :

WHEEL_DELTA_S:120
wheel-scale:4
amt:-8

WHEEL_DELTA_S:120
wheel-scale:4
amt:-40

WHEEL_DELTA_S:120
wheel-scale:4
amt:-168

WHEEL_DELTA_S:120
wheel-scale:4
amt:-48

WHEEL_DELTA_S:120
wheel-scale:4
amt:-200

WHEEL_DELTA_S:120
wheel-scale:4
amt:-80

WHEEL_DELTA_S:120
wheel-scale:4
amt:-332

WHEEL_DELTA_S:120
wheel-scale:4
amt:-92

WHEEL_DELTA_S:120
wheel-scale:4
amt:-376

  Amt is often larger than WHEEL_DELTA. After applying the changes 
(dividing WHEEL-DELTA and removing the wheel-scale mul) :

WHEEL_DELTA_S:30
wheel-scale:4
amt:-2

WHEEL_DELTA_S:30
wheel-scale:4
amt:-4

WHEEL_DELTA_S:30
wheel-scale:4
amt:-6

WHEEL_DELTA_S:30
wheel-scale:4
amt:-8

WHEEL_DELTA_S:30
wheel-scale:4
amt:-11

WHEEL_DELTA_S:30
wheel-scale:4
amt:-13

WHEEL_DELTA_S:30
wheel-scale:4
amt:-15

WHEEL_DELTA_S:30
wheel-scale:4
amt:-17

WHEEL_DELTA_S:30
wheel-scale:4
amt:-19

WHEEL_DELTA_S:30
wheel-scale:4
amt:-22


Amt is never above WHEEL_DELTA, which triggers only the first branch of the 
cond. The amt value is used with no adjustment, hense the precise behaviour.

Dex

On Thursday, April 15, 2021 at 1:49:53 PM UTC+2 Matthew Flatt wrote:

> Thanks for this summary! But I remain puzzled...
>
> As I understand it, `wheel-scale` ends up being 4 on your machine. So
> removing the multiplication by `wheel-scale` means that `amt` is 1/4 of
> what it used to be. But `amt` is effectively always divided by
> `WHEEL_DELTA`, which you've also divided by 4 in switching to
> `WHEEL_DELTA_S`.
>
> It seems like those factors of 1/4 would cancel out. Do the numbers
> passed to `do-key` end up being different in some way that I'm missing?
>
> Matthew
>
> At Mon, 12 Apr 2021 04:13:16 -0700 (PDT), Dexter Lagan wrote:
> > I started a new thread as the original topic no longer matched.
> > I installed 8.1.0.2 x64 CS and enabled logging in gen-wheels. Matt was 
> > right: wheel-steps-mode is indeed set to 'integer while gen-wheels runs 
> in 
> > DrRacket's editor. The only two changes required to get smooth/accurate 
> > scrolling on touchpad gestures and trackpoint are therefore:
> > 
> > In share\pkgs\gui-lib\mred\private\wx\win32\window.rkt's gen-wheels 
> private 
> > method:
> > 
> > (let loop ([amt (* wheel-scale amt)])
> > to
> > (let loop ([amt amt])
> > 
> > and reduce WHEEL_DELTA by a factor of 4, such as gen-wheels looks like:
> > 
> > (define/private (gen-wheels w msg lParam amt down up)
> > (define WHEEL_DELTA_S (/ WHEEL_DELTA 4))
> > (let loop ([amt amt])
> > (cond
> > [((abs amt) . < . WHEEL_DELTA_S)
> > (case wheel-steps-mode
> > [(one integer) amt]
> > [(fraction)
> > (unless (zero? amt)
> > (do-key w msg down lParam #f #f void (/ amt (exact->inexact 
> > WHEEL_DELTA_S
> > 0.0])]
> > [(negative? amt)
> > (case wheel-steps-mode
> > [(one)
> > (do-key w msg down lParam #f #f void 1.0)
> > (loop (+ amt WHEEL_DELTA_S))]
> > [(integer)
> > (define steps (quotient (- amt) WHEEL_DELTA_S))
> > (do-key w msg down lParam #f #f void (exact->inexact steps))
> > (loop (+ amt (* steps WHEEL_DELTA_S)))]
> > [else
> > (do-key w msg down lParam #f #f void (/ (- amt) (exact->inexact 
> > WHEEL_DELTA_S)))
> > 0.0])]
> > [else
> > (case wheel-steps-mode
> > [(one)
> > (do-key w msg up lParam #f #f void 1.0)
> > (loop (- amt WHEEL_DELTA_S))]
> > [(integer)
> > (define steps (quotient amt WHEEL_DELTA_S))
> > (do-key w msg up lParam #f #f void (exact->inexact steps))
> > (loop (- amt (* steps WHEEL_DELTA_S)))]
> > [else
> > (do-key w msg up lParam #f #f void (/ amt (exact->inexact 
> > WHEEL_DELTA_S)))
> > 0.0])])))
> > 
> > Happy Monday,
> > 
> > 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/28e13460-c86d-4967-aa25-5527d672e
> > 711n%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/c604a711-b12d-4b82-bb17-819f2ab142d0n%40googlegroups.com.

Re: [racket-users] Wheel / touchpad / trackpoint accuracy/speed scrolling fix for DrRacket

[Dexter Lagan]

I’ll log the values at different spots and let you know what I find. Clearly, 
multiplying amt by wheel-scale affects the scrolling behaviour. Somehow this 
does not affect mouse wheel scrolling une same way. Either the scrolling 
changes when a different device is used, or the device driver itself changes 
the values and/or behaviour.

Dex


From: Matthew Flatt 
Sent: Thursday, April 15, 2021 1:49:49 PM
To: Dexter Lagan 
Cc: Racket Users 
Subject: Re: [racket-users] Wheel / touchpad / trackpoint accuracy/speed 
scrolling fix for DrRacket

Thanks for this summary! But I remain puzzled...

As I understand it, `wheel-scale` ends up being 4 on your machine. So
removing the multiplication by `wheel-scale` means that `amt` is 1/4 of
what it used to be. But `amt` is effectively always divided by
`WHEEL_DELTA`, which you've also divided by 4 in switching to
`WHEEL_DELTA_S`.

It seems like those factors of 1/4 would cancel out. Do the numbers
passed to `do-key` end up being different in some way that I'm missing?

Matthew

At Mon, 12 Apr 2021 04:13:16 -0700 (PDT), Dexter Lagan wrote:
>   I started a new thread as the original topic no longer matched.
> I installed 8.1.0.2 x64 CS and enabled logging in gen-wheels. Matt was
> right: wheel-steps-mode is indeed set to 'integer while gen-wheels runs in
> DrRacket's editor. The only two changes required to get smooth/accurate
> scrolling on touchpad gestures and trackpoint are therefore:
>
> In share\pkgs\gui-lib\mred\private\wx\win32\window.rkt's gen-wheels private
> method:
>
> (let loop ([amt (* wheel-scale amt)])
> to
> (let loop ([amt amt])
>
> and reduce WHEEL_DELTA by a factor of 4, such as gen-wheels looks like:
>
>   (define/private (gen-wheels w msg lParam amt down up)
> (define WHEEL_DELTA_S (/ WHEEL_DELTA 4))
> (let loop ([amt amt])
>   (cond
> [((abs amt) . < . WHEEL_DELTA_S)
>  (case wheel-steps-mode
>[(one integer) amt]
>[(fraction)
> (unless (zero? amt)
>   (do-key w msg down lParam #f #f void (/ amt (exact->inexact
> WHEEL_DELTA_S
> 0.0])]
> [(negative? amt)
>  (case wheel-steps-mode
>[(one)
> (do-key w msg down lParam #f #f void 1.0)
> (loop (+ amt WHEEL_DELTA_S))]
>[(integer)
> (define steps (quotient (- amt) WHEEL_DELTA_S))
> (do-key w msg down lParam #f #f void (exact->inexact steps))
> (loop (+ amt (* steps WHEEL_DELTA_S)))]
>[else
> (do-key w msg down lParam #f #f void (/ (- amt) (exact->inexact
> WHEEL_DELTA_S)))
> 0.0])]
> [else
>  (case wheel-steps-mode
>[(one)
> (do-key w msg up lParam #f #f void 1.0)
> (loop (- amt WHEEL_DELTA_S))]
>[(integer)
> (define steps (quotient amt WHEEL_DELTA_S))
> (do-key w msg up lParam #f #f void (exact->inexact steps))
> (loop (- amt (* steps WHEEL_DELTA_S)))]
>[else
> (do-key w msg up lParam #f #f void (/ amt (exact->inexact
> WHEEL_DELTA_S)))
> 0.0])])))
>
> Happy Monday,
>
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/28e13460-c86d-4967-aa25-5527d672e
> 711n%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/DM6PR08MB39467A9EDDE20FDD3161A7EEFC4D9%40DM6PR08MB3946.namprd08.prod.outlook.com.

[racket-users] Wheel / touchpad / trackpoint accuracy/speed scrolling fix for DrRacket

[Dexter Lagan]

  I started a new thread as the original topic no longer matched.
I installed 8.1.0.2 x64 CS and enabled logging in gen-wheels. Matt was 
right: wheel-steps-mode is indeed set to 'integer while gen-wheels runs in 
DrRacket's editor. The only two changes required to get smooth/accurate 
scrolling on touchpad gestures and trackpoint are therefore:

In share\pkgs\gui-lib\mred\private\wx\win32\window.rkt's gen-wheels private 
method:

(let loop ([amt (* wheel-scale amt)])
to
(let loop ([amt amt])

and reduce WHEEL_DELTA by a factor of 4, such as gen-wheels looks like:

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

Happy Monday,

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/28e13460-c86d-4967-aa25-5527d672e711n%40googlegroups.com.

[racket-users] Incorrect value/typo in write-resource procedure documentation

[Dexter Lagan]

https://docs.racket-lang.org/file/resource.html

For the proc write-resource, 
type : (or/c 

 'string 'bytes 'integer) = 'string
should read
type : (or/c 

 'string 'bytes 'dword) = 'string

As the 'integer value is not supported. Attempting to use the 'integer 
value returns the following error:
write-resource: expected argument of type <'string, 'bytes, or 'dword>; 
given: 'integer

Cheers,

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/3a88a91a-864d-4b63-a7f1-db25798a708bn%40googlegroups.com.

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

[Dexter Lagan]

  I'll study all this and get back to you.
Reminds me of my win32 API days, making event loops...

Dex

On Saturday, April 10, 2021 at 8:35:35 PM UTC+2 Matthew Flatt wrote:

> At Sat, 10 Apr 2021 17:26:21 +0000, 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/4e58ab94-b114-4a76-95ca-6efe3e31356an%40googlegroups.com.

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)))

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

[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 
&g

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 comp

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

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 

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.

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

[Dexter Lagan]

  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  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 
>>> > distribut

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

[Dexter Lagan]

  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  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.
>>
>>

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

[Dexter Lagan]

  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  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

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 
> > >&

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
> >> > > <https://github.com/bluerider/flattener> 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 m

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

[Dexter Lagan]

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:

> 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 
>>>> > > <https://github.com/bluerider/flattener> 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 
>>> > > <https://github.com/bluerider/flattener> 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 
>> > > <https://github.com/bluerider/flattener> 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 
> > > <https://github.com/bluerider/flattener> 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.

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

[Dexter Lagan]

  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 
> <https://github.com/bluerider/flattener> 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/a2a14107-01fb-4f36-b6e1-c02498f357adn%40googlegroups.com.

[racket-users] Executable file size and raco demod

[Dexter Lagan]

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/0a560a0b-7bf1-4277-8e68-57708859d681n%40googlegroups.com.

Re: [racket-users] Racket slower than Chez Scheme on interpreter benchmark, potential low hanging fruit?

[Dexter Lagan]

  For what it's worth, I ran my own benchmark on Racket 8.0 and Racket 
8.0.10 (current), and current is between 50 and 100% faster for certain 
operations. There must have been some optimizations done recently to 
current.

Dex
On Tuesday, March 2, 2021 at 9:37:29 AM UTC+1 wanp...@gmail.com wrote:

> I previously came out with a version that converts a BF program directly 
> into a module, which has received some optimization contributions from 
> Matthew Flatt.
> Got some pretty good results.
>
> Execute bench.b in cpu time: 1542 ms, (2.2s include compile time).
>
> And mandel.b in cpu time: 3851 ms, (7s include compile time). But you have 
> to manually "export PLT_CS_COMPILE_LIMIT=10" environment variable in 
> order to get compiled and executed properly.
>
> https://gist.github.com/sleepnova/92d7b2a7f077e7de76da4ce31f60335e
>
> philngu...@gmail.com  於 2021年3月1日 週一 下午3:39寫道：
>
>> There’s this benchmark on BF interpreter where the Racket 
>>  and Chez 
>> Scheme  
>> implementations are very similar, but Chez Scheme is much faster than 
>> Racket 8.0 at interpreting bench.b 
>>  (3s vs 8s) and mandel.b 
>>  (40s vs 136s).
>>
>> There’s the “Racket (Syntax Object) 
>> ”
>>  
>> variant that directly parses BF’s syntax into Racket syntax object, which 
>> is faster (3.7s for bench, 82s for mandel), but still significantly behind 
>> Chez Scheme’s naive interpreter.
>>
>> Profiling doesn’t give very illuminating results, saying most of the cost 
>> is from interpreting BF’s loop instruction.
>>
>> Given that Racket is on Chez, could this benchmark reveal some low 
>> hanging fruit for improving Racket’s performance?
>>
>> -- 
>>
> 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/83b2819d-8295-4769-944d-fa0c155976dan%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> - sleepnova
> 呼叫小黃創辦人 & CEO
>

-- 
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/281c3e71-028e-4709-bc77-6f9956afadf1n%40googlegroups.com.

Re: [racket-users] Quickscript of the day: Extract to function

[Dexter Lagan]

Nice!! Yay for laziness.

On Thu, May 7, 2020 at 11:33 AM Laurent  wrote:

> Have you ever wanted to extract a block of code out of its context and
> wrap it in a function?
>
> Have you ever *not* done it because of the cognitive load(*) of figuring
> out the function arguments and the return values?
>
> Well, now it's as easy as Ctrl-Shift-X and Ctrl-Shift-Y. Using
> check-syntax, the extract-function and put-function scripts figure out what
> goes in and out for you.
>
> Video: https://www.youtube.com/watch?v=XinMxDLZ7Zw
> `raco pkg install quickscript-extra` to install, or
> `raco pkg update quickscript-extra` if it's already installed.
>
> (*) a.k.a. laziness ;)
>
> --
> 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/CABNTSaHpOYQM2X3TW%3DHYGP7_CTA8jCaj4Euh0mcjnus1aOdt-g%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/CACUENrJhQfB4KWYH%2B8FqD%2BDAkNBNoZWcYitTQsS4336tHmfNJQ%40mail.gmail.com.

Re: [racket-users] A convenient assertion macro - with one caveat

[Dexter Lagan]

Awesome! Thanks. Racket is freaking amazing.

Dex

> On May 7, 2020, at 11:51 AM, Jens Axel Søgaard  wrote:
> 
> 
> You can use syntax/loc to give a piece of syntax location information.
> 
> #lang racket
> (require (for-syntax syntax/parse))
> 
> (define-syntax (assert stx)
>   (syntax-parse stx
> [(_assert ?a ?b)
>  (quasisyntax/loc stx
>(module+ test
>  (require rackunit)
>  #,(syntax/loc stx (check-equal? ?a ?b #'?a]
> [(_assert ?a)
>  (quasisyntax/loc stx
>(module+ test
>  (require rackunit)
>  #,(syntax/loc stx (check-true ?a #'?a]))
> 
> 
> /Jens Axel
> Racket Stories
> https://racket-stories.com
> 
>> Den tor. 7. maj 2020 kl. 11.22 skrev Dexter Lagan :
>> Hi,
>> 
>>   I made a simple macro which saves me the trouble of defining a test 
>> module, requiring RackUnit and then declaring '(module+ test' after each 
>> procedure definition, as I like to keep unit tests close by. The repo :
>> 
>> https://github.com/DexterLagan/assert 
>> 
>>   Here's the macro, apologies for the broken formatting :
>> 
>> (define-syntax (assert stx)
>>   (syntax-parse stx
>> [(_ ?a ?b)
>>  #'(module+ test
>>  (require rackunit)
>>  (check-equal? ?a ?b #'?a))]
>> [(_ ?a)
>>  #'(module+ test
>>  (require rackunit)
>>  (check-true ?a #'?a))]))
>> 
>> The macro works great, and I was able to pipe through an assertion message 
>> through rackunit's check-equal? and other procedures.
>> I have one question however: would there be a way to make DrRacket point to 
>> the failed assertion line instead of the macro itself when a failure occurs? 
>> Here's a screenshot of how it looks like at the moment:
>> 
>> 
>> 
>> 
>>   It would be even better if DrRacket highlighted the (assert ...) line 
>> itself, but I'm asking a bit much :) If assert is an actual module, I'm not 
>> sure where DrRacket would then point at.
>> I also have doubts about whenever Racket will remove the test module once 
>> compiled. Since macros are processed at compile-time, I'm guessing it would 
>> remove the test module right after, but let me know if you have a more 
>> definite answer.
>> 
>> 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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/racket-users/CACUENrLX%3D9ix2kv9MNpp3nNoSN%3DsWBx%2BFTRdwNyNA7EiVWQ0mA%40mail.gmail.com.
> 
> 
> -- 
> -- 
> Jens Axel Søgaard
> 

-- 
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/FC1246E9-81C3-456F-90F6-64467FC097B0%40gmail.com.

[racket-users] A convenient assertion macro - with one caveat

[Dexter Lagan]

Hi,

  I made a simple macro which saves me the trouble of defining a test
module, requiring RackUnit and then declaring '(module+ test' after each
procedure definition, as I like to keep unit tests close by. The repo :

https://github.com/DexterLagan/assert

  Here's the macro, apologies for the broken formatting :

(define-syntax (assert stx)
(syntax-parse stx
[(_ ?a ?b)
#'(module+ test
(require rackunit)
(check-equal? ?a ?b #'?a))]
[(_ ?a)
#'(module+ test
(require rackunit)
(check-true ?a #'?a))]))

The macro works great, and I was able to pipe through an assertion message
through rackunit's check-equal? and other procedures.
I have one question however: would there be a way to make DrRacket point to
the failed assertion line instead of the macro itself when a failure
occurs? Here's a screenshot of how it looks like at the moment:

[image: assert.PNG]

  It would be even better if DrRacket highlighted the (assert ...) line
itself, but I'm asking a bit much :) If assert is an actual module, I'm not
sure where DrRacket would then point at.
I also have doubts about whenever Racket will remove the test module once
compiled. Since macros are processed at compile-time, I'm guessing it would
remove the test module right after, but let me know if you have a more
definite answer.

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CACUENrLX%3D9ix2kv9MNpp3nNoSN%3DsWBx%2BFTRdwNyNA7EiVWQ0mA%40mail.gmail.com.

Re: [racket-users] trickiness about the order of definitions in GUI code

[Dexter Lagan]

Hi James,

  Like others said, Unit is the proper solution, but to add my 2c, I was
able to avoid this problem altogether by using these two simple tricks :
1) add the controls in the order of their requirement (defining table3
before info-menu-item), then re-ordering the controls before displaying the
window, as follows:

(send frame3 change-children
  (λ (children)
(list ...
  info-menu-item
  table3
  ...)))

2) to get around the problem of separating gui and logic code, one solution
is to create an englobing 'display-gui' function which takes the callback
func names as parameters. That allows one to move all the callback
functions outside of the GUI, and pipe them through from another module.
For example:

main.rkt:

;;; defs

(define (menu3-callback-proc param1 ...)
   ...)

;;; main

(show-gui  menu3-callback-proc ...)

gui.rkt:
(define (show-gui menu3-callback-proc-name ...)

  gui code...

  )

Let me know if this helps...

Dex

On Thu, May 7, 2020 at 1:50 AM James Platt  wrote:

> I'm working on organizing and documenting some things and I have some
> code, below, which works but I don't understand why.  Specifically, why
> don't I get an error about table3 not being defined?
>
> This is a very simplified version of what I'm working on.  What I actually
> want to do is put all the code related to creating a standard table editing
> menu in a file which I can then include wherever I want that menu.  The
> full menu will be a lot of code.  Unfortunately I can't seem to get this to
> work without either getting an error that row-edit-menu is not defined or
> that table3 is not defined.  In other words, I want to be able to define
> table3 in one file which requires the file where row-edit-menu is defined
> but I can't seem to figure out how to get this to work.  It works just fine
> when all the code is in one file, however.
>
> James
>
>
> #lang racket
> (require racket/gui/base
>  qresults-list
>  )
>
> ;set up columns
> (define (column1 data) (vector-ref data 0))
> (define (column2 data) (vector-ref data 1))
>
> (define my-columns
>   (list
>(qcolumn "Column1" column1 column1)
>(qcolumn "Column2"
> (lambda (row)
>   ;(displayln row)
>   ;(displayln (db-row-ref row "Column2" headers 1))
>   (if (number? (column2 row)) (number->string (column2 row))
> "");This allows a cell to be blank.
>   ;(number->string (column2 row))
>   )
> column2)
>
>)
>   )
>
> (define frame3 (new frame%
>   [label "myTable 3"]
>   [width 800]
>   [height 600]
>   ))
>
>
> (define row-edit-menu (new popup-menu% ))
>
> (define info-menu-item (new menu-item%
>   (label "info")
>   (parent row-edit-menu)
>   (callback (lambda (menu-item event)
>   (message-box "Info"
>(~a "You have
> selected " (length (send table3 get-selected-row-indexes)) " rows")
>#f)
>   ))
>   ))
>
> (define table3
>(new (class qresults-list% (init) (super-new)
>   [parent frame3]
>   [pref-tag 'preferences-tag]
>   [selection-type 'multiple]
>   [right-click-menu row-edit-menu])
>   )
>
> (send table3 setup-column-defs my-columns)
>
> (send frame3 show #t)
>
> (send table3 add-row (vector "R1C1" 10))
> (send table3 add-row (vector "R2C1" 11))
> (send table3 add-row (vector "R3C1" 12))
> (send table3 add-row (vector "R4C1" 13))
>
>
> --
> 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/F54B34B7-F04F-4DF7-9236-FD6C4FE3C983%40biomantica.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/CACUENrL0tZx_SYrz1FLWpj4K6FUZOuBmv%2B5L356eN8m9boxb8g%40mail.gmail.com.

Re: [racket-users] Questions about working on DrRacket and gui

[Dexter Lagan]

  If you open DrRacket, a new tab opens with #lang racket.
I can type anything I want, a lot of random characters, numbers etc. As soon as 
any keyword is recognized, there’s the pause. For example:

Hejheke
Idhnehje
Osjdjvehjekd
Hdiisbsidhjd
Gueojd jdbdbskbd jdjdb defino definii define <- pause here

  It does the same on any of my systems.

Dex

> On May 6, 2020, at 3:05 PM, Gustavo Massaccesi  wrote:
> 
> 
> I´m not sure if you are writing your own list of known symbols or if you are 
> reusing a list of known symbols that DrRacket is using for something else.
> 
> Gustavo
> 
>> On Wed, May 6, 2020 at 9:25 AM Dexter Lagan  wrote:
>>   If that can help, I narrowed down the delay to new files only, after 
>> typing a known symbol only. When opening an existing file, no matter what I 
>> type in, no delay. If I start a fresh DrRacket, I can type anything in the 
>> definitions window with no delay. The delay only happens if I type a known 
>> function name, for example ‘define’. If I type ‘defind’, there’s no delay. 
>> The delay also appears in Scheme mode, and with background expansion 
>> disabled. No delay in Text mode, which makes sense.
>> 
>>  
>> 
>>   I’m currently looking at the definitions-text from unit.rkt, to see 
>> where’s the hook that detects symbols. I have the day off, and I’m enjoying 
>> this very much.
>> 
>>  
>> 
>> Cheers,
>> 
>>  
>> 
>> Dex
>> 
>>  
>> 
>> From: Robby Findler  
>> Sent: Tuesday, May 5, 2020 6:18 PM
>> To: Gustavo Massaccesi 
>> Cc: Dexter Lagan ; Matthew Flatt 
>> ; Racket Users 
>> Subject: Re: [racket-users] Questions about working on DrRacket and gui
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> On Tue, May 5, 2020 at 10:36 AM Gustavo Massaccesi  
>> wrote:
>> 
>> I try to encourage people to participate, but be careful because this task 
>> is probably too big for a first contribution. GUI is difficult, DrRacket has 
>> a lot of moving parts, and opening DrRacket inside DrRacket is possible but 
>> weird.
>> 
>>  
>> 
>>  
>> 
>> +1
>> 
>>  
>> 
>> I think the guess of Matthew is correct, it´s a problem with the blue arrow 
>> with the docs. There is no pause while you type numbers but when you type a 
>> letter or +-*/... there is a pause of 1 or 2 seconds.
>> 
>>  
>> 
>> I didn't see the code but my guess is that the docs are loaded lazily in a 
>> thread and when DrRackets see something like an identifier it waits until 
>> the thread is ready. It would be nice if the blue arrow is disabled until 
>> the docs are completely loaded lazily. I think Robby can tell if I'm correct 
>> and how hard is to fix this.
>> 
>>  
>> 
>>  
>> 
>> Definitely sounds like an extremely actionable hypothesis to investigate 
>> and, if it turns out to be correct, I guess it should be a simple matter of 
>> programming to do what you're suggesting.
>> 
>>  
>> 
>> Robby
>> 
>>  

-- 
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/4297A05D-9CB4-4629-80C2-25B7206105A6%40gmail.com.

RE: [racket-users] Questions about working on DrRacket and gui

[Dexter Lagan]

  If that can help, I narrowed down the delay to new files only, after typing a 
known symbol only. When opening an existing file, no matter what I type in, no 
delay. If I start a fresh DrRacket, I can type anything in the definitions 
window with no delay. The delay only happens if I type a known function name, 
for example ‘define’. If I type ‘defind’, there’s no delay. The delay also 
appears in Scheme mode, and with background expansion disabled. No delay in 
Text mode, which makes sense.

 

  I’m currently looking at the definitions-text from unit.rkt, to see where’s 
the hook that detects symbols. I have the day off, and I’m enjoying this very 
much.

 

Cheers,

 

Dex

 

From: Robby Findler  
Sent: Tuesday, May 5, 2020 6:18 PM
To: Gustavo Massaccesi 
Cc: Dexter Lagan ; Matthew Flatt ; 
Racket Users 
Subject: Re: [racket-users] Questions about working on DrRacket and gui

 

 

 

On Tue, May 5, 2020 at 10:36 AM Gustavo Massaccesi mailto:gust...@oma.org.ar> > wrote:

I try to encourage people to participate, but be careful because this task is 
probably too big for a first contribution. GUI is difficult, DrRacket has a lot 
of moving parts, and opening DrRacket inside DrRacket is possible but weird.

 

 

+1

 

I think the guess of Matthew is correct, it´s a problem with the blue arrow 
with the docs. There is no pause while you type numbers but when you type a 
letter or +-*/... there is a pause of 1 or 2 seconds.

 

I didn't see the code but my guess is that the docs are loaded lazily in a 
thread and when DrRackets see something like an identifier it waits until the 
thread is ready. It would be nice if the blue arrow is disabled until the docs 
are completely loaded lazily. I think Robby can tell if I'm correct and how 
hard is to fix this.

 

 

Definitely sounds like an extremely actionable hypothesis to investigate and, 
if it turns out to be correct, I guess it should be a simple matter of 
programming to do what you're suggesting.

 

Robby

 

-- 
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/010201d623a1%245c4e23e0%2414ea6ba0%24%40gmail.com.

Re: [racket-users] Questions about working on DrRacket and gui

[Dexter Lagan]

  To add to my previous message, I know and understand that DrRacket and
GUI are very complex. I've been going over unit.rkt. Yeah it's a lot of
code. But it's not as bad as I thought.
I'm just offering a hand in making sense of it all. With enough time and
patience I'm sure I'll get something out of it. Now, if you think my time
would be better used for something else Racket-related, do tell.

Dex

On Tue, May 5, 2020 at 6:17 PM Robby Findler 
wrote:

>
>
> On Tue, May 5, 2020 at 10:36 AM Gustavo Massaccesi 
> wrote:
>
>> I try to encourage people to participate, but be careful because this
>> task is probably too big for a first contribution. GUI is difficult,
>> DrRacket has a lot of moving parts, and opening DrRacket inside DrRacket is
>> possible but weird.
>>
>>
> +1
>
>
>> I think the guess of Matthew is correct, it´s a problem with the blue
>> arrow with the docs. There is no pause while you type numbers but when you
>> type a letter or +-*/... there is a pause of 1 or 2 seconds.
>>
>> I didn't see the code but my guess is that the docs are loaded lazily in
>> a thread and when DrRackets see something like an identifier it waits until
>> the thread is ready. It would be nice if the blue arrow is disabled until
>> the docs are completely loaded lazily. I think Robby can tell if I'm
>> correct and how hard is to fix this.
>>
>>
> Definitely sounds like an extremely actionable hypothesis to investigate
> and, if it turns out to be correct, I guess it should be a simple matter of
> programming to do what you're suggesting.
>
> Robby
>
>

-- 
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/CACUENrKfb-Av93DdPhureK6FRA9AfGBiKqWPGb%2BAFM%2Bb6QWUQw%40mail.gmail.com.

Re: [racket-users] Questions about working on DrRacket and gui

[Dexter Lagan]

  Couple years ago I developed an IDE for NewLISP called NewIDE using a
commercial tool called Xojo. It was supposed to become NewLISP's official
IDE. I had to put the project on pause because of work and family, and at
the same time I switched to Racket, hence my interest. It had replicated
most of DrRacket's basic functions apart from the debugger and profiler,
but was much faster (native controls + LLVM). I have plenty of time on my
hands lately, and I'll take a couple hours each day to analyze DrRacket and
see where I can reduce delays and improve responsiveness. Who knows, it
might pay off.

After a quick first pass over each module, what DrRacket's source needs is :
1) a detailed description of what each module does;
2) a description of what each function/class does, methods and properties
etc. I don't see a lot of comments at the moment.

  I'll gladly volunteer to write those. I'll annotate the code as I go
through it, and I'll push it to a new github when I have enough of it
documented. If the DrRacket's authors are happy with the result, we'll
merge?

  As for the delay, I'm sure there's a callback somewhere which launches
the context-sensitive help, or loads the docs in the background like you
said. There's gotta be a way to move this loading time somewhere more
appropriate, like say during the init splash, or at the very least display
a loading dialog box to inform the user.

Let me know what you think,

Dex

On Tue, May 5, 2020 at 6:17 PM Robby Findler 
wrote:

>
>
> On Tue, May 5, 2020 at 10:36 AM Gustavo Massaccesi 
> wrote:
>
>> I try to encourage people to participate, but be careful because this
>> task is probably too big for a first contribution. GUI is difficult,
>> DrRacket has a lot of moving parts, and opening DrRacket inside DrRacket is
>> possible but weird.
>>
>>
> +1
>
>
>> I think the guess of Matthew is correct, it´s a problem with the blue
>> arrow with the docs. There is no pause while you type numbers but when you
>> type a letter or +-*/... there is a pause of 1 or 2 seconds.
>>
>> I didn't see the code but my guess is that the docs are loaded lazily in
>> a thread and when DrRackets see something like an identifier it waits until
>> the thread is ready. It would be nice if the blue arrow is disabled until
>> the docs are completely loaded lazily. I think Robby can tell if I'm
>> correct and how hard is to fix this.
>>
>>
> Definitely sounds like an extremely actionable hypothesis to investigate
> and, if it turns out to be correct, I guess it should be a simple matter of
> programming to do what you're suggesting.
>
> Robby
>
>

-- 
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/CACUENr%2BDgdCBJ3JDUT8MQMCaRY03A2-y5TtFXLO8bRe%3Dyctkpg%40mail.gmail.com.

Re: [racket-users] Re: On the importance of testing for noobs - or 'there's no such thing as a stupid test'.

[Dexter Lagan]

  Yes! Haven’t played with contracts yet, but they’re next in my list.

Cheers,

Dex

> On May 4, 2020, at 1:19 PM, Simon Schlee  wrote:
> 
> 
> And use contracts. 
> I can't claim that all my code uses contracts everywhere, but when I 
> encounter unexpected/bewildering behavior I add contracts to break those 
> chains of "piped functions".
> You can start with define/contract for ease of use.
> 
> Later on you can put functions that belong together in one module and test 
> that they work as expected.
> Then use (provide (contract-out ...)) to put contracts on the exposed 
> functions, structs, etc. to make sure that they can't be used with unexpected 
> values from the outside.
> This way your module can have internal invariants which can't be broken from 
> the outside.
> 
> 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/f2bd097c-5718-4ead-b497-7703942af12b%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/665ECEA9-2B6F-4EC0-BE96-E397B8439228%40gmail.com.

RE: [racket-users] Re: Futures + threads SIGSEGV

[Dexter Lagan]

  Thank you sir, no doubt futures are being used in an unsafe manner. The code 
was used in language benchmarks and was 'optimized' to squeeze every ounce of 
performance. What I find strange is that it does work well, and saturates all 
cores (that was the intent) on Win10, but crashes randomly on certain systems 
and certain versions of Racket. It believe it started becoming unstable around 
Racket 7.0. On Linux it only uses one thread, which could very well be caused 
by a difference in the way futures are implemented on Linux.

Dex

-Original Message-
From: racket-users@googlegroups.com  On Behalf 
Of George Neuner
Sent: Monday, May 4, 2020 4:03 AM
To: racket-users@googlegroups.com
Subject: [racket-users] Re: Futures + threads SIGSEGV

On Sat, 2 May 2020 14:10:19 +0200, Dexter Lagan  wrote:

> I’ve been getting inconsistent results as well. A while ago I made a 
>benchmark based on a parallel spectral norm computation. The benchmark 
>works fine on Windows on most systems and uses all cores, but crashes 
>randomly on other systems. I haven’t been able to figure out why. On 
>Linux it doesn’t seem to use more than one core. I’d be interested to 
>know if this is related. Here’s the benchmark code :
>
>https://github.com/DexterLagan/benchmark
>
>Dex

I haven't examined the code in detail, but I suspect you're not giving the 
futures time to do anything.  Your 'for/par' function touches them almost 
immediately, and touching forces a future to be evaluated by the thread that 
has touched it.

Also be aware that futures essentially are limited to data access and math ... 
in particular if you try to do any kind of I/O within a future it will force 
(at least) that future into serial execution.

George

--
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/i2tuafl9rs29bjlr9i6rb387bdqj02epqg%404ax.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/00bd01d621e4%24968e8130%24c3ab8390%24%40gmail.com.

Re: [racket-users] Reducing parentheses without language damage.

[Dexter Lagan]

  Spoiled is an understatement. I wrote a lot of programs in debug (DOS). And 
it was nice! Turbo Pascal was what really spoiled me. :) I miss the in-line asm 
days.

Dex

> On May 3, 2020, at 9:46 PM, George Neuner  wrote:
> 
> 
>> On 5/2/2020 4:58 AM, Dexter Lagan wrote:
>>   For the sake of discussion, here’s a long rant:
>> 
>>   I might have a very uninformed opinion here, but wouldn’t having 
>> significant white space and no scope-defining character amount to multiple 
>> spaces and line feeds being part of the syntax? The next best thing being, 
>> allowing semicolons in place of line feeds. I’m no language designer, so let 
>> me try to give you my perspective as an average programmer:
>> 
>>   I find editing Python and Haskell a pain, because of white spaces. I can’t 
>> count the times I got that dreaded ‘invalid indentation’ error, because I’m 
>> editing code with a different editor on a different system. I also had to 
>> reformat entire programs after somebody saved using the incorrect tab 
>> setting, and I avoid Python because of this. Yet I haven’t heard this 
>> complaint from Python programmers, so I always believed I was just too dumb.
> 
> Python is as much a cult as a programming language.
> 
> 
>>   I haven’t seen a better solution than s-expr to make expressions and scope 
>> ultra-visible and easy to manipulate. Yet s-expressions still bring their 
>> own requirements for comfortable editing: most people still require a 
>> specialized editor or a plugin for lisps. I fact, is there any language that 
>> doesn’t require some sort of plugin or specialized editor to be attractive 
>> to new programmers? Thinking of it, isn’t the IDE almost as important as the 
>> syntax or the language these days?
> 
> For most languages, IDEs are mainly needed for debugging.  For just editing, 
> the majority of languages really don't need syntax or structure awareness.  
> Syntax coloring is nice, but programmers got along fine without it for ~50 
> years.
> 
> Most languages in use now have syntax based (however loosely) on C and mostly 
> are not WS sensitive.  The compiler doesn't care about how the code is 
> formatted:  there is a statement terminator (or separator [there is a 
> difference]) character that serves to keep the compiler synchronized with the 
> source.
> 
> In Pascal, you can write an entire program on a single edit line. In C and 
> C++, the preprocessor is line sensitive, so it isn't possible to write a 
> whole program in one line - but the mainline code is WS indifferent, and you 
> can write entire functions, or even multiple functions, in one line.
> 
> But no one does that except in those competitions trying to pack a whole 
> program into 255 characters or less.
> 
> For most languages it is visual debugging: tracing and breaking execution, 
> probing runtime values, while seeing the source ... *that* is where an IDE 
> comes into its own.
> 
> 
> S-expr languages are different in this respect because they are expression 
> based rather than statement based.  Expressions can be nested arbitrarily, 
> and it is more difficult to visually identify things without some editor 
> assistance like coloration, parenthesis matching, and syntax directed 
> indentation.
> 
> S-expr languages have long used - though not required - indentation as a 
> guide to visualize program structure.  When you program with Racket (or 
> Scheme or Lisp) for a while, you cease to see the parentheses and really 
> mostly see only the indentation structure.
> 
> For debugging: tracing and breaking S-expr code is more complicated to 
> *display* and interact with reasonably - the UI matters greatly to programmer 
> efficiency.  But the actual debugger internally is not really much different 
> from a debugger for a statement language - it's mostly how the programmer 
> interacts with it that needs to change.
> 
> 
>> Some JavaScript programmers can’t work without VSCode, scope-sensitive 
>> autocomplete, a linter and god knows how many other plugins. PHP programmers 
>> also feel naked without a fancy IDE and a host of plugins. I keep hearing 
>> people complain about x or y language because it doesn’t have a good editor, 
>> IDE or plugin for VSCode. Globally, people use more and more tools to 
>> program in the same languages.
> 
> Programmers today are spoiled.  My first program was written on a teletype 
> connected by modem to a PDP-10 at some nearby college.  It took half an hour 
> to get a 10 line program working.
> 
> 
>>   That’s what turned me into a sort of ‘digital minimalist’. I take comfort 
>> in not being dependant on anythin

[racket-users] Quick Scripts collection

[Dexter Lagan]

  I made a repo for my QuickScripts and moved both compile-standalone and
my provide generator into it:

https://github.com/DexterLagan/Quick-Scripts

  At work I also got a really nice one to generate program skeletons, I'll
upload it tomorrow. Lemme know what you think.

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CACUENrK_gUd1CSVBviJvy76z2uDC%3DjNRvhY_NjhwEt2Mt5Ph0Q%40mail.gmail.com.

[racket-users] On the importance of testing for noobs - or 'there's no such thing as a stupid test'.

[Dexter Lagan]

  If it wasn't abundantly clear yet, I'm a Racket noob, so when I had this
kind of thing in my code:

(define x 'a)
(case x
  (('a) return-something)
  (('b) return-something-else)
  (('c) return-yet-another-thing))

  I was baffled to find out that the case form always returned void (thanks
Alex).
I made this mistake a few times in the past: quoting symbols in case forms.
I'm human, humans make errors, and I make a LOT of errors.
  I wrote the case form out of habit. I quoted symbols out of habit. I
didn't test the proc in the REPL, because well, I was quite sure how case
worked. The same habit pushed me to write a test. But I thought... bah this
is just too simple, why bother? Yet I should have, because it would have
instantly showed me that my expectations were off.

(module+ test
  (require rackunit))
...
(define (bad-case x)
  (case x
(('a) return-something)
(('b) return-something-else)
(('c) return-yet-another-thing)))
; unit test
(module+ test
  (check-equal? (bad-case 'b) 'b))
; test fails, bad-case returns void.

Obviously the correct syntax is:

(case x
((a) return-something)
((b) return-something-else)
((c) return-yet-another-thing))

  That very basic mistake made me spend quite a few hours tracking where
that void was coming from. And when that void pipes through a few functions
before landing in a find-files predicate, and that the error doesn't quite
mentions which parameter it came from...

  I read somewhere, that we should use plenty of asserts in our code. I
usually have unit tests for most of my functions, except on the ones I find
trivial. Silly mistake.
  So uh.. if you're a noob like me, write lots of tests. Test your
functions in the REPL. We say 'there's no such thing as a stupid question'.
I say, there's no such thing as a stupid test. Best of all, tests are free
with Racket!

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CACUENr%2BmNO9WhDUB1EBs-0F-UnU9KWmMBWr-0j%2BAK-1T5sDV9Q%40mail.gmail.com.

[racket-users] Strange find-files problem

[Dexter Lagan]

Hello Sunday coders,

  So I made a QuickScript to compile to standalone executable in a
platform-independent manner - without zipping. It works great, and Laurent
gave me a hand with the file browsing part for Linux. However I'm
encountering a hard to track runtime error with find-files. I am listing
all files with a certain extension. In the past I have used string-suffix?
for this, but I found out about path-has-extension? and attempted to use it
instead. I'm getting an error with both. Here's the code :

;; find files of a given extension recursively from the current directory
(define (find-files/ext path ext)
  (define (ext-file? f)
(and (not (void? f))
 (or (path? f) (string? f))
 (file-exists? f)
 (path-has-extension? f ext)))
  (find-files ext-file? path))

The error I'm getting should not be possible. I have added all these checks
to try and catch it, to no avail:

[image: Capture.PNG]

;; same as previous, but using string-suffix?
(define (find-files/ext# path ext)
  (define (ext-file? f)
(and (not (void? f))
 (or (path? f) (string? f))
 (file-exists? f)
 (string-suffix? (path->string f) ext)))
  (find-files ext-file? path))

When using string-suffix?, I'm getting a different error:

[image: Capture2.PNG]
  I have used find-files many times over the years and I have never seen
this. The start-path is issued from (path-only f), where f is the source
file path given by QuickScript for the current source file.
If you're testing this code, note that when using path-has-extension?, the
icon file extension constants have to be prefixed with '#' to comply with
the function's param type.
Here's the full source :

https://github.com/DexterLagan/compile-to-standalone-quick/blob/master/compile-to-standalone.rkt


  Any help would be appreciated.

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CACUENrKjUJ_zG7qu2NnNDUU%3D_7bLbD4%2B6q%2BkVui2DYQ7yZw0Zw%40mail.gmail.com.

Re: [racket-users] Futures + threads SIGSEGV

[Dexter Lagan]

Hi Dominik,

  Ah that explains why I was getting an incorrect number of threads! I didn’t 
think about using future-visualizer, but I’ll give it a try. Thanks!

Dex

> On May 2, 2020, at 2:27 PM, Dominik Pantůček  
> wrote:
> 
> Hi Dex,
> 
>> On 02. 05. 20 14:10, Dexter Lagan wrote:
>> Hello,
>> 
>>   I’ve been getting inconsistent results as well. A while ago I made a
>> benchmark based on a parallel spectral norm computation. The benchmark
>> works fine on Windows on most systems and uses all cores, but crashes
>> randomly on other systems. I haven’t been able to figure out why. On
>> Linux it doesn’t seem to use more than one core. I’d be interested to
>> know if this is related. Here’s the benchmark code :
>> 
>> https://github.com/DexterLagan/benchmark
> 
> Beware that (processor-count) returns the number of HT-cores, so your
> v1.3 is actually requesting twice the number of threads as there are
> HTs. At least on Linux this is the case (checked right now).
> 
> Interesting idea... 16 threads:
> 
> $ time racket crash.rkt -d 4
> SIGSEGV MAPERR si_code 1 fault on addr (nil)
> Aborted (core dumped)
> 
> real6m37,579s
> user32m55,192s
> sys0m35,124s
> 
> So that is consistent to what I see.
> 
> Have you tried using future-visualizer[1] for checking why it uses only
> single CPU thread? Last summer I spent quite some time with it to help
> me find the right futures usage patterns that actually enable the
> speculative computation in parallel. Usually if your code is too deep
> and keeps allocating "something" each frame, it goes back to the runtime
> thread for each allocation.
> 
> 
> Cheers,
> Dominik
> 
> [1] https://docs.racket-lang.org/future-visualizer/index.html
> 
>> 
>> Dex
>> 
>>> On May 2, 2020, at 1:56 PM, Dominik Pantůček
>>>  wrote:
>>> 
>>> Hello fellow Racketeers,
>>> 
>>> during my research into how Racket can be used as generic software
>>> rendering platform, I've hit some limits of Racket's (native) thread
>>> handling. Once I started getting SIGSEGVs, I strongly suspected I am
>>> doing too much unsafe operations - and to be honest, that was true.
>>> There was one off-by-one memory access :).
>>> 
>>> But that was easy to resolve - I just switched to safe/contracted
>>> versions of everything and found and fixed the bug. But I still got
>>> occasional SIGSEGV. So I dug even deeper (during last two months I've
>>> read most of the JIT inlining code) than before and noticed that the
>>> crashes disappear when I refrain from calling bytes-set! in parallel
>>> using futures.
>>> 
>>> So I started creating a minimal-crashing-example. At first, I failed
>>> miserably. Just filling a byte array over and over again, I was unable
>>> to reproduce the crash. But then I realized, that in my application,
>>> threads come to play and that might be the case. And suddenly, creating
>>> MCE was really easy:
>>> 
>>> Create new eventspace using parameterize/make-eventspace, put the actual
>>> code in application thread (thread ...) and make the main thread wait
>>> for this application thread using thread-wait. Before starting the
>>> application thread, I create a simple window, bitmap and a canvas, that
>>> I keep redrawing using refresh-now after each iteration. Funny thing is,
>>> now it keeps crashing even without actually modifying the bitmap in
>>> question. All I need to do is to mess with some byte array in 8 threads.
>>> Sometimes it takes a minute on my computer before it crashes, sometimes
>>> it needs more, but it eventually crashes pretty consistently.
>>> 
>>> And it is just 60 lines of code:
>>> 
>>> #lang racket/gui
>>> 
>>> (require racket/future racket/fixnum racket/cmdline)
>>> 
>>> (define width 800)
>>> (define height 600)
>>> 
>>> (define framebuffer (make-fxvector (* width height)))
>>> (define pixels (make-bytes (* width height 4)))
>>> 
>>> (define max-depth 0)
>>> 
>>> (command-line
>>> #:once-each
>>> (("-d" "--depth") d "Futures binary partitioning depth" (set! max-depth
>>> (string->number d
>>> 
>>> (file-stream-buffer-mode (current-output-port) 'none)
>>> 
>>> (parameterize ((current-eventspace (make-eventspace)))
>>>  (define win (new frame%
>>>   (label "test")
>>> 

Re: [racket-users] Futures + threads SIGSEGV

[Dexter Lagan]

Hello,

  I’ve been getting inconsistent results as well. A while ago I made a 
benchmark based on a parallel spectral norm computation. The benchmark works 
fine on Windows on most systems and uses all cores, but crashes randomly on 
other systems. I haven’t been able to figure out why. On Linux it doesn’t seem 
to use more than one core. I’d be interested to know if this is related. Here’s 
the benchmark code :

https://github.com/DexterLagan/benchmark

Dex

> On May 2, 2020, at 1:56 PM, Dominik Pantůček  
> wrote:
> 
> Hello fellow Racketeers,
> 
> during my research into how Racket can be used as generic software
> rendering platform, I've hit some limits of Racket's (native) thread
> handling. Once I started getting SIGSEGVs, I strongly suspected I am
> doing too much unsafe operations - and to be honest, that was true.
> There was one off-by-one memory access :).
> 
> But that was easy to resolve - I just switched to safe/contracted
> versions of everything and found and fixed the bug. But I still got
> occasional SIGSEGV. So I dug even deeper (during last two months I've
> read most of the JIT inlining code) than before and noticed that the
> crashes disappear when I refrain from calling bytes-set! in parallel
> using futures.
> 
> So I started creating a minimal-crashing-example. At first, I failed
> miserably. Just filling a byte array over and over again, I was unable
> to reproduce the crash. But then I realized, that in my application,
> threads come to play and that might be the case. And suddenly, creating
> MCE was really easy:
> 
> Create new eventspace using parameterize/make-eventspace, put the actual
> code in application thread (thread ...) and make the main thread wait
> for this application thread using thread-wait. Before starting the
> application thread, I create a simple window, bitmap and a canvas, that
> I keep redrawing using refresh-now after each iteration. Funny thing is,
> now it keeps crashing even without actually modifying the bitmap in
> question. All I need to do is to mess with some byte array in 8 threads.
> Sometimes it takes a minute on my computer before it crashes, sometimes
> it needs more, but it eventually crashes pretty consistently.
> 
> And it is just 60 lines of code:
> 
> #lang racket/gui
> 
> (require racket/future racket/fixnum racket/cmdline)
> 
> (define width 800)
> (define height 600)
> 
> (define framebuffer (make-fxvector (* width height)))
> (define pixels (make-bytes (* width height 4)))
> 
> (define max-depth 0)
> 
> (command-line
> #:once-each
> (("-d" "--depth") d "Futures binary partitioning depth" (set! max-depth
> (string->number d
> 
> (file-stream-buffer-mode (current-output-port) 'none)
> 
> (parameterize ((current-eventspace (make-eventspace)))
>  (define win (new frame%
>   (label "test")
>   (width width)
>   (height height)))
>  (define bmp (make-bitmap width height))
>  (define canvas (new canvas%
>  (parent win)
>  (paint-callback
>   (λ (c dc)
> (send dc draw-bitmap bmp 0 0)))
>  ))
> 
>  (define (single-run)
>(define (do-bflip start end (depth 0))
>  (cond ((fx< depth max-depth)
> (define cnt (fx- end start))
> (define cnt2 (fxrshift cnt 1))
> (define mid (fx+ start cnt2))
> (let ((f (future
>   (λ ()
> (do-bflip start mid (fx+ depth 1))
>   (do-bflip mid end (fx+ depth 1))
>   (touch f)))
>(else
> (for ((i (in-range start end)))
>   (define c (fxvector-ref framebuffer i))
>   (bytes-set! pixels (+ (* i 4) 0) #xff)
>   (bytes-set! pixels (+ (* i 4) 1) (fxand (fxrshift c 16)
> #xff))
>   (bytes-set! pixels (+ (* i 4) 2) (fxand (fxrshift c 8) #xff))
>   (bytes-set! pixels (+ (* i 4) 3) (fxand c #xff))
>(do-bflip 0 (* width height))
>(send canvas refresh-now))
> (send win show #t)
> 
>  (define appthread
>(thread
> (λ ()
>   (let loop ()
> (single-run)
> (loop)
>  (thread-wait appthread))
> 
> Note: the code is deliberately de-optimized to highlight the problem.
> Not even mentioning CPU cache coherence here
> 
> Running this from command-line, I can adjust the number of threads.
> Running with 8 threads:
> 
> $ time racket crash.rkt -d 3
> SIGSEGV MAPERR si_code 1 fault on addr (nil)
> Aborted (core dumped)
> 
> real1m18,162s
> user7m11,936s
> sys0m3,832s
> $ time racket crash.rkt -d 3
> SIGSEGV MAPERR si_code 1 fault on addr (nil)
> Aborted (core dumped)
> 
> real3m44,005s
> user20m10,920s
> sys0m11,702s
> $ time racket crash.rkt -d 3
> SIGSEGV MAPERR si_code 1 fault on addr (nil)
> Aborted (core dumped)
> 
> real2m1,650s
> user10m58,392s
> sys0m6,445s
> $ time racket crash.rkt -d 3
> 

Re: [racket-users] Reducing parentheses without language damage.

[Dexter Lagan]

  For the sake of discussion, here’s a long rant:

  I might have a very uninformed opinion here, but wouldn’t having significant 
white space and no scope-defining character amount to multiple spaces and line 
feeds being part of the syntax? The next best thing being, allowing semicolons 
in place of line feeds. I’m no language designer, so let me try to give you my 
perspective as an average programmer:

  I find editing Python and Haskell a pain, because of white spaces. I can’t 
count the times I got that dreaded ‘invalid indentation’ error, because I’m 
editing code with a different editor on a different system. I also had to 
reformat entire programs after somebody saved using the incorrect tab setting, 
and I avoid Python because of this. Yet I haven’t heard this complaint from 
Python programmers, so I always believed I was just too dumb.

  I haven’t seen a better solution than s-expr to make expressions and scope 
ultra-visible and easy to manipulate. Yet s-expressions still bring their own 
requirements for comfortable editing: most people still require a specialized 
editor or a plugin for lisps. I fact, is there any language that doesn’t 
require some sort of plugin or specialized editor to be attractive to new 
programmers? Thinking of it, isn’t the IDE almost as important as the syntax or 
the language these days? Some JavaScript programmers can’t work without VSCode, 
scope-sensitive autocomplete, a linter and god knows how many other plugins. 
PHP programmers also feel naked without a fancy IDE and a host of plugins. I 
keep hearing people complain about x or y language because it doesn’t have a 
good editor, IDE or plugin for VSCode. Globally, people use more and more tools 
to program in the same languages.

  That’s what turned me into a sort of ‘digital minimalist’. I take comfort in 
not being dependant on anything other than a compiler/interpreter and a simple 
editor I can whip out of any system in seconds. I think there’s value in 
reducing our dependencies, including on tools, editors, IDEs and plugins. That 
being said, I love DrRacket and its facilities, also because it’s 
self-contained and bundled with Racket. One less thing to install.

  These are the considerations I’d take in account when thinking of a new 
syntax. Still, like I said before, I’m excited by the fact that the Racket team 
is looking for a solution to this problem, and I’ll be the first to applaud a 
way to keep the next Racket expressive and powerful, while making it more 
attractive to people used to more familiar syntax. Parentheses are, and always 
will be a barrier to entry for potential Racket adopters, and this is no small 
matter. I think Julia is a good example of the right balance between simple, 
attractive syntax and power. Are there downsides to their approach?

Cheers,

Dex

> On May 2, 2020, at 2:12 AM, George Neuner  wrote:
> 
>  
> On 5/1/2020 4:35 PM, Dexter Lagan wrote:
>>   Is there value in Rob Pike’s comment on avoiding significant white space 
>> in the Go language?
>> 
>> “We have had extensive experience tracking down build and test failures 
>> caused by cross-language builds where a Python snippet embedded in another 
>> language, for instance through a SWIG invocation, is subtly and invisibly 
>> broken by a change in the indentation of the surrounding code.” — Rob Pike, 
>> 2012
> 
> I'm not really sure what Pike is getting at there:  I haven't used SWIG 
> myself, but if I understand it correctly, Python code would have to be in a 
> module to be called from "other" language code.  If so, I don't see how the 
> indentation of the "other" code could affect the Python.
> 
> That aside: 
> 
> Even working only in Python, programmers routinely get tripped up by 
> copy/paste errors - so it is evident that indentation sensitivity is not any 
> real solution to scope related logic problems.  It might [for some 
> definition] help newbies identify stupid errors, but I believe that even 
> moderately experienced programmers are more hindered than helped by it.
> 
> 
>>   I personally dislike white space and prefer either mustaches or 
>> parenthesis, just so I know my code will still work if line feeds are 
>> stripped somehow, or that some piece of code is embedded or quoted in 
>> another language, which is what I gather Rob was talking about. However, 
>> Haskell and Python people don’t seem to mind, and if it saves us more 
>> keystrokes while keeping expressiveness, why not?
> 
> Well, few people use Haskell, so I would discount it as a data point.  Even 
> so, one of the tutorials includes this interesting tidbit:
> 
> With good text editor, programming is fun. Of course, you can get along with 
> simplistic
> editor capable of just cut-n-paste, but good editor is capable of doing most 
>

Re: [racket-users] Reducing parentheses without language damage.

[Dexter Lagan]

  Is there value in Rob Pike’s comment on avoiding significant white space in 
the Go language?

“We have had extensive experience tracking down build and test failures caused 
by cross-language builds where a Python snippet embedded in another language, 
for instance through a SWIG invocation, is subtly and invisibly broken by a 
change in the indentation of the surrounding code.” — Rob Pike, 2012

  I personally dislike white space and prefer either mustaches or parenthesis, 
just so I know my code will still work if line feeds are stripped somehow, or 
that some piece of code is embedded or quoted in another language, which is 
what I gather Rob was talking about. However, Haskell and Python people don’t 
seem to mind, and if it saves us more keystrokes while keeping expressiveness, 
why not?

Dex

> On May 1, 2020, at 10:20 PM, George Neuner  wrote:
> 
> 
> I haven't followed all the discussion regarding a potential successor to 
> Racket.  AFAIHS, no one actually has suggested a required indentation scheme 
> ala Python, but since source indentation (and formatting in general) 
> currently is under discussion, I wanted to make known my feelings on the 
> matter.
> 
> If you don't feel strongly about source indentation, you can skip this.
> 
> George
> 
> 
>> On 5/1/2020 1:19 PM, Christopher Lemmer Webber wrote:
>> Sorawee Porncharoenwase writes:
>> 
>> >
>> >> I hate being at the mercy of whatever editor I'm stuck using.
>> >
>> >
>> > I agree with this in principle, but in practice, it's really a matter of
>> > what mainstream editors support. Editors in the past don't universally
>> > support automatic indentation, and I could imagine a criticism like
>> > "Indentation sucks, because I hate being at the mercy of whatever editor
>> > I'm stuck using." But now, automatic indentation is universal, and the
>> > criticism goes away.
>> 
>> You don't even need to imagine it... when Python was taking off, one of
>> the biggest arguments was that it forced people to learn to do
>> reasonable indentation.  Doesn't seem like as much of a good argument
>> now as I thought it was then, and that's partly because most code is
>> indented fine these days due to, as you say, good IDE support.
> 
> The indentation requirement - aka "significant whitespace" - is one of the 
> main things I dislike about Python [the other is its comprehension syntax].  
> An argument certainly can be made for advocating a readable coding style ... 
> but on principle I disagree with a language *requiring* any particular style.
> 
> 
> As it happens, I am old enough to remember when Fortran required very 
> particular formatting: worse even than Python, Fortran was designed around 
> 80-column punch cards, and for a VERY long time it was necessary that 
> particular things be placed in particular columns ... else the statement 
> would not compile.
> 
> see https://web.stanford.edu/class/me200c/tutorial_77/03_basics.html
> 
> Fortran's adherence to rigid source formatting really did not simplify the 
> compiler much at all  (actually an argument can be made that it unnecessarily 
> complicated recognizing certain constructs). And if it ever helped, it wasn't 
> necessary for long - by 1962 [Fortran was introduced in 1959] compilers were 
> able to deal with free form code.  The first version of Lisp [1961] was on 
> punch cards as well, but from the beginning Lisp never had column based 
> restrictions on source format.
> 
> Fortran ... still recognizes the old style, but ... no longer requires column 
> based formatting.  Free form source has been supported by compilers since 
> Fortran90.
> 
> Historically, there have been a handful of (higher level, non-assembly) 
> languages that had odd source formatting requirements, but none were as 
> onerous as Fortran, and none of them survived very long.  But just as Fortran 
> finally was giving up on the idea, Python came along to revive it.  [Python 
> began at about the same time Fortran90 was in committee.]
> 
> 
> Forcing programmers to do menial tasks like configuring editors to certain 
> modes [spaces vs tabs], and to manually count spaces when corresponding 
> scoped lines are too far apart to eyeball the vertical alignment is simply 
> counterproductive - there are plenty of more important things that 
> programmers should be worrying about. Programming editors having language 
> structural awareness have been around since the 80's ... there is no reason 
> ever to bake such things as indentation requirements into the language.
> 
> Just my 2 cents.
> 
> -- 
> 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/e180703e-6e2e-ea6b-d918-b46ff4eebb07%40comcast.net.

-- 
You received this message because you are 

Re: [racket-users] Questions about working on DrRacket and gui

[Dexter Lagan]

  Thanks I’ll look into this.

Dex

> On May 1, 2020, at 5:03 PM, Sorawee Porncharoenwase  
> wrote:
> 
> 
> Sam just suggested me in the other email thread that a much easier way to do 
> things is to download and install Minimal Racket, then install DrRacket from 
> source.
> 
>> On Fri, May 1, 2020 at 7:59 AM Dexter Lagan  wrote:
>> Hi,
>> 
>>   I apologize in advance if my questions are naïve or have been asked 
>> previously. I read the 'Building Racket from Source' guide and couldn't find 
>> answers to some specific questions. I'm new to Git.
>> 
>>   I'd like to download DrRacket's source and profile it, say to improve 
>> scrolling performance or track this post-startup lock-up :
>> - Do I need to download the entire Racket tree in order to build DrRacket?
>> - Is the DrRacket's built-in profiler solid enough to handle profiling 
>> DrRacket itself?
>> - Modules in DrRacket's repo don't always have very telling names. Is there 
>> a document describing what each module does?
>> - If I make a change to a source file on my system, yet somebody else 
>> modifies the same file on their local system. Say both of our changes are 
>> accepted by whoever manages commits, how will accepted changes to the code 
>> merged?
>> 
>>   Also, say I have a suggestion regarding how DrRacket handles compiling 
>> standalone executables, do I still need to create an issue on its Github? 
>> For work I compile to standalone all day long, and I really wish DrRacket 
>> didn't zip the resulting file (it would be better to have the .exe file in 
>> an automatically created /bin or /output folder). Zipping the file takes 
>> time, and I have to unzip it each time, which takes more time, this piles up 
>> when done every few minutes, all day long. I could use raco exe, but I'd 
>> rather stay in DrRacket, and I'm sure many people would rather have the 
>> default behavior to not zip, just to have single responsibility on the 
>> compile function.
>> 
>>  One last questions: I have encountered differences in the behavior of 
>> macros between the REPL, a launcher and a standalone executable for 
>> distribution. Is there a document outlining the deeper differences between 
>> these three ways of executing Racket code?
>> 
>> Have a great weekend, wherever you're confined,
>> 
>> Dexter
>> -- 
>> 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/CACUENr%2B%3Drr87rehZHQyDX%2BusXBZHdCY_46-pkKTuotj6HRwffg%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/078809BB-8EA9-4C2A-B8C4-DD32FEADFF62%40gmail.com.

[racket-users] Questions about working on DrRacket and gui

[Dexter Lagan]

Hi,

  I apologize in advance if my questions are naïve or have been asked
previously. I read the 'Building Racket from Source' guide and couldn't
find answers to some specific questions. I'm new to Git.

  I'd like to download DrRacket's source and profile it, say to improve
scrolling performance or track this post-startup lock-up :
- Do I need to download the entire Racket tree in order to build DrRacket?
- Is the DrRacket's built-in profiler solid enough to handle profiling
DrRacket itself?
- Modules in DrRacket's repo don't always have very telling names. Is there
a document describing what each module does?
- If I make a change to a source file on my system, yet somebody else
modifies the same file on their local system. Say both of our changes are
accepted by whoever manages commits, how will accepted changes to the code
merged?

  Also, say I have a suggestion regarding how DrRacket handles compiling
standalone executables, do I still need to create an issue on its Github?
For work I compile to standalone all day long, and I really wish DrRacket
didn't zip the resulting file (it would be better to have the .exe file in
an automatically created /bin or /output folder). Zipping the file takes
time, and I have to unzip it each time, which takes more time, this piles
up when done every few minutes, all day long. I could use raco exe, but I'd
rather stay in DrRacket, and I'm sure many people would rather have the
default behavior to not zip, just to have single responsibility on the
compile function.

 One last questions: I have encountered differences in the behavior of
macros between the REPL, a launcher and a standalone executable for
distribution. Is there a document outlining the deeper differences between
these three ways of executing Racket code?

Have a great weekend, wherever you're confined,

Dexter

-- 
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/CACUENr%2B%3Drr87rehZHQyDX%2BusXBZHdCY_46-pkKTuotj6HRwffg%40mail.gmail.com.

Re: [racket-users] Reducing parentheses without language damage.

[Dexter Lagan]

  No it’s not, I checked again and couldn’t reproduce the problem. Please 
ignore my earlier comment.

  I’ve been tracking a bug that causes the colouring of a part of the code as 
comment and disable parenthesis handling, and since I switch debugging on and 
off often, I assumed it was related. I’ll dig further and post the issue if I 
can find out what triggers it.

Dex

> On Apr 30, 2020, at 10:06 PM, Stephen De Gabrielle  
> wrote:
> 
> 
> 
> 
>> On Thu, 30 Apr 2020 at 20:01, Hendrik Boom  wrote:
>> [...]
>> > Also is there a programming editor that *won't* do parenthesis matching?
>> 
>> Evidently the Racket editor whan debugging is disabled,
> 
> I’m not sure that’s true.
> 
> Kind regards
> Stephen
> 
> -- 
> 
> -- 
> 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-K_AbF4jmakuSixjnY_rNwPCqYgrd-JSWOrKFjash1Cvg%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/E7008AC4-B012-4686-9244-93378E990C46%40gmail.com.

Re: [racket-users] on reducing barriers in the Racket community

[Dexter Lagan]

  I put my foot in my mouth again, it's working. I must have had something
else disabled. I clearly remember not being able to make the cursor 'jump'
around expressions.

Dex

On Thu, Apr 30, 2020 at 9:16 PM Sorawee Porncharoenwase <
sorawee.pw...@gmail.com> wrote:

> I have debugging disabled, but my parenthesis highlighting is NOT
> disabled. Are we talking about the same parenthesis highlighting? Can you
> attach the screenshot of this "parenthesis highlighting is also disabled"
> to the mailing list?
>
> On Thu, Apr 30, 2020 at 12:36 AM Dexter Lagan 
> wrote:
>
>>   There’s one thing I noticed: if debugging is disabled, then parenthesis
>> highlighting is also disabled (as well as other visual aids, if I remember
>> well?). The editor also feels faster because of this, but navigating
>> parentheses becomes slightly more tedious without it.
>>
>> Dex
>>
>> On Apr 25, 2020, at 3:25 PM, sleepnova  wrote:
>>
>> 
>> That may help to reduce misimpression. And plus, maybe append some
>> message to error message to inform user that they can turn on errortrace if
>> they need more detailed debugging information, when errortrace doesn't
>> enabled.
>>
>> To be clarify, what you mentioned is "Preserve errortrace" option, what
>> about "Debugging" option, is it a must enabled option in a non-debugging
>> run?
>>
>> <截圖 2020-04-25 下午9.22.20.png>
>>
>>
>> Sorawee Porncharoenwase  於 2020年4月25日 週六
>> 下午8:17寫道：
>>
>>> It could go either way, no? I've also heard a lot of people complaining
>>> that debugging Racket programs is difficult because the stack trace is not
>>> useful, and this is because they use the command-line version which doesn't
>>> have errortrace enabled (by default).
>>>
>>> Perhaps what you really are complaining is that the option to
>>> enable/disable errortrace is not easily discoverable. Would it help if at:
>>>
>>> 
>>>
>>>
>>> the text is changed from `racket, with debugging` to `racket, with
>>> debugging (slower)`. And the texts are linkified so that when `racket` is
>>> clicked, it leads you to the non-detailed language setting, and when `with
>>> debugging (slower)` is clicked, it leads you to the detailed language
>>> setting?
>>>
>>> On Sat, Apr 25, 2020 at 3:51 AM Liwei Chou  wrote:
>>>
>>>> Thanks Dexter,
>>>>
>>>> Yes, now I know it’s due to the debugging and tracing configuration.
>>>> After turn off debugging and profiling, it becomes.
>>>>
>>>> cpu time: 20 real time: 20 gc time: 0
>>>>
>>>> If disable Preserve stacktrace also, I got.
>>>>
>>>> cpu time: 7 real time: 7 gc time: 0
>>>>
>>>> Which is pretty decent, 16x acceleration.
>>>>
>>>> It's not a problem for me now. However, this behavior may give some new
>>>> users the wrong impression that the language may not be very efficient,
>>>> which may make some people choose not to continue trying it.
>>>>
>>>> From the perspective of increasing adoption and reducing barriers, it's
>>>> not a good thing.
>>>>
>>>> If Racket team can consider making normal run and debug run using
>>>> different default settings, which conventional development environments
>>>> usually do, that can easily solve this problem.
>>>>
>>>> Dexter Lagan於 2020年4月25日星期六 UTC+8下午5時17分31秒寫道：
>>>>>
>>>>> Hi Liwei,
>>>>>
>>>>>   I believe disabling debugging and tracing does accelerate the
>>>>> evaluation quite a bit from inside DrRacket. On my system, it seems to be
>>>>> running my code at the same speed as the main racket binary.
>>>>>
>>>>> 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+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/racket-users/cb5e4fa5-2766-4242-aff5-8933bee637c6%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/racket-users/cb5e4fa5-2766-4242-aff5-8933bee637c6%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
&g

Re: [racket-users] Re: contributing fixes to documentation

[Dexter Lagan]

  Thanks, this guide is great. I'll make sure I fix whatever problem I find
when I scour the docs. I do have a question however: say I find a typo in a
function definition, is there any part of the doc that is automatically
generated, and should not be updated, or updated with specific attention?

Dex

On Thu, Apr 30, 2020 at 11:55 AM Stephen De Gabrielle <
spdegabrie...@gmail.com> wrote:

> I'd forgotten the tutorial to contributing - someone kindly reminded me
> recently
> https://blog.racket-lang.org/2017/09/tutorial-contributing-to-racket.html
>
> This covers everything from fixing a typo to contributing to the racket
> language and the main distribution.
>
> it is worth the read!
>
> S
>
> On Thursday, April 30, 2020 at 10:49:33 AM UTC+1, Stephen De Gabrielle
> wrote:
>>
>> Yo Racketeers!
>>
>> Someone recently mentioned that is was tricky to update documentation. it
>> can be.
>> I thought I'd provide the steps I took to create a PR for the DrRacket
>> documentation in the hope that they are useful for others who see an issue
>> with documentation but finding locating the right scribble file a problem.
>>
>> In my case I wanted to create a PR to update the 'Extending DrRacket'
>> part of the DrRacket manual.
>>
>> My steps were
>> 1. click on the header of the heading in the manual, it opens up with a
>> little link on how to link to that section note the path:
>> scribblings/drracket/drracket.scrbl
>> Link to this section with
>>  @secref["extending-drracket"
>>  #:doc '(lib "scribblings/drracket/drracket.scrbl")]
>>
>> 2.  go to the DrRacket repo and look for something matching that path.
>> It was buried a little but I found it at
>> https://github.com/racket/drracket/blob/master/drracket/scribblings/drracket/drracket.scrbl
>>
>> 3. this scribble file is a list of includes, but I was able to match
>> https://docs.racket-lang.org/drracket/extending-drracket.html
>> with
>> @include-section["extending.scrbl"]
>>
>> 4. opening extending.scrbl I find the section I want to change
>>
>> https://github.com/racket/drracket/blob/master/drracket/scribblings/drracket/extending.scrbl
>>
>> #lang scribble/doc
>> @(require "common.rkt"
>> (for-label compiler/cm setup/parallel-build racket/promise))
>> @(define racodoc '(lib "scribblings/raco/raco.scrbl"))
>> @title[#:tag "extending-drracket"]{Extending DrRacket}
>> DrRacket supports two forms of extension to the programming
>> environment:
>> @itemize[
>> (gmail formatted this weirdly)
>>
>> 5. For simple changes (e.g. typos) you can just list in place and create
>> a PR
>>  - for more complex changes you will need to fork the repo and rebuild
>> the scribble to ensure it works before submitting the PR. e.g
>> https://github.com/racket/drracket/pull/372
>>
>> 6. if you run into trouble ask here on racket-users, or on the Racket
>> slack - there are many helpful racketeers out there.
>>
>> Kind regards
>>
>> Stephen
>>
>>
>> --
> 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/9e7438ef-0a7d-4660-a5ba-c2bb41928a3c%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/CACUENrKUjZ-ziAVVH1xt6z3Jn8MChwnvDGwEMg3XBs990H0Zuw%40mail.gmail.com.

Re: [racket-users] on reducing barriers in the Racket community

[Dexter Lagan]

  There’s one thing I noticed: if debugging is disabled, then parenthesis 
highlighting is also disabled (as well as other visual aids, if I remember 
well?). The editor also feels faster because of this, but navigating 
parentheses becomes slightly more tedious without it.

Dex

> On Apr 25, 2020, at 3:25 PM, sleepnova  wrote:
> 
> 
> That may help to reduce misimpression. And plus, maybe append some message to 
> error message to inform user that they can turn on errortrace if they need 
> more detailed debugging information, when errortrace doesn't enabled.
> 
> To be clarify, what you mentioned is "Preserve errortrace" option, what about 
> "Debugging" option, is it a must enabled option in a non-debugging run?
> 
> <截圖 2020-04-25 下午9.22.20.png>
> 
> 
> Sorawee Porncharoenwase  於 2020年4月25日 週六 下午8:17寫道：
>> It could go either way, no? I've also heard a lot of people complaining that 
>> debugging Racket programs is difficult because the stack trace is not 
>> useful, and this is because they use the command-line version which doesn't 
>> have errortrace enabled (by default). 
>> 
>> Perhaps what you really are complaining is that the option to enable/disable 
>> errortrace is not easily discoverable. Would it help if at:
>> 
>> 
>> 
>> 
>> the text is changed from `racket, with debugging` to `racket, with debugging 
>> (slower)`. And the texts are linkified so that when `racket` is clicked, it 
>> leads you to the non-detailed language setting, and when `with debugging 
>> (slower)` is clicked, it leads you to the detailed language setting?
>> 
>> On Sat, Apr 25, 2020 at 3:51 AM Liwei Chou  wrote:
>>> Thanks Dexter,
>>> 
>>> Yes, now I know it’s due to the debugging and tracing configuration. After 
>>> turn off debugging and profiling, it becomes.
>>> 
>>> cpu time: 20 real time: 20 gc time: 0
>>> 
>>> If disable Preserve stacktrace also, I got.
>>> 
>>> cpu time: 7 real time: 7 gc time: 0
>>> 
>>> Which is pretty decent, 16x acceleration.
>>> 
>>> It's not a problem for me now. However, this behavior may give some new 
>>> users the wrong impression that the language may not be very efficient, 
>>> which may make some people choose not to continue trying it.
>>> 
>>> From the perspective of increasing adoption and reducing barriers, it's not 
>>> a good thing.
>>> 
>>> If Racket team can consider making normal run and debug run using different 
>>> default settings, which conventional development environments usually do, 
>>> that can easily solve this problem.
>>> 
>>> Dexter Lagan於 2020年4月25日星期六 UTC+8下午5時17分31秒寫道：
>>>> 
>>>> Hi Liwei,
>>>> 
>>>>   I believe disabling debugging and tracing does accelerate the evaluation 
>>>> quite a bit from inside DrRacket. On my system, it seems to be running my 
>>>> code at the same speed as the main racket binary.
>>>> 
>>>> 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+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/racket-users/cb5e4fa5-2766-4242-aff5-8933bee637c6%40googlegroups.com.
> 
> 
> -- 
> - sleepnova
> 呼叫小黃創辦人 & CEO
> -- 
> 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/CABa2-7O1cv_sOrGRWxoHetdwDLiKLSOpZdt8T3YPj4yQQome7w%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/71148F23-E424-4580-8CAB-DC40AA0B5D47%40gmail.com.

Re: [racket-users] Rhombus project plan

[Dexter Lagan]

  I just read myself, I meant runtime errors, not compile-time errors. One big 
complain I hear from people used to compiled languages - when they first use 
dynamic and interpreter languages - is the idea of having errors occur at 
runtime, which ‘should’ have been picked up by the interpreter before runtime.

  I understand there’s a major trade off here, and there are things that are 
possible to do with interpreters that aren’t with compilers, and vice versa. 
What I was referring to, is a way to analyse further the source, to identify 
potential errors before they happen at runtime. I thought that’s what contracts 
and typing in general was supposed to catch, and I have yet to experiment with 
contracts in my code, in production. However I have encountered this problem 
many times :

(get-text-from-user ...) returns a string of #f.

  If I use the output of this function, I always run the risk of having the 
user click cancel, and get a contract error returned by the next function. So I 
always have to have something like

(unless result (exit 0))
...or something more involved to deal with the possibility of getting #f like:

(if result (do-something-with result)
   (display-error-and-do-something-else))

  Somehow I’ve always been surprised by the behaviour, and I wish there was a 
solution to this, apart from literally filling my code with checks (which is 
what I do now). If only there was a way to trace the possible output of 
functions against the permitted input of the next function in the chain 
(through continuation marks?), then maybe we could solve a piece of that 
runtime errors puzzle.

Dex

> On Apr 29, 2020, at 11:24 PM, Dexter Lagan  wrote:
> 
>   You’ve always been very inspiring to me. I’ll do my best to better the 
> docs if there’s a guide on how to do so. Bear with me, I have no background 
> in computer science and I don’t even know what a pull request is. I only 
> recently started using version control. I’ve always worked alone, until 
> recently - now I have to lead a team, and I can not longer escape the hard 
> stuff.
> 
>  I have a million questions, about Racket’s direction and symbolic 
> computation in general. I’ve been reading day and night on everything I 
> should have learned in comp-sci. 
> 
>  My dream is to find a solution to compile-time errors (through some kind of 
> analysis, maybe contracts already solve this?), and find a way to teach kids 
> how to program. Thanks for telling me about bootstrapworld. I’ll check it out.
> 
> Dex
> 
>>> On Apr 29, 2020, at 2:21 PM, Matthew Flatt  wrote:
>>> 
>>> At Wed, 29 Apr 2020 11:14:47 +0200, Dexter Lagan wrote:
>>> To the point: what would make Racket2 the ultimate tool (for me):
>>> Performance. Faster startup times, shorter execution times in general. 
>>> Optionally, a ‘lite’ version of Racket that compiles directly to no-deps 
>>> binaries, bypassing the JIT altogether, would be a game-changer. As far as 
>>> high levels languages with functional concepts and metaprogramming 
>>> facilities 
>>> that compiles to tiny, fast bins, Nim comes dangerously close, but it’s not 
>>> a 
>>> Lisp, and it’s not Racket.
>>> Production-quality, modern and fast GUI facilities. I’ll take properly 
>>> documented, complete Qt bindings. Racket/GUI is great for internal tools, 
>>> but 
>>> it quickly becomes slow, tedious and limited for more complex client-facing 
>>> UIs.
>>> One complete, commercial-grade Web framework, inspired from Symphony or 
>>> Laravel. Security and ease of use first, continuations later.
>>> Better documentation: Racket docs are aesthetically very pleasing, complete 
>>> and detailed. However some parts are still very obscure and lacking simple 
>>> examples (if only the part about Continuations included just one basic 
>>> example, such as a ‘return’ implementation, on the very first page. If only 
>>> the Macros documentation started with define-simple-macro and a few very 
>>> basic, practical examples. Instead we’re greeted with pattern-based macros, 
>>> which although very powerful, are very hard to comprehend for newcomers).
>> 
>> Which of these things will you be working on?
>> 
>> 
>>> I am well aware that what I’m wishing for isn’t necessarily compatible with 
>>> Racket’s intended public’s needs (comp-sci teachers and students? That’s 
>>> the 
>>> impression I’m getting). But Racket is the most advanced general purpose 
>>> programming tool I’ve ever seen. Wouldn’t it be a shame if it was limited 
>>> to 
>>> academic use?
>> 
>> https://www.youtube.com/watch?v=LN0qG-i1iT0=youtu.be
>> 
>> -

Re: [racket-users] Rhombus project plan

[Dexter Lagan]

  You’ve always been very inspiring to me. I’ll do my best to better the docs 
if there’s a guide on how to do so. Bear with me, I have no background in 
computer science and I don’t even know what a pull request is. I only recently 
started using version control. I’ve always worked alone, until recently - now I 
have to lead a team, and I can not longer escape the hard stuff.

  I have a million questions, about Racket’s direction and symbolic computation 
in general. I’ve been reading day and night on everything I should have learned 
in comp-sci. 

  My dream is to find a solution to compile-time errors (through some kind of 
analysis, maybe contracts already solve this?), and find a way to teach kids 
how to program. Thanks for telling me about bootstrapworld. I’ll check it out.

Dex

> On Apr 29, 2020, at 2:21 PM, Matthew Flatt  wrote:
> 
> At Wed, 29 Apr 2020 11:14:47 +0200, Dexter Lagan wrote:
>>  To the point: what would make Racket2 the ultimate tool (for me):
>> Performance. Faster startup times, shorter execution times in general. 
>> Optionally, a ‘lite’ version of Racket that compiles directly to no-deps 
>> binaries, bypassing the JIT altogether, would be a game-changer. As far as 
>> high levels languages with functional concepts and metaprogramming 
>> facilities 
>> that compiles to tiny, fast bins, Nim comes dangerously close, but it’s not 
>> a 
>> Lisp, and it’s not Racket.
>> Production-quality, modern and fast GUI facilities. I’ll take properly 
>> documented, complete Qt bindings. Racket/GUI is great for internal tools, 
>> but 
>> it quickly becomes slow, tedious and limited for more complex client-facing 
>> UIs.
>> One complete, commercial-grade Web framework, inspired from Symphony or 
>> Laravel. Security and ease of use first, continuations later.
>> Better documentation: Racket docs are aesthetically very pleasing, complete 
>> and detailed. However some parts are still very obscure and lacking simple 
>> examples (if only the part about Continuations included just one basic 
>> example, such as a ‘return’ implementation, on the very first page. If only 
>> the Macros documentation started with define-simple-macro and a few very 
>> basic, practical examples. Instead we’re greeted with pattern-based macros, 
>> which although very powerful, are very hard to comprehend for newcomers).
> 
> Which of these things will you be working on?
> 
> 
>>  I am well aware that what I’m wishing for isn’t necessarily compatible with 
>> Racket’s intended public’s needs (comp-sci teachers and students? That’s the 
>> impression I’m getting). But Racket is the most advanced general purpose 
>> programming tool I’ve ever seen. Wouldn’t it be a shame if it was limited to 
>> academic use?
> 
> https://www.youtube.com/watch?v=LN0qG-i1iT0=youtu.be
> 
> -- 
> 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/5ea97134.1c69fb81.8c167.2c68SMTPIN_ADDED_MISSING%40gmr-mx.google.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/99FC74E9-A31E-4D9A-AA82-2B393ED35A87%40gmail.com.

Re: [racket-users] Rhombus project plan

[Dexter Lagan]

  I’d like to help too, so if I understand this pull request correctly, there’s 
demand for a guide on how to update the docs? I was about to ask precisely 
that, how to contribute to the docs. If there’s JavaScript to make, I can take 
a look. I don’t use Slack, is there an alternative?

Cheers,

Dex

> On Apr 29, 2020, at 4:27 PM, Sam Tobin-Hochstadt  wrote:
> 
> Hi David,
> 
> If you ping me on Slack, I'll be happy to walk you through how to make
> changes to the docs. And maybe you can lend a hand to finally
> completing https://github.com/racket/racket/pull/874 which I think is
> mostly a matter of JavaScript programming now.
> 
> Sam
> 
>> On Wed, Apr 29, 2020 at 9:35 AM David Storrs  wrote:
>> 
>> 
>> 
>>> On Wed, Apr 29, 2020 at 8:21 AM Matthew Flatt  wrote:
>>> 
>>> At Wed, 29 Apr 2020 11:14:47 +0200, Dexter Lagan wrote:
>>>>  To the point: what would make Racket2 the ultimate tool (for me):
>>>> Performance. Faster startup times, shorter execution times in general.
>>>> Optionally, a ‘lite’ version of Racket that compiles directly to no-deps
>>>> binaries, bypassing the JIT altogether, would be a game-changer. As far as
>>>> high levels languages with functional concepts and metaprogramming 
>>>> facilities
>>>> that compiles to tiny, fast bins, Nim comes dangerously close, but it’s 
>>>> not a
>>>> Lisp, and it’s not Racket.
>>>> Production-quality, modern and fast GUI facilities. I’ll take properly
>>>> documented, complete Qt bindings. Racket/GUI is great for internal tools, 
>>>> but
>>>> it quickly becomes slow, tedious and limited for more complex client-facing
>>>> UIs.
>>>> One complete, commercial-grade Web framework, inspired from Symphony or
>>>> Laravel. Security and ease of use first, continuations later.
>>>> Better documentation: Racket docs are aesthetically very pleasing, complete
>>>> and detailed. However some parts are still very obscure and lacking simple
>>>> examples (if only the part about Continuations included just one basic
>>>> example, such as a ‘return’ implementation, on the very first page. If only
>>>> the Macros documentation started with define-simple-macro and a few very
>>>> basic, practical examples. Instead we’re greeted with pattern-based macros,
>>>> which although very powerful, are very hard to comprehend for newcomers).
>>> 
>>> Which of these things will you be working on?
>> 
>> 
>> I'll step up.
>> 
>> Matt, I need some help with Scribble and how to contribute to the Racket 
>> docs.  I'd be willing to pay for a couple hours of your time (or whomever 
>> else's has the skill/knowledge) to walk me through that.  After that I'll be 
>> happy to pitch in by offering documentation patches.  This will be a big 
>> help for me, since I'm finding myself having trouble writing docs for my own 
>> code.
>> 
>>> 
>>> 
>>> 
>>>>  I am well aware that what I’m wishing for isn’t necessarily compatible 
>>>> with
>>>> Racket’s intended public’s needs (comp-sci teachers and students? That’s 
>>>> the
>>>> impression I’m getting). But Racket is the most advanced general purpose
>>>> programming tool I’ve ever seen. Wouldn’t it be a shame if it was limited 
>>>> to
>>>> academic use?
>>> 
>>> https://www.youtube.com/watch?v=LN0qG-i1iT0=youtu.be
>>> 
>>> --
>>> 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/5ea97134.1c69fb81.8c167.2c68SMTPIN_ADDED_MISSING%40gmr-mx.google.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/CAE8gKoe%3D5XYkfveAKUy2b6iq7pfNJsZVr%3Djhh7G-8rszHrwfbQ%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/741E3460-796E-4DCC-B7D6-7B54CC7C031F%40gmail.com.

Re: [racket-users] Rhombus project plan

[Dexter Lagan]

Thanks so much for your reply, it's very nice to see another perspective. I
added specific comments below :

They say that Racket is slow. I would like to know who are "they".
>

  Same here, never had a problem, but I do understand there may be
requirements for real-time apps and system programming. Everything I said
about performance really should be put into the context of wider
acceptance. I don't look at benchmarks, but all of my colleagues do, and
that deeply saddens me. Being a better tool isn't necessarily just being a
faster tool, but performance attracts people and businesses.

  If there was two things I'd love to look at, performance-wise - and they
aren't related to Racket itself - it would be the 2-3s lock-up I get after
opening DrRacket. I can type a line of code, and everything locks up for a
few seconds before I can type again. It's nothing big, but it's so annoying
that I'm considering downloading the source tree and hack at it. The other
problem I'm encountering is the relatively slow scrolling / navigation,
again in DrRacket. I usually disable all the plugins, and sometimes even
debugging to get smoother performance. But Racket itself isn't slow at all.
Considering the power it provides, it's very fast.


> My experience is quite contrary to that. In the last three years we were
> forced to develop a few GUI tools used by our customers and there are no
> complains only against the tools using racket/gui. Yes, it is far from
> perfect - but it is the only thing that really behaves consistently
> across all three platforms we need to support (Linux, Mac, and ...
> Windows). Python+Qt and go+Qt are absolutely insupportable without a
> long list of per-platform/per-widget hacks. It might be that we are just
> hitting corner cases (actually that's pretty probably), yet with Racket
> there were no such hurdles.
>

  True, Racket's gui seems to cross over much better than most frameworks.
I use MrEd to make more complex GUIs, and so far the main limitation that
prevents me from using it for production (beyond tiny UIs for internal
tools) is the relatively limited listbox (I haven't figured out how to edit
cells or color text. But that's probably because I haven't dug the docs
enough, and I stopped looking when I read other people's similar complains
(for ex https://news.ycombinator.com/item?id=18048347)


>
> >   * One complete, commercial-grade Web framework, inspired from Symphony
> > or Laravel. Security and ease of use first, continuations later.
>
> And this is the part that made me actually hit the "Reply List" button.
> The good thing about mentioned PHP frameworks is only that anyone can
> start producing something with them without any prior experience. So
> right now we are encountering vulnerable and unmaintainable code
> anywhere we bump into some 3rd party "web application" we are hired to
> audit. With Racket - the entry barrier is really high, I agree. I
> actually spent many days getting through it - but once you pass the
> barrier, it really helps you write applications where you can focus on
> the actual functionality and let the libraries do the rest for you. And
> securing such application is almost trivial task. Yes, I have hit some
> corner cases here as well, but if you follow for example Bogdan's
> work[2][3], you'll see that there are solutions readily available. It is
> just necessary to read the docs and understand how the whole thing works.
>

  I couldn't get myself to go through the Web app tutorials. I ended up
writing a framework in NewLisp mainly made out of macros spitting out
Boostrap chunks.
https://github.com/dexterlagan/newstrap
I ran out of time when I hit multi-page navigation. That's when I
understood why everybody uses WP or Symphony. Time is money, and most
people who make a living out of Web apps/sites just don't have the time to
learn a new language. I asked some of the Web developers in my team to go
through the Racket Web tutorials, and all of them loved the power, but went
straight back to WordPress, where they feel at home surrounded by thousands
of plugins they can simply install and invoice to our clients. All of this
really annoys me, and I stay away from the Web side of things, just because
I can't stand the idea of making something, only to have to write it again
in two years using a different framework, in a different language. I think
that until there's a real commercial interest in making a competitive
framework in Racket, people will not use the language for the commercial
Web. Maybe it's better this way?


> I am not sure whether it is the best thing to start with
> define-simple-macro (if anything, I'd start with define-syntax-rule),
> but yes, more examples are always useful. Just write them and send a
> pull request to appropriate repository - I was pleasantly surprised when
> I first did this. All the Racketeers are super helpful when it comes to
> incorporating any improvements. (Thanks Ben!)
>

I didn't know it was that 

Re: [racket-users] Rhombus project plan

[Dexter Lagan]

  To be clear, I have never had a problem with Racket's performance, I'm
just thinking about ways to push for a wider adoption. Personally, anything
faster than Python is more than enough, especially with a good FFI. I'm
guessing a lot of people look at Rust and Go just because it's supposed to
be faster (than Java) and safer (than C). I strongly believe performance
depends on who's in front of the keyboard, not which compiler one uses.

Dex

On Wed, Apr 29, 2020 at 4:26 PM Dominik Pantůček <
dominik.pantu...@trustica.cz> wrote:

> Hi,
>
> I can't leave this without reaction...
>
> >
> >   To the point: what would make Racket2 the ultimate tool (for me):
> >
> >   * Performance. Faster startup times, shorter execution times in
> > general. Optionally, a ‘lite’ version of Racket that compiles
> > directly to no-deps binaries, bypassing the JIT altogether, would be
> > a game-changer. As far as high levels languages with functional
> > concepts and metaprogramming facilities that compiles to tiny, fast
> > bins, Nim comes dangerously close, but it’s not a Lisp, and it’s not
> > Racket.
>
> They say that Racket is slow. I would like to know who are "they".
>
> Racket can be surprising. For example - our GUI application on RPi has a
> start-up time of 24s... But when we compile it using `raco exe`, it goes
> down under 2s including some hardware setup the program does. Usually
> the slow startup times are caused by not using compiled byte-code.
>
> As I have mentioned a few times on this list, I am working on a side
> project right now which pushes Racket to its limits and let's say that
> the results might look impossible to many people. Full 3D rendering
> pipeline in pure Racket with no external libraries (no OpenGL, no SDL,
> just pure Racket) which can run at 60fps FullHD kind of beats the
> argument "Racket is slow". Racket can be REALLY fast. But you need to
> know how to achieve that (think contract boundaries, unsafe ops guarded
> by other mechanisms, ultimate parallelism support - yes, once you grasp
> futures to their full extent, you will see what performance gains you
> get virtually for free... see my sorting package[1])
>
> >   * Production-quality, modern and fast GUI facilities. I’ll take
> > properly documented, complete Qt bindings. Racket/GUI is great for
> > internal tools, but it quickly becomes slow, tedious and limited for
> > more complex client-facing UIs.
>
> My experience is quite contrary to that. In the last three years we were
> forced to develop a few GUI tools used by our customers and there are no
> complains only against the tools using racket/gui. Yes, it is far from
> perfect - but it is the only thing that really behaves consistently
> across all three platforms we need to support (Linux, Mac, and ...
> Windows). Python+Qt and go+Qt are absolutely insupportable without a
> long list of per-platform/per-widget hacks. It might be that we are just
> hitting corner cases (actually that's pretty probably), yet with Racket
> there were no such hurdles.
>
> >   * One complete, commercial-grade Web framework, inspired from Symphony
> > or Laravel. Security and ease of use first, continuations later.
>
> And this is the part that made me actually hit the "Reply List" button.
> The good thing about mentioned PHP frameworks is only that anyone can
> start producing something with them without any prior experience. So
> right now we are encountering vulnerable and unmaintainable code
> anywhere we bump into some 3rd party "web application" we are hired to
> audit. With Racket - the entry barrier is really high, I agree. I
> actually spent many days getting through it - but once you pass the
> barrier, it really helps you write applications where you can focus on
> the actual functionality and let the libraries do the rest for you. And
> securing such application is almost trivial task. Yes, I have hit some
> corner cases here as well, but if you follow for example Bogdan's
> work[2][3], you'll see that there are solutions readily available. It is
> just necessary to read the docs and understand how the whole thing works.
>
> >   * Better documentation: Racket docs are aesthetically very pleasing,
> > complete and detailed. However some parts are still very obscure and
> > lacking simple examples (if only the part about Continuations
> > included just one basic example, such as a ‘return’ implementation,
> > on the very first page. If only the Macros documentation started
> > with define-simple-macro and a few very basic, practical examples.
> > Instead we’re greeted with pattern-based macros, which although very
> > powerful, are very hard to comprehend for newcomers).
>
> I am not sure whether it is the best thing to start with
> define-simple-macro (if anything, I'd start with define-syntax-rule),
> but yes, more examples are always useful. Just write them and send a
> pull request to appropriate repository - I was 

Re: [racket-users] Rhombus project plan

[Dexter Lagan]

Hi all,

  I had written a few of my early thoughts about ‘racket2’, but after mulling 
over all this for a good year, I’d like to write something more definitive.

  My background: I started programming in BASIC on C64, followed by ADA, 
Pascal, C and macro-assembly on 8086 with MASM in the 90’s. My main hobby as a 
teen was to make demos in assembly, trying to squeeze every byte out of 64kb’s. 
Once my ‘low-level honeymoon’ phase faded, I went on a quest to find a high 
level language which would make me more productive and spare me the pain of 
having to explain every little detail directly to the CPU.

  Through work I have had to write a lot of JavaScript and PHP for the Web, 
plenty of C++, later replaced by C# for Windows-only projects. I played with Go 
for network services, toyed with Nim for automation, and later (painfully) 
learned Rust just to see if it was a viable Assembly substitute. I found Rust 
way more annoying to learn and use than Assembly. For me, Macro-Assembly + 
Win32 API is still the combo to beat to produce tiny, fast internal apps with 
no dependencies other than the OS. Over the years, my MASM macro library has 
grown so much that I can write an entire GUI app, in a language that looks like 
BASIC. Only it compiles to a few kilobytes, loads instantly and runs on any 
version of Windows since 95. If only I could do that in a cross-platform way... 
so for anything client-facing, x-platform on the desktop, I ended up joining 
the masses, and use C++/Qt.

  During my quest for the ultimate language, I played with Common Lisp, Haskell 
and OCaml, but only found true love with Scheme, which I found ‘purer’ and 
closer to my idea of a universal, ‘100-years language’. Racket only amplified 
my attraction to parentheses and multi-paradigm languages. I now use Racket 
every day to write internal automation tools, and have developed over 100 
command-line and GUI apps to do anything from file format conversion to video 
encoding/decoding, to financial analysis, to production asset tracking and 
packaging. Some of these tools span dozens of modules.

  To the point: what would make Racket2 the ultimate tool (for me):
Performance. Faster startup times, shorter execution times in general. 
Optionally, a ‘lite’ version of Racket that compiles directly to no-deps 
binaries, bypassing the JIT altogether, would be a game-changer. As far as high 
levels languages with functional concepts and metaprogramming facilities that 
compiles to tiny, fast bins, Nim comes dangerously close, but it’s not a Lisp, 
and it’s not Racket.
Production-quality, modern and fast GUI facilities. I’ll take properly 
documented, complete Qt bindings. Racket/GUI is great for internal tools, but 
it quickly becomes slow, tedious and limited for more complex client-facing UIs.
One complete, commercial-grade Web framework, inspired from Symphony or 
Laravel. Security and ease of use first, continuations later.
Better documentation: Racket docs are aesthetically very pleasing, complete and 
detailed. However some parts are still very obscure and lacking simple examples 
(if only the part about Continuations included just one basic example, such as 
a ‘return’ implementation, on the very first page. If only the Macros 
documentation started with define-simple-macro and a few very basic, practical 
examples. Instead we’re greeted with pattern-based macros, which although very 
powerful, are very hard to comprehend for newcomers).

  I am well aware that what I’m wishing for isn’t necessarily compatible with 
Racket’s intended public’s needs (comp-sci teachers and students? That’s the 
impression I’m getting). But Racket is the most advanced general purpose 
programming tool I’ve ever seen. Wouldn’t it be a shame if it was limited to 
academic use?

  Racket’s home page starts with ‘Racket - Solve Problems - Make Languages’. 
That very first line will scare anybody looking to just... write programs. Yes 
it is the entire point, but why not try and go back to basics with Racket2, and 
(also) tackle what really matters? Easily writing correct, fast and powerful 
programs that let us build tomorrow’s technologies.

Dex

> On Apr 28, 2020, at 5:23 PM, David Storrs  wrote:
> 
> 
> I'll throw this in simply so that it's part of this thread.  There's nothing 
> new here, so if you've seen my comments in earlier Racket2 threads then you 
> can skip this.
> 
> I've said before and continue to think that getting rid of the parenthesis 
> syntax is a major error.  It is inarguable that there are significant 
> advantages to parenthesis syntax -- to name a few: No need to memorize 
> precedence tables, ease of code serialization and composition, extreme 
> friendliness to parsers and generators.  So far as I've seen, no one has yet 
> presented an argument in support of eliminating parenthesis notation aside 
> from "My students will find it easier."  That may or may not be true but I 
> find myself unconvinced that it is the major 

Re: [racket-users] on reducing barriers in the Racket community

[Dexter Lagan]

Hi Liwei,

  I believe disabling debugging and tracing does accelerate the evaluation
quite a bit from inside DrRacket. On my system, it seems to be running my
code at the same speed as the main racket binary.

Dex

On Sat, Apr 25, 2020 at 7:35 AM Liwei Chou  wrote:

> Dexter Lagan於 2019年7月22日星期一 UTC+8下午4時52分42秒寫道
>>
>>   From my perspective the only barrier of entry to Racket is the
>> documentation: it is very clear, detailed and well-written, but to certain
>> of my students they can also be quite obscure, especially to those who
>> don’t have comp-sci background and those whose first language isn’t
>> English. The best example is the few pages about continuations. For quite a
>> while I could not understand what they were about from the Racket docs, and
>> it took quite a bit of web crawling to find meaningful examples of their
>> use. I also found the pages about macros lacking simple examples, and it’s
>> not until Beautiful Racket that I finally found very basic uses.
>>
>
> I agree with Dexter's opinion about documentation.
>
> I was reading "The Racket Guide" and found it too verbose for a newcomer
> with some programming experience. Then I discovered "Teach Yourself
> Racket", which is easy to read and I'm really enjoy.
>
> https://cs.uwaterloo.ca/~plragde/flaneries/TYR/
>
> I strongly recommend to include "Teach Yourself Racket" in the beginner's
> guide section of Racket 's official website. Or produce some more materials
> like that.
>
> Another aspect is about the tooling.
>
> Stephen helpful forwarded my feedback here.
> https://groups.google.com/d/msg/racket-users/PftpYnJt49c/2abSsQOYAgAJ
>
> I just quote here. A little bit about my journey as a newbie.
>
> When I started to learn Racket, due to the slow startup time and huge
> memory consumption of DrRacket, the overall impression given to me was that
> it’s very inefficient.
>
> After done some micro-benchmark, it did show that it did not perform well,
> and It did make me hesitate. *(barrier for beginners)*
> But I still want to try it, because I am very interested in its
> expressiveness. And I’m happy to find out it’s actually quite fast.
>
> The micro-benchmark I ran is.
>
> > (time (for ([i (in-range 1000)])
>   (void)))
> cpu time: 115 real time: 115 gc time: 0
>
> (Now I know it’s due to the debugging stuff...)
> Turn out in DrRacket, it’s about 16x slower than in Racket REPL.
>
> However, there isn't a convenient way to separate normal build/run from
> debug build/run, which conventional development environments usually do.
>
> My point is, the impression of this language is not very efficient, which
> is bad, and will scare some people out. Which is a barrier also. It would
> be better if not the case.
>
> --
> 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/140e226d-ed25-4aac-ae95-4f5f347bb3ba%40googlegroups.com
> <https://groups.google.com/d/msgid/racket-users/140e226d-ed25-4aac-ae95-4f5f347bb3ba%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CACUENr%2BPNW-6dzf04jWiP1TPXKD%2BkfbwEukf3%3DLVwqRcWq3_vA%40mail.gmail.com.

[racket-users] Re: Error on F6 after code incorrectly colored as comment, using Large Letters

[Dexter Lagan]

  Note that the affected code is correctly displayed after the F6 press 
error. DrRacket seems unaffected beyond the error.

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/ca661c89-872a-4ea0-af4f-80c93a3f0153%40googlegroups.com.

Re: [racket-users] Re: Racket2 possibilities

[Dexter Lagan]

  The second comment by slaymaker1907 is more progressive and closer to the 
truth no doubt. I merely meant to say that it does feel odd to take off parens 
off such a great scheme/lisp. But if there’s an elegant way to do it while 
maintaining all its power AND making it more approachable, all the better. If 
we could have the best of both worlds, Racket could appeal to a much wider 
audience.

  Like others have said, it also takes time for people to understand the 
potential, like it took me years to warm up to the idea of lisp in general, and 
months before I began really seeing a difference in my projects after picking 
Racket up. No matter what the outcome, this is exciting. 

  Simply contemplating the prospect of the evolution of such a powerful 
abstraction tool is exciting, and inspiring.

Dex

> On Jul 23, 2019, at 3:21 PM, Neil Van Dyke  wrote:
> 
> Dexter Lagan wrote on 7/23/19 3:32 AM:
>> Like the first HN comment said,
> 
> Currently 71 comments: https://news.ycombinator.com/item?id=20490423
> 
> FWIW, due to how the HN post was done, I don't know how representative the 
> comments are of professional developers.  The link was posted around 5pm 
> California time last night, and got 92 points, but had fallen off the front 
> page by early this morning Boston time.  (It could reappear this morning on 
> the front page, and get more representative comments, iff it organically gets 
> voted back up as Californians wake up.  But please no "brigade" voting, as 
> that's against the rules, bad form, and the admins can tell.)
> 
> -- 
> 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/6099bb78-7b2e-2749-0ed2-d19585a2f28b%40neilvandyke.org.

-- 
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/CD94ED47-9423-4348-9F97-560C4B9DAF69%40gmail.com.

Re: [racket-users] Re: Racket2 possibilities

[Dexter Lagan]

  Agreed, parentheses make manipulating code blocks a breeze. Also, I just 
realized I had confused Crystal with Julia in my initial rant. Made a fool of 
myself (again). I played with Julia when it reached 1.0 and liked the no-parens 
yet functional approach. It felt like a lisp in disguise, a bit like Python, 
but much cleaner. What I initially meant to say, apologies to Mr. King, is that 
a parent-less Racket2 would remind me of Julia. On the surface, at least! 
Crystal does have macros but that’s all it has in common with Julia and Racket.

  I did read the Honu paper and I agree: if there’s a way to transition, that’d 
be a very elegant one. Parentheses absolutely are a barrier of entry, and this 
would go a long way to make Racket less intimidating to non-lisp users. But is 
it worth the effort? Like the first HN comment said, ‘best way to break a good 
lisp is removing the parentheses’. I don’t think it’s that black, but 
there’s certainly some truth there.

Dex

> On Jul 23, 2019, at 12:17 AM, Zelphir Kaltstahl  
> wrote:
> 
> I just want to give one thought as input to this discussion and will admit, 
> that I did not read every (but some) of the posts above.
> 
> When I write code in Racket or Scheme, I mostly like the parentheses, as they 
> make writing the code easy. I can very easily select a block and move it 
> around, without introducing any syntax errors. I can also quickly see what 
> the scope of something is, what other expression it is in. I don't get these 
> things from languages without this many parentheses or without s-expression 
> syntax. I need my parentheses as markers for my cursor to quickly jump 
> around. It is the most pleasant code typing experience I've ever had. So when 
> considering to move away from parentheses, please also consider the burden 
> that those parentheses take away from the person writing the code. When I 
> edit for example Python code, things are not clear when moving around code. 
> This is worse in Python than in other languages, which at least have curly 
> braces (but usually some other annoying deficiencies). If there was a move 
> away from this many parentheses (read markers for my cursor), it would have 
> to provide equal editability, for it to be attractive to me. A design based 
> on indentation or something like that is not going to cut it for me. And what 
> else would be used as start and end markers for expressions? Wouldn't that in 
> essence just be another form of "parentheses", just looking different? How 
> would any editor know, where an expression starts and ends for easy selection 
> and moving around, if there were no such markers? So far I got no idea how 
> that could be done without introducing loads of new constraints about how you 
> can nest expressions into the language. So it beats me. Maybe my imagination 
> in this area is still somewhat limited.
> 
> Just my 2c.
> -- 
> 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/bf0b5dd1-8802-4c78-af7a-4231ae30ad60%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/6994654B-255A-4A0A-AF63-2702EFD67B75%40gmail.com.

Re: [racket-users] Racket2 possibilities

[Dexter Lagan]

  More specifically, I was referring to design goals for S-expressions:
-- generality: S-expressions should be good at representing arbitrary data. 
 -- readability: it should be easy for someone to examine and understand the 
structure of an S-expression. 
 -- economy: S-expressions should represent data compactly. 
 -- tranportability: S-expressions should be easy to transport over 
communication media (such as email) that are known to be less than perfect. 
 -- flexibility: S-expressions should make it relatively simple to modify and 
extend data structures. 
 -- canonicalization: it should be easy to produce a unique "canonical" form of 
an S-expression, for digital signature purposes. 
 -- efficiency: S-expressions should admit in-memory representations that allow 
efficient processing.

  These are just as relevant today as they were 50 years ago. Why change 
something that works?
Dex

> On Jul 22, 2019, at 4:15 PM, Alexis King  wrote:
> 
>> On Jul 22, 2019, at 14:16, Dexter Lagan  wrote:
>> 
>> A parens-less Racket2 would become Crystal.
> 
> 
> No it won’t. I am quite confident that Racket with any syntax will not be 
> like any other language that currently exists. What other language has 
> Racket’s advanced, robust compile-time metaprogramming support, its 
> higher-order contract system, its #lang mechanism (applied to great effect in 
> technologies like Scribble and Typed Racket), its 
> language-as-an-operating-system support for runtime sandboxing and 
> introspection, and its featureful and extensible FFI, among many other 
> things? To say that Racket is so defined by its syntax that it will cease to 
> be distinguishable from any other language if it is changed is absurd, and 
> it’s frankly insulting to all the people who have put so much effort into 
> every part of Racket.
> 
> If you believe Racket’s syntax is its most important feature, and that 
> everything else that sets it apart from other languages is pragmatically 
> irrelevant, I can’t really argue with that. I disagree, but it’s a matter of 
> opinion. That said, that kind of criticism isn’t very constructive, since I 
> don’t know how to interpret it beyond “I really like parentheses,” which is 
> hardly actionable or debatable.
> 
> I make no claims of representing the will of PLT, so I could be wrong, but I 
> think discussing what about s-expressions you like—and what about other 
> syntaxes you dislike—is on-topic and can produce constructive discussion. But 
> although it’s possible I didn’t read it carefully enough, the link you 
> provided doesn’t seem to have much in the way of that sort of explanation… it 
> seems to focus on how to most usefully take advantage of s-expressions, but 
> it doesn’t compare them to other formats.
> 

-- 
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/4F504C9A-9D20-4A79-B136-A7C0D0F7DABD%40gmail.com.

Re: [racket-users] Racket2 possibilities

[Dexter Lagan]

  Like I said, my limited experience makes my opinion of limited interest. I’m 
really only speaking from a practical standpoint, meaning, how a Python or Java 
programmer would see Racket. For example, I have no experience with language 
design, and I only used Racket and Scribble as-is. Most people I talk to use 
Python, Go or Java because of their tooling, and don’t complain about Go’s lack 
of generics.

  I entirely agree with you, Racket is much more than another Scheme, and 
reducing it to its syntax isn’t fair. However, coming from object and 
imperative languages, and looking at Racket’s surface, one wouldn’t suspect 
there’s so much under the hood without digging deeper. It’s quite difficult to 
explain why Racket is so powerful, precisely when people stop at the 
parentheses.

  All that to say, I apologize if I offended anyone, and only wish to suggest 
there might be ways to make Racket more appealing without reinventing the 
wheel. My personal wish list doesn’t contain anything more advanced than what’s 
already there: for my use, faster startup and a slightly more advanced GUI 
framework and editor would be enough.

  What I’m suggesting is that if we want to expose Racket to a broader 
audience, maybe we could start at the bottom and target the more basic users?

Dex

> On Jul 22, 2019, at 4:15 PM, Alexis King  wrote:
> 
>> On Jul 22, 2019, at 14:16, Dexter Lagan  wrote:
>> 
>> A parens-less Racket2 would become Crystal.
> 
> 
> No it won’t. I am quite confident that Racket with any syntax will not be 
> like any other language that currently exists. What other language has 
> Racket’s advanced, robust compile-time metaprogramming support, its 
> higher-order contract system, its #lang mechanism (applied to great effect in 
> technologies like Scribble and Typed Racket), its 
> language-as-an-operating-system support for runtime sandboxing and 
> introspection, and its featureful and extensible FFI, among many other 
> things? To say that Racket is so defined by its syntax that it will cease to 
> be distinguishable from any other language if it is changed is absurd, and 
> it’s frankly insulting to all the people who have put so much effort into 
> every part of Racket.
> 
> If you believe Racket’s syntax is its most important feature, and that 
> everything else that sets it apart from other languages is pragmatically 
> irrelevant, I can’t really argue with that. I disagree, but it’s a matter of 
> opinion. That said, that kind of criticism isn’t very constructive, since I 
> don’t know how to interpret it beyond “I really like parentheses,” which is 
> hardly actionable or debatable.
> 
> I make no claims of representing the will of PLT, so I could be wrong, but I 
> think discussing what about s-expressions you like—and what about other 
> syntaxes you dislike—is on-topic and can produce constructive discussion. But 
> although it’s possible I didn’t read it carefully enough, the link you 
> provided doesn’t seem to have much in the way of that sort of explanation… it 
> seems to focus on how to most usefully take advantage of s-expressions, but 
> it doesn’t compare them to other formats.
> 

-- 
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/B6F04E29-2123-410E-85EB-2E51FA554BC5%40gmail.com.

Re: [racket-users] on reducing barriers in the Racket community

[Dexter Lagan]

 First I’d like to express my immense gratitude for your contributions to the 
Racket community. Beautiful Racket greatly enhanced my understanding of 
language-oriented programming and macros in general.

TL;DR: Racket is the most inspiring language and ecosystem I have ever used. I 
use it not just because it does the job, but because I’m having an absolute 
blast writing code in it, something that hasn’t happened to me since uhh.. x86 
macro-assembler, or Pascal. All it needs is a simpler, localized, more 
practical intro page for existing programmers, and lots of promotion. Oh and 
maybe more speed, but it’s fast enough for my use.

  Now, the wall of text:

  From my perspective the only barrier of entry to Racket is the documentation: 
it is very clear, detailed and well-written, but to certain of my students they 
can also be quite obscure, especially to those who don’t have comp-sci 
background and those whose first language isn’t English. The best example is 
the few pages about continuations. For quite a while I could not understand 
what they were about from the Racket docs, and it took quite a bit of web 
crawling to find meaningful examples of their use. I also found the pages about 
macros lacking simple examples, and it’s not until Beautiful Racket that I 
finally found very basic uses.

 My opinion doesn’t count for much, but from my experience and the feedback I 
got from my employees and students, the main Racket site and docs is missing a 
very basic presentation of the language. Something really clear, concise, that 
does not use comp-sci or advanced vocabulary. The best example that comes to my 
mind is say, Go’s tour pages - in 20 languages. I understand there is Matthew’s 
Quick Introduction on the main page, but somehow I’m imagining a smaller, 
quicker ‘batteries included’, practical intro, for programmers familiar with 
other languages :

1) how to read/write from/to a file
2) how to display text on the screen
3) how to use conditionals and loops
4) how to write a function
5) how to compile functions into modules

  The hyperpolyglot.org/lisp ultra concise, parallel presentation of languages 
helped me more than once make sense of a new language. If only Racket had 
something similar for say, C, Java, Python and Racket. That way Python and Java 
programmers (perhaps Racket’s main target in the production env) could get a 
very quick sense of how things work.

  Localisation would also go a long way towards bringing Racket to the world. 
I’m currently in France and Racket is completely unknown here, yet sorely 
needed when I see the slow-motion Java disaster going on in every engineering 
school and every company.

Dex

> On Jul 21, 2019, at 10:46 PM, Matthew Butterick  wrote:
> 
> I'm not a member of Racket management. But I spend a lot of time using & 
> promoting Racket. Most recently, I taught the Beautiful Racket Workshop as 
> part of Racket Week 2019. 
> 
> I care a lot about Racket — the technology, but especially the human 
> community that makes it possible.
> 
> I've heard from a few people that events before, during, or after Racket Week 
> left them questioning Racket's commitment to making everyone feel welcome. 
> And to be honest, it wasn't the first time. 
> 
> This saddens me. It's not consistent with my own values. It's not what I want 
> Racket to stand for. I want everyone to feel welcome, wanted, and valued. 
> 
> In a nearby thread, Matthew Flatt talked about the importance of "reducing 
> barriers" in a technical sense. But it matters in a community sense too, of 
> course. 
> 
> If Racket is putting up social barriers — even unwittingly — that are 
> frustrating newcomers (or existing members) then we ought to be able to hear 
> this with an open mind & heart, and make adjustments. This is our duty as 
> empathetic, moral members of a community.
> 
> I'm not sure what I can do to improve this situation. I'm open to 
> suggestions. I can at least offer the following (I would rather risk looking 
> foolish than doing nothing):
> 
> 
> 1) If you've had an experience where the Racket community made you feel less 
> than totally welcomed, I invite you to add it to this thread, or contact me 
> privately. If you want details of your story shared, in some anonymized way, 
> I can do that. 
> 
> I recognize the irony of making this offer on the racket-users mailing list — 
> those who've had a bad experience are likely long gone. But I also know there 
> are people here who, like me, want to help make Racket better, even on rough 
> days.
> 
> 
> 2) Gently, I suggest that we work together to reduce the volatility of these 
> conversations. I know that some feel that these matters are better handled 
> away from the racket-users list. But this is counterproductive: it amounts to 
> saying that we should feel free to harvest the benefits of 
> Racket-the-technology while avoiding obligations to Racket-the-community. As 
> a matter of logic and ethics, I can't see 

Re: [racket-users] Re: Racket2 possibilities

[Dexter Lagan]

  I'm not going over why s-expressions are the way to go, mr. Rivest did it
best in his 1997 MIT doc:

https://people.csail.mit.edu/rivest/Sexp.txt

  A parens-less Racket2 would become Crystal. And I don't think we need yet
another functional parens-less language. We already have Haskell (hard to
read) and Crystal (weird half-commercial proposition that won't produce
binaries without major hacks). I say we keep the parens but make them even
less intrusive. Newlisp may be an ugly hack, but its simplified forms and
anaphoric vars are very nice to use. For example:

http://www.newlisp.org/downloads/newlisp_manual.html#if

Dex


On Mon, Jul 22, 2019 at 5:11 AM Ray Racine  wrote:

> Over the years I have loved Racket ... except for those parens ... if
> only.   I don't know when it happened but one day parens and I made a peace
> treaty, mind melded, became enlightened or just got tired of fighting, but
> right now I can't see a Racket without parens (s-exps). I have, in fact,
> grown rather fond of them.
>
> There is the bottom up approach to grow Racket2 from examples and snippets
> of syntax all to be compared and endlessly debated.
>
> Rhetorical mullings from the top down perspective is interesting.
>
> Assume a Racket2 will not be another Ruby or Python as Racket is a BIG
> language and could not be compressed down to a simplistic Python or simple
> lisp without parens Ruby.  And what is the point of Racket2 being a Ruby or
> Python wanna-be anyway?  Would the world move to a better Python/Ruby?
>
> Assume it will not be some variation of a Swift, Java or C#.
>
> If moving from s-exp to traditional in-fix and f(x,y,z) function
> application makes sense to seek wider adoption, would not moving from
> functional to imperative also make sense? After all, all the popular
> languages are imperative, therefore, to enhance the likelihood of wide
> adoption should Racket2 be imperative as well?
>
> But then wouldn't Racket2 be Algol2 or Ada2 with macros?
>
> If it stays functional and expression based with macros then isn't Racket2
> then Dylan2?
>
> Of the three axioms of Racket2, the f(x,y,z) proscription prohibits some
> of the cleaner syntax out there as used in SML and Haskell.  Is it a hard
> requirement to ensure full macro support can happen?
>
> If Racket2 moves to be even more functional in thrust, drops the f(x,y,z)
> proscription and adopts currying then isn't Racket2 a polished up nextgen
> SML2?
>
> Maybe a nextgen SML2 for semantics and typing but with the lighter Haskell
> syntax (no laziness)?
>
> What will be the magic twist for widespread adoption that Algol, Ada,
> Dylan, SML, Haskell and s-exp Racket, all with quality implementations,
> failed to achieve?
>
> How much of a languages adoption success is just shear dumb luck, the
> right place at the right time independent of the languages overall quality
> and capability? Does Javascript even need to mentioned here?
>
> Should we cover all possible bases and make Racket and its "make
> languages" core a nextgen DotNet and put together a whole suite of
> languages, a Lisp like, an Algo like, a SML like, a Haskell like, a
> Java/Swift like, an Erlang like, ... all interoperable.   If that all of
> that happened tomorrow by magic would the world embrace Racket(2...).
>
>
>
>
>
>
>
>
>
> --
> 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/c8abfd8b-3304-4ed5-9e23-bf2f1d7da8cb%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/CACUENr%2BPQq8DCuUBcuZOL37QD2ByypNiu0rx3MagvTOY0zxDjg%40mail.gmail.com.

Re: [racket-users] Re: doing a "show hn" of your racket project

[Dexter Lagan]

  Thank you sir, I plan on posting more original content when time allows.

Dex

> On Jul 9, 2019, at 4:56 PM, stewart mackenzie  wrote:
> 
> That's some cool bloggery going on there, thanks for sharing.
> 
>> On Fri, 21 Jun 2019, 16:16 Dexter Lagan,  wrote:
>> www.newlisper.com/blog
>> www.eicm.net/blog
> 
> -- 
> 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/CA%2BLh%3Dn08yAqTQA7UT6-ZBSMt6G5Rm4TM%3Dsdd99EyCFMGXZBoRw%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/1F048EC0-94B6-4DB4-A753-E6AFE170F77C%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Scribble localization and manual style questions

[Dexter Lagan]

  Great, thanks for the info! 

Dex

> On Jun 21, 2019, at 4:36 PM, Sam Tobin-Hochstadt  wrote:
> 
>> On Fri, Jun 21, 2019 at 4:10 AM Dexter Lagan  wrote:
>> 
>> 
>> Am I allowed to use scribble/manual to write my manual? I love Scribble the 
>> Racket docs style and wish I could use the same style;
> 
> Yes, certainly. Everyone is welcome to use this.
> 
>> By default the scribble/manual style is localized for English: @author 
>> prefixes with ‘by’ and appends ‘and’ between authors. The Author and 
>> Author+Email functions are hardcoded this way. The ‘author paragraph seems 
>> to be writing the prefix ‘by’, but I couldn’t find its definition, and 
>> writing a new scheme file just to override the functions and paragraph defs 
>> seems overkill. Can I localize this to my language?
> 
> Currently there's no way to localize this, but the `author` and
> `author+email` functions are quite simple. The whole implementation is
> here: 
> https://github.com/racket/scribble/blob/54606422140136dbc8f0759f2d44e757a0193ac4/scribble-lib/scribble/base.rkt#L111-L138
> 
> The "by" is added in CSS, in the SAuthorList::before rule. That you
> can change with a simple custom additional CSS file.
> 
>> By default, scribble/manual displays the Racket version number on top. Is 
>> there a way to prevent this, or use my own version number?
> 
> I usually remove this with CSS as well.
> 
> Sam

-- 
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/49A03E4F-9E74-4C50-8AE1-0D779FBEB2AB%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: doing a "show hn" of your racket project

[Dexter Lagan]

  Once my git repos will be presentable, you can be sure I'll show it all 
to HN. I'm a beyond-full-time Racket programmer and I intend to share most 
of the non-commercial code I write. I also started two blogs:

About lisp in general, but contains a lot of Racket-related posts
www.newlisper.com/blog

and

A more general, deeply technical blog, will also contain less specific 
posts about Racket:
www.eicm.net/blog

  They haven't been published anywhere, and maybe Racketeers can give me 
some feedback before I make a fool of myself elsewhere. If the content is 
up to par, feel free to mention it in the newsletter.

Dex

On Friday, June 21, 2019 at 12:28:07 AM UTC+2, Neil Van Dyke wrote:
>
> If you make something in Racket, such as a microstartup Web site, or 
> something that HN readers can otherwise use, you can publicize it with a 
> "Show HN" post, and possibly also promote Racket as a side effect. 
>
> For example, here's one making the front page of HN right now: 
>
> "Show HN: A star map creation tool with Common Lisp (thestarmaps.com)" 
> https://news.ycombinator.com/item?id=20231328 
>
> Other recent examples at: 
> https://news.ycombinator.com/show 
>
> Here's how to do it (HN has reasoned rules): 
> https://news.ycombinator.com/showhn.html 
> https://news.ycombinator.com/newsguidelines.html 
> https://news.ycombinator.com/newsfaq.html 
>
>

-- 
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/972cbb2f-4320-4621-b988-0f7a73805b8b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Scribble localization and manual style questions

[Dexter Lagan]

Hi folks,

 

  I hope this is the right group for my questions. The Scribble users Google
group seems empty.

I am in the process of writing a commercial application's manual. This
particular app is in French and so should be the manuals.

 

1.  Am I allowed to use scribble/manual to write my manual? I love
Scribble the Racket docs style and wish I could use the same style;
2.  By default the scribble/manual style is localized for English:
@author prefixes with 'by' and appends 'and' between authors. The Author and
Author+Email functions are hardcoded this way. The 'author paragraph seems
to be writing the prefix 'by', but I couldn't find its definition, and
writing a new scheme file just to override the functions and paragraph defs
seems overkill. Can I localize this to my language?
3.  By default, scribble/manual displays the Racket version number on
top. Is there a way to prevent this, or use my own version number?

 

Thanks in advance,

 

Dexter

-- 
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/01df01d52811%247b861ec0%2472925c40%24%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] [ann] marionette: control Firefox from Racket

[Dexter Lagan]

  Pure awesomeness. Thank you for sharing!

Dex

> On Jun 8, 2019, at 5:46 PM, Bogdan Popa  wrote:
> 
> Hey everybody!
> 
> I just wrote `marionette`, a library that lets you control the Firefox
> web browser from Racket and I figured I'd share it!
> 
> * the source code is here: https://github.com/bogdanp/marionette,
> * you can install the package by running `raco pkg install marionette` and
> * the docs will be available on the package server within the next day or so.
> 
> It's still early days but a lot of the basic functionality you would
> expect is already supported.  If you give it a try, let me know what you
> think!
> 
> - Bogdan
> 
> -- 
> 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/m2lfyc2i6q.fsf%40192.168.0.139.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/224B383E-0698-44D6-91B3-05929D2D58D0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Racket v7.3

[Dexter Lagan]

  I’ll compare file write times as soon as we’re done testing the tool I’m 
working on.

Cheers

Dex

> On May 16, 2019, at 10:03 PM, Piyush Katariya  
> wrote:
> 
> I am also keen to know the IO perf optimization results in real world.
> 
> Dexter, if possible can you give us some approximate throughput or latency 
> numbers when you switch to v7.3 
> -- 
> 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/a2edb6b8-e792-42be-bfc9-63e78ef38e95%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/3D57811B-57E4-48CB-AAF9-1A307F70E888%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

RE: [racket-users] Racket v7.3

[Dexter Lagan]

A huge thanks to everybody who worked on Racket. 

 

  IO improvements will surely make everybody’s life a little better in my team 
and the whole studio. We’re relying on large (200MB text files), and numerous 
(in the 100,000’s) file reads and writes daily. We’re converting shell scripts 
to Racket and I recon it’s hard to beat some GNU command’s optimizations. I 
have been tempted to try Rust but a) it’s not guaranteed to perform better for 
pure IO, and b) I’d rather code it directly in macro-asm if it meant better 
speed. But so far, Racket’s performance has been more than adequate for our 
tasks, and thanks to this I can do it all in Racket. That puts a big, gleeful 
smile on my face.

 

From: racket-users@googlegroups.com  On Behalf 
Of Laurent
Sent: 16 May, 2019 3:28 PM
To: John Clements 
Cc: Racket Users 
Subject: Re: [racket-users] Racket v7.3.

 

Thank you all for the new release!

 

On Wed, May 15, 2019 at 7:05 PM 'John Clements' via Racket Users 
mailto:racket-users@googlegroups.com> > wrote:

- Racket's IO system has been refactored to improve performance
 and simplify internal design.

 

Is it mild overall performance improvement, or are there cases where there can 
be a big boost? (Like "previous bottlenecks have become highways" kind of 
improvement)

 

 

-- 
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/CABNTSaEotkhQ_yK8n60fkFgkOmULX061eoj-LmDfhSBopA4h1Q%40mail.gmail.com
 

 .
For more options, visit https://groups.google.com/d/optout.

-- 
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/011301d50c07%244f52f9c0%24edf8ed40%24%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Question regarding the function printBoard board

[Dexter Lagan]

Hi there!

  You can suppress à function’s output with (void (func ...)) like so:

(void (printBoard  '((0 0 2 0) (0 0 0 0) (0 0 8 0) (0 0 0 0

Or you can modify your original function and replace the “” by (void) like so:

...
(cond ((empty? board) (void) ) 
...

Dexter

> On Apr 23, 2019, at 8:53 PM, orenpa11  wrote:
> 
> Hi
> I am using  the functionprintBoard board  (DrRacket  Pretty Big) 
> 
> (printBoard  '((0 0 2 0) (0 0 0 0) (0 0 8 0) (0 0 0 0)))
> 
> and the result is 
> 
> (0 0 2 0)
> (0 0 0 0)
> (0 0 8 0)
> (0 0 0 0)
> "" 
> 
> How do I delete the "" ?
> 
> I would like the output to be  
> 
> (0 0 2 0)
> (0 0 0 0)
> (0 0 8 0)
> (0 0 0 0)
> 
> Thanks
> 
> 
> P.S. the code is 
> 
> (define (buildBoard n)   ;build the started board  
>(cond ((= n 0) '())
>  (else (cons '(0 0 0 0) (buildBoard (sub1 n))
> 
> (define (printBoard board) ;print the board
>   (cond ((empty? board) "" ) 
> (else (writeln(first board))
>  (printBoard (rest board)
> 
> 
> 
>  
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

RE: [racket-users] Provide form generator

[Dexter Lagan]

  Thanks Matthias. I'm fairly new to Racket, and I thought the provide form was 
just a way to indicate which functions to expose. I'll look into it.

Dexter

-Original Message-
From: Matthias Felleisen <matth...@felleisen.org> 
Sent: Tuesday, May 8, 2018 12:11 PM
To: Dexter Lagan <dexterla...@gmail.com>
Cc: us...@racket-lang.org
Subject: Re: [racket-users] Provide form generator



Neat. 

Keep in mind that the API of a module should be considered a specification 
(purpose, signature) that the module body (generated later) lives up to. No, 
this is not how we always work in practice because software evolves, but that 
is the principle. 




> On May 8, 2018, at 11:21 AM, Dexter Lagan <dexterla...@gmail.com> wrote:
> 
> Hi folks,
> 
>   I developed a provide form generator to take the pain out of writing module 
> headers: 
> 
> https://github.com/dexterlagan/provide-generator
> 
>  It works great, but I wonder if there wouldn’t be a simpler and more 
> standard way to write this. My original idea was to parse the module syntax 
> and simply delete the body of each define form, converting each function 
> definition to string and use it as comment to each provide element. I 
> couldn’t make it work that way, so I had to switch from syntax objects to 
> strings half-way and handle it by hand. Any insight?
> 
> Thanks!
> 
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


-- 
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.
For more options, visit https://groups.google.com/d/optout.

RE: [racket-users] Provide form generator

[Dexter Lagan]

  Thanks a lot for your insights. I'll look into (module+test ...). Progedit 
looks great as well, it'd streamline a large part of my program.
I need to get familiar with Scribble and write proper documentation, but my 
time is very limited. As soon as I got a free weekend I'll give Scribble a 
better look.
I wasn't aware there was another way to use provide, thanks again for 
explaining.

Have a great day,

Dex

-Original Message-
From: Neil Van Dyke <n...@neilvandyke.org> 
Sent: Tuesday, May 8, 2018 12:25 PM
To: Dexter Lagan <dexterla...@gmail.com>; us...@racket-lang.org
Subject: Re: [racket-users] Provide form generator

Thank you for contributing.  A few suggestions:

* You probably want to put your unit tests, and the `(require rackunit)`, 
inside `(module+ test ...)` forms.  That makes it better as a library or 
program, and also is what Racket expects for testing.

* You can make this a full-fledged Racket package, with an `info.rkt` and 
Scribble documentation, and listing it on "http://pkgs.racket-lang.org/;.  See: 
https://docs.racket-lang.org/pkg/index.html

* You can make your program automatically add the `provide` form in 
user's files, and perhaps `progedit` is helpful for that: 
http://www.neilvandyke.org/racket/progedit/

* There seem to be two schools of thought on where `provide` belongs: 
(1) one big form near the top/bottom of the file or module, like an interface 
summary; and (2) locating the `provided`-ness information of a symbol at the 
definition site, such as through a `provide` form right next to the `define` 
form, or with syntax that combines `provide` and `define`.  So, while you're 
using a tool you developed for #1, remember that #2 is something you might also 
want to try sometime.


-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Provide form generator

[Dexter Lagan]

Hi folks,

  I developed a provide form generator to take the pain out of writing module 
headers: 

https://github.com/dexterlagan/provide-generator

 It works great, but I wonder if there wouldn’t be a simpler and more standard 
way to write this. My original idea was to parse the module syntax and simply 
delete the body of each define form, converting each function definition to 
string and use it as comment to each provide element. I couldn’t make it work 
that way, so I had to switch from syntax objects to strings half-way and handle 
it by hand. Any insight?

Thanks!

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.