@mflatt should I revert any changes that deleted trailing white spaces in my pull request? like in this one: https://github.com/racket/racket/pull/2893/files

Porting question: I’m looking into porting some Java and C# code to Racket. Are there any major gotchas in the translation process or should it go fairly smoothly? From my toplevel reading, Racket’s object system appears to match up pretty well.

Whitespace changes are not ideal, but to me also not worth worrying about.

object construction is the major thing that’s different

There aren’t class or static methods either right? You can generally hoist those to the top.

@steveh2009 FWIW The paper on the Racket object system is here: https://www.cs.utah.edu/plt/publications/aplas06-fff.pdf

I’ve recently been unhappy with how much memory Herbie uses. Is there a heap profiler for Racket? In particular I can’t think of many data structures in Herbie that use a lot of memory, but we do load a lot of libraries (including big ones like plot).

Alternatively, is there a way to share those libraries across place-based threads?

It looks to me that each place has a separate copy of each library.

For numbers, in its “lightest” mode Herbie uses about 200MB before doing anything, and in its “normal” mode about 400MB.

If you compile Racket with --enable-backtrace, you will get a bunch of information when you execute dump-memory-stats.

Hmm, thanks!

It would be really nice to have a profiler for how much memory the instantiation of each module costs. That combined with info about the module dependency graph would make it easier to see where it would help to split up modules so that clients don’t pull in a bunch of unneeded code.

@pavpanchekha it’s strange to me that each place you’re creating is loading that many libraries. I would assume a structure that’s more like a master thread that loads a lot of libraries, but which dispatches out tasks to worker places whose implementations only require the libraries needed for that specific task

You could probably build that by extending the module name resolver.