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:1
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*
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
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 d
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 talke
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/30/11 02:06, James Vega wrote:
> Eli Barzilay 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 Fed
Eli Barzilay 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 movi
On Thu, Sep 29, 2011 at 5:25 PM, Neil Toronto 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
Actually, it would probably make more sense to add fitting routines to the
science collection. They are definitely more general than just plotting.
And, the PLoT package only implements non-linear least squares fitting.
On Thu, Sep 29, 2011 at 4:31 PM, Neil Toronto wrote:
> On 09/29/2011 12:27 PM
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 n
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
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 Barzilay 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
10 minutes ago, Sam Tobin-Hochstadt wrote:
> On Thu, Sep 29, 2011 at 2:15 PM, Eli Barzilay 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
On Thu, Sep 29, 2011 at 2:15 PM, Eli Barzilay 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 diff
Just now, Robby Findler wrote:
> On Thu, Sep 29, 2011 at 1:25 PM, Eli Barzilay wrote:
> > Just now, Robby Findler wrote:
> >> On Thu, Sep 29, 2011 at 1:15 PM, Eli Barzilay wrote:
> >> > Just now, Robby Findler wrote:
> >> >> I don't think that what I said implies this. A compatibility layer
> >>
On Thu, Sep 29, 2011 at 2:25 PM, Eli Barzilay wrote:
> Just now, Robby Findler wrote:
>> On Thu, Sep 29, 2011 at 1:15 PM, Eli Barzilay 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 off
On Thu, Sep 29, 2011 at 1:25 PM, Eli Barzilay wrote:
> Just now, Robby Findler wrote:
>> On Thu, Sep 29, 2011 at 1:15 PM, Eli Barzilay 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 off
Just now, Robby Findler wrote:
> On Thu, Sep 29, 2011 at 1:15 PM, Eli Barzilay 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
On Thu, Sep 29, 2011 at 1:15 PM, Eli Barzilay 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
>>
Just now, Robby Findler wrote:
> On Thu, Sep 29, 2011 at 1:08 PM, Eli Barzilay wrote:
> > 6 hours ago, Robby Findler wrote:
> >> On Thu, Sep 29, 2011 at 3:33 AM, Eli Barzilay wrote:
> >> > Yesterday, Neil Toronto wrote:
> >> >>
> >> >> 1. Obviously, Module 2's path should be 'plot'. Right? And it
Just now, Robby Findler wrote:
> On Thu, Sep 29, 2011 at 1:04 PM, Eli Barzilay 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
On Thu, Sep 29, 2011 at 1:08 PM, Eli Barzilay wrote:
> 6 hours ago, Robby Findler wrote:
>> On Thu, Sep 29, 2011 at 3:33 AM, Eli Barzilay wrote:
>> > Yesterday, Neil Toronto wrote:
>> >>
>> >> 1. Obviously, Module 2's path should be 'plot'. Right? And its
>> >> documentation needs a note that it'
On Thu, Sep 29, 2011 at 1:04 PM, Eli Barzilay 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
>> >
6 hours ago, Robby Findler wrote:
> On Thu, Sep 29, 2011 at 3:33 AM, Eli Barzilay 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 th
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
On 09/29/2011 05:51 AM, Sam Tobin-Hochstadt wrote:
On Thu, Sep 29, 2011 at 7:47 AM, Robby Findler
wrote:
On Thu, Sep 29, 2011 at 3:33 AM, Eli Barzilay wrote:
Yesterday, Neil Toronto wrote:
1. Obviously, Module 2's path should be 'plot'. Right? And its
documentation needs a note that it's d
On Thu, Sep 29, 2011 at 7:47 AM, Robby Findler
wrote:
> On Thu, Sep 29, 2011 at 3:33 AM, Eli Barzilay 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
On Thu, Sep 29, 2011 at 3:33 AM, Eli Barzilay 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
> po
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
co
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.
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
31 matches
Mail list logo
