Re: [racket-dev] [plt] Push #24958: master branch updated

[James Swaine]

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 8:03 PM, Robby Findler
wrote:

> On Thu, Jul 12, 2012 at 3:57 PM, Matthias Felleisen
>  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 perhaps
> one with foo/test foo/private, etc) plus tagging / searching works
> very well.
>
> So maybe we should try to add some better tagging/searching instead of
> trying to some hierarchy in there?
>
> Robby
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Robby Findler]

On Thu, Jul 12, 2012 at 3:57 PM, Matthias Felleisen
 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 perhaps
one with foo/test foo/private, etc) plus tagging / searching works
very well.

So maybe we should try to add some better tagging/searching instead of
trying to some hierarchy in there?

Robby
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Matthias Felleisen]

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 easy to switch things around so that collects/foo is actually
>in its own repository, managed separately from the whole tree (and
>I think that getting to that point is absolutely inevitable)
>  - It's easy to package it up and ship it somewhere -- just zip it,
>and send it with instructions for where to unzip it.
>  - Things like ownership become very easy: you know that if it's in
>xrepl/* then you complain to me, and it's easy for me to see when
>someone else commits to xrepl so I can look at it.
> 
> * Having said that, note that it isn't completely disjoint from using
>  the directory structure in a way that follow its use -- the only
>  thing is that the main "package name" comes first, and then a
>  subdirectory like "tool" or "tests".


I think we're actually in agreement. I never liked tests/foo; I always wanted 
foo/tests. 

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. 

But whatever, too much water under the bridge so let's continue muddling. 
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Neil Van Dyke]

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, exclusive, permanent 
``part of'' relationship.


For example, I think that the PlaneT categories are already getting 
outdated, and I am glad that the categories are not used in naming.


Neil V.

_
 Racket Developers list:
 http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Eli Barzilay]

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 hierarchical organization. [...]

* One reason is from a simple code organization point of view.  I
  referred to the unix filesystem convention as an example of this:
  - On Windows, every application is in its own directory (there used
to be files in the Windows directory, but they strongly push away
from that)
  - On Linux, the Foo application will usually have /usr/bin/foo,
/usr/lib/libfoo, /usr/share/doc/foo, /usr/share/lib/foo,
/usr/share/icons/foo.png, /usr/share/info/foo.info,
/usr/share/man/man1/foo.1 etc etc etc.
  - And the new kid on the block inherits a lot of unix-isms, but goes
even further than windows in having the executable itself be a
Foo.app that contains everything it needs...

  Now, in our tree we have a little of both -- for example, there are
  collects/foo/tests directories in some cases, and collects/tests/foo
  in other cases, and scribblings are similarly organized in two ways
  too.

  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 easy to switch things around so that collects/foo is actually
in its own repository, managed separately from the whole tree (and
I think that getting to that point is absolutely inevitable)
  - It's easy to package it up and ship it somewhere -- just zip it,
and send it with instructions for where to unzip it.
  - Things like ownership become very easy: you know that if it's in
xrepl/* then you complain to me, and it's easy for me to see when
someone else commits to xrepl so I can look at it.

* Having said that, note that it isn't completely disjoint from using
  the directory structure in a way that follow its use -- the only
  thing is that the main "package name" comes first, and then a
  subdirectory like "tool" or "tests".

  *But* -- there is also danger in abusing the directory tree too much
  as a replacement for keywords/tags.  Say that there's some
  "foo/tool/inspector" and later "foo/tool/profiler", what happens
  when there's a type inspector -- which keyword "comes first" in the
  hierarchy?  (Incidentally, the first point makes this question easy
  for *me*: it's whatever foo's author wants to do...)

* Finally, there are a few minor exceptions.  "typed" can have
  subdirectories that are owned by other people, "file"/"net"/"data"
  etc are designed to be hosts for very common "keyword-like" uses.


> Perhaps Google will eventually accommodate all these people who
> don't like hierarchical organizations with search tools that find
> everything, including their misplaced car keys, reading glasses, and
> wallets. But we don't have such a tool for finding things in our
> collects/ tree and until we have such a search perhaps we should
> exploit the file system that we do have.

Actually we probably do...  I've set up a google code mirror, and they
most likely have tools to search it.

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Eli Barzilay]

20 minutes ago, Robby Findler wrote:
> On Thu, Jul 12, 2012 at 1:28 PM, Matthias Felleisen
>  wrote:
> >
> > On Jul 12, 2012, at 2:19 PM, Robby Findler wrote:
> >
> >> On Thu, Jul 12, 2012 at 1:14 PM, Matthias Felleisen
> >>  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?
> >>
> >> - I think the creation of a tool collection at this point is not
> >>   great because there will be lots of tools that are not in it.
> >
> > Are you saying that because we already gave > 110 collects it is
> > too late to do anything about the bushiness of the tree? That's
> > kind of sad.
> 
> It is very sad.

I don't think that this is sad wrt the current issue, since it's a new
toy.  Also, the possibly sad point is about the difficulty of moving
things around given that there is already code that refers to their
current locations -- but that's not at all specific to our source
tree.


> Relatedly, sticking these two together under the name "tool" does
> not really help unless you have a plan to stick more there. Having
> two different, half-followed conventions is worse than one bad
> convention.

+1 -- since it's unclear how many of these things will pop up and how
well they'd fit any label, it makes another point for going with a new
collection and be done with it.  (But this is a minor point, of
course.)


> >> - "tool" has often been a synonym for "drracket plugin" and the
> >>   future visualizer is not a drracket plugin.

(This is probably a confusion that I contributed to, assuming that it
was a drr tool.)

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Robby Findler]

On Thu, Jul 12, 2012 at 1:28 PM, Matthias Felleisen
 wrote:
>
> On Jul 12, 2012, at 2:19 PM, Robby Findler wrote:
>
>> On Thu, Jul 12, 2012 at 1:14 PM, Matthias Felleisen
>>  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?
>>
>> - I think the creation of a tool collection at this point is not great
>> because there will be lots of tools that are not in it.
>
> Are you saying that because we already gave > 110 collects it is too late to 
> do anything about the bushiness of the tree? That's kind of sad.

It is very sad.

Relatedly, sticking these two together under the name "tool" does not
really help unless you have a plan to stick more there. Having two
different, half-followed conventions is worse than one bad convention.

>> - "tool" has often been a synonym for "drracket plugin" and the future
>> visualizer is not a drracket plugin.
>
> I accept that you think 'tool' alludes to 'drracket plug in' in our 
> community, but I will say that when I was growing up 'ls' 'wc' 'find' and 
> friends were 'tools' and you composed them with '|'.  Later I considered 
> 'emacs' a tool but it was extensible; the 'scheme' mode wasn't a tool.
>
>> (I see some merit in trying to find a name for a collection having to
>> do with performance related tools, but "tool" is the wrong name for
>> that collection since it is too generic of a name.)
>
> I don't think it is about performance directly but indirectly. The two 
> 'tools' we're discussing are 'inspectors' that help you find out what's going 
> inside of Racket's compiler and during an execution with futures.

I wouldn't mind a word that has more specificity than "tool"; even
better if there weren't already N of them in separate places in the
collects that cannot be moved.

Robby

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Matthias Felleisen]

On Jul 12, 2012, at 2:19 PM, Robby Findler wrote:

> On Thu, Jul 12, 2012 at 1:14 PM, Matthias Felleisen
>  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?
> 
> - I think the creation of a tool collection at this point is not great
> because there will be lots of tools that are not in it.

Are you saying that because we already gave > 110 collects it is too late to do 
anything about the bushiness of the tree? That's kind of sad. 

> - "tool" has often been a synonym for "drracket plugin" and the future
> visualizer is not a drracket plugin.

I accept that you think 'tool' alludes to 'drracket plug in' in our community, 
but I will say that when I was growing up 'ls' 'wc' 'find' and friends were 
'tools' and you composed them with '|'.  Later I considered 'emacs' a tool but 
it was extensible; the 'scheme' mode wasn't a tool. 

> (I see some merit in trying to find a name for a collection having to
> do with performance related tools, but "tool" is the wrong name for
> that collection since it is too generic of a name.)

I don't think it is about performance directly but indirectly. The two 'tools' 
we're discussing are 'inspectors' that help you find out what's going inside of 
Racket's compiler and during an execution with futures. 

-- Matthias




_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Robby Findler]

On Thu, Jul 12, 2012 at 1:14 PM, Matthias Felleisen
 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?

- I think the creation of a tool collection at this point is not great
because there will be lots of tools that are not in it.

- "tool" has often been a synonym for "drracket plugin" and the future
visualizer is not a drracket plugin.

(I see some merit in trying to find a name for a collection having to
do with performance related tools, but "tool" is the wrong name for
that collection since it is too generic of a name.)

Robby
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Matthias Felleisen]

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 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 
hierarchical organization. Perhaps Google will eventually accommodate all these 
people who don't like hierarchical organizations with search tools that find 
everything, including their misplaced car keys, reading glasses, and wallets. 
But we don't have such a tool for finding things in our collects/ tree and 
until we have such a search perhaps we should exploit the file system that we 
do have. 

-- Matthias


_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Eli Barzilay]

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 observation that it uses the
framework, and assumed it was a drr tool...)

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Robby Findler]

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 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 the statistical profiler.
>
> * Re moving things in there -- like Vincent said, some of these tools
>   have an interface that is independent of drracket or of any gui, so
>   it's less appealing.
>
> And that last point leads to what I think is the main issue here: the
> name of such a collection is not really important since its intended
> for drracket tools -- so it's not something that you'll actually need
> to type in.  I think that this clarifies the organization too: there's
> not much point in a toplevel collection that is dedicated to drr tools
> since then it turns into a place where unrelated things live.  In
> other words, it becomes yet another place to split code into in a unix
> filesystem kind of way:
>
>   foo/, tests/foo, scribblings/foo, and now: tools/foo
>
> vs having all of these be subdirectories of foo.  I think that in
> terms of maintaining and managing code, having all of foo's code in a
> single place is ultimately better.  The management point is in making
> it easy to package the complete foo code, keep it in its own
> repository, etc; the maintenance point is -- for example -- in making
> it clear that foo's author is responsible for the code rather than
> tools/foo where it implicitly becomes "more shared" with Robby.
>
> Given all of this, I think that the best option is still a new
> toplevel collection for the new tool, and the decision on the name is
> something that James and Robby (wearing the futures hat, not the
> drracket one) should consider as the home of additional functionality
> that might be added there.
>
> --
>   ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
> http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Eli Barzilay]

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 the statistical profiler.

* Re moving things in there -- like Vincent said, some of these tools
  have an interface that is independent of drracket or of any gui, so
  it's less appealing.

And that last point leads to what I think is the main issue here: the
name of such a collection is not really important since its intended
for drracket tools -- so it's not something that you'll actually need
to type in.  I think that this clarifies the organization too: there's
not much point in a toplevel collection that is dedicated to drr tools
since then it turns into a place where unrelated things live.  In
other words, it becomes yet another place to split code into in a unix
filesystem kind of way:

  foo/, tests/foo, scribblings/foo, and now: tools/foo

vs having all of these be subdirectories of foo.  I think that in
terms of maintaining and managing code, having all of foo's code in a
single place is ultimately better.  The management point is in making
it easy to package the complete foo code, keep it in its own
repository, etc; the maintenance point is -- for example -- in making
it clear that foo's author is responsible for the code rather than
tools/foo where it implicitly becomes "more shared" with Robby.

Given all of this, I think that the best option is still a new
toplevel collection for the new tool, and the decision on the name is
something that James and Robby (wearing the futures hat, not the
drracket one) should consider as the home of additional functionality
that might be added there.

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Robby Findler]

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 for the two tools at hand.

Perhaps separate top-level collections is the best we can do.

Robby

On Wed, Jul 11, 2012 at 8:25 PM, Matthias Felleisen
 wrote:
>
> 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 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 Wed, Jul 11, 2012 at 7:12 PM, Matthias Felleisen
>>  wrote:
>>>
>>> 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 Keith used to call them. And of course even when 
>>> 'optimizations' reduce the running time and/or the space consumption, they 
>>> aren't _optimizations_ as John Dennis used to remind us. There is a similar 
>>> conflation that additional related work pointed out. People tend to confuse 
>>> 'analysis results' with 'can do optimization'. This is certainly not true 
>>> for in-lining in Racket and if you know of more those optimizations, I'd 
>>> love to hear about them.
>>>
>>> 'Tuning' would work but we decided that 'coaching' was a good term for what 
>>> was going on from the programmer's perspective. And the word isn't used 
>>> anywhere else in CS as far as I know, while other terms (including 
>>> 'tuning') are used and may have a different connotation.
>>>
>

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Vincent St-Amour]

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, 11 Jul 2012 21:25:04 -0400,
Matthias Felleisen wrote:
> 
> 
> 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 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 Wed, Jul 11, 2012 at 7:12 PM, Matthias Felleisen
> >  wrote:
> >> 
> >> 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 Keith used to call them. And of course even when 
> >> 'optimizations' reduce the running time and/or the space consumption, they 
> >> aren't _optimizations_ as John Dennis used to remind us. There is a 
> >> similar conflation that additional related work pointed out. People tend 
> >> to confuse 'analysis results' with 'can do optimization'. This is 
> >> certainly not true for in-lining in Racket and if you know of more those 
> >> optimizations, I'd love to hear about them.
> >> 
> >> 'Tuning' would work but we decided that 'coaching' was a good term for 
> >> what was going on from the programmer's perspective. And the word isn't 
> >> used anywhere else in CS as far as I know, while other terms (including 
> >> 'tuning') are used and may have a different connotation.
> >> 
> 
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Matthias Felleisen]

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 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 Wed, Jul 11, 2012 at 7:12 PM, Matthias Felleisen
>  wrote:
>> 
>> 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 Keith used to call them. And of course even when 
>> 'optimizations' reduce the running time and/or the space consumption, they 
>> aren't _optimizations_ as John Dennis used to remind us. There is a similar 
>> conflation that additional related work pointed out. People tend to confuse 
>> 'analysis results' with 'can do optimization'. This is certainly not true 
>> for in-lining in Racket and if you know of more those optimizations, I'd 
>> love to hear about them.
>> 
>> 'Tuning' would work but we decided that 'coaching' was a good term for what 
>> was going on from the programmer's perspective. And the word isn't used 
>> anywhere else in CS as far as I know, while other terms (including 'tuning') 
>> are used and may have a different connotation.
>> 


_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Robby Findler]

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 Wed, Jul 11, 2012 at 7:12 PM, Matthias Felleisen
 wrote:
>
> 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 
> Keith used to call them. And of course even when 'optimizations' reduce the 
> running time and/or the space consumption, they aren't _optimizations_ as 
> John Dennis used to remind us. There is a similar conflation that additional 
> related work pointed out. People tend to confuse 'analysis results' with 'can 
> do optimization'. This is certainly not true for in-lining in Racket and if 
> you know of more those optimizations, I'd love to hear about them.
>
> 'Tuning' would work but we decided that 'coaching' was a good term for what 
> was going on from the programmer's perspective. And the word isn't used 
> anywhere else in CS as far as I know, while other terms (including 'tuning') 
> are used and may have a different connotation.
>

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Matthias Felleisen]

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 Keith used to 
call them. And of course even when 'optimizations' reduce the running time 
and/or the space consumption, they aren't _optimizations_ as John Dennis used 
to remind us. There is a similar conflation that additional related work 
pointed out. People tend to confuse 'analysis results' with 'can do 
optimization'. This is certainly not true for in-lining in Racket and if you 
know of more those optimizations, I'd love to hear about them. 

'Tuning' would work but we decided that 'coaching' was a good term for what was 
going on from the programmer's perspective. And the word isn't used anywhere 
else in CS as far as I know, while other terms (including 'tuning') are used 
and may have a different connotation. 


_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Robby Findler]

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 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 things sounds good to me:
>
>  tools/
> stepper/
> macro-stepper
> optimizations/
> future-visualuzation/
> editing/
>
> and so on would work.
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Matthias Felleisen]

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 things sounds good to me:

 tools/
stepper/
macro-stepper 
optimizations/
future-visualuzation/
editing/ 

and so on would work. 

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Vincent St-Amour]

+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 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:
> >>
> >> 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 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?
> >> >> >
> >> >> > 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 of the `typed-racket' collect.
> >> >> > It would be a good candidate for the `tools' collection.
> >> >> >
> >> >> > Vincent
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Robby Findler]

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 carry the same expectation (to me, at least).
>
> Vincent
>
>
>
> At Wed, 11 Jul 2012 10:39:53 -0500,
> Robby Findler wrote:
>>
>> 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 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?
>> >> >
>> >> > 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 of the `typed-racket' collect.
>> >> > It would be a good candidate for the `tools' collection.
>> >> >
>> >> > Vincent
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Vincent St-Amour]

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:
> 
> 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 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?
> >> >
> >> > 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 of the `typed-racket' collect.
> >> > It would be a good candidate for the `tools' collection.
> >> >
> >> > Vincent
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Robby Findler]

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 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
>>
>> 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 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?
>> >> >
>> >> > 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 of the `typed-racket' collect.
>> >> > It would be a good candidate for the `tools' collection.
>> >> >
>> >> > Vincent
>
>
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Eli Barzilay]

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
>
> 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 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?
> >> >
> >> > 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 of the `typed-racket' collect.
> >> > It would be a good candidate for the `tools' collection.
> >> >
> >> > Vincent
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Robby Findler]

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 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?
>> >
>> > 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 of the `typed-racket' collect.
>> > It would be a good candidate for the `tools' collection.
>> >
>> > Vincent
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Vincent St-Amour]

(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 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 of the `typed-racket' collect.
> > It would be a good candidate for the `tools' collection.
> >
> > Vincent
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Robby Findler]

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?
>
> 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 of the `typed-racket' collect.
> It would be a good candidate for the `tools' collection.
>
> Vincent
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Vincent St-Amour]

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 of the `typed-racket' collect.
It would be a good candidate for the `tools' collection.

Vincent
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Robby Findler]

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" 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

Re: [racket-dev] [plt] Push #24958: master branch updated

[Matthew Flatt]

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

Re: [racket-dev] [plt] Push #24958: master branch updated

[Robby Findler]

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

Re: [racket-dev] [plt] Push #24958: master branch updated

[Robby Findler]

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 wrote:
>> > On Tue, Jul 10, 2012 at 10:41 PM, Eli Barzilay  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 that it fits well with other meta-analysis kind of tools like
>> > > errortrace and the profiler, so a new toplevel collection seems to
>> > > make perfect sense.  I don't have a concrete suggestion better than
>> > > "future-visualizer" though since I don't know what it does exactly.
>> > > Maybe "future-debugger" or "future-tracker" or something like that?
>> >
>> > I think we have too many top-level collections and making a new one,
>> > especially with "future-" in the name seems like a step in the wrong
>> > direction.
>>
>> If more tools will be there, then it could be "futute/something"...
>> Or maybe add a new "tools" collection for other similar things?
>> But in any case, having a new toplevel collection seems much less of a
>> problem than having a tool in racket/*.
>>
>> > ("visualizer" is a better word than "debugger" or "tracker" for what
>> > it does, IMO, altho it has elements of those. But if you read the docs
>> > in the Guide about it, you should get some idea what it does.)
>>
>> An hour and a half ago, James Swaine wrote:
>> >
>> > Agreed, "debugger" and "tracker" don't really adequately describe
>> > it.  Maybe "future-profiler" is another option, but maybe confusing
>> > since we already have "profiler".  (But I still think "visualizer"
>> > is best, IMHO).
>>
>> (I did say that I don't know what it's doing so I was blindly
>> guessing...)
>>
>> --
>>   ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
>> http://barzilay.org/   Maze is Life!
>>
>> _
>>   Racket Developers list:
>>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Matthew Flatt]

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:
> > >
> > > 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 that it fits well with other meta-analysis kind of tools like
> > > errortrace and the profiler, so a new toplevel collection seems to
> > > make perfect sense.  I don't have a concrete suggestion better than
> > > "future-visualizer" though since I don't know what it does exactly.
> > > Maybe "future-debugger" or "future-tracker" or something like that?
> > 
> > I think we have too many top-level collections and making a new one,
> > especially with "future-" in the name seems like a step in the wrong
> > direction.
> 
> If more tools will be there, then it could be "futute/something"...
> Or maybe add a new "tools" collection for other similar things?
> But in any case, having a new toplevel collection seems much less of a
> problem than having a tool in racket/*.
> 
> > ("visualizer" is a better word than "debugger" or "tracker" for what
> > it does, IMO, altho it has elements of those. But if you read the docs
> > in the Guide about it, you should get some idea what it does.)
> 
> An hour and a half ago, James Swaine wrote:
> > 
> > Agreed, "debugger" and "tracker" don't really adequately describe
> > it.  Maybe "future-profiler" is another option, but maybe confusing
> > since we already have "profiler".  (But I still think "visualizer"
> > is best, IMHO).
> 
> (I did say that I don't know what it's doing so I was blindly
> guessing...)
> 
> -- 
>   ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
> http://barzilay.org/   Maze is Life!
> 
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Eli Barzilay]

An hour and a half ago, Robby Findler wrote:
> On Tue, Jul 10, 2012 at 10:41 PM, Eli Barzilay  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 that it fits well with other meta-analysis kind of tools like
> > errortrace and the profiler, so a new toplevel collection seems to
> > make perfect sense.  I don't have a concrete suggestion better than
> > "future-visualizer" though since I don't know what it does exactly.
> > Maybe "future-debugger" or "future-tracker" or something like that?
> 
> I think we have too many top-level collections and making a new one,
> especially with "future-" in the name seems like a step in the wrong
> direction.

If more tools will be there, then it could be "futute/something"...
Or maybe add a new "tools" collection for other similar things?
But in any case, having a new toplevel collection seems much less of a
problem than having a tool in racket/*.

> ("visualizer" is a better word than "debugger" or "tracker" for what
> it does, IMO, altho it has elements of those. But if you read the docs
> in the Guide about it, you should get some idea what it does.)

An hour and a half ago, James Swaine wrote:
> 
> Agreed, "debugger" and "tracker" don't really adequately describe
> it.  Maybe "future-profiler" is another option, but maybe confusing
> since we already have "profiler".  (But I still think "visualizer"
> is best, IMHO).

(I did say that I don't know what it's doing so I was blindly
guessing...)

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[James Swaine]

On Tue, Jul 10, 2012 at 10:51 PM, Robby Findler  wrote:

> On Tue, Jul 10, 2012 at 10:41 PM, Eli Barzilay  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 that it fits well with other meta-analysis kind of tools like
> > errortrace and the profiler, so a new toplevel collection seems to
> > make perfect sense.  I don't have a concrete suggestion better than
> > "future-visualizer" though since I don't know what it does exactly.
> > Maybe "future-debugger" or "future-tracker" or something like that?
>
> I think we have too many top-level collections and making a new one,
> especially with "future-" in the name seems like a step in the wrong
> direction.
>
> ("visualizer" is a better word than "debugger" or "tracker" for what
> it does, IMO, altho it has elements of those. But if you read the docs
> in the Guide about it, you should get some idea what it does.)
>

Agreed, "debugger" and "tracker" don't really adequately describe it.
 Maybe "future-profiler" is another option, but maybe confusing since we
already have "profiler".  (But I still think "visualizer" is best, IMHO).


>
> Robby
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Robby Findler]

On Tue, Jul 10, 2012 at 10:41 PM, Eli Barzilay  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 that it fits well with other meta-analysis kind of tools like
> errortrace and the profiler, so a new toplevel collection seems to
> make perfect sense.  I don't have a concrete suggestion better than
> "future-visualizer" though since I don't know what it does exactly.
> Maybe "future-debugger" or "future-tracker" or something like that?

I think we have too many top-level collections and making a new one,
especially with "future-" in the name seems like a step in the wrong
direction.

("visualizer" is a better word than "debugger" or "tracker" for what
it does, IMO, altho it has elements of those. But if you read the docs
in the Guide about it, you should get some idea what it does.)

Robby
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Eli Barzilay]

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 profiler, so a new toplevel collection seems to
make perfect sense.  I don't have a concrete suggestion better than
"future-visualizer" though since I don't know what it does exactly.
Maybe "future-debugger" or "future-tracker" or something like that?



> On Tue, Jul 10, 2012 at 9:34 PM, Eli Barzilay  wrote:
> > 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?

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Robby Findler]

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  wrote:
> 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  2012-02-29 11:43
>> :
>> | Add futures visualizer, improvements to futures logging
>> :
>>   A collects/racket/future/private/constants.rkt
>>   A collects/racket/future/private/display.rkt
>>   A collects/racket/future/private/drawing-helpers.rkt
>>   A collects/racket/future/private/graph-drawing.rkt
>>   A collects/racket/future/private/gui-helpers.rkt
>>   A collects/racket/future/private/visualizer-data.rkt
>>   A collects/racket/future/private/visualizer-drawing.rkt
>>   A collects/racket/future/private/visualizer-gui.rkt
>>   A collects/racket/future/visualizer.rkt
>
> --
>   ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
> http://barzilay.org/   Maze is Life!
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Eli Barzilay]

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  2012-02-29 11:43
> :
> | Add futures visualizer, improvements to futures logging
> :
>   A collects/racket/future/private/constants.rkt
>   A collects/racket/future/private/display.rkt
>   A collects/racket/future/private/drawing-helpers.rkt
>   A collects/racket/future/private/graph-drawing.rkt
>   A collects/racket/future/private/gui-helpers.rkt
>   A collects/racket/future/private/visualizer-data.rkt
>   A collects/racket/future/private/visualizer-drawing.rkt
>   A collects/racket/future/private/visualizer-gui.rkt
>   A collects/racket/future/visualizer.rkt

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[James Swaine]

Cool!

On Tue, Jul 10, 2012 at 2:02 PM, Neil Toronto wrote:

> 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.
>>
>> http://git.racket-lang.org/**plt/48e154e3cb..dbec8765e3
>>
>> =[ 6 Commits ]=**
>> =
>> Directory summary:
>>34.5% collects/racket/future/**private/
>>43.6% collects/scribblings/guide/
>> 6.5% collects/scribblings/**reference/
>>11.1% collects/tests/future/
>>
>> ~~
>>
>> b6f71ec James Swaine  2012-02-29 11:43
>> :
>> | Add futures visualizer, improvements to futures logging
>> :
>>A collects/racket/future/**private/constants.rkt
>>A collects/racket/future/**private/display.rkt
>>A collects/racket/future/**private/drawing-helpers.rkt
>>A collects/racket/future/**private/graph-drawing.rkt
>>A collects/racket/future/**private/gui-helpers.rkt
>>A collects/racket/future/**private/visualizer-data.rkt
>>A collects/racket/future/**private/visualizer-drawing.rkt
>>A collects/racket/future/**private/visualizer-gui.rkt
>>A collects/racket/future/**visualizer.rkt
>>M collects/scribblings/guide/**futures.scrbl | 398
>> +---
>>A collects/scribblings/guide/**mand-bad-hover.png
>>A collects/scribblings/guide/**mand-bad.png
>>A collects/scribblings/guide/**mand-good.png
>>A collects/scribblings/guide/**vis-main.png
>>M collects/scribblings/**reference/concurrency.scrbl |   1 +
>>M collects/scribblings/**reference/futures.scrbl |  18 +-
>>A collects/scribblings/**reference/futures-visualizer.**scrbl
>>A collects/tests/future/bad-**trace1.rkt
>>M collects/tests/future/future.**rkt |   2 +-
>>A collects/tests/future/**visualizer.rkt
>>A qsort2.rkt
>>M src/racket/src/future.c  | 145 +--
>>M src/racket/src/future.h  |   2 +-
>>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #24958: master branch updated

[Neil Toronto]

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.
   http://git.racket-lang.org/plt/48e154e3cb..dbec8765e3

=[ 6 Commits ]==
Directory summary:
   34.5% collects/racket/future/private/
   43.6% collects/scribblings/guide/
6.5% collects/scribblings/reference/
   11.1% collects/tests/future/

~~

b6f71ec James Swaine  2012-02-29 11:43
:
| Add futures visualizer, improvements to futures logging
:
   A collects/racket/future/private/constants.rkt
   A collects/racket/future/private/display.rkt
   A collects/racket/future/private/drawing-helpers.rkt
   A collects/racket/future/private/graph-drawing.rkt
   A collects/racket/future/private/gui-helpers.rkt
   A collects/racket/future/private/visualizer-data.rkt
   A collects/racket/future/private/visualizer-drawing.rkt
   A collects/racket/future/private/visualizer-gui.rkt
   A collects/racket/future/visualizer.rkt
   M collects/scribblings/guide/futures.scrbl | 398 +---
   A collects/scribblings/guide/mand-bad-hover.png
   A collects/scribblings/guide/mand-bad.png
   A collects/scribblings/guide/mand-good.png
   A collects/scribblings/guide/vis-main.png
   M collects/scribblings/reference/concurrency.scrbl |   1 +
   M collects/scribblings/reference/futures.scrbl |  18 +-
   A collects/scribblings/reference/futures-visualizer.scrbl
   A collects/tests/future/bad-trace1.rkt
   M collects/tests/future/future.rkt |   2 +-
   A collects/tests/future/visualizer.rkt
   A qsort2.rkt
   M src/racket/src/future.c  | 145 +--
   M src/racket/src/future.h  |   2 +-

_
 Racket Developers list:
 http://lists.racket-lang.org/dev