Is there a way to inspect from the repl what method an interface provides?

is there a similar way to inspect other types (eg structs)

?

Yes, see interface->method-names

thanks!

Hmm I am trying

> (reuqire data/monad) > (interface->method-names gen:monad) ; :53:25: gen:monad: illegal use of syntax ; in: gen:monad ; value at phase 1: #<generic-info>

I believe there’s a difference between interfaces and generic interface s; an interface is an object-oriented concept defined in racket/class whereas a generic interfaceis a concept defined in racket/generic and the two are not connected

In <https://docs.racket-lang.org/syntax/stxparse-intro.html|the syntax-parse introduction> , after adding the “distinct-bindings” syntax class the code switches from (_ (b:binding ...) body ...+) to (_ bs:distinct-bindings . body) i.e. from body ...+ to . body . This seems like a mistake since the error message changes from: ; /Users/badkins/sync/code/racket/syntax-parse/1.1.rkt:40:0: mylet: expected more terms starting with any term ; at: () ; within: (mylet ((a 1) (b 2))) ; in: (mylet ((a 1) (b 2))) to the inferior: ; /Users/badkins/sync/code/racket/syntax-parse/1.1.rkt:21:8: λ: bad syntax ; in: (λ (a b)) or am I missing something?

It also then switches back in the next section.

Yeah, it should be body ...+.

I think the doc simply wants to demonstrate the distinct-bindings syntax-class, so it didn’t care about other patterns.’

I’m finding other issues, so I think I’ll queue up some doc pull requests.

hmm, and racket/generic does not seem to provide a similar function

So for Racket Mode I have a WIP multi-back-end branch that lets you use multiple back ends. (Racket Mode has an Emacs Lisp front end, and a Racket back end. The back end implements various “commands”.)

The original motivation is a neat PR https://github.com/greghendershott/racket-mode/pull/553. But for this to work properly Racket Mode needs more changes to support a remote vs. a local back end.

Also I wanted to generalize this to support any mix of local and remote back ends. (For example, maybe you want files in some project to use Racket 8.2 locally, but in some other project you need Racket 8.0, and it would be handy to work with both projects at once.) Ergo the bigger branch I’ve been working on, to explore what that would mean.

To test I’m renting a little AWS LightSail host, with just 4 GB. One thing I noticed is that certain documentation operations would result in the Linux oom-killer abending the process. I’m still thinking about this, but one thing I’m trying is to do a major GC around the ops, which seems to help: https://github.com/greghendershott/racket-mode/commit/755f1557bc474c7941aefdfaca74f84ab190085d

But it also seems kind of kludgy. So I wanted to toss it out here to see if anyone has any better ideas.

TL;DR: Is it dumb to (collect-garbage 'major) in an effort to make Racket less likely to ask the OS for more memory that it might not actually need?

Hi greg, I am fakedrake on github. I did come back from my vacation finally but I forgot about the branch, sorry about. Just wanted to thank you for actually coming through with this despite my flaliness

@christos.perivolaropo Oh, hi! :slightly_smiling_face:

No worries. It was a great PR! It just pulled on a thread and before the whole sweater unraveled I needed to do a lot of thinking. :slightly_smiling_face:

I think that approach will reduce peak memory consumption

One warning: we had a serious problem in the handin-server related to forced GCs: https://github.com/racket/handin/commit/719148138c6551c66505b019de73b8ff92599f42

@samth Thanks for that feedback re peak use. I believe the handin-server situation is different, because 1. I’m not trying to impose a limit, and 2. getting oom-killed represents a failure to make progress :slightly_smiling_face: — but I’ll also reflect on that awhile and see if I have some other ideas.

Right, I don’t think that situation is like yours, but it seemed related-enough to mention