Re: [racket-users] Catching syntax errors

[Philip McGrath]

If testing with parenthetical syntax is sufficient, you might want
something like this:

#lang racket

(with-handlers ([exn:fail:syntax? values])
  (eval `(module bad racket (define foo (define bar 1)))
(make-base-namespace)))

which returns:

(exn:fail:syntax
 "define: not allowed in an expression context"
 #
 '(.#))







-Philip

On Fri, Jun 30, 2017 at 3:47 PM, Sam Waxman  wrote:

> Hello,
>
> I'm trying to test whether or not certain programs result in syntax
> errors. For example the program
>
> #lang racket
> a
>
> will result in an unbound identifier error, even before runtime (you'll
> see the little error message at the bottom because it errored in phase 1).
>
> I know how to catch runtime errors, but I haven't been able to catch these
> expansion time errors as of yet. I've tried doing roughly the same thing as
> catching runtime errors, but with begin-for-syntax, but it hasn't been
> working out for me.
>
> Ideally, I want a macro like
>
> (return-syntax-error stuff-to-expand ...)
>
> that will run stuff-to-expand, and if runs into a syntax error, for it to
> be caught and returned (as the error struct # #).
>
> Any tips?
>
> Many thanks in advance.
>
> --
> 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.

[racket-users] Catching syntax errors

[Sam Waxman]

Hello,

I'm trying to test whether or not certain programs result in syntax errors. For 
example the program

#lang racket
a

will result in an unbound identifier error, even before runtime (you'll see the 
little error message at the bottom because it errored in phase 1).

I know how to catch runtime errors, but I haven't been able to catch these 
expansion time errors as of yet. I've tried doing roughly the same thing as 
catching runtime errors, but with begin-for-syntax, but it hasn't been working 
out for me.

Ideally, I want a macro like

(return-syntax-error stuff-to-expand ...)

that will run stuff-to-expand, and if runs into a syntax error, for it to be 
caught and returned (as the error struct #).

Any tips?

Many thanks in advance.

-- 
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] Re: Plot: line with histogram

[Deren Dohoda]

I asked too soon. It appears that the markers for histograms are not ticks.
So you can simply parameterize plot-x-ticks to no-ticks. This does not
affect the histogram markers.

Sorry for the noise.

Deren

On Fri, Jun 30, 2017 at 2:28 PM, Deren Dohoda 
wrote:

> Hi Racketeers,
>
> I'm trying to put a horizontal line on a histogram plot so one can see
> whether the height passes some threshold. It's no problem for plot, but the
> ticks generated are some combination of how (function ...) wants to have
> ticks and how (discrete-histogram ...) wants to have ticks.
>
> Is there some way to suppress the ticks from the line, so only the
> discrete-histogram ticks are shown? Or for that matter to grab the ticks
> that discrete-histogram implies to parameterize the plot-x-ticks?
>
> Thanks,
> Deren
>

-- 
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] Plot: line with histogram

[Deren Dohoda]

Hi Racketeers,

I'm trying to put a horizontal line on a histogram plot so one can see
whether the height passes some threshold. It's no problem for plot, but the
ticks generated are some combination of how (function ...) wants to have
ticks and how (discrete-histogram ...) wants to have ticks.

Is there some way to suppress the ticks from the line, so only the
discrete-histogram ticks are shown? Or for that matter to grab the ticks
that discrete-histogram implies to parameterize the plot-x-ticks?

Thanks,
Deren

-- 
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] can `impersonate-hash` really filter out hash keys?

[Matthew Butterick]

That's a good suggestion. Yes, that will be smoother.


> On Jun 30, 2017, at 10:31 AM, Philip McGrath  wrote:
> 
> If it doesn't absolutely have to be a hash, you can definitely make dict-ref 
> and dict-iterate-key etc. work differently.

-- 
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] can `impersonate-hash` really filter out hash keys?

[Philip McGrath]

If it doesn't absolutely have to be a hash, you can definitely
make dict-ref and dict-iterate-key etc. work differently.

-Philip

On Fri, Jun 30, 2017 at 12:15 PM, Matthew Butterick  wrote:

>
> > On Jun 30, 2017, at 10:07 AM, Robby Findler 
> wrote:
> >
> > Maybe you could make the impersonator (it would be a chaperone, really
> > in what I'm suggesting) signal an error if it gets one of the private
> > keys and then hand out only the hashes with the impersonator around
> > it, keeping the "raw" one around for code that is allowed to access
> > the private keys?
>
> I still want the private keys to be directly accessible. Maybe this is the
> best bet, where I include a #f/#f entry in the table, and then I can use
> #:when to do the filtering easily:
>
> (define ih (impersonate-hash (make-hash (list (cons #f #f)))
>  (λ (h k) (values k (λ (h k v) v)))
>  (λ (h k v) (values k v))
>  (λ (h k) k)
>  (λ (h k) (and (eq? k 'foo) k
> (hash-set! ih 'foo 42)
> (hash-set! ih 'bar 21)
> (hash-set! ih 'zam 7)
> (for/list ([(k v) (in-hash ih)]
>  #:when k)
>  (cons k v)) ; '((foo . 42))
> (hash-ref ih 'foo) ; 42
> (hash-ref ih 'bar) ; 21
> (hash-ref ih 'zam) ; 7
>
> --
> 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] can `impersonate-hash` really filter out hash keys?

[Matthew Butterick]

> On Jun 30, 2017, at 10:07 AM, Robby Findler  
> wrote:
> 
> Maybe you could make the impersonator (it would be a chaperone, really
> in what I'm suggesting) signal an error if it gets one of the private
> keys and then hand out only the hashes with the impersonator around
> it, keeping the "raw" one around for code that is allowed to access
> the private keys?

I still want the private keys to be directly accessible. Maybe this is the best 
bet, where I include a #f/#f entry in the table, and then I can use #:when to 
do the filtering easily:

(define ih (impersonate-hash (make-hash (list (cons #f #f)))
 (λ (h k) (values k (λ (h k v) v)))
 (λ (h k v) (values k v))
 (λ (h k) k)
 (λ (h k) (and (eq? k 'foo) k
(hash-set! ih 'foo 42)
(hash-set! ih 'bar 21)
(hash-set! ih 'zam 7)
(for/list ([(k v) (in-hash ih)]
 #:when k)
 (cons k v)) ; '((foo . 42))
(hash-ref ih 'foo) ; 42
(hash-ref ih 'bar) ; 21 
(hash-ref ih 'zam) ; 7

-- 
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] can `impersonate-hash` really filter out hash keys?

[Robby Findler]

Maybe you could make the impersonator (it would be a chaperone, really
in what I'm suggesting) signal an error if it gets one of the private
keys and then hand out only the hashes with the impersonator around
it, keeping the "raw" one around for code that is allowed to access
the private keys?

Robby


On Fri, Jun 30, 2017 at 11:55 AM, Matthew Butterick  wrote:
> I'd like to make a hash impersonator that has "private" keys that can be
> reached by `hash-ref`, but which are not reported by `hash-keys` and other
> operations that iterate over all keys.
>
> The docs for `impersonate-hash` [1] say that you can "use `key-proc` to
> filter keys extracted from the table". OK, sounds promising. But later, it
> says `key-proc` "must produce a replacement for the key". So apparently it's
> more of a map-like operation than a filter-like operation.
>
> For instance, this key-proc function intends to omit any key but 'foo. But
> AFAICT there is no value you can return that signals "please pretend this
> key does not exist."
>
> #lang racket
> (define ih (impersonate-hash (make-hash)
>  (λ (h k) (values k (λ (h k v) v)))
>  (λ (h k v) (values k v))
>  (λ (h k) k)
>  ;; key-proc below: can I omit keys? I think not
>  (λ (h k) (if (eq? k 'foo)
>   k
>   #f
> (hash-set! ih 'foo 42)
> (hash-set! ih 'bar 21)
> (hash-set! ih 'zam 7)
> (hash-keys ih) ; '(#f #f foo), want just '(foo)
>
>
>
> [1]
> http://docs.racket-lang.org/reference/chaperones.html?q=impersonate-hash#%28def._%28%28quote._~23~25kernel%29._impersonate-hash%29%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.
> 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] how to get full tracebacks in DrRacket?

[Matthew Butterick]

Whoa! Nice feature, perhaps a little too well camouflaged ;)


> On Jun 30, 2017, at 8:41 AM, Robby Findler  
> wrote:
> 
> You have to click on the icon (to the right of "in-list" in the example) to 
> see it in the current implementation.

-- 
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] can `impersonate-hash` really filter out hash keys?

[Matthew Butterick]

I'd like to make a hash impersonator that has "private" keys that can be 
reached by `hash-ref`, but which are not reported by `hash-keys` and other 
operations that iterate over all keys.

The docs for `impersonate-hash` [1] say that you can "use `key-proc` to filter 
keys extracted from the table". OK, sounds promising. But later, it says 
`key-proc` "must produce a replacement for the key". So apparently it's more of 
a map-like operation than a filter-like operation.

For instance, this key-proc function intends to omit any key but 'foo. But 
AFAICT there is no value you can return that signals "please pretend this key 
does not exist."

#lang racket
(define ih (impersonate-hash (make-hash)
 (λ (h k) (values k (λ (h k v) v)))
 (λ (h k v) (values k v))
 (λ (h k) k)
 ;; key-proc below: can I omit keys? I think not
 (λ (h k) (if (eq? k 'foo)
  k
  #f
(hash-set! ih 'foo 42)
(hash-set! ih 'bar 21)
(hash-set! ih 'zam 7)
(hash-keys ih) ; '(#f #f foo), want just '(foo)



[1] 
http://docs.racket-lang.org/reference/chaperones.html?q=impersonate-hash#%28def._%28%28quote._~23~25kernel%29._impersonate-hash%29%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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Typed Racket Type Annotations - Best Practices?

[Sam Tobin-Hochstadt]

On Fri, Jun 30, 2017 at 10:03 AM, Zelphir Kaltstahl
 wrote:
>
> Ok but what is the best practice? Using:
>
> ~~~
> (ann a Type)
> ~~~
>
> ~~~
> (: a Type)
> ~~~
>
> ~~~
> (a : Type)
> ~~~
>
> and when? For example in a let form, I could imagine that it might be best 
> practice to specify the type where the variable is specified, instead of a 
> new line and a new s-expression.
> But I'd like to read some reasoning or guide from someone who knows a lot 
> about Typed Racket or maybe even worked on it.

The `(ann e T)` form is an expression, which has the type `T`.

The way I'd annotate your term is:

(let ([x : Positive-Flonum 7.0]) x)

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

Re: [racket-users] Hint on opening enclosing directory of current file from DrRacket

[James]

On Jun 28, 2017, at 5:42 PM, Glenn Hoetker wrote:

> Caveats: 1. Since CWD is set to the most recently run file, you have to have 
> run the file whose enclosing directory you wish to open. The default appears 
> to the home directory. 2. I know this works on MacOS. I can't see why it 
> wouldn't work on Unix systems. Windows scares me, so I have idea if it would 
> work there.

The open command, as such, is Mac specific.  The "." argument to open tells it 
to open the current working directory but you can specify any folder or file to 
open.  In Debian, the xdg-open command is very similar.  

-- 
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] Typed Racket Type Annotations - Best Practices?

[Zelphir Kaltstahl]

On Friday, June 30, 2017 at 6:59:27 AM UTC+2, johnbclements wrote:
> > On Jun 29, 2017, at 17:33, Zelphir Kaltstahl  
> > wrote:
> > 
> > A while ago I started looking at Typed Racket and today I took a look again.
> > 
> > The documentation says:
> > 
> >> Typed Racket provides modified versions of core Racket forms, which permit 
> >> type annotations. Previous versions of Typed Racket provided these with a 
> >> : suffix, but these are now only included as legacy forms for backwards 
> >> compatibility.
> > 
> > To me this sounds as if I am not supposed to use them anymore. So I tried 
> > the following, which works:
> > 
> > ~~~
> > racket -I typed/racket
> > 
> > (let ([x 7.0])
> >  (ann x Positive-Flonum)
> >  x)
> > ~~~
> > 
> > So I could use `ann` instead, but is it not as short as the colon notation.
> > Then I also discovered:
> > 
> > ~~~
> > (let ([x 7.0])
> >  (: x Positive-Flonum)
> >  x)
> > ~~~
> > 
> > Which also works. It is not a change in a core form, so I guess this is not 
> > part of the stuff kept for backward compatibility (?).
> > 
> > I'd like to know what the best practice of writing type annotations is. The 
> > guide in the documentation still uses a lot of the changed core forms, 
> > which is my impression are not recommended, since they're only kept for 
> > backwards compatibility, so one should not rely on them.
> 
> I believe this text is referring to forms such as for: and lambda: — that is, 
> syntactic terms where the lambda is attached to the identifier. I believe 
> this text is *not* referring to the use of the colon as a simple “has-type” 
> form.
> 
> John

Hm that could be it! I was already wondering why it was talking about "suffix" 
instead of "infix". I was assuming it meant suffix because it is after the 
first element of the s-expressions and it was a comment next to where those 
were introduced.

Ok but what is the best practice? Using:

~~~
(ann a Type)
~~~

~~~
(: a Type)
~~~

~~~
(a : Type)
~~~

and when? For example in a let form, I could imagine that it might be best 
practice to specify the type where the variable is specified, instead of a new 
line and a new s-expression.
But I'd like to read some reasoning or guide from someone who knows a lot about 
Typed Racket or maybe even worked on it.

-- 
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] Missing request-post-data/raw (from web-server/http)

[Philip McGrath]

Thanks, Jay. It is definitely POST, and there is a Content-Length header,
so it seems like the problem is indeed #3. I was expecting the raw data to
be there even if it had been parsed — I believe the POST data of #
"corpus=austen=corpus.CorpusMetadata" was also parsed into bindings
(though not from multipart, obviously).

So it sounds like what I'll need to do is detect when this situation is
happening — I guess that would be when the method is POST, the
request-post-data/raw
is #f, and there are some bindings — and convert the bindings back into
multipart form data to give to http-sendrecv/url.

-Philip

On Fri, Jun 30, 2017 at 8:20 AM, Jay McCarthy 
wrote:

> Hi Philip,
>
> I don't necessarily know the answer and it's possible that it is an
> error. I'll explain what it is doing and maybe that will help us move
> forward.
>
> 1) The request-bindings/raw is just an abstraction over
> request-post-data/raw (and the URI)
> 2) The request-post-data/raw is always #f for GETs, are you sure they are
> POSTs?
> 3) POSTs with multipart form data are converted into a
> request-bindings and the raw data is not made available, un-parsed.
> 4) If there's no Content-Length header, then even if there is data,
> then it is not exposed.
>
> I think that your problem may be (3). It sounds like you expect to see
> a copy of the raw data of the request all the time even if it has been
> parsed. (The logic of the current behavior is that at the
> "application" level there is no POST data, but there is only form
> data, but because of "transport" level constraints on the length of
> URIs it had to be sent in the data part of the transport layer.)
>
> Jay
>
>
> On Thu, Jun 29, 2017 at 9:08 PM, Philip McGrath
>  wrote:
> > I'm working on a Racket web application for which I need to proxy certain
> > requests to a non-Racket service over HTTP. I've built a very basic
> proxy on
> > top of http-sendrecv/url that works quite well for the most part.
> >
> > For POST requests, I pass the request-post-data/raw of the original
> request
> > as the #:data argument of http-sendrecv/url.
> >
> > However, I've discovered that certain POST requests (specifically
> involving
> > file uploads) are not working as expected. On these requests, Chrome
> reports
> > that it is performing a request with a header
> > Content-Type:multipart/form-data;
> > boundary=WebKitFormBoundaryAJOgATwBujJhhtbY and a payload as
> follows:
> >
> > --WebKitFormBoundaryAJOgATwBujJhhtbY
> > Content-Disposition: form-data; name="tool"
> > corpus.CorpusCreator
> > --WebKitFormBoundaryAJOgATwBujJhhtbY
> > Content-Disposition: form-data; name="palette"
> > default
> > --WebKitFormBoundaryAJOgATwBujJhhtbY
> > Content-Disposition: form-data; name="textarea-1014-inputEl"
> > Type in one or more URLs on separate lines or paste in a full text.
> > --WebKitFormBoundaryAJOgATwBujJhhtbY
> > Content-Disposition: form-data; name="upload"; filename="tmp-file.txt"
> > Content-Type: text/plain
> > --WebKitFormBoundaryAJOgATwBujJhhtbY--
> >
> >
> > However, at the Racket level, request-post-data/raw returns #f for these
> > requests — but, adding to my confusion, the bindings still show up in
> > request-bindings/raw.
> >
> > Why doesn't this content show up in request-post-data/raw? Is there a
> way to
> > access the raw, original data for these requests, or do I need to somehow
> > reconstruct it from the bindings?
> >
> > Thanks very much,
> > Philip
> >
> > --
> > 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.
>
>
>
> --
> -=[ Jay McCarthy   http://jeapostrophe.github.io]=-
> -=[ Associate ProfessorPLT @ CS @ UMass Lowell ]=-
> -=[ Moses 1:33: And worlds without number have I created; ]=-
>

-- 
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] Missing request-post-data/raw (from web-server/http)

[Jay McCarthy]

Hi Philip,

I don't necessarily know the answer and it's possible that it is an
error. I'll explain what it is doing and maybe that will help us move
forward.

1) The request-bindings/raw is just an abstraction over
request-post-data/raw (and the URI)
2) The request-post-data/raw is always #f for GETs, are you sure they are POSTs?
3) POSTs with multipart form data are converted into a
request-bindings and the raw data is not made available, un-parsed.
4) If there's no Content-Length header, then even if there is data,
then it is not exposed.

I think that your problem may be (3). It sounds like you expect to see
a copy of the raw data of the request all the time even if it has been
parsed. (The logic of the current behavior is that at the
"application" level there is no POST data, but there is only form
data, but because of "transport" level constraints on the length of
URIs it had to be sent in the data part of the transport layer.)

Jay


On Thu, Jun 29, 2017 at 9:08 PM, Philip McGrath
 wrote:
> I'm working on a Racket web application for which I need to proxy certain
> requests to a non-Racket service over HTTP. I've built a very basic proxy on
> top of http-sendrecv/url that works quite well for the most part.
>
> For POST requests, I pass the request-post-data/raw of the original request
> as the #:data argument of http-sendrecv/url.
>
> However, I've discovered that certain POST requests (specifically involving
> file uploads) are not working as expected. On these requests, Chrome reports
> that it is performing a request with a header
> Content-Type:multipart/form-data;
> boundary=WebKitFormBoundaryAJOgATwBujJhhtbY and a payload as follows:
>
> --WebKitFormBoundaryAJOgATwBujJhhtbY
> Content-Disposition: form-data; name="tool"
> corpus.CorpusCreator
> --WebKitFormBoundaryAJOgATwBujJhhtbY
> Content-Disposition: form-data; name="palette"
> default
> --WebKitFormBoundaryAJOgATwBujJhhtbY
> Content-Disposition: form-data; name="textarea-1014-inputEl"
> Type in one or more URLs on separate lines or paste in a full text.
> --WebKitFormBoundaryAJOgATwBujJhhtbY
> Content-Disposition: form-data; name="upload"; filename="tmp-file.txt"
> Content-Type: text/plain
> --WebKitFormBoundaryAJOgATwBujJhhtbY--
>
>
> However, at the Racket level, request-post-data/raw returns #f for these
> requests — but, adding to my confusion, the bindings still show up in
> request-bindings/raw.
>
> Why doesn't this content show up in request-post-data/raw? Is there a way to
> access the raw, original data for these requests, or do I need to somehow
> reconstruct it from the bindings?
>
> Thanks very much,
> Philip
>
> --
> 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.



-- 
-=[ Jay McCarthy   http://jeapostrophe.github.io]=-
-=[ Associate ProfessorPLT @ CS @ UMass Lowell ]=-
-=[ Moses 1:33: And worlds without number have I created; ]=-

-- 
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] TCP no delay (De-activating Nagle's algorithm).

[Maël N .]

Hello,

When implementing latency-sensitive TCP application, it's really common to use 
the option TCP_NODELAY do de-activate Nagle's algorithm 
(https://en.wikipedia.org/wiki/Nagle%27s_algorithm).

I found no way in racket/tcp (https://docs.racket-lang.org/reference/tcp.html) 
or racket & openssl (https://docs.racket-lang.org/openssl/) to use this option.

This make implementing latency sensistive application in Racket difficult 
because you have to either reimplement racket/tcp to be able to add the option 
TCP_NODELAY or reimplement your protocol using UDP (which might not be 
desirable).

Has anyone found a way to use TCP_NODELAY in a simple and "Rackety" way ?
Do you think it's worth opening an issue on Racket repository to ask for this 
option to be added to racket/tcp & openssl ?

Faithfully yours,

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