@mflatt @robby I am seeing a problem where drracket/check-syntax show-content returns bad pathnames in syncheck:add-jump-to-definition items. This doesn’t seem to happen in DrRacket itself, just via show-content. I’ve spent some hours trying to figure it out myself, but I’m stumped. A short write-up: https://gist.github.com/greghendershott/5dd59c00f8daa2ce0987ad343244489e

The TL;DR seems to be that somehow a #<module-path-index:"b.rkt" + '\|expanded module\|> results, and becomes a #<resolved-module-path:"/tmp/a.rkt/b.rkt">.

@stchang et al. https://www.reddit.com/r/Racket/comments/ev3gdu/dependent_type_systems_as_macros/

I think you’re right that it’s about current-load-relative-directory. That’s set in “traverse.rkt” to the path passed in to make-traversal.

The argument to make-travseral appears to be a file path, not a directory, in “check-syntax.rkt”.

I don’t think that’s it. I had tried adjusting that to be path-only, but same result.

I will double-check, though.

I had a run where my hacky “trace” showed current-load-relative-directory to be simply "/tmp/", and I was still getting that “unusual” (to me) #<module-path-index:"b.rkt" + '\|expanded module\|> (but maybe that is a red herring) and the wrong "/tmp/a.rkt/b.rkt".

@mflatt and @robby DrRacket seems to have a memory leak when closing files.

Namely, not only does it not return memory to the OS when you close a file, but it also doesn’t seem tore-use that memory when a new tab is opened.

I am trying to use racket/sandbox ’s make-evaluator within an application distributed with raco exe , but I’m having trouble getting the lang (racket in this case) embedded in such a way that it works with make-evaluator . I’m currently doing something like:

(define-runtime-module-path-index the-lang 'racket) (make-evaluator (resolved-module-path-name (module-path-index-resolve the-lang))) But this fails when run from an executable generated with raco exe with:

make-evaluator: bad language spec: '#%embedded:racket/main:

I’ve tried other things such as using passing ++named-lib '' racket (i.e. a named lib with an empty prefix) and a plain ++lang racket to raco exe , but both approaches fail. Is there something I’m missing or is this a bug in make-evaluator ?

I’m not able to reproduce the leak.

I opened a file, gc’d to a fixed point, opened another file, gc’d to a fixed point, closed the second file, and gc’d and it didn’t go down, but when I opened and closed a third file, things went back down to the original fixed point (actually below it).

(Also, there is a test on drdr for this)

@robby It seems to be a problem even if you close and reopen the same file.

Like, DrRacket’s memory usage slowly climbed from 600 MB to 1.2 GB as I closed and reopened a file.

I’ll see if I can find a nice way to record it for you.

what if you click on the gc icon .a lot, @leif ?

Does that eventually make things go back down?

@robby Sadly nope

I have a recording now, uploading it.

any advice on how to watch this video?

oh, it disappeared

Ya, sorry, I expected slack to stream it. Reuploading it to youtube.

@robby Okay, here it is:

https://www.youtube.com/watch?v=m2h0wbMdFts

I can’t claim to understand the relationship between the number that racket reports and the number that the OS reports but the numbers that racket reports don’t look like a leak to me

In particular at the 1:01 mark in the video you’re back down to 511MB

Ya. that makes me inclined to think that if anything, its a racket VM bug, rather than a DrRacket specific one.

Maybe.

I don’t see you clicking onthe gc icon much

Right, well according to DrRacket.

I only do it at the end.

I think there was only one major collection in the video?

Yeah, you need those if you want memory to go back to the OS

You need to do it more.

(Or maybe someone could tune the GC I suppose but it has been tuned a lot over the years.)

I mean, I clicked on it a lot at the end.

And it still didn’t go down.

(By that I mean what the OS reported, rather than what DrRacket claimed)

Maybe you have to click on the numbers

from 1:13 on when your mouse is over the gc icon, there is no gc actually happening

While I didn’t try that in this video, I have tried that before.

sorry, I don’t have anything more useful here :disappointed:

No worries. I’ll play with it more.

Thanks anyway. I appreciate the suggestions you’ve given me. :slightly_smiling_face:

There are so many pitfalls here.

The first one is that the result of resolved-module-path-name is not generally a module path: it’s a path (which does turn out to be a module path) or a symbol.

Another set of problems is related to the fact that make-evaluator creates a new namespace with a new module registry, so modules defined in the original registry need to be attached via sandbox-namespace-specs.

And then there are more issues with the configure-runtime submodule.

And there are issues with filesystem access, definitely for a dumb reason in the first case that I hit, but there may be more.

Long story short, when using raco exe ++lang racket, I can get this to work:

#lang racket/base (require racket/sandbox) (parameterize ([sandbox-namespace-specs (append (sandbox-namespace-specs) (list 'racket 'racket/runtime-config))]) (call-with-trusted-sandbox-configuration (lambda () (make-evaluator 'racket)))) Using call-with-trusted-sandbox-configuration to avoid the filesystem issue may well defeat the point for your purposes.

Thank you for digging into this! For now I’m going to distribute the app in source form, alongside a Racket install since that seems like the path of least resistance.