Re: [racket-dev] [plt] Push #24958: master branch updated
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 ro...@eecs.northwestern.eduwrote: 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 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, 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
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? - 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
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 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
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 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
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
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
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
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 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
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: 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
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, 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?) 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
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
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
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 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
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
(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 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
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 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 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
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 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 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 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
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 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 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 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 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
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 stamo...@ccs.neu.edu 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 stamo...@ccs.neu.edu 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
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 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 stamo...@ccs.neu.edu 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 stamo...@ccs.neu.edu 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
+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 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 stamo...@ccs.neu.edu 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 stamo...@ccs.neu.edu 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
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 '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
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
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 matth...@ccs.neu.edu 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
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 matth...@ccs.neu.edu 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
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 matth...@ccs.neu.edu 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
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 matth...@ccs.neu.edu 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 matth...@ccs.neu.edu 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
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 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
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
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 jamesswa...@racket-lang.org 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
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 updated `master' from 48e154e3cb to dbec8765e3. http://git.racket-lang.org/**plt/48e154e3cb..dbec8765e3http://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 jamesswa...@racket-lang.org 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
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 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
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 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 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
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 e...@barzilay.org 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
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 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
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 ... 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
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?) 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
