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] Deprecating collects
All well and fine but defmacro should be specified as a library for 'porting old CL code, but highly discouraged for useful macros'. -- Matthias On Jul 10, 2012, at 9:20 PM, Eli Barzilay wrote: 50 minutes ago, Matthew Flatt wrote: Some will want `defmacro', maybe for porting old code. So, if we don't provide `defmacro', then others will waste time re-creating it and/or asking how to re-create it. +7. And given a plan for migrating code from mzlib/* to racket/*, I think that this should be moved too -- but the documentation should be very explicit about the bad sides of using it, much more than it does now. (It could also mention a brief note on how it guesses the context back since that makes the hack aspect very obvious.) Three concrete examples for it being very useful: 1. Porting old scheme or CL code, or even new code written by people who know only symbolic macros. In both cases it's better to have some way to do a quick job, and later on upgrade to proper macros rather than make it an all-or-nothing job (which in these cases will often end up on the nothing side). 2. Semi-related: some people will inevitably use defmacro because they have a vague intuition that it's obviously the most powerful system, so they'll continue using it. Having a defmacro in Racket is a very real way to say no, it's a weaker system that can be emulated. I know that this is a very high-level reason, but it is manifested in a real way by allowing these people to port/write code quickly and later on learn about proper macros. (This item is based on a *lot* of interactions I've had with many people on this subject.) 3. Another place where I find it useful (and also semi²-related), is teaching. I find it very useful to introduce macros as just sexpr functions since it corresponds to the simplified mental model that students use for writing interpreters, then see how that breaks, then show how the syntax type should grow from sexpr to sexpr+scope, which also makes it more natural to later see how it keeps growing to accomodate source information and more. -- ((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
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] Proposal for a no-argument
At Sun, 8 Jul 2012 08:40:41 -0400, Eli Barzilay wrote: Quick summary: I'll remove the #:before-first and #:after-last feature. If anyone wants them, please tell me -- maybe it can be left for the spliced case, or maybe they could always be spliced. +2 to always splicing. This gives us the additional features without needing the `#:nothing' argument. 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] [racket-bug] all/12861: promise/c does not maintain equality
(sending this e-mail to dev since it's not directly related to promise/c) On 2012-07-10 22:13:58 -0500, Robby Findler wrote: Note that this means the guard on there is now going to be gone (as it is meaningless since impersonators can arbitrarily change it). This is something that has confused me about impersonators on struct type property accessors. It seems like there is a use case for having an impersonatable property that still has a guard. For example, suppose the property and its accessor are defined and retained local to some module (for example, to store a generic method access table). This means that nobody outside of the module can impersonate the property through the accessor. Assuming your module itself upholds whatever invariants you expect of the property guard, it's not going to be arbitrarily violated. For example, with generics it might be desirable to have optional polymorphic contracts applied to methods in the method table. Since polymorphic contracts are impersonator contracts, the proxy on the method table property itself must be an impersonator. However, this impersonation doesn't violate the invariants of the method table property guard, which just ensures that the user provided valid methods for the method table. Maybe I'm missing something obvious though? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket-bug] all/12861: promise/c does not maintain equality
If you're limiting access, could you provide a function-based interface that wrapped the impersonating procedures to add the checks instead of using a guard? Robby On Wed, Jul 11, 2012 at 11:25 AM, Asumu Takikawa as...@ccs.neu.edu wrote: (sending this e-mail to dev since it's not directly related to promise/c) On 2012-07-10 22:13:58 -0500, Robby Findler wrote: Note that this means the guard on there is now going to be gone (as it is meaningless since impersonators can arbitrarily change it). This is something that has confused me about impersonators on struct type property accessors. It seems like there is a use case for having an impersonatable property that still has a guard. For example, suppose the property and its accessor are defined and retained local to some module (for example, to store a generic method access table). This means that nobody outside of the module can impersonate the property through the accessor. Assuming your module itself upholds whatever invariants you expect of the property guard, it's not going to be arbitrarily violated. For example, with generics it might be desirable to have optional polymorphic contracts applied to methods in the method table. Since polymorphic contracts are impersonator contracts, the proxy on the method table property itself must be an impersonator. However, this impersonation doesn't violate the invariants of the method table property guard, which just ensures that the user provided valid methods for the method table. Maybe I'm missing something obvious though? Cheers, Asumu _ 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 #24974: master branch updated
Excellent! On 07/11/2012 09:25 AM, stamo...@racket-lang.org wrote: 84feb38 Vincent St-Amour stamo...@racket-lang.org 2011-10-11 14:26 : | Enable performance report no matter the language. : M collects/typed-racket/optimizer/tool/tool.rkt | 21 +++-- I can't tell from the overall diff. Does that also include student languages? 331d47e Vincent St-Amour stamo...@racket-lang.org 2011-11-30 17:56 : | Remove vestigial file. : D collects/typed-racket/optimizer/tool/utilities.rkt This made me laugh. I thought of tail bones and appendixes. (Misapplying biology always makes me laugh. Q. What's the squiggly thing under the c in façade? A. Most biologists believe it's a flagellum.) Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24974: master branch updated
At Wed, 11 Jul 2012 09:37:19 -0700, Neil Toronto wrote: On 07/11/2012 09:25 AM, stamo...@racket-lang.org wrote: 84feb38 Vincent St-Amour stamo...@racket-lang.org 2011-10-11 14:26 : | Enable performance report no matter the language. : M collects/typed-racket/optimizer/tool/tool.rkt | 21 +++-- I can't tell from the overall diff. Does that also include student languages? Oops, good point. It does. I'll see how the Macro Stepper avoids that problem, and do the same. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket-bug] all/12861: promise/c does not maintain equality
On 2012-07-11 11:33:39 -0500, Robby Findler wrote: If you're limiting access, could you provide a function-based interface that wrapped the impersonating procedures to add the checks instead of using a guard? I'm not sure this would work because the user interface for inserting the data into the property is via the #:property or #:methods arguments in the `struct` form. The guard seems to be the only way to add any checking there (without wrapping or modifying `struct`). Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24974: master branch updated
Not to be a PITA, but the buttons are huge and if they are now always there, we should be doing something different with the UI. The view menu would be my first suggestion for where this should go. Robby On Wed, Jul 11, 2012 at 11:40 AM, Vincent St-Amour stamo...@ccs.neu.edu wrote: At Wed, 11 Jul 2012 09:37:19 -0700, Neil Toronto wrote: On 07/11/2012 09:25 AM, stamo...@racket-lang.org wrote: 84feb38 Vincent St-Amour stamo...@racket-lang.org 2011-10-11 14:26 : | Enable performance report no matter the language. : M collects/typed-racket/optimizer/tool/tool.rkt | 21 +++-- I can't tell from the overall diff. Does that also include student languages? Oops, good point. It does. I'll see how the Macro Stepper avoids that problem, and do the same. 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
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 #24974: master branch updated
I would hate to hide a nifty new tool away in a menu item. How about using narrower text on the button? It doesn't have to be the same as the GUI's title text. By analogy, a tool has two kinds of icons: a logo and a toolbar icon. In general, a logo is memorable, possibly abstract, and indicates what the tool *is*. (For example, the steppers' logos are feet.) A toolbar icon indicates what the tool *does* when you click the icon. The GUI's title and the toolbar text can have the same is/does distinction. Another option is to split the toolbar into two parts. Or have two dockable toolbars. I know that's more work for Robby... :D Neil ⊥ On 07/11/2012 10:03 AM, Robby Findler wrote: Not to be a PITA, but the buttons are huge and if they are now always there, we should be doing something different with the UI. The view menu would be my first suggestion for where this should go. Robby On Wed, Jul 11, 2012 at 11:40 AM, Vincent St-Amour stamo...@ccs.neu.edu wrote: At Wed, 11 Jul 2012 09:37:19 -0700, Neil Toronto wrote: On 07/11/2012 09:25 AM, stamo...@racket-lang.org wrote: 84feb38 Vincent St-Amour stamo...@racket-lang.org 2011-10-11 14:26 : | Enable performance report no matter the language. : M collects/typed-racket/optimizer/tool/tool.rkt | 21 +++-- I can't tell from the overall diff. Does that also include student languages? Oops, good point. It does. I'll see how the Macro Stepper avoids that problem, and do the same. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24974: master branch updated
Well, how many of the things currently in the View menu are nify tools? The module browser at least? We have too many buttons up there-- we need fewer. We need a more scalable way to include these things. Check Syntax should go away (and it will when online check syntax is done), for example. Robby On Wed, Jul 11, 2012 at 12:34 PM, Neil Toronto neil.toro...@gmail.com wrote: I would hate to hide a nifty new tool away in a menu item. How about using narrower text on the button? It doesn't have to be the same as the GUI's title text. By analogy, a tool has two kinds of icons: a logo and a toolbar icon. In general, a logo is memorable, possibly abstract, and indicates what the tool *is*. (For example, the steppers' logos are feet.) A toolbar icon indicates what the tool *does* when you click the icon. The GUI's title and the toolbar text can have the same is/does distinction. Another option is to split the toolbar into two parts. Or have two dockable toolbars. I know that's more work for Robby... :D Neil ⊥ On 07/11/2012 10:03 AM, Robby Findler wrote: Not to be a PITA, but the buttons are huge and if they are now always there, we should be doing something different with the UI. The view menu would be my first suggestion for where this should go. Robby On Wed, Jul 11, 2012 at 11:40 AM, Vincent St-Amour stamo...@ccs.neu.edu wrote: At Wed, 11 Jul 2012 09:37:19 -0700, Neil Toronto wrote: On 07/11/2012 09:25 AM, stamo...@racket-lang.org wrote: 84feb38 Vincent St-Amour stamo...@racket-lang.org 2011-10-11 14:26 : | Enable performance report no matter the language. : M collects/typed-racket/optimizer/tool/tool.rkt | 21 +++-- I can't tell from the overall diff. Does that also include student languages? Oops, good point. It does. I'll see how the Macro Stepper avoids that problem, and do the same. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24974: master branch updated
How about a tools drop-down? Or Online Optimization Coach (You can do it, Vincent!) Neil ⊥ On 07/11/2012 10:47 AM, Robby Findler wrote: Well, how many of the things currently in the View menu are nify tools? The module browser at least? We have too many buttons up there-- we need fewer. We need a more scalable way to include these things. Check Syntax should go away (and it will when online check syntax is done), for example. Robby On Wed, Jul 11, 2012 at 12:34 PM, Neil Toronto neil.toro...@gmail.com wrote: I would hate to hide a nifty new tool away in a menu item. How about using narrower text on the button? It doesn't have to be the same as the GUI's title text. By analogy, a tool has two kinds of icons: a logo and a toolbar icon. In general, a logo is memorable, possibly abstract, and indicates what the tool *is*. (For example, the steppers' logos are feet.) A toolbar icon indicates what the tool *does* when you click the icon. The GUI's title and the toolbar text can have the same is/does distinction. Another option is to split the toolbar into two parts. Or have two dockable toolbars. I know that's more work for Robby... :D Neil ⊥ On 07/11/2012 10:03 AM, Robby Findler wrote: Not to be a PITA, but the buttons are huge and if they are now always there, we should be doing something different with the UI. The view menu would be my first suggestion for where this should go. Robby On Wed, Jul 11, 2012 at 11:40 AM, Vincent St-Amour stamo...@ccs.neu.edu wrote: At Wed, 11 Jul 2012 09:37:19 -0700, Neil Toronto wrote: On 07/11/2012 09:25 AM, stamo...@racket-lang.org wrote: 84feb38 Vincent St-Amour stamo...@racket-lang.org 2011-10-11 14:26 : | Enable performance report no matter the language. : M collects/typed-racket/optimizer/tool/tool.rkt | 21 +++-- I can't tell from the overall diff. Does that also include student languages? Oops, good point. It does. I'll see how the Macro Stepper avoids that problem, and do the same. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24974: master branch updated
On Wed, Jul 11, 2012 at 1:06 PM, Neil Toronto neil.toro...@gmail.com wrote: How about a tools drop-down? Or Online Optimization Coach (You can do it, Vincent!) I had that same thought, actually: online check syntax is actually factored into two parts. DrRacket provides an online expansion service and plugins you can register two handlers, one to run in the place where the expansion happened that is expected to produce a value to send back to the main place where the other handler gets it and can update the GUI. Probably Vincent has fairly little work to break that up; I'd guess the more substantial question will be how to reflect the information into the GUI in a way that doesn't fight with the check syntax information. Robby Neil ⊥ On 07/11/2012 10:47 AM, Robby Findler wrote: Well, how many of the things currently in the View menu are nify tools? The module browser at least? We have too many buttons up there-- we need fewer. We need a more scalable way to include these things. Check Syntax should go away (and it will when online check syntax is done), for example. Robby On Wed, Jul 11, 2012 at 12:34 PM, Neil Toronto neil.toro...@gmail.com wrote: I would hate to hide a nifty new tool away in a menu item. How about using narrower text on the button? It doesn't have to be the same as the GUI's title text. By analogy, a tool has two kinds of icons: a logo and a toolbar icon. In general, a logo is memorable, possibly abstract, and indicates what the tool *is*. (For example, the steppers' logos are feet.) A toolbar icon indicates what the tool *does* when you click the icon. The GUI's title and the toolbar text can have the same is/does distinction. Another option is to split the toolbar into two parts. Or have two dockable toolbars. I know that's more work for Robby... :D Neil ⊥ On 07/11/2012 10:03 AM, Robby Findler wrote: Not to be a PITA, but the buttons are huge and if they are now always there, we should be doing something different with the UI. The view menu would be my first suggestion for where this should go. Robby On Wed, Jul 11, 2012 at 11:40 AM, Vincent St-Amour stamo...@ccs.neu.edu wrote: At Wed, 11 Jul 2012 09:37:19 -0700, Neil Toronto wrote: On 07/11/2012 09:25 AM, stamo...@racket-lang.org wrote: 84feb38 Vincent St-Amour stamo...@racket-lang.org 2011-10-11 14:26 : | Enable performance report no matter the language. : M collects/typed-racket/optimizer/tool/tool.rkt | 21 +++-- I can't tell from the overall diff. Does that also include student languages? Oops, good point. It does. I'll see how the Macro Stepper avoids that problem, and do the same. 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
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 #24974: master branch updated
At Wed, 11 Jul 2012 18:00:26 -0500, Robby Findler wrote: On Wed, Jul 11, 2012 at 1:06 PM, Neil Toronto neil.toro...@gmail.com wrote: How about a tools drop-down? Or Online Optimization Coach (You can do it, Vincent!) I had that same thought, actually: online check syntax is actually factored into two parts. DrRacket provides an online expansion service and plugins you can register two handlers, one to run in the place where the expansion happened that is expected to produce a value to send back to the main place where the other handler gets it and can update the GUI. Probably Vincent has fairly little work to break that up; I'd guess the more substantial question will be how to reflect the information into the GUI in a way that doesn't fight with the check syntax information. Making the two tools combine nicely would take some thought. Currently, Optimization Coach is probably too slow to be used online, but I'm planning to work on that. Probably not before the release, though. Vincent _ 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
[racket-dev] When are values chaperones of another?
The docs on when a value is a chaperone of another are confusing and don't seem to match the implementation. They seem to say that (and (not (chaperone? a)) (not (chaperone? b)) (equal? a b)) implies (chaperone-of? a b) but this does not seem to hold. They also change behavior if I switch from a transparent structure to a structure where I explicitly implement equality. #lang racket (struct foo (v) #:property prop:equal+hash (list (lambda (l r equal?) (equal? l r)) (lambda (v hash) (hash v)) (lambda (v hash) (hash v #; (struct foo (v) #:transparent) (define foo1 (foo (box 0))) (define foo2 (foo (box 0))) (define foo3 (foo (foo-v foo1))) 1 2 (equal? foo1 foo2) (chaperone-of? foo1 foo2) (chaperone-of? foo2 foo1) 1 3 (equal? foo1 foo3) (chaperone-of? foo1 foo3) (chaperone-of? foo3 foo1) ;;--- 1 2 #t #f #f 1 3 #t #f #f I expect these to all return true but only the equals do. If I switch to transparent equality then 1 and 3 are equal. The goal in this is to have my own struct type (free identifier tables) be able to support chaperone-of? like immutable hashes do: (chaperone-of? (hash 'a 'b) (hash 'a 'b)) ;; = #t These are different hashes but are chaperones of each other. The importance of this is chaperone contracts on free identifier tables need to make a copy like hash/c does on immutable hashes. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
Yesterday, Matthias Felleisen wrote: All well and fine but defmacro should be specified as a library for 'porting old CL code, but highly discouraged for useful macros'. Sure. I'd add to that that no proper code should use it, at most a stopgap for some quick conversion job which should always be expected to be proper-ified later. On Jul 10, 2012, at 9:20 PM, Eli Barzilay wrote: 50 minutes ago, Matthew Flatt wrote: Some will want `defmacro', maybe for porting old code. So, if we don't provide `defmacro', then others will waste time re-creating it and/or asking how to re-create it. +7. And given a plan for migrating code from mzlib/* to racket/*, I think that this should be moved too -- but the documentation should be very explicit about the bad sides of using it, much more than it does now. (It could also mention a brief note on how it guesses the context back since that makes the hack aspect very obvious.) Three concrete examples for it being very useful: 1. Porting old scheme or CL code, or even new code written by people who know only symbolic macros. In both cases it's better to have some way to do a quick job, and later on upgrade to proper macros rather than make it an all-or-nothing job (which in these cases will often end up on the nothing side). 2. Semi-related: some people will inevitably use defmacro because they have a vague intuition that it's obviously the most powerful system, so they'll continue using it. Having a defmacro in Racket is a very real way to say no, it's a weaker system that can be emulated. I know that this is a very high-level reason, but it is manifested in a real way by allowing these people to port/write code quickly and later on learn about proper macros. (This item is based on a *lot* of interactions I've had with many people on this subject.) 3. Another place where I find it useful (and also semi²-related), is teaching. I find it very useful to introduce macros as just sexpr functions since it corresponds to the simplified mental model that students use for writing interpreters, then see how that breaks, then show how the syntax type should grow from sexpr to sexpr+scope, which also makes it more natural to later see how it keeps growing to accomodate source information and more. -- ((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
