The db library currently only creates one extra place to perform queries. One solution would be to create a separate non-place connection for the query you expect to be short. Or I can add the ability to create db places and choose which one is used by a new connection. (Place creation and initialization is somewhat expensive, so I didn’t want to create a new place per connection by default.)

I see. To give some context:

On a cliente, we have a “document format” built on top of SQLite, each document being a SQLite file on the server. Currently we have a Java web app to expose and manage the documents (versioning, editing, generating reports, etc). Depending on the day of the month, we can have about 200 people working simutaneously on 150 different documents. So basically we have lots of shortlived connections to multiple SQLite databases. This app is in production for some time and is working fine, but…

We are working on a prototype for a 2.0 version that builds on this “conceptual core” and adds workflow, data validation, custom users scripts, etc. We’ll build it from scratch, and hopefully in Racket =)

Given the strong dependency on SQLite as our data storage format (and we don’t have any reasons to change that in the forseable future), is there alternatives for this use case? Maybe we can build a specific SQLite API via FFI?

I think now I understand the problem: Racket threads are not “OS threads”, so if a ffi call take some time, the whole thing blocks. Places are “OS threads”, that’s why we need them…

Just opened a PR for the define-inline bug

Does anyone have useful tricks in hunting down memory leaks in long running Racket programs?

The not-very-documented (dump-memory-stats) is helpful here.

particularly because you can get backtraces indicating what keeps objects alive

One thing I’ve learned I should keep in mind is ‘reachability’. The GC can’t claim objects that may still be reachable later.

(like an if where you know the condition is false but the compiler doesn’t figure it out)

Wow, (dump-memory-stats) does look helpful

Is there a way to get a struct with prop:struct-info and prop:rename-transformer to play nicely together?

#lang racket (require (for-syntax racket/struct-info)) (begin-for-syntax ;; Simplified compile-time metadata (struct my:struct-info [info] #:transparent ;; If the rename-transformer doesn't exist, the match expander works #:property prop:rename-transformer (λ (stx) (cadr (my:struct-info-info stx))) #:property prop:struct-info (λ (stx) (my:struct-info-info stx)))) (define-syntax foo (my:struct-info (list #f #'cons #'pair? (list #'car #'cdr) (list #f) #t))) (foo 1 1) ;; Illegal syntax error in pattern (match '(1 . 2) [(foo x y) x])

Can you add a layer of indirection?

Sorry, I don’t quite understand what you mean by a layer of indirection (not sure where it would help?).

A macro that expands into something that has the struct info property

alternatively you could make it a match expander

Oh I see - you mean the rename expands into something with a struct-info?

Yes

Yeah - I think I can do that. (I’d ideally not go down the match-expander route because I wanted them to have the same id).

What do each of the columns generally mean?

maybe objects and bytes?

hex number or do I have much more memory than I thought? # of installed finalizers: 4e34

I’m on CS so I think the format may be a little different. At least according to the docs.

Hmm - I’m not sure it works; it expands the rename recursively so no-matter how many levels of indirection I’m using, if I have a rename at that level (which I need to otherwise the constructor isn’t bound). @samth maybe I’m misunderstanding your suggestion?

I’m working on a language that simulates variables using set!-transformer. How should I deal with #%variable-reference?

More elaborately, I transform:

(define-values (x) v) into

(splicing-let ([x* (box v)]) (define-syntax x (syntax-id-rules (set!) [(set! _ b) (set-box! x* b)] [(_ . args) ((unbox x*) . args)] [_ (unbox x*)]))) x is now a macro, so it doesn’t have a location, so (#%variable-reference x) fails. I also try changing it to (#%variable-reference x*), but that somehow fails too.

This is a transformation at #%module-begin, FWIW, since I want to catch everything that expands to define-values.

I suppose you could change (define-values (x) v) to (define-values (x) v) (define-values (x-loc) 'dummy) and let the location of x-loc represent the location of x.

But maybe there is something simpler?

Oh, of course, splicing-let will fail because x* is out of scope outside splicing-let, duh

Yep, an additional define-values should do the trick, thanks!

I see that (#%variable-reference) produces an anonymous variable reference. Could (#%variable-reference x) simply expand to (#%variable-reference) ?

Confirmed define-values works! I honestly am not sure about the semantics of #%variable-reference, so I would leave it alone for now.

I have learned that managing srclocs for good errors is an art, and syntax/loc is your friend.