Yes, that makes sense. future-visualizer/trace seems best (especially since future-visualizer will re-export all of future-visualizer/trace).
Robby On Wed, Jul 11, 2012 at 8:06 AM, Matthew Flatt <[email protected]> wrote: > 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
