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 sho
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 t
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 fro
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 wrote:
> Several randomly collected replies:
>
> * Re "perf" -- I dislike it because it's easy
Several randomly collected replies:
* Re "perf" -- I dislike it because it's easy to confuse with
the very different "pref"...
* Re my reply about a "future profiler tool" -- to clarify, I meant
"future" in the English sense, ie, some proper drracket tool that
will visualize the results of
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 f
At Wed, 11 Jul 2012 18:00:26 -0500,
Robby Findler wrote:
>
> On Wed, Jul 11, 2012 at 1:06 PM, Neil Toronto 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
> factor
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, 1
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 sug
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
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
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
wrote:
>
> Keep in mind that we were whacked for using 'performance' when
On Wed, Jul 11, 2012 at 1:06 PM, Neil Toronto 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 service
and plugins
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.
Keep in mind that we were whacked for using 'performance' when we really meant
'optimization'.
I kind of like the 'tools' idea. I can see that it is too broad (a spell
checking tool shouldn't co-habit with a visualizer for futures) but a tools
collections with sub-collections for various thin
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.
Ro
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 indicat
+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
> wrote:
> > I would prefer the full word, "performance".
> >
> > But with a name like that, I would expect thi
What about naming the collection "tuning"?
Robby
On Wed, Jul 11, 2012 at 11:34 AM, Vincent St-Amour 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"
> doesn't
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 wrote:
> At Wed, 11 Jul 2012 09:37:19 -07
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
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 2011-10-11 14:26
> > :
> > | Enable performance report no matter the language.
> > :
> >M collects/typed-racket/optimizer/tool/tool.rkt | 21
> > +
Excellent!
On 07/11/2012 09:25 AM, stamo...@racket-lang.org wrote:
84feb38 Vincent St-Amour 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 overall diff. Does that also
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:
>
>
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 wrote:
> (sending this e-mail to dev since it's not directly related to
> promise/
(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 confus
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 wrote:
> A point to consider here is that this should also be the place for a future
> profiler thing, and maybe other les
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"
wrote:
> Better than "tools", IMO. How about "perf"? Ie, perf/future-visualizer
> and perf/optimization-coach/ ?
>
> Robby
>
>
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 wrote:
> (Performance) tuning?
>
> Vincent
>
>
> At Wed, 11 Jul 2012 10:04:46 -0500,
> Robby Findler wrote:
>>
>> tools seems like too ge
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
(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
> wrote:
> > At Wed, 11 Ju
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 wrote:
> At Wed, 11 Jul 2012 01:33:02 -0400,
> Eli Barzilay wrote:
>> Or maybe add a new "tools" collection for other similar things
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 outsid
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
Sorry for spreading the rumour :)
On Tue, Jul 10, 2012 at 10:55 PM, Eli Barzilay wrote:
> No, I didn't write `racket/stream' -- Matthew did it based on the
> stream srfi. This came up not too long ago, and I sent a question
> about it here:
> http://lists.racket-lang.org/dev/archive/2012-June/00
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 wrote:
> If you mean that a connection to the runtime system implies being in
> the "racket" collecti
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
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 separat
Uncle.
Robby
On Wed, Jul 11, 2012 at 7:14 AM, Matthew Flatt 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, Robby Findler
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 wrote:
> > >
> > >
40 matches
Mail list logo
