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

[Liwei Chou]

Similar discussion here.
https://groups.google.com/forum/#!topic/racket-users/WvThwc98kMU

Sorawee Porncharoenwase於 2020年4月26日星期日 UTC+8上午2時03分13秒寫道：
>
> I like the idea of adding a "with debugging" to the banner when a program 
>> is run in DrRacket, but I´m not sure it is possible. 
>>
>
> It current exists already! The screenshot I attached above is from the 
> actual DrRacket when debugging is enabled.
>  
>
>> (It would be even better if the user can click it and go to the help page 
>> about the configuration of the language). But I'm not sure it is possible.
>>
>
> Right, and that's my proposal. Make it a link, put the word "slow" there 
> to draw attention. I think it would be nice if the language configuration 
> control is self-explanatory so that we don't need the help page.
>  
>
>> Another possibility is to have two "Run" buttons, a normal "Run" button 
>> and a "Run fast" button. The problem is that too many buttons make the UI 
>> confusing for beginners.
>>
>
> I considered this possibility too and reached the same conclusion. Also, 
> I'm not sure if multiple "Run" buttons make sense for every language in 
> 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/cd970f80-2c11-40ca-b40c-7b346586b2e4%40googlegroups.com.

Re: [racket-users] Typed Racket: Generics and interfaces/subtyping

[unlimitedscolobb]

Hi Sam,

Thank you for your answer!  I'll try to hang around on Slack next week 
(starting tomorrow).  Contributing to Typed Racket would be very exciting 
to me!

-
Sergiu


On Saturday, April 25, 2020 at 9:55:30 PM UTC+2, Sam Tobin-Hochstadt wrote:
>
> Structure type properties are getting better support incrementally 
> thanks to Fred Fu, and that sentence needs to be revised. However, 
> there's been no work yet on generic interfaces. I'm happy to chat 
> about the issues there, but it's not simply a matter of doing some 
> programming -- there are a lot of hard design questions. Feel free to 
> ping me on Slack to discuss further. 
>
> Sam 
>
> On Sat, Apr 25, 2020 at 12:10 PM unlimitedscolobb 
> > wrote: 
> > 
> > Hello, 
> > 
> > The Typed Racket Guide states "Most structure type properties do not 
> work in Typed Racket, including support for generic interfaces." [0] Is 
> that due to some incompatibility between the design of Typed Racket and 
> structure type properties, or is it because somebody should just get around 
> and implement these?  I'm particularly interested in generics right now. 
> > 
> > How would you go about expressing something like an abstract interface 
> in Typed Racket?  Something similar to the collections library, possibly 
> even less featureful.  Should I be looking at class inheritance? 
> > 
> > As a lot of people here, I don't have very much time spare time, but I 
> would be happy to extend Typed Racket to handle more of the code I write. 
> > 
> > - 
> > Sergiu 
> > 
> > [0] 
> https://docs.racket-lang.org/ts-guide/caveats.html#%28part._.Unsupported_features%29
>  
> > 
> > -- 
> > 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...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/6e5f6bb0-4768-4f4d-86b0-0c0c08f64171%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/0a4d8713-7414-4f62-976d-55c0dee400be%40googlegroups.com.

Re: [racket-users] Question about generating urls with dispatch-rules from imported modules

[Bogdan Popa]

I solved this in koyo by defining an alternate version[1] of
`dispatch-rules' whose generated `reverse-uri' functions take route
names rather than functions as arguments:

https://koyoweb.org/dispatch/index.html#%28form._%28%28lib._koyo%2Fdispatch..rkt%29._dispatch-rules%2Broles%29%29

The generated function is installed into a parameter on app init and
another function[2] knows how to look it up and apply it when called:

https://koyoweb.org/url/index.html#%28def._%28%28lib._koyo%2Furl..rkt%29._current-reverse-uri-fn%29%29

I hope that helps!

[1]: 
https://github.com/Bogdanp/koyo/blob/331701e9e8d7f553955ea5a950df424ee13ce9d4/koyo-lib/koyo/dispatch.rkt
[2]: 
https://github.com/Bogdanp/koyo/blob/331701e9e8d7f553955ea5a950df424ee13ce9d4/koyo-lib/koyo/url.rkt#L60

Yury Bulka writes:

> Oops, small correction:
>
>> The x-expressions need to include hyperlinks to urls
>> defined via dispatch-rules in main.rkt, i.e., call the url-generating
>> function.
>
> Should be `routing.rkt` instead of `main.rkt`.
>
> --
> Yury Bulka
> https://mamot.fr/@setthemfree
> #NotOnFacebook
>
>
>
> Yury Bulka  writes:
>
>> Dear Racket community,
>>
>> First of all I want to say hello since this is my first post here.
>>
>> I have a question about using the url dispatch library:
>> https://docs.racket-lang.org/web-server/dispatch.html
>>
>> More specifically about the url-generation function in the context of
>> inter-module dependencies.
>>
>> Let's say in `routing.rkt` I define some request handlers and then map
>> them to urls using dispatch-rules.
>>
>> The request handlers call functions from another module that are
>> responsible for generating the x-expressions (let's call this module
>> `templates.rkt`). The x-expressions need to include hyperlinks to urls
>> defined via dispatch-rules in main.rkt, i.e., call the url-generating
>> function.
>>
>> The url-generating function, in turn, needs to be provided the request
>> handler as the first argument.
>>
>> That means that the xexpr-generating function needs to have access to
>> the url-generating function and all the request handlers it might
>> need to include hyperlinks to, or it may need to be provided with all
>> the generated urls in advance.
>>
>> Something like this wouldn't work if render-post needed to generate a url:
>>
>> ;; A request handler associated with a url
>> (define (single-post-view request post-id)
>>   (response/xexpr (render-post (post-id))) ;; render-post is in another 
>> file/module
>>
>> I wouldn't want to make templates.rkt require routing.rkt (I'm not sure
>> this is technically possible to have modules depend on each other like
>> that), nor would I want to provide all the request handlers as arguments
>> to `render-post`. I also thought about putting the url-generating
>> function into a parameter, but `render-post` also needs access to the
>> request handlers.
>>
>> What approach should I take?
>>
>> --
>> Yury Bulka
>> https://mamot.fr/@setthemfree
>> #NotOnFacebook

-- 
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/m21robnvcf.fsf%40192.168.0.142.

Re: [racket-users] Question about generating urls with dispatch-rules from imported modules

[Yury Bulka]

Oops, small correction:

> The x-expressions need to include hyperlinks to urls
> defined via dispatch-rules in main.rkt, i.e., call the url-generating
> function.

Should be `routing.rkt` instead of `main.rkt`.

--
Yury Bulka
https://mamot.fr/@setthemfree
#NotOnFacebook



Yury Bulka  writes:

> Dear Racket community,
>
> First of all I want to say hello since this is my first post here.
>
> I have a question about using the url dispatch library:
> https://docs.racket-lang.org/web-server/dispatch.html
>
> More specifically about the url-generation function in the context of
> inter-module dependencies.
>
> Let's say in `routing.rkt` I define some request handlers and then map
> them to urls using dispatch-rules.
>
> The request handlers call functions from another module that are
> responsible for generating the x-expressions (let's call this module
> `templates.rkt`). The x-expressions need to include hyperlinks to urls
> defined via dispatch-rules in main.rkt, i.e., call the url-generating
> function.
>
> The url-generating function, in turn, needs to be provided the request
> handler as the first argument.
>
> That means that the xexpr-generating function needs to have access to
> the url-generating function and all the request handlers it might
> need to include hyperlinks to, or it may need to be provided with all
> the generated urls in advance.
>
> Something like this wouldn't work if render-post needed to generate a url:
>
> ;; A request handler associated with a url
> (define (single-post-view request post-id)
>   (response/xexpr (render-post (post-id))) ;; render-post is in another 
> file/module
>
> I wouldn't want to make templates.rkt require routing.rkt (I'm not sure
> this is technically possible to have modules depend on each other like
> that), nor would I want to provide all the request handlers as arguments
> to `render-post`. I also thought about putting the url-generating
> function into a parameter, but `render-post` also needs access to the
> request handlers.
>
> What approach should I take?
>
> --
> Yury Bulka
> https://mamot.fr/@setthemfree
> #NotOnFacebook

-- 
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/87tv17iaq8.fsf%40privacyrequired.com.

[racket-users] Question about generating urls with dispatch-rules from imported modules

[Yury Bulka]

Dear Racket community,

First of all I want to say hello since this is my first post here.

I have a question about using the url dispatch library:
https://docs.racket-lang.org/web-server/dispatch.html

More specifically about the url-generation function in the context of
inter-module dependencies.

Let's say in `routing.rkt` I define some request handlers and then map
them to urls using dispatch-rules.

The request handlers call functions from another module that are
responsible for generating the x-expressions (let's call this module
`templates.rkt`). The x-expressions need to include hyperlinks to urls
defined via dispatch-rules in main.rkt, i.e., call the url-generating
function.

The url-generating function, in turn, needs to be provided the request
handler as the first argument.

That means that the xexpr-generating function needs to have access to
the url-generating function and all the request handlers it might
need to include hyperlinks to, or it may need to be provided with all
the generated urls in advance.

Something like this wouldn't work if render-post needed to generate a url:

;; A request handler associated with a url
(define (single-post-view request post-id)
  (response/xexpr (render-post (post-id))) ;; render-post is in another 
file/module

I wouldn't want to make templates.rkt require routing.rkt (I'm not sure
this is technically possible to have modules depend on each other like
that), nor would I want to provide all the request handlers as arguments
to `render-post`. I also thought about putting the url-generating
function into a parameter, but `render-post` also needs access to the
request handlers.

What approach should I take?

--
Yury Bulka
https://mamot.fr/@setthemfree
#NotOnFacebook

-- 
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/87v9lnib0e.fsf%40privacyrequired.com.

Re: [racket-users] Typed Racket: Generics and interfaces/subtyping

[Sam Tobin-Hochstadt]

Structure type properties are getting better support incrementally
thanks to Fred Fu, and that sentence needs to be revised. However,
there's been no work yet on generic interfaces. I'm happy to chat
about the issues there, but it's not simply a matter of doing some
programming -- there are a lot of hard design questions. Feel free to
ping me on Slack to discuss further.

Sam

On Sat, Apr 25, 2020 at 12:10 PM unlimitedscolobb
 wrote:
>
> Hello,
>
> The Typed Racket Guide states "Most structure type properties do not work in 
> Typed Racket, including support for generic interfaces." [0] Is that due to 
> some incompatibility between the design of Typed Racket and structure type 
> properties, or is it because somebody should just get around and implement 
> these?  I'm particularly interested in generics right now.
>
> How would you go about expressing something like an abstract interface in 
> Typed Racket?  Something similar to the collections library, possibly even 
> less featureful.  Should I be looking at class inheritance?
>
> As a lot of people here, I don't have very much time spare time, but I would 
> be happy to extend Typed Racket to handle more of the code I write.
>
> -
> Sergiu
>
> [0] 
> https://docs.racket-lang.org/ts-guide/caveats.html#%28part._.Unsupported_features%29
>
> --
> 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/6e5f6bb0-4768-4f4d-86b0-0c0c08f64171%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/CAK%3DHD%2Baq-XQJtkOWKwNqJN3fQfP7Zecf-T9zJTjaXWRgU6%3DLWw%40mail.gmail.com.

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

[Sorawee Porncharoenwase]

>
> I like the idea of adding a "with debugging" to the banner when a program
> is run in DrRacket, but I´m not sure it is possible.
>

It current exists already! The screenshot I attached above is from the
actual DrRacket when debugging is enabled.


> (It would be even better if the user can click it and go to the help page
> about the configuration of the language). But I'm not sure it is possible.
>

Right, and that's my proposal. Make it a link, put the word "slow" there to
draw attention. I think it would be nice if the language configuration
control is self-explanatory so that we don't need the help page.


> Another possibility is to have two "Run" buttons, a normal "Run" button
> and a "Run fast" button. The problem is that too many buttons make the UI
> confusing for beginners.
>

I considered this possibility too and reached the same conclusion. Also,
I'm not sure if multiple "Run" buttons make sense for every language in
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/CADcuegunm5ThVbZgHnbEY1pDjoh8ne-f0HH0vEPvCiYwMQGMBQ%40mail.gmail.com.

[racket-users] Typed Racket: Generics and interfaces/subtyping

[unlimitedscolobb]

Hello,

The Typed Racket Guide states "Most structure type properties do not work 
in Typed Racket, including support for generic interfaces." [0] Is that due 
to some incompatibility between the design of Typed Racket and structure 
type properties, or is it because somebody should just get around and 
implement these?  I'm particularly interested in generics right now.

How would you go about expressing something like an abstract interface in 
Typed Racket?  Something similar to the collections library, possibly even 
less featureful.  Should I be looking at class inheritance?

As a lot of people here, I don't have very much time spare time, but I 
would be happy to extend Typed Racket to handle more of the code I write.

-
Sergiu

[0] 
https://docs.racket-lang.org/ts-guide/caveats.html#%28part._.Unsupported_features%29

-- 
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/6e5f6bb0-4768-4f4d-86b0-0c0c08f64171%40googlegroups.com.

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

[Sorawee Porncharoenwase]

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:

[image: Screen Shot 2020-04-25 at 05.11.29.png]

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

-- 
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/CADcuegvJUgbWvYFbtxYv2HUYCZaJwWtp5HdmUR7N-Nh_bp4UOg%40mail.gmail.com.

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

[Liwei Chou]

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.

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

-- 
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] DrRacket's dark mode: anyone familiar with Windows internals?

[Sorawee Porncharoenwase]

Hi everyone,

DrRacket's dark mode currently doesn't work on Windows. If you know Windows
internals and would like to help, you can participate at
https://github.com/racket/drracket/issues/235.

-- Forwarded message -
From: Robby Findler 
Date: Fri, Apr 24, 2020 at 7:32 PM
Subject: Re: [racket/drracket] Visibility issues with Dr Racket and dark
themes (#235)
To: racket/drracket 
Cc: sorawee , Mention 


Yeah, the windows situation isn't great. I think that basically all of the
problems there can be traced to not knowing how to implement this function
under windows:

https://docs.racket-lang.org/mrlib/White_on_Black_Panel_Predicate.html

If you have knowledge of windows internals or the strength to dig through
the various google results on the topic and come up with something, that
would be huge!

-- 
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/CADcuegs%2B0r2wTL7bz0%3DL4avxSNiE%3DnbMtp3At4798GDc62tucA%40mail.gmail.com.