I don't know if there's consensus here yet, but it seems like the best
thing is to move racket/future/visualizer into a top-level:
future-visualizer. Then racket/future/trace will become
future-visualizer/trace. If that sounds reasonable, I'll go ahead and move
them.
On Thu, Jul 12, 2012 at
Robby, could you share w/ us why you don't like the tool designation for the
Optimization Coach and the Future Visualizer? Or if you can't articulate the
dislike for 'tool', can you say what a better word is?
Eli, could you share w/ us why
tool/optimization-coach .. with everything in it
On Thu, Jul 12, 2012 at 1:14 PM, Matthias Felleisen
matth...@ccs.neu.edu wrote:
Robby, could you share w/ us why you don't like the tool designation for the
Optimization Coach and the Future Visualizer? Or if you can't articulate the
dislike for 'tool', can you say what a better word is?
-
On Jul 12, 2012, at 2:19 PM, Robby Findler wrote:
On Thu, Jul 12, 2012 at 1:14 PM, Matthias Felleisen
matth...@ccs.neu.edu wrote:
Robby, could you share w/ us why you don't like the tool designation for the
Optimization Coach and the Future Visualizer? Or if you can't articulate the
On Thu, Jul 12, 2012 at 1:28 PM, Matthias Felleisen
matth...@ccs.neu.edu wrote:
On Jul 12, 2012, at 2:19 PM, Robby Findler wrote:
On Thu, Jul 12, 2012 at 1:14 PM, Matthias Felleisen
matth...@ccs.neu.edu wrote:
Robby, could you share w/ us why you don't like the tool designation for
the
An hour and a half ago, Matthias Felleisen wrote:
Eli, could you share w/ us why
tool/optimization-coach .. with everything in it for this software
tool/future-visualizer .. with everything in it for this software
is a bad idea? Perhaps I am old but I do see a lot of value in a
deep
I spent some time working with taxonomies and ontologies, and switched
to generally preferring that the permanent names for things be in a flat
namespace, and that any organizations (e.g., hierarchical) be separate,
indirect, and more fluid.
One possible exception is when there is a strong,
On Jul 12, 2012, at 3:53 PM, Eli Barzilay wrote:
I think that the single directory is ultimately easier to deal
with, even when there is a package system that can keep track of
files in different places. There are *many* advantages that you can
get out of it. To name a few:
- It's
On Thu, Jul 12, 2012 at 3:57 PM, Matthias Felleisen
matth...@ccs.neu.edu wrote:
All I regret is that we have a very shallow structure now, and I think it
would have helped if we had stuck to about a dozen or so categories after all.
I think the modern experience is that a flat hierarchy (or
I think the tool should be outside of the racket collection, too, and
a future-visualizer collection sounds right to me.
At Wed, 11 Jul 2012 01:33:02 -0400, Eli Barzilay wrote:
An hour and a half ago, Robby Findler wrote:
On Tue, Jul 10, 2012 at 10:41 PM, Eli Barzilay e...@barzilay.org wrote:
Uncle.
Robby
On Wed, Jul 11, 2012 at 7:14 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
I think the tool should be outside of the racket collection, too, and
a future-visualizer collection sounds right to me.
At Wed, 11 Jul 2012 01:33:02 -0400, Eli Barzilay wrote:
An hour and a half ago,
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
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
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 mfl...@cs.utah.edu wrote:
If you mean that a connection to the runtime system implies being in
the
At Wed, 11 Jul 2012 01:33:02 -0400,
Eli Barzilay wrote:
Or maybe add a new tools collection for other similar things?
I'm about to push the new version of Optimization Coach (formerly
Performance Report). Since it now works with any language (not just TR),
it would make sense to move it outside
(Performance) tuning?
Vincent
At Wed, 11 Jul 2012 10:04:46 -0500,
Robby Findler wrote:
tools seems like too generic of a word. Is there something like
performance-debugging that isn't so long?
Robby
On Wed, Jul 11, 2012 at 9:58 AM, Vincent St-Amour stamo...@ccs.neu.edu
wrote:
At
Better than tools, IMO. How about perf? Ie, perf/future-visualizer
and perf/optimization-coach/ ?
Robby
On Wed, Jul 11, 2012 at 10:10 AM, Vincent St-Amour stamo...@ccs.neu.edu wrote:
(Performance) tuning?
Vincent
At Wed, 11 Jul 2012 10:04:46 -0500,
Robby Findler wrote:
tools seems like
A point to consider here is that this should also be the place for a future
profiler thing, and maybe other less pref-y things...
On Jul 11, 2012 6:39 PM, Robby Findler ro...@eecs.northwestern.edu
wrote:
Better than tools, IMO. How about perf? Ie, perf/future-visualizer
and
A future profiler seems like a performance related tool, no?
(Also, I think the profiler could move into this library.)
Robby
On Wed, Jul 11, 2012 at 11:01 AM, Eli Barzilay e...@barzilay.org wrote:
A point to consider here is that this should also be the place for a future
profiler thing, and
I would prefer the full word, performance.
But with a name like that, I would expect things from
`racket/unsafe/ops' and `racket/performance-hint' to be there. Tuning
doesn't carry the same expectation (to me, at least).
Vincent
At Wed, 11 Jul 2012 10:39:53 -0500,
Robby Findler wrote:
What about naming the collection tuning?
Robby
On Wed, Jul 11, 2012 at 11:34 AM, Vincent St-Amour stamo...@ccs.neu.edu wrote:
I would prefer the full word, performance.
But with a name like that, I would expect things from
`racket/unsafe/ops' and `racket/performance-hint' to be there. Tuning
+1
Vincent
At Wed, 11 Jul 2012 12:04:11 -0500,
Robby Findler wrote:
What about naming the collection tuning?
Robby
On Wed, Jul 11, 2012 at 11:34 AM, Vincent St-Amour stamo...@ccs.neu.edu
wrote:
I would prefer the full word, performance.
But with a name like that, I would expect
Would tuning work?
And can you say more about how the whackers made this distinction? Is
the issues that optimizing things doesn't always improve
performance... maybe?
On Wed, Jul 11, 2012 at 12:53 PM, Matthias Felleisen
matth...@ccs.neu.edu wrote:
Keep in mind that we were whacked for using
On Jul 11, 2012, at 7:18 PM, Robby Findler wrote:
Would tuning work?
They were correct, and you conjectured correctly. We conflated 'optimization'
with 'performance gains.' As everyone knows who has been around real compilers
and their writers, some 'optimizations' are 'pessimizations' as
I like coaching for the (formerly known as) performance report tool. A lot!
I was suggesting tuning for the collection that would house the
future visualizer and the performance coach and hopefully eventually a
memory profiler. (And maybe Eli's profiler could move in there someday
too.)
Robby
Is 'tool' plus flat subcollections really out?
I am not really keen on 'tuning', plus I see a chance to thin out the
collection top-level tree here.
On Jul 11, 2012, at 8:26 PM, Robby Findler wrote:
I like coaching for the (formerly known as) performance report tool. A lot!
I was
Some tools have components that are required programmatically. E.g., the
macro-debugger's useless requires detector or the graphical debugger
API (which doesn't seem to be documented). Moving them may break code.
But I do agree that a top-level `tool' collect would make sense.
Vincent
At Wed,
For backwards compatibility reasons, I doubt we can really move lots
of stuff into 'tools', but I agree that there is lots of stuff we
could move there. If we started this kind of thinking, there are
probably a bunch of very broad categories we could move things into.
I dislike tools as the name
That all makes sense to me (except, of course, that the futures
visualizer has nothing to do with drracket. Were the docs not clear on
this point somehow?)
On Wed, Jul 11, 2012 at 10:06 PM, Eli Barzilay e...@barzilay.org wrote:
Several randomly collected replies:
* Re perf -- I dislike it
A few minutes ago, Robby Findler wrote:
That all makes sense to me (except, of course, that the futures
visualizer has nothing to do with drracket. Were the docs not clear
on this point somehow?)
Sorry -- just a(n apparently broken) conjecture, since I didn't read
the docs... (I started from
I've been looking forward to trying this since I read your paper draft
last night. I didn't expect it so soon, though!
Neil ⊥
On 07/10/2012 09:01 AM, jamesswa...@racket-lang.org wrote:
jamesswaine has updated `master' from 48e154e3cb to dbec8765e3.
Cool!
On Tue, Jul 10, 2012 at 2:02 PM, Neil Toronto neil.toro...@gmail.comwrote:
I've been looking forward to trying this since I read your paper draft
last night. I didn't expect it so soon, though!
Neil ⊥
On 07/10/2012 09:01 AM, jamesswa...@racket-lang.org wrote:
jamesswaine has
This commit adds a bad dependency from the core to framework. Fixing
it is probably not hard, but it leads to an obvious question:
Why is this in racket instead of some new collection?
10 hours ago, jamesswa...@racket-lang.org wrote:
b6f71ec James Swaine jamesswa...@racket-lang.org
It is the future visualizer so I thought it belonged with the visualizer. No?
Alternative suggestions welcome.
Robby
On Tue, Jul 10, 2012 at 9:34 PM, Eli Barzilay e...@barzilay.org wrote:
This commit adds a bad dependency from the core to framework. Fixing
it is probably not hard, but it
10 minutes ago, Robby Findler wrote:
It is the future visualizer so I thought it belonged with the
visualizer. No?
(You mean ... belonged with the futures, right?)
Alternative suggestions welcome.
I think that it fits well with other meta-analysis kind of tools like
errortrace and the
On Tue, Jul 10, 2012 at 10:41 PM, Eli Barzilay e...@barzilay.org wrote:
10 minutes ago, Robby Findler wrote:
It is the future visualizer so I thought it belonged with the
visualizer. No?
(You mean ... belonged with the futures, right?)
Right. :)
Alternative suggestions welcome.
I think
On Tue, Jul 10, 2012 at 10:51 PM, Robby Findler ro...@eecs.northwestern.edu
wrote:
On Tue, Jul 10, 2012 at 10:41 PM, Eli Barzilay e...@barzilay.org wrote:
10 minutes ago, Robby Findler wrote:
It is the future visualizer so I thought it belonged with the
visualizer. No?
(You mean ...
An hour and a half ago, Robby Findler wrote:
On Tue, Jul 10, 2012 at 10:41 PM, Eli Barzilay e...@barzilay.org wrote:
10 minutes ago, Robby Findler wrote:
It is the future visualizer so I thought it belonged with the
visualizer. No?
(You mean ... belonged with the futures, right?)
38 matches
Mail list logo
