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
All well and fine but defmacro should be specified as a
library for 'porting old CL code, but highly discouraged
for useful macros'.
-- Matthias
On Jul 10, 2012, at 9:20 PM, Eli Barzilay wrote:
50 minutes ago, Matthew Flatt wrote:
Some will want `defmacro', maybe for porting old
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
At Sun, 8 Jul 2012 08:40:41 -0400,
Eli Barzilay wrote:
Quick summary: I'll remove the #:before-first and #:after-last
feature. If anyone wants them, please tell me -- maybe it can be left
for the spliced case, or maybe they could always be spliced.
+2 to always splicing.
This gives us the
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
(sending this e-mail to dev since it's not directly related to
promise/c)
On 2012-07-10 22:13:58 -0500, Robby Findler wrote:
Note that this means the guard on there is now going to be gone (as it
is meaningless since impersonators can arbitrarily change it).
This is something that has
If you're limiting access, could you provide a function-based
interface that wrapped the impersonating procedures to add the checks
instead of using a guard?
Robby
On Wed, Jul 11, 2012 at 11:25 AM, Asumu Takikawa as...@ccs.neu.edu wrote:
(sending this e-mail to dev since it's not directly
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:
Excellent!
On 07/11/2012 09:25 AM, stamo...@racket-lang.org wrote:
84feb38 Vincent St-Amour stamo...@racket-lang.org 2011-10-11 14:26
:
| Enable performance report no matter the language.
:
M collects/typed-racket/optimizer/tool/tool.rkt | 21 +++--
I can't tell from the
At Wed, 11 Jul 2012 09:37:19 -0700,
Neil Toronto wrote:
On 07/11/2012 09:25 AM, stamo...@racket-lang.org wrote:
84feb38 Vincent St-Amour stamo...@racket-lang.org 2011-10-11 14:26
:
| Enable performance report no matter the language.
:
M collects/typed-racket/optimizer/tool/tool.rkt |
On 2012-07-11 11:33:39 -0500, Robby Findler wrote:
If you're limiting access, could you provide a function-based
interface that wrapped the impersonating procedures to add the checks
instead of using a guard?
I'm not sure this would work because the user interface for inserting the data
into
Not to be a PITA, but the buttons are huge and if they are now always
there, we should be doing something different with the UI. The view
menu would be my first suggestion for where this should go.
Robby
On Wed, Jul 11, 2012 at 11:40 AM, Vincent St-Amour stamo...@ccs.neu.edu wrote:
At Wed, 11
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
I would hate to hide a nifty new tool away in a menu item.
How about using narrower text on the button? It doesn't have to be the
same as the GUI's title text.
By analogy, a tool has two kinds of icons: a logo and a toolbar icon. In
general, a logo is memorable, possibly abstract, and
Well, how many of the things currently in the View menu are nify
tools? The module browser at least?
We have too many buttons up there-- we need fewer. We need a more
scalable way to include these things.
Check Syntax should go away (and it will when online check syntax is
done), for example.
How about a tools drop-down? Or Online Optimization Coach (You can
do it, Vincent!)
Neil ⊥
On 07/11/2012 10:47 AM, Robby Findler wrote:
Well, how many of the things currently in the View menu are nify
tools? The module browser at least?
We have too many buttons up there-- we need fewer.
On Wed, Jul 11, 2012 at 1:06 PM, Neil Toronto neil.toro...@gmail.com wrote:
How about a tools drop-down?
Or Online Optimization Coach (You can do
it, Vincent!)
I had that same thought, actually: online check syntax is actually
factored into two parts. DrRacket provides an online expansion
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,
At Wed, 11 Jul 2012 18:00:26 -0500,
Robby Findler wrote:
On Wed, Jul 11, 2012 at 1:06 PM, Neil Toronto neil.toro...@gmail.com wrote:
How about a tools drop-down?
Or Online Optimization Coach (You can do
it, Vincent!)
I had that same thought, actually: online check syntax is
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
The docs on when a value is a chaperone of another are confusing and
don't seem to match the implementation.
They seem to say that (and (not (chaperone? a)) (not (chaperone? b))
(equal? a b)) implies (chaperone-of? a b) but this does not seem to
hold.
They also change behavior if I switch from a
Yesterday, Matthias Felleisen wrote:
All well and fine but defmacro should be specified as a
library for 'porting old CL code, but highly discouraged
for useful macros'.
Sure. I'd add to that that no proper code should use it, at most a
stopgap for some quick conversion job which should
36 matches
Mail list logo
