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
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
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
Is it possible to change the name of this thing?
http://groups.google.com/group/plt-scheme/
Robby
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
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?
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 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
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
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
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
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
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
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
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
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
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
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
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
It sure looks to me like this sentence from the docs is missing a really
important not:
The consequence of this second feature is that place should appear immediately
in a module or in a function that is called in a module’s top level; otherwise,
invoking the module will invoke the same module
Again, ignore this if it's already been fixed. The docs contain this example:
#lang racket
(provide main)
(define (any-double? l)
(for/or ([i (in-list l)])
(for/or ([i2 (in-list l)])
(= i2 (* 2 i)
(define (main)
(define p
(place ch
(define l (place-channel-get
The example in the guide works fine:
#lang racket
(provide main)
(define (any-double? l)
(for/or ([i (in-list l)])
(for/or ([i2 (in-list l)])
(= i2 (* 2 i)
(define (main)
(define p
(place ch
(define l (place-channel-get ch))
(define l-double? (any-double?
21 matches
Mail list logo
