> ...
> So far, I have made two attempts to work around these issues: (1) by creating
> a metamodel-like data structure using Racket structs, and transforming syntax
> objects into struct instances; or (2) using syntax objects only and attaching
> context data to each of them as a syntax
Norman Gray writes:
> But what happens in this case (the my-app/error case in my example) is
> that the (server) program keeps going but the client stalls. The
> unexpected error in the response-output procedure is caught, and (as
> far as I can see) handled by killing the producer thread
I'm assuming chunked Transfer-Encoding, which is IIRC what the Racket web
server uses for unknown-length payloads. If the server hasn't committed to
chunked encoding (by sending the header), then it probably hasn't sent the
status code either. So truncation is definitely detectable.
RFC 7230
Ryan and Matthew, hello.
On 25 May 2020, at 19:43, Ryan Culpepper wrote:
As I understand the HTTP protocol (that is, some but not lots), the
most
reasonable thing for the server to do if it discovers an error after
the
status code has been sent seems to be to just hang up and let the
AFAICT this is the intended behavior. To me it is consistent with the usual
policy: an uncaught error stops the program. If you want the program to keep
running, then you have to catch the error and make other arrangements. All my
servlet routes are surrounded by a top-level `with-handlers`
As I understand the HTTP protocol (that is, some but not lots), the most
reasonable thing for the server to do if it discovers an error after the
status code has been sent seems to be to just hang up and let the client
realize that *something* went wrong. I don't mean just truncate the output;
I
Thank you, Brian and Jesse, for your thoughts on this. There may still
be an exception problem here, though.
(and sorry for being sluggish to respond)
On 16 May 2020, at 20:16, Norman Gray wrote:
Now, in tracking this down I can see that I have a wrong design here:
the servlet has
Thank you Ryan and Ryan.
I think make-element-id-transformer is the easiest solution.
(let ([set #f]) (racket set)) is nice too because it can be used just where
needed.
I’ll try if that works around an interaction too.
An expression containing ‘set’ both as local and as imported variable
You can also use make-element-id-transformer, like this:
(define-syntax SET
(make-element-id-transformer
(lambda _ #'(racketvarfont "set"
Then Scribble will automatically replace SET within rendered code with the
element expression above.
Another trick is to break the
My favorite way to avoid this problem is simply to choose another name, or
use `except-in` to avoid importing `set` for-label. But if you must use the
name `set` and you want it linking to racket/set most of the time (but not
this time), here is a technique I've used in the past:
#lang
On Thursday, April 30, 2020 at 3:59:49 PM UTC+8, Laurent wrote:
>
> Alex, that looks like an interesting workflow. Maybe worth a blog post? ;)
>
Well, it took longer than I anticipated, but here it is:
https://alex-hhh.github.io/2020/05/dependency-management-in-racket-applications.html
I
Hi Guillaume,
Thanks for taking the time to write this question.
...
> My main concern is about managing the scopes/lexical contexts in my
language.
> I am still browsing the documentation but I have found no library or
guide that addresses this issue.
> The language examples that I have found
12 matches
Mail list logo
