Re: [racket-dev] Adding the new plot library [was: Re: Plot?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/30/11 02:06, James Vega wrote: Eli Barzilay eli@... writes: The thing is that keeping things completely backward compatible means keeping some C code (the fit thing), and that translates to a real problem with linux distributions (see the Fedora point earlier). Not being completely backward compatible has the advantage of moving at least the Fedora distribution faster (and I won't be surprised if Debian/Ubuntu would have issues with this too -- I'm surprised they didn't say anything about it so far). I did -- http://bugs.racket-lang.org/query/?cmd=viewpr=10756. :) You convinced me that the status quo was good enough for now and that it'd eventually be replaced by scheme^Wracket. Glad to see that's happening. I'm confused now. That bug talks about a bundled zlib, while Eli says this is about: ``keeping the C code that was ripped out of gnuplot.'' which would IIUC be a violation of gnuplot's license. Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6FcjoACgkQp/VmCx0OL2wdQgCbByav/H9v6rl2Fhsi38DJlu0K OHIAn1eUdjpjEz/PtALj59vS597vB8vY =2R0l -END PGP SIGNATURE- _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Adding the new plot library [was: Re: Plot?]
50 minutes ago, Neil Van Dyke wrote: Marijn wrote at 09/30/2011 03:39 AM: ``keeping the C code that was ripped out of gnuplot.'' which would IIUC be a violation of gnuplot's license. Below is the Copyright file from the version of gnuplot included in Debian Stable. I don't know what C code from gnuplot is being talked about, and I do not see any in the Racket 5.1.3 source tree. The code in question has its own \copyright\: http://git.racket-lang.org/plt/tree/HEAD:/src/plot/fit -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Adding the new plot library [was: Re: Plot?]
11 hours ago, Neil Toronto wrote: On 09/29/2011 12:28 PM, Eli Barzilay wrote: Because you wanted to have a completely compatible interface? (Excluding pixels.) My point was that if you don't keep it (which I very strongly prefer), then you don't have a compatible interface to plot anyway, and changing the name from `plot' to `plot/compat' makes more sense. The pixels that make up the plots generated by the compatibility library are quite different. But I can't imagine that nicer plots will be anything but a pleasant surprise. By (Excluding pixels.) I meant that the compatibility that I'm talking about is *not* about them. I definitely don't want to talk about them. (I should have added in any way shape or form...) The first is what happens when users run old code that uses the 'plot' library. - (Robby/Sam) The compatibility library is 'collects/plot' and the new library is 'collects/rackplot' (or 'collects/omg-raph' or whatever): their code just runs. - (Eli) The compatibility library is 'collects/plot/compat' and the new library is 'collects/plot': some code will run with more changes than just pixels (semantic errors in the plots), some will give runtime errors, and most will give compile-time errors. Yes, except that the compatibility library (under any name) will not be completely compatible, hence code will need to be adapted, and therefore I view the change in the code from (require plot) to (require plot/compat) as an acceptable one. The second interaction is what happens when new users look for plot in the manual. - (Robby/Sam): They get the old 'plot'. Clicking on it reveals a big red deprecation warning, and a link to the new stuff. Of course, that doesn't guarantee that they will *read* the warning. Very much so. Specifically, if you look for a `plot' function and click it, you get directly to its documentation, and won't see the deprecated message at the top. The obvious solution being adding it in all functions, but even that my guess is that people will miss it. Observations: With Robby/Sam's idea, the apparent bait-and-switch, and needing two clicks to get to the right library, is also fail. And it lasts for years until we finally decide to rip out the compatibility library, and thus break more code. +1 -- but that's nothing new for this case. In general, compatibility is a good thing for obvious reasons, but it also has a dark side that we're already into: when things are very compatible up to including the docs and not showing any warnings, then code will exist, and will grow more code that uses the compatibility layers. (There were some good examples that I finally cleaned up recently: lots of foo.ss requires, uses of `@scheme' in scribble files, etc. The main reason I cleaned it up is that I don't want to see these things spread further, and given that code in the repository is often used for templates, having those things in there mean that they will linger on.) And BTW, re finally decide to rip out: it's questionable if such a future exist. There are some extremely ancient things that are still in. (Look in `syntax/zodiac' for a live demo.) To me, the ideal would be to name the compatibility library 'collects/plot', and then somehow keep it from showing up in searches. Actually, that would be a good step towards proper deprecation: just drop the documentation for the deprecated bindings. I'd be in favor of that. (But somehow I think that won't be a popular vote.) 11 hours ago, Neil Toronto wrote: On 09/29/2011 12:27 PM, Sam Tobin-Hochstadt wrote: You're referring to the code that implements `fit', right? Shouldn't we just keep that until someone does the same thing that Neil has done for that code too? Yes. I'll likely convert that one as well, but not right now. I've got quite a bit of experience with nonlinear function fitting, from another graduate program, a lifetime ago. (Or 3-4 years ago. or whatever.) I still think that a poll is the best way to go. It is unlikely that the fit code is used, and wasting precious resources (your time) on writing code that won't get used is IMO a bad investment. (Yes, unlikely is my opinion -- hence the poll suggestion.) 10 hours ago, Robby Findler wrote: On Thu, Sep 29, 2011 at 5:25 PM, Neil Toronto neil.toro...@gmail.com wrote: Observations: With Robby/Sam's idea, the apparent bait-and-switch, and needing two clicks to get to the right library, is also fail. And it lasts for years until we finally decide to rip out the compatibility library, and thus break more code. No _more_ code, hopefully. And in the meantime we give people time to switch to the new thing. Giving people no time (ie zero releases) in which to port their code is unwise. BTW, to further clarify my opinion: if meantime above was a known reasonable period, then I'd say something completely different. (For example, it could
Re: [racket-dev] Adding the new plot library [was: Re: Plot?]
I think concern about backward-compatibility is great. (For example, moving to non-mutable pairs was painful for one of my libraries. #:exists without backward-compatibility or static checking was annoying.) I have two questions: 1. Does anyone think that there is likely any *substantial* *current* use of the plotting-related C code in question that you *don't* know about? Or do you probably know of all the people who might be affected, and you can work with them on this question? 2. If you want to get some C code out of core Racket, does the option of moving it to PLaneT simplify things? -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Adding the new plot library [was: Re: Plot?]
In the science and simulation collections I explicitly hid the usage of PLoT - thus, all of the -plot routines in separate modules. The original PLoT has always been something of a kludge - albeit a useful one - that I expected to be replaced at some point. Bring it on! On Fri, Sep 30, 2011 at 4:16 AM, Neil Van Dyke n...@neilvandyke.org wrote: I think concern about backward-compatibility is great. (For example, moving to non-mutable pairs was painful for one of my libraries. #:exists without backward-compatibility or static checking was annoying.) I have two questions: 1. Does anyone think that there is likely any *substantial* *current* use of the plotting-related C code in question that you *don't* know about? Or do you probably know of all the people who might be affected, and you can work with them on this question? 2. If you want to get some C code out of core Racket, does the option of moving it to PLaneT simplify things? -- http://www.neilvandyke.org/ __**___ For list-related administrative tasks: http://lists.racket-lang.org/**listinfo/devhttp://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Adding the new plot library [was: Re: Plot?]
Yesterday, Neil Toronto wrote: 1. Obviously, Module 2's path should be 'plot'. Right? And its documentation needs a note that it's deprecated. (I'll do that.) I don't know if it's that important, maybe poll the users list for potential code that uses it? If it is, then given that it's a complete reimplementation, I think that it's fine to go with some `plot/compat' or something like that -- it forces users who have code to change files, but my guess is that most people used it just to try stuff out in quick scripts, and on the other side you have Doug who is deep enough into it that he'll most likely need to change code anyway. 2. Should Module 2 send a deprecation warning to stderr or the log when 'require'd? No. 3. Should Module 1's path be 'racket/plot'? No. I've also thought of 'new-plot' (which is a cute pun on gnuplot but inconsistent with other names) and 'rackplot' (which is consistent with 'racklog' and 'rackunit'). Could also go with omgraph or whatever. I'm open to suggestions. If the above sounds reasonable, then it can be just `plot'. (Unless you really want to update the name.) 4. I didn't write a 'plot/extend' replacement because it would have been painful and bit convoluted. Also, nearly everything 'plot/extend' provides is more easily done using either the old 'plot' or Module 1. As of now, it will just quietly disappear. Is that okay? (Fine with me, but polling the users list would be safer.) 5. I'll have general questions about how to put things in the collects. I could probably answer them all by looking at a GOOD example. What, in your opinion, is the archetypal collects library, which would show me How It Should Be Done? It depends on the code -- probably best if we take this off-list. Last thing: I haven't replaced the 'fit' function, because it has nothing to do with plotting or the plotting C library! I don't know why it's in 'plot' in the first place. The C library behind 'fit' will have to stay for now, so there will still be a bit of a C mess that makes Eli throw up. Is there any actual need for it? (BTW, there is a good point in getting rid of that code: the Fedora packages have issues with duplicating code from other libraries instead of using libraries.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Adding the new plot library [was: Re: Plot?]
On Thu, Sep 29, 2011 at 3:33 AM, Eli Barzilay e...@barzilay.org wrote: Yesterday, Neil Toronto wrote: 1. Obviously, Module 2's path should be 'plot'. Right? And its documentation needs a note that it's deprecated. (I'll do that.) I don't know if it's that important, maybe poll the users list for potential code that uses it? If it is, then given that it's a complete reimplementation, I think that it's fine to go with some `plot/compat' or something like that -- it forces users who have code to change files, but my guess is that most people used it just to try stuff out in quick scripts, and on the other side you have Doug who is deep enough into it that he'll most likely need to change code anyway. I don't think we should do that. And certainly not without a release or two of warning. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Adding the new plot library [was: Re: Plot?]
On Thu, Sep 29, 2011 at 7:47 AM, Robby Findler ro...@eecs.northwestern.edu wrote: On Thu, Sep 29, 2011 at 3:33 AM, Eli Barzilay e...@barzilay.org wrote: Yesterday, Neil Toronto wrote: 1. Obviously, Module 2's path should be 'plot'. Right? And its documentation needs a note that it's deprecated. (I'll do that.) I don't know if it's that important, maybe poll the users list for potential code that uses it? If it is, then given that it's a complete reimplementation, I think that it's fine to go with some `plot/compat' or something like that -- it forces users who have code to change files, but my guess is that most people used it just to try stuff out in quick scripts, and on the other side you have Doug who is deep enough into it that he'll most likely need to change code anyway. I don't think we should do that. And certainly not without a release or two of warning. I agree with Robby. We've gotten a lot better about backwards compatibility, and I don't think the win here is worth breaking that. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Adding the new plot library [was: Re: Plot?]
On 09/29/2011 05:51 AM, Sam Tobin-Hochstadt wrote: On Thu, Sep 29, 2011 at 7:47 AM, Robby Findler ro...@eecs.northwestern.edu wrote: On Thu, Sep 29, 2011 at 3:33 AM, Eli Barzilaye...@barzilay.org wrote: Yesterday, Neil Toronto wrote: 1. Obviously, Module 2's path should be 'plot'. Right? And its documentation needs a note that it's deprecated. (I'll do that.) I don't know if it's that important, maybe poll the users list for potential code that uses it? If it is, then given that it's a complete reimplementation, I think that it's fine to go with some `plot/compat' or something like that -- it forces users who have code to change files, but my guess is that most people used it just to try stuff out in quick scripts, and on the other side you have Doug who is deep enough into it that he'll most likely need to change code anyway. I don't think we should do that. And certainly not without a release or two of warning. I agree with Robby. We've gotten a lot better about backwards compatibility, and I don't think the win here is worth breaking that. I can totally see Eli's point, as the first result when searching for plot in the manuals is the old stuff. But I agree with you two. This isn't worth antagonizing users over. Except maybe Doug. We can always antagonize the users we love most. :D I've done a dry run with a repo cloned from github, where I've replaced most of 'plot' with a compatibility module and added 'rackplot'. I'll get it in the main repo as soon as Eli signs me up for everything that'll make me formally responsible for the new code (push list, bug list, nag list, etc.). Neil T _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Adding the new plot library [was: Re: Plot?]
Yesterday, Matthias Felleisen wrote: On Sep 28, 2011, at 12:01 PM, Neil Toronto wrote: 3. Should Module 1's path be 'racket/plot'? I've also thought of 'new-plot' (which is a cute pun on gnuplot but inconsistent with other names) and 'rackplot' (which is consistent with 'racklog' and 'rackunit'). Could also go with omgraph or whatever. I'm open to suggestions. I like rackplot. (FWIW, I think that the simple rackfoo names where foo is some obvious name is already overused...) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Adding the new plot library [was: Re: Plot?]
On Thu, Sep 29, 2011 at 1:04 PM, Eli Barzilay e...@barzilay.org wrote: Yesterday, Matthias Felleisen wrote: On Sep 28, 2011, at 12:01 PM, Neil Toronto wrote: 3. Should Module 1's path be 'racket/plot'? I've also thought of 'new-plot' (which is a cute pun on gnuplot but inconsistent with other names) and 'rackplot' (which is consistent with 'racklog' and 'rackunit'). Could also go with omgraph or whatever. I'm open to suggestions. I like rackplot. (FWIW, I think that the simple rackfoo names where foo is some obvious name is already overused...) I do too, but a) it is some nice uniformity and b) I'm not coming up with any good puns. :) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Adding the new plot library [was: Re: Plot?]
On Thu, Sep 29, 2011 at 1:08 PM, Eli Barzilay e...@barzilay.org wrote: 6 hours ago, Robby Findler wrote: On Thu, Sep 29, 2011 at 3:33 AM, Eli Barzilay e...@barzilay.org wrote: Yesterday, Neil Toronto wrote: 1. Obviously, Module 2's path should be 'plot'. Right? And its documentation needs a note that it's deprecated. (I'll do that.) I don't know if it's that important, maybe poll the users list for potential code that uses it? If it is, then given that it's a complete reimplementation, I think that it's fine to go with some `plot/compat' or something like that -- it forces users who have code to change files, but my guess is that most people used it just to try stuff out in quick scripts, and on the other side you have Doug who is deep enough into it that he'll most likely need to change code anyway. I don't think we should do that. And certainly not without a release or two of warning. Do you know of any actual code that uses it? My personal knowledge of code that uses it (or yours) is a BAD way to make this kind of decision. The thing is that keeping things completely backward compatible means keeping some C code (the fit thing), and that translates to a real problem with linux distributions (see the Fedora point earlier). Not being completely backward compatible has the advantage of moving at least the Fedora distribution faster (and I won't be surprised if Debian/Ubuntu would have issues with this too -- I'm surprised they didn't say anything about it so far). I don't think that what I said implies this. A compatibility layer using Neil's new library is what was offered (or so I thought). I think we just want something that has the same Racket-level UI and something reasonably close in the pictures you get out, as discussed earlier. To get that advantage, things will not be completely backward compatible anyway, and in that case a change from `plot' to `plot/compat' is a small price, IMO smaller than the benefit of getting happy linux packages. I remain unconvinced. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Adding the new plot library [was: Re: Plot?]
Just now, Robby Findler wrote: On Thu, Sep 29, 2011 at 1:04 PM, Eli Barzilay e...@barzilay.org wrote: Yesterday, Matthias Felleisen wrote: I like rackplot. (FWIW, I think that the simple rackfoo names where foo is some obvious name is already overused...) I do too, but a) it is some nice uniformity Well, such uniformity is roughly equivalent to using `rackfoo' instead of `racket/foo'... and b) I'm not coming up with any good puns. :) Neil had a few that sounded better to me. (Mainly because they weren't rackplot though.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Adding the new plot library [was: Re: Plot?]
Just now, Robby Findler wrote: On Thu, Sep 29, 2011 at 1:08 PM, Eli Barzilay e...@barzilay.org wrote: 6 hours ago, Robby Findler wrote: On Thu, Sep 29, 2011 at 3:33 AM, Eli Barzilay e...@barzilay.org wrote: Yesterday, Neil Toronto wrote: 1. Obviously, Module 2's path should be 'plot'. Right? And its documentation needs a note that it's deprecated. (I'll do that.) I don't know if it's that important, maybe poll the users list for potential code that uses it? If it is, then given that it's a complete reimplementation, I think that it's fine to go with some `plot/compat' or something like that -- it forces users who have code to change files, but my guess is that most people used it just to try stuff out in quick scripts, and on the other side you have Doug who is deep enough into it that he'll most likely need to change code anyway. I don't think we should do that. And certainly not without a release or two of warning. Do you know of any actual code that uses it? My personal knowledge of code that uses it (or yours) is a BAD way to make this kind of decision. I suggested polling the list. (Grepping the planet code would be useful too, but not enough.) The thing is that keeping things completely backward compatible means keeping some C code (the fit thing), and that translates to a real problem with linux distributions (see the Fedora point earlier). Not being completely backward compatible has the advantage of moving at least the Fedora distribution faster (and I won't be surprised if Debian/Ubuntu would have issues with this too -- I'm surprised they didn't say anything about it so far). I don't think that what I said implies this. A compatibility layer using Neil's new library is what was offered (or so I thought). I think we just want something that has the same Racket-level UI and something reasonably close in the pictures you get out, as discussed earlier. If it's just that layer (rather than keeping the C code in), then it's not completely compatible anyway. (And I don't see a point in keeping a strict backward compatibility if it's not strict anyway.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Adding the new plot library [was: Re: Plot?]
On Thu, Sep 29, 2011 at 1:15 PM, Eli Barzilay e...@barzilay.org wrote: Just now, Robby Findler wrote: I don't think that what I said implies this. A compatibility layer using Neil's new library is what was offered (or so I thought). I think we just want something that has the same Racket-level UI and something reasonably close in the pictures you get out, as discussed earlier. If it's just that layer (rather than keeping the C code in), then it's not completely compatible anyway. (And I don't see a point in keeping a strict backward compatibility if it's not strict anyway.) We seem to be miscommunicating. I'm saying that it seems likely that people have scripts and things that use the API of the plot library to build graphs and things in various places. I'm saying that it seems unlikely that people have programs that depend on a pixel-perfect rendering. I'm saying that, imo, the best thing we can do for our users here is provide a compatibility layer for the old plot in the same place as the old plot currently is that calls into the new plot and uses it to draw the actual pictures. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Adding the new plot library [was: Re: Plot?]
Just now, Robby Findler wrote: On Thu, Sep 29, 2011 at 1:15 PM, Eli Barzilay e...@barzilay.org wrote: Just now, Robby Findler wrote: I don't think that what I said implies this. A compatibility layer using Neil's new library is what was offered (or so I thought). I think we just want something that has the same Racket-level UI and something reasonably close in the pictures you get out, as discussed earlier. If it's just that layer (rather than keeping the C code in), then it's not completely compatible anyway. (And I don't see a point in keeping a strict backward compatibility if it's not strict anyway.) We seem to be miscommunicating. I'm saying that it seems likely that people have scripts and things that use the API of the plot library to build graphs and things in various places. I'm saying that it seems unlikely that people have programs that depend on a pixel-perfect rendering. The issue is not pixel placements, it's keeping the C code that was ripped out of gnuplot. I'm saying that, imo, the best thing we can do for our users here is provide a compatibility layer for the old plot in the same place as the old plot currently is that calls into the new plot and uses it to draw the actual pictures. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Adding the new plot library [was: Re: Plot?]
On Thu, Sep 29, 2011 at 1:25 PM, Eli Barzilay e...@barzilay.org wrote: Just now, Robby Findler wrote: On Thu, Sep 29, 2011 at 1:15 PM, Eli Barzilay e...@barzilay.org wrote: Just now, Robby Findler wrote: I don't think that what I said implies this. A compatibility layer using Neil's new library is what was offered (or so I thought). I think we just want something that has the same Racket-level UI and something reasonably close in the pictures you get out, as discussed earlier. If it's just that layer (rather than keeping the C code in), then it's not completely compatible anyway. (And I don't see a point in keeping a strict backward compatibility if it's not strict anyway.) We seem to be miscommunicating. I'm saying that it seems likely that people have scripts and things that use the API of the plot library to build graphs and things in various places. I'm saying that it seems unlikely that people have programs that depend on a pixel-perfect rendering. The issue is not pixel placements, it's keeping the C code that was ripped out of gnuplot. So I guess I don't understand. Why would we want to keep that? (I can see why we would want to get rid of it.) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Adding the new plot library [was: Re: Plot?]
On Thu, Sep 29, 2011 at 2:15 PM, Eli Barzilay e...@barzilay.org wrote: If it's just that layer (rather than keeping the C code in), then it's not completely compatible anyway. (And I don't see a point in keeping a strict backward compatibility if it's not strict anyway.) There's a really really big difference between my old code runs, and the pictures look ever-so-slightly different and I have to edit my code. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Adding the new plot library [was: Re: Plot?]
10 minutes ago, Sam Tobin-Hochstadt wrote: On Thu, Sep 29, 2011 at 2:15 PM, Eli Barzilay e...@barzilay.org wrote: If it's just that layer (rather than keeping the C code in), then it's not completely compatible anyway. (And I don't see a point in keeping a strict backward compatibility if it's not strict anyway.) There's a really really big difference between my old code runs, and the pictures look ever-so-slightly different and I have to edit my code. I have *NOT* talked about pixel changes in any place. Please read my emails before you reply. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Adding the new plot library [was: Re: Plot?]
On 09/29/2011 12:27 PM, Sam Tobin-Hochstadt wrote: You're referring to the code that implements `fit', right? Shouldn't we just keep that until someone does the same thing that Neil has done for that code too? Yes. I'll likely convert that one as well, but not right now. I've got quite a bit of experience with nonlinear function fitting, from another graduate program, a lifetime ago. (Or 3-4 years ago. or whatever.) A 'fit' module that does polynomial and more general least-squares fitting, linear and spline interpolation, and kernel density estimators would be really handy in quite a few situations. (Heck, let's just incorporate williams/science while we're at it. Batteries included!) Neil T _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Adding the new plot library [was: Re: Plot?]
Neil, I haven't had a chance to read the thread thoroughly - hopefully I can this evening at home. But, I'd like to update the science collection graphics to use it. Fortunately, all of the graphics routines are in separate modules, so it shouldn't be too bad. I do use the plot extensions to add new capabilities to the current plot package - for example, for 1d and 2d histograms. Is the plot extension capability still there? [It wouldn't be that hard to write the histograms from scratch if it isn't.] Also, in my analysis code at work we do use the contour plots for some things. Pretty much everything else is in my own specialized plot packages. Doug On Thu, Sep 29, 2011 at 4:25 PM, Neil Toronto neil.toro...@gmail.comwrote: On 09/29/2011 12:28 PM, Eli Barzilay wrote: Just now, Robby Findler wrote: On Thu, Sep 29, 2011 at 1:25 PM, Eli Barzilaye...@barzilay.org wrote: The issue is not pixel placements, it's keeping the C code that was ripped out of gnuplot. So I guess I don't understand. Why would we want to keep that? (I can see why we would want to get rid of it.) Because you wanted to have a completely compatible interface? (Excluding pixels.) My point was that if you don't keep it (which I very strongly prefer), then you don't have a compatible interface to plot anyway, and changing the name from `plot' to `plot/compat' makes more sense. The pixels that make up the plots generated by the compatibility library are quite different. But I can't imagine that nicer plots will be anything but a pleasant surprise. So I don't want to read about pixels anymore. Seriously. Logical reductio ad absurdum about pixels in pictures - which are valuable because of their *semantic* content - borders on fallacious. It won't get us anywhere. What will is discussing the most important user interactions. -- The first is what happens when users run old code that uses the 'plot' library. - (Robby/Sam) The compatibility library is 'collects/plot' and the new library is 'collects/rackplot' (or 'collects/omg-raph' or whatever): their code just runs. - (Eli) The compatibility library is 'collects/plot/compat' and the new library is 'collects/plot': some code will run with more changes than just pixels (semantic errors in the plots), some will give runtime errors, and most will give compile-time errors. Examples: (plot (points (list (vector a b) ...))) = Runs, but puts tighter bounds on the plot (semantic error) (plot (error-bars (list (vector a b c) ...))) = Runs, but puts tighter bounds on the plot (semantic error) (plot (points (list (vector a b) ...) #:sym 'fullsquare)) = points: does not expect an argument with keyword #:sym (plot (vector-field (λ (v) v))) = vector-field: contract violation, expected a procedure that accepts 2 mandatory arguments without any keywords, given: #procedure contract from: (function vector-field), blaming: collects/plot/plot2d/point.**rkt (plot (line sqr)) = expand: unbound identifier in module in: line Also, 'contour', 'shade' and 'surface' do the same as 'line'. Observations: There's nothing that tells the user that changing (require plot) to (require plot/compat) will fix the errors. It just looks like random fail. But if it's random fail only once for a very small percentage of users, it might be okay-ish. -- The second interaction is what happens when new users look for plot in the manual. - (Robby/Sam): They get the old 'plot'. Clicking on it reveals a big red deprecation warning, and a link to the new stuff. Of course, that doesn't guarantee that they will *read* the warning. - (Eli): They get the new 'plot', with a note about the compatibility library that they can ignore. Observations: With Robby/Sam's idea, the apparent bait-and-switch, and needing two clicks to get to the right library, is also fail. And it lasts for years until we finally decide to rip out the compatibility library, and thus break more code. -- To me, the ideal would be to name the compatibility library 'collects/plot', and then somehow keep it from showing up in searches. Oh, and also push 'mrlib/plot' downward in the search results. What is that, anyway? It seems that nothing in the collects uses it. Neil T __**___ For list-related administrative tasks: http://lists.racket-lang.org/**listinfo/devhttp://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Adding the new plot library [was: Re: Plot?]
Eli Barzilay eli@... writes: The thing is that keeping things completely backward compatible means keeping some C code (the fit thing), and that translates to a real problem with linux distributions (see the Fedora point earlier). Not being completely backward compatible has the advantage of moving at least the Fedora distribution faster (and I won't be surprised if Debian/Ubuntu would have issues with this too -- I'm surprised they didn't say anything about it so far). I did -- http://bugs.racket-lang.org/query/?cmd=viewpr=10756. :) You convinced me that the status quo was good enough for now and that it'd eventually be replaced by scheme^Wracket. Glad to see that's happening. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Adding the new plot library [was: Re: Plot?]
Eli, I'm moving part of our discussion to the dev list for others' input. On 09/25/2011 04:39 PM, Eli Barzilay wrote: Three hours ago, Neil Toronto wrote: It's going well. We could put it in the repo later today if you want. I just have to consolidate a bunch of parameters first, and move bits of code around to their final resting places. That would be wonderful. Just to clarify, every time I see the C mess there I need to throw up, and I think that I'm not the only one. It's ready now, but I have questions. The new plot library is actually two modules. The old 'plot' assumed that a plot data only needed to DRAW in a plot area, so a plot data is just a lambda that accepts a plot area argument. There's no way for the plot data to negotiate its drawing bounds, request ticks and tick labels, or report the data necessary to assemble a legend. So I had to redesign it all. In the new plot library, a renderer has those nifty abilities. The new library has scads of other improvements, more plot types, and a richer API. I'll call its main module Module 1. Module 2 is a compatibility module, a thin wrapper around Module 1. It's a drop-in replacement for the old 'plot' module. Questions: 1. Obviously, Module 2's path should be 'plot'. Right? And its documentation needs a note that it's deprecated. (I'll do that.) 2. Should Module 2 send a deprecation warning to stderr or the log when 'require'd? 3. Should Module 1's path be 'racket/plot'? I've also thought of 'new-plot' (which is a cute pun on gnuplot but inconsistent with other names) and 'rackplot' (which is consistent with 'racklog' and 'rackunit'). Could also go with omgraph or whatever. I'm open to suggestions. 4. I didn't write a 'plot/extend' replacement because it would have been painful and bit convoluted. Also, nearly everything 'plot/extend' provides is more easily done using either the old 'plot' or Module 1. As of now, it will just quietly disappear. Is that okay? 5. I'll have general questions about how to put things in the collects. I could probably answer them all by looking at a GOOD example. What, in your opinion, is the archetypal collects library, which would show me How It Should Be Done? -- Last thing: I haven't replaced the 'fit' function, because it has nothing to do with plotting or the plotting C library! I don't know why it's in 'plot' in the first place. The C library behind 'fit' will have to stay for now, so there will still be a bit of a C mess that makes Eli throw up. I can replace that too - eventually. I think it would be best to separate concerns for now. Neil T _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Adding the new plot library [was: Re: Plot?]
On Sep 28, 2011, at 12:01 PM, Neil Toronto wrote: 1. Obviously, Module 2's path should be 'plot'. Right? And its documentation needs a note that it's deprecated. (I'll do that.) Yes. It needs a link at the top of the page that points to the expanded capabilities of Module 1 (docs). 2. Should Module 2 send a deprecation warning to stderr or the log when 'require'd? I wouldn't bother. 3. Should Module 1's path be 'racket/plot'? I've also thought of 'new-plot' (which is a cute pun on gnuplot but inconsistent with other names) and 'rackplot' (which is consistent with 'racklog' and 'rackunit'). Could also go with omgraph or whatever. I'm open to suggestions. I like rackplot. 4. I didn't write a 'plot/extend' replacement because it would have been painful and bit convoluted. Also, nearly everything 'plot/extend' provides is more easily done using either the old 'plot' or Module 1. As of now, it will just quietly disappear. Is that okay? 5. I'll have general questions about how to put things in the collects. I could probably answer them all by looking at a GOOD example. What, in your opinion, is the archetypal collects library, which would show me How It Should Be Done? Do not look at 2htdp and hdtp, because teachpacks are different :-) Last thing: I haven't replaced the 'fit' function, because it has nothing to do with plotting or the plotting C library! I don't know why it's in 'plot' in the first place. The C library behind 'fit' will have to stay for now, so there will still be a bit of a C mess that makes Eli throw up. I can replace that too - eventually. I think it would be best to separate concerns for now. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
