@lexi.lambda the drawback of exporting keyword functions from the expander is that then the expander code needs to have the full kw infrastructure compiled in

I can’t remember if the current status eliminates it all, but it should be possible currently

@ben I think the struct-predicate optimization generates (-> any/c any/c) contracts when it should generate (-> any/c any) contracts

yes, this program shows the problem: #lang typed/racket (: f : Any -> Boolean) (define (f x) (string? x)) (provide f)

@samth re: expander keyword functions, I agree that the performance of the expander is critical, so I’d be okay with having to do the racket/base wrapping if it’s really necessary. I just think it would be an awkward limitation if all of the functions in the syntax local zoo were restricted from every using keyword arguments.

@lexi.lambda I agree that kw arguments are useful, which is why the wrapping is sensible — it’s already done for lots of functions like call-with-input-file

yes, that’s all I really meant by “it would be useful in general to be able to export functions with keywords from the expander layer”, but in retrospect, I don’t think that was the best phrasing

@ryanc Poke?

is it possible to set environment variables for the package server builds? I want to see some log events, so I want to set PLTSTDERR

Is there any way to handle VM out of memory conditions in Racket?

I sometimes hit these for big computations, and I’d like to “catch” the error and terminate that computation, instead of terminating the whole program.

Or should I do everything inside custodians with memory limits?

@pavpanchekha Maybe someone will have better advice for you later, but: I think yes I’d try using custodian-limit-memory. Do note the caveats in the docs. The limit is checked only when a GC is done. You may exceed the limit; the limit might need to be much less than actual available memory. https://docs.racket-lang.org/reference/custodians.html#%28def._%28%28quote._~23~25kernel%29._custodian-limit-memory%29%29

Also FYI racket/sandbox provides call-with-limits and with-limits. The memory limit aspect of these is implemented using custodian-limit-memory. But, they might be simpler one-liner wrappers you could try first.

(As a mitigation for the memory limit being checked only during GC, I suppose you could try calling collect-garbage manually at “suitable intervals”, but that’s a bit hacky and idk if it would actually help much.)