Perfect, it’s working. Thanks.

@notjack because sandboxes exist already, eval is set up nicely, the linklet level is not designed for this

Any ideas to why I am getting this error?

Have you installed it?

I installed the Full Racket v7.3.

This is a package by @lexi.lambda I think

collections-lib

http://lexi-lambda.github.io/racket-collections/index.html

So it’s not included in the base package

That’s a different package. See https://docs.racket-lang.org/collections/index.html?q=data%2Fcollection

Modules like data/gvector and data/bit-vector work fine.

mbp:~ soegaard$ ls "/Applications/Racket v7.3/collects/data/"
bit-vector.rkt	compiled	integer-set.rkt	private		queue.rkt

If I have data coming into my Racket app through a socket, need to build them up into messages, queued to be responded to by the app, Do you think the best way to go is to put each message into a struct and then put’em an async channel? Thanks for the advice.

…put them on an async channel.

@steveh2009 That sounds about right.

@sorawee You were right. It was collections-lib.

And it even says to the the right side in the docs: https://docs.racket-lang.org/collections/index.html?q=collection

Still a bit confused about how one can make modules that appear under data/

Okay - got it now. There is a search path. lexi-lambda just used the same name (so the collection and the packages are stored in two different locations).

@mbutterick you can’t

@steveh2009 This might be more detail than you need or want to care about, but: Keep in mind that an async-channel has a buffer. (make-async-channel) defaults to “the buffer can grow until you run out of memory”. Maybe that’s OK, especially for a first version where you care about getting other things to work. Instead, you can give make-async-channel a maximum number of elements. In case you need “back pressure”. (“Thank you, socket, but I can’t keep up so I’m going to start NACK-ing or dropping packets.”)

(Or, “I’m going to block and not read more, yet, so, some lower layer is going to nack or drop”)

@mbutterick it seems void can be serialized (https://docs.racket-lang.org/reference/serialization.html), so I think adding a serialization as a middle step would solve the problem?

@sorawee yes, you can use serialization but that won’t make file->value (which is just a wrapper around read) work

Right, (void) is not readable. As @sorawee suggests, serialize is probably a good choice, depending on what else you need to write.

another option is the racket/fasl library

@greg The library I’m thinking of porting is Interactive Brokers trading API. Probably have to dump the responsibility of not consuming messages on the client app side because a real-time trading app can’t afford to have any messages dropped.

or delayed

@steveh2009 I could definitely make use of such a library! :slightly_smiling_face: Do let me know if you get around to it. Good luck.

This? https://interactivebrokers.github.io/tws-api/introduction.html

> The TWS is designed to accept up to fifty messages per second coming from the client side…. On the other hand, there are no limits on the amount of messages the TWS can send to the client application. ¯_(ツ)_/¯

I guess that explains Apache Kafka’s name :grin:

Anyway you said “socket” and for some reason I heard “UDP”. If you’re reading from TCP, then you’ll read as fast as you can and the buffering and retries is ultimately up to them.

@pocmatos Will do. I wanted something that can run on Windows, Linux and Mac, be able to code in a LISP (b/c fun is more important at my age), give end-user multiple script language options, and have a well integrated graphics API to work with. AND have excellent docs and community for a LISP noob like me to reference. Well, Racket is pretty much it.