If you mean that a connection to the runtime system implies being in the "racket" collection, I'd say that isn't necessarily so. (The "ffi" collection relies on a connection to the run-time system, for example.) So, it would make sense to me to move that to "future-visualizer", too.
I can also see how you might want to keep the trace support available separate from the visualizer, in which case `racket/future/trace' seems better than merging it into `racket/future'. But I still think that `future-visualizer/trace' is better for now, and it could be moved back out if there's ever actually another consumer of the library. At Wed, 11 Jul 2012 07:57:20 -0500, Robby Findler wrote: > There are two pieces to the visualizer: one part extracts traces from > a computation and the other part shows them. The trace-extraction part > requires a connection to the runtime system and is, I believe, > currently in racket/future/trace. Should that be moved into > racket/future, or kept as a separate piece in racket/future/trace? (Or > something else?) > > Robby _________________________ Racket Developers list: http://lists.racket-lang.org/dev