@ben you might be interested in datum->syntax

as well as this line from the docs for datum->syntax: “Mutable vectors and boxes are replaced by immutable vectors and boxes.”

@samth That makes sense for one direction. But then it doesn’t make sense why when its done at phase 1 the vector becomes mutable.

@leif I agree, I don’t understand what’s going on there

but that should be investigated without using 3 layers of quoting

@samth Ha, ya, I do agree with that.

and is unrelated to the typing issue

I also agree with that.

(I forgot that this originated from a typed/racket thing. @ben and I were discussing it (outside of slack) without the context of TR.)

@mflatt (Or anyone else familiar enough with the FFI to answer), I have the following program that uses ffi/unsafe/alloc: https://gist.github.com/LeifAndersen/353e0da21d9213dcd6a79cbd9b8c94ee

In a loop, it allocates a frame, relying on the GC to clean up.

However, it leaks memory very quickly.

yes @samth thanks for pointing out datum->syntax. Here’s another phase 1 example (still returns the weird result) #lang racket/base (require (for-syntax racket/base)) (define-syntax (foo stx) (with-syntax ((x (datum->syntax stx (vector-immutable 1)))) (syntax (syntax x)))) (immutable? (syntax-e (foo)))

BUT, if I remove line 15 (the deallocator wrapper), it stops leaking memory.

Does anyone have any suggestions?

@ben here’s the bug:

(For the record, if I remove both alloc and dealloc, and just call the av-frame-free function by hand everything works fine.)

> (immutable? (syntax-e (quote-syntax #(1))))
#f

note that syntax->datum does the right thing

leif: The short answer is that the finalization system used by allocator is not good enough (and wouldn’t be good enough in most runtimes). Finalizers via allocator are run in a separate thread, so the program requires a combination of a GC and a context switch and another GC before some relevant memory can be reclaimed. Some solutions might involve limiting the allocator via (sleep) or forcing an occasional GC via (collect-garbage).

I now see the rest of your original message, and I’m puzzled offhand that removing #:wrap (deallocator) helps, so I’ll investigate a little more.

@samth and @ben FWIW, I ran this test on Racket7, and got: leif@FATT ~/src/racket7/racket/bin (master) $ ./racket test.rkt -------------------- FAILURE name: check-false location: test.rkt:4:0 params: '(#t) message: "(syntax-e (syntax (vector))) made immutable vector" -------------------- -------------------- FAILURE name: check-false location: test.rkt:19:0 params: '(#t) message: "(syntax-e (syntax (vector))) made immutable vector" --------------------

So I’m pretty sure there is a bug here.

^ this test = http://pasterack.org/pastes/86496

(point is, now the failures are consistent)

As far as I can tell, adding #:wrap (deallocator) slows down av-frame-free enough that the finalization thread moves more slowly than the allocation thread, so my original answer is still what I think is happening. Removing #:wrap (deallocator) might be a reasonable solution if av-frame-free is not to be called directly.

Ah, okay, thanks makes a lot of sense. Thank you.

That would also explain why writing my own finalizer (and a single thread that calls the will executors in a loop), doesn’t have the same problem.

If I register a will for a value exported by a module, can that will ever be executed?

use case is a value used by test modules, wondering if it can be automatically cleaned up after the tests finish by relying on raco test somehow

@notjack The namespace where the module is instantiated would have to become inaccessible, including not being current-namespace

@mflatt if I raco test -p mypackage, which contains some test submodules that require a module providing a value with an attached will, would raco test’s shutdown process trigger the will execution? would running the tests in parallel with -j affect that?

@notjack No, I don’t think raco test will trigger the will execution. Either you’re in --direct mode and it’s all done in one namespace or the relevant place/process exits still holding its namespace

drat

Matthias surprised me – no easy feat, since this is about 3′ x 4′ – with a movie poster for my office.

leif: Hi Leif!

Awwww

is there an addendum for the redex book anywhere? the syntax in the book is a bit crufty. not sure what else changed