TIL about <https://docs.racket-lang.org/reference/fasl.html|Fast-Load Serialization> - thanks @massung :)

is there a function that does the same as clojure’s slurp https://clojuredocs.org/clojure.core/slurp

?

file->string is the closest I can think of

More generally, there’s port->string which consumes a port as an argument

And you can provide a file port, or a HTTP port

yes port->string is the one, thanks!

Is there a way for me to make a hash table w/ an initial size (ie, # of buckets/slots)?

No, there isn’t. (Note that make-hash creates an empty hash and incrementally fills it.)

The underlying Chez procedures support a capacity argument, so adding the feature should be relatively straightforward.

is there a way to require non-provided symbols from a file?

require/expose

Is there a standard multiplex port like such that (fprintf (mux-ports p1 p2) "abc") will send "abc" to both p1 and p2?

“standard” as in “one that I don’t have to install or implement”

combine-output

Thanks!

in my case, i just know the hash gets large, and would like to reduce the resize/copying that takes place

is there any difference between (fprintf p "xyz ~a abc\r\n" "/") and (fprintf p (format "xyz ~a abc\r\n" "/"))?

The context is that p is an http port and the former prompts a slightly different response from the server.

Those should be the same (although more generally the second one can do format string substitution twice).

Yep. Same output.

#lang racket

(define p1 (open-output-string)) (fprintf p1 "xyz ~a abc\r\n" "/") (get-output-string p1)

(define p2 (open-output-string)) (fprintf p2 (format "xyz ~a abc\r\n" "/")) (get-output-string p2)

“xyz / abc\r\n” “xyz / abc\r\n”

Ok. This is what the thread we were talking about yesterday boils down to ( https://racket.slack.com/archives/C06V96CKX/p1643651087419999

Changing a single line fixes it: (fprintf p "~a ~a HTTP/~a\r\n" .... ) to (fprintf p (format "~a ~a HTTP/~a\r\n" .... ))

not even to all lines of the request header. Just this line of the header determines if the response contains a header or if it’s just the body

and I can’t reproduce it on any other network

:disappointed:

Which single line are we looking at?

In http-conn-send!?

yes

My guess is that it’s about how many bytes are sent at once. Probably the former writes each interpolated piece separately to the port, whereas the latter processes the entire string at once.

http-client.rkt:162

And something on your network is doing things too eagerly, or something like that.

probably right @samth are there any relevant knobs I can turn?

You could test it by changing the line to use multiple calls to fprintf without the format and see if that breaks.

It’s also possible that there’s some buffer size configuration on something that you could change.

Exactly, breaking it into 3 printfs reproduces the problem

(fprintf to "GET ") (fprintif to "/") (fprintf to " HTTP/1.1\r\n")

does the bad thing

(fprintf to "GET / HTTP/1.1\r\n") does the good thing

I’m pretty sure that this indicates a bug somewhere in your computer/OS/network/firewall/etc.

makes sense

thanks!

BTW, you should either use (fprintf p "~a" (format ___)) or (write-string (format ___) p). That is, it’s almost always a bad idea to call fprintf etc with a computed format string, since it might happen to contain formatting directives.