Re: [racket-users] package manager woes on Windows 10?

[Sorawee Porncharoenwase]

Can you explain why you are not sure? Under what circumstances do you think
the current 'single style behavior is useful?

We can add 'single-no-return (though I dislike it because 'single means no
return already!) and change existing places that use 'single. However,
without switching the default style from 'single to 'single-no-return,
people will make mistakes again in the future. But if we will change the
default style to 'single-no-return too, why don't we simply directly change
the behavior 'single?

On Sun, Sep 13, 2020 at 1:36 PM Robby Findler 
wrote:

> I'm not sure. I would probably add a 'single-no-return style and then grep
> the codebase for places that use 'single and change them (as appropriate).
>
> Robby
>
>
> On Sun, Sep 13, 2020 at 3:15 PM Sorawee Porncharoenwase <
> sorawee.pw...@gmail.com> wrote:
>
>> I meant, wouldn’t it be better to fix text-field% itself, instead of
>> only some instances of it? Sorry if that was confusing.
>>
>> On Sun, Sep 13, 2020 at 1:12 PM Sorawee Porncharoenwase <
>> sorawee.pw...@gmail.com> wrote:
>>
>>> Should the fix apply to all 'single styled text-field%
>>>  too?
>>>
>>> On Sun, Sep 13, 2020 at 7:50 AM Robby Findler 
>>> wrote:
>>>
 Yea, I agree. I'd made that change locally but hadn't pushed because I
 couldn't make the bad behavior happen reliably. Perhaps that lack shouldn't
 stop us! Pushed now.

 Robby


 On Sat, Sep 12, 2020 at 11:15 PM jackh...@gmail.com <
 jackhfi...@gmail.com> wrote:

> Could we make the "do what I mean" box just automatically strip any
> newlines pasted into it? It seems sensible to me to require that it only 
> be
> a single line input.
>
> On Friday, September 11, 2020 at 6:22:59 AM UTC-7
> hen...@topoi.pooq.com wrote:
>
>> On Thu, Sep 10, 2020 at 10:27:39AM -0400, George Neuner wrote:
>> >
>> >
>> > On 9/10/2020 10:06 AM, Philip McGrath wrote:
>> > > Also, this is happening over encrypted HTTPS: no one is sniffing
>> the
>> > > User-Agent header.
>> >
>> > While it may not be the issue here, you need to understand that
>> appliance
>> > firewalls CAN and routinely DO examine data inside encrypted
>> connections.
>>
>> Using man-in-the-middle attacks?
>>
>> -- hendrik
>>
> --
> 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/84b16cf0-7837-4d54-9423-c1286f5e2b7an%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/CAL3TdON46%3DPR6_-iyppSMLsfEvNEveq3uGu64gQ3Lu1or7QgNw%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/CADcuegtFzzeErTTqi3m9Hyr%2Bu1m8YEo0cnAEw2onhKXGnTzHOg%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/CADcuegsBYxxQJgjSz9ohS6fiRHaOXiO_Bx%3D_JoiiAvTQMHWH6A%40mail.gmail.com.

Re: [racket-users] Why is get-impure-port* slower than a system call to curl?

[Sam Phillips]

Hi Stephen,

I ran this small benchmark against a remote web server, and was
definitely getting better response using the http-easy module.

https://gist.github.com/samdphillips/32763ebd0d938678c2972b1dd8ee5778

$ racket -e '(require (submod "http-perf.rkt" curl))'
cpu time: 768 real time: 35299 gc time: 0

$ racket -e '(require (submod "http-perf.rkt" http-easy))'
cpu time: 1810 real time: 17316 gc time: 70

On Mon, Sep 14, 2020 at 12:57 PM Stephen Foster  wrote:
>
> Finally circling back to this issue.  I've disabled debugging in DrRacket and 
> also done a test outside of DrRacket.  It's still slow. :(
>
> I also tried the newer HTTP client: 
> https://docs.racket-lang.org/http-easy/index.html.  Like the others, it is 
> also slow.
>
> I'll do some more digging.  I'm currently trying to figure out if this is a 
> "just me" / "just my system" problem.  So... I'd be grateful if anyone who 
> has written code that sends HTTP requests from Racket could chime in with: 1) 
> I can confirm that sending HTTP requests from Racket has always been fast for 
> me, or 2) I too have noticed Racket HTTP requests are slow.
>
> (Note that by "slow", I mean: takes noticeably longer than curl.)
>
>
>
> On Tue, Jul 7, 2020 at 12:21 PM Jon Zeppieri  wrote:
>>
>> Hi Stephen,
>>
>> Your video shows you running this code in DrRacket with debugging
>> enabled. That usually affects performance. Have you made measurements
>> when running this code outside of DrRacket?
>>
>> - Jon
>>
>>
>> On Tue, Jul 7, 2020 at 2:13 PM Stephen Foster  
>> wrote:
>> >
>> > I'm considering using Racket to remake my 3D game CodeSpells.  I'm using 
>> > http requests to have Unreal Engine and Racket talk to each other.
>> >
>> > When I use the http/request library, Racket fires off its GET request much 
>> > slower than if it were to do a system call to curl.  (Same is true if I 
>> > use simple-http, which makes me think the problem might be a deep one.)
>> >
>> > Here's a video to demo the issue.  Notice how, with curl, the experience 
>> > is playable, whereas with the Racket function, there's way too much time 
>> > between the spell landing and the effect occurring:
>> >
>> > https://youtu.be/jTqUFVlfBFA
>> >
>> > Obviously, I'd like to do things in a Rackety way.  But I'm not above 
>> > doing things the silly way.  I'd just be grumpy about it.
>> >
>> > Any ideas?
>> >
>> >
>> >
>> > --
>> > 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/997693d6-b94a-4f69-85cf-aa475c807b20n%40googlegroups.com.
>
>
>
> --
>
>
> Stephen Foster
> ThoughtSTEM Co-Founder
> 318-792-2035
>
> --
> 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%2BzSu2_%2BTKVTe--OZRU_BE_LyofFkA869c-2v%2BRJ76HjDQt4_w%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/CAHsjV0ytpkiHvb%2BtXXW6iEcB1HMxVsUkkmWY-NGmEDBJ_fUR9Q%40mail.gmail.com.

Re: [racket-users] Why is get-impure-port* slower than a system call to curl?

[Jon Zeppieri]

I ran a few tests where I fetch the google homepage via curl,
get-impure-port, and get-impure-port*. Curl does, in fact, seem to be
faster, but not nearly so much so to account for the delays in that
video. So, one thing to check is if the racket code gets slower
results when requesting arbitrary urls vs. when requesting that
specific server.

It could be an issue with the requests headers that you're sending
(which is to say, the library defaults) vs. what curl is sending. Or
it could be a bad interaction with Nagle's algorithm, though that
seems unlikely with an http GET, since the most likely culprit would
be separate flushes of header and body data -- and there is no body in
a GET request. I think maybe all of the things you tried use http 1.0
requests by default (simple-http reuses the code from
net/http-client), so you might want to try explicitly using 1.1.




On Mon, Sep 14, 2020 at 3:57 PM Stephen Foster  wrote:
>
> Finally circling back to this issue.  I've disabled debugging in DrRacket and 
> also done a test outside of DrRacket.  It's still slow. :(
>
> I also tried the newer HTTP client: 
> https://docs.racket-lang.org/http-easy/index.html.  Like the others, it is 
> also slow.
>
> I'll do some more digging.  I'm currently trying to figure out if this is a 
> "just me" / "just my system" problem.  So... I'd be grateful if anyone who 
> has written code that sends HTTP requests from Racket could chime in with: 1) 
> I can confirm that sending HTTP requests from Racket has always been fast for 
> me, or 2) I too have noticed Racket HTTP requests are slow.
>
> (Note that by "slow", I mean: takes noticeably longer than curl.)
>
>
>
> On Tue, Jul 7, 2020 at 12:21 PM Jon Zeppieri  wrote:
>>
>> Hi Stephen,
>>
>> Your video shows you running this code in DrRacket with debugging
>> enabled. That usually affects performance. Have you made measurements
>> when running this code outside of DrRacket?
>>
>> - Jon
>>
>>
>> On Tue, Jul 7, 2020 at 2:13 PM Stephen Foster  
>> wrote:
>> >
>> > I'm considering using Racket to remake my 3D game CodeSpells.  I'm using 
>> > http requests to have Unreal Engine and Racket talk to each other.
>> >
>> > When I use the http/request library, Racket fires off its GET request much 
>> > slower than if it were to do a system call to curl.  (Same is true if I 
>> > use simple-http, which makes me think the problem might be a deep one.)
>> >
>> > Here's a video to demo the issue.  Notice how, with curl, the experience 
>> > is playable, whereas with the Racket function, there's way too much time 
>> > between the spell landing and the effect occurring:
>> >
>> > https://youtu.be/jTqUFVlfBFA
>> >
>> > Obviously, I'd like to do things in a Rackety way.  But I'm not above 
>> > doing things the silly way.  I'd just be grumpy about it.
>> >
>> > Any ideas?
>> >
>> >
>> >
>> > --
>> > 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/997693d6-b94a-4f69-85cf-aa475c807b20n%40googlegroups.com.
>
>
>
> --
>
>
> Stephen Foster
> ThoughtSTEM Co-Founder
> 318-792-2035

-- 
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/CAKfDxxyzT9z9inrjoLumvK%3DZi4CNpBo0RpMuOkkwUs4WG2g4Gg%40mail.gmail.com.

Re: [racket-users] Why is get-impure-port* slower than a system call to curl?

[Stephen Foster]

Finally circling back to this issue.  I've disabled debugging in DrRacket
and also done a test outside of DrRacket.  It's still slow. :(

I also tried the newer HTTP client:
https://docs.racket-lang.org/http-easy/index.html.  Like the others, it is
also slow.

I'll do some more digging.  I'm currently trying to figure out if this is a
"just me" / "just my system" problem.  So... I'd be grateful if anyone who
has written code that sends HTTP requests from Racket could chime in with:
1) I can confirm that sending HTTP requests from Racket has always been
fast for me, or 2) I too have noticed Racket HTTP requests are slow.

(Note that by "slow", I mean: takes noticeably longer than curl.)



On Tue, Jul 7, 2020 at 12:21 PM Jon Zeppieri  wrote:

> Hi Stephen,
>
> Your video shows you running this code in DrRacket with debugging
> enabled. That usually affects performance. Have you made measurements
> when running this code outside of DrRacket?
>
> - Jon
>
>
> On Tue, Jul 7, 2020 at 2:13 PM Stephen Foster 
> wrote:
> >
> > I'm considering using Racket to remake my 3D game CodeSpells.  I'm using
> http requests to have Unreal Engine and Racket talk to each other.
> >
> > When I use the http/request library, Racket fires off its GET request
> much slower than if it were to do a system call to curl.  (Same is true if
> I use simple-http, which makes me think the problem might be a deep one.)
> >
> > Here's a video to demo the issue.  Notice how, with curl, the experience
> is playable, whereas with the Racket function, there's way too much time
> between the spell landing and the effect occurring:
> >
> > https://youtu.be/jTqUFVlfBFA
> >
> > Obviously, I'd like to do things in a Rackety way.  But I'm not above
> doing things the silly way.  I'd just be grumpy about it.
> >
> > Any ideas?
> >
> >
> >
> > --
> > 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/997693d6-b94a-4f69-85cf-aa475c807b20n%40googlegroups.com
> .
>


-- 


Stephen Foster
ThoughtSTEM Co-Founder
318-792-2035

-- 
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%2BzSu2_%2BTKVTe--OZRU_BE_LyofFkA869c-2v%2BRJ76HjDQt4_w%40mail.gmail.com.

[racket-users] Racket News Issue 38

[Paulo Matos]

Hi all,

Racket News Issue 38 is here!
https://racket-news.com/2020/09/racket-news-issue-38.html

Enjoy!
Paulo Matos

-- 
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/a28fc970-7ff5-4887-afa7-9a85c743c38cn%40googlegroups.com.

Re: [racket-users] Re: hashcons

[Tony Garnock-Jones]

On Mon, 14 Sep 2020 at 14:18, Hendrik Boom  wrote:

> I would, ideally, only use hashcons on those cons-cells which had
> themselves
> been hashconsed, so eq? would suffice.
>

The challenge is checking to see whether a new allocation is required.
Checking `eq?` of the cdr suffices, but seldom is `eq?` appropriate for the
car, assuming you want `(eq? (hashcons (set) '()) (hashcons (set) '()))`
and similar to hold. Canonicalize looks, roughly, like

(define (canonicalize c)
  (match c
[(cons a d) (if (cell-exists-in-weak-table-with-car-and-cdr? a d) ;; (X)
(extract-and-return-existing-cell a d)
(intern-and-return-cons-of a (canonicalize d)))]
[_ c]))

The line marked (X) will usually want to compare `a` with `equal?` and `d`
with `eq?`.

-- 
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/CAM8fPiS0moqzAfDUdtH5aBx337Mt-TrWQkZ8EQro5HHWJtkEKg%40mail.gmail.com.

Re: [racket-users] Re: hashcons

[Hendrik Boom]

On Mon, Sep 14, 2020 at 01:11:34AM -0700, Tony Garnock-Jones wrote:
> On Sunday, September 13, 2020 at 12:41:15 AM UTC+2 hen...@topoi.pooq.com 
> wrote:
> 
> > True, but that would require rewriting list, and quasiquote, ans 
> > others like that to use the hashcons. 
> >
> > Not impossible. 
> >
> 
> One potentially useful trick is to write a function `canonicalize` which 
> deeply traverses the structure of its argument, rebuilding it if necessary 
> to produce the canonical representative for each piece of substructure. 
> Then you can `(canonicalize (map f xs))` without having to rewrite `map`, 
> and it takes (asymptotically) the same time as it would if you did alter 
> `map`.
> 
> Another thing to watch out for is that hashconsing via `equal?` can be 
> quite expensive for things like hash tables. I used hashconsing extensively 
> in the first implementation of Syndicate and ended up having to implement 
> my own treaps to get good asymptotic performance with a hashconsed 
> dictionary structure.

I would, ideally, only use hashcons on those cons-cells which had themselves 
been hashconsed, so eq? would suffice.

-- hendrik

-- 
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/20200914121810.vsbo56odmxf7r4f6%40topoi.pooq.com.

Re: [racket-users] question about places and main thread gc

[Matthew Flatt]

At Mon, 14 Sep 2020 00:34:08 -0500, Nate Griswold wrote:
> If i understand correctly, in racket cs embedded if i am not currently
> running anything in the main racket thread then gc cannot happen. But the
> next time i make a call into racket on that reserved racket thread (which
> has not been shut down, and by using racket_apply or some such) then gc can
> happen. But i do not know about the other threads that racket has spawned.

In Racket CS, you can enable GC without the main thread by deactivating
the thread. At the Racket level, use `#blocking? #t` for a foreign
function to deactivate the current thread while calling the function.
At the C level, you can use `Sdeactivate_thread` and
`Sactivate_therad` from Chez Scheme's API.

Racket BC doesn't have a notation of deactivating a thread. Most GCs
with BC can run in separate places even without the main thread active,
but the main thread is needed when there has been enough shared-space
allocation that all threads must be involved.

One caution for both CS and BC, though: Some foreign-library bindings
use `#:in-original-place?` to make use of the foreign library
single-threaded by routing all calls through the main place. That
requires the main thread to be active.


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

Re: [racket-users] Re: hashcons

[Tony Garnock-Jones]

On Sunday, September 13, 2020 at 12:41:15 AM UTC+2 hen...@topoi.pooq.com 
wrote:

> True, but that would require rewriting list, and quasiquote, ans 
> others like that to use the hashcons. 
>
> Not impossible. 
>

One potentially useful trick is to write a function `canonicalize` which 
deeply traverses the structure of its argument, rebuilding it if necessary 
to produce the canonical representative for each piece of substructure. 
Then you can `(canonicalize (map f xs))` without having to rewrite `map`, 
and it takes (asymptotically) the same time as it would if you did alter 
`map`.

Another thing to watch out for is that hashconsing via `equal?` can be 
quite expensive for things like hash tables. I used hashconsing extensively 
in the first implementation of Syndicate and ended up having to implement 
my own treaps to get good asymptotic performance with a hashconsed 
dictionary structure.

Cheers,
  Tony
 

-- 
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/8de04262-e1c3-44b4-83a0-1a0c637e3f47n%40googlegroups.com.