I want to equip my rsounds with a gen:equal+hash implementation, so that I can
compare them using equal? and thereby use them in check-expect test cases. I
have to roll this myself, since s16vectors don't do non-eq? equal?. My
question: is there an accepted hash function for an s16vector, or mo
Just now, Robby Findler wrote:
> So, IIUC, Ryan should have used
>
> 5.91.0.1
>
> as the version number on the release branch?
Yes.
(Part of this is probably the result of the poor estimate that the
Emacs code does for creating the checklist template -- mostly because
I originally intended
So, IIUC, Ryan should have used
5.91.0.1
as the version number on the release branch?
Robby
On Tue, Nov 26, 2013 at 2:38 PM, Eli Barzilay wrote:
> Yesterday, Matthew Flatt wrote:
> > At Mon, 25 Nov 2013 09:56:45 -0500, Ryan Culpepper wrote:
> > > On 11/25/2013 09:44 AM, Matthew Flatt wrot
Yesterday, Matthew Flatt wrote:
> At Mon, 25 Nov 2013 09:56:45 -0500, Ryan Culpepper wrote:
> > On 11/25/2013 09:44 AM, Matthew Flatt wrote:
> > > Here's the full comment:
> > >
> > > The version string has one of the forms:
> > >X.Y
> > >X.Y.Z Z != 0
> > >X.Y.Z.W
Earlier today, Asumu Takikawa wrote:
> Hi all,
>
> Should dynamically required libraries induce a package dependency?
>
> Take for example the "xrepl-lib" package. It currently depends on
> five other packages, but I think two of them can be dropped and
> `raco setup` won't complain.
>
> On the
+1 for Robby.
On Nov 26, 2013, at 12:05 PM, Robby Findler wrote:
> This isn't the semantics of the limits. It is about the way that calling the
> evaluator interacts with threads. Changing this program (from Eli's email)
>
> -> ,r racket/sandbox
> -> (define e (make-evaluator 'racke
This isn't the semantics of the limits. It is about the way that calling
the evaluator interacts with threads. Changing this program (from Eli's
email)
-> ,r racket/sandbox
-> (define e (make-evaluator 'racket))
-> (e '(define foo 1))
-> (e '(thread (lambda () (sleep 5) (set! foo 2
How can you change the documentation to say anything other than
"Wherever you see an thunk having a time restriction, don't think that
that means the thunk is restricted to using only a certain amount of
time"? We'd have to say something like "Time in this content is a
-first-order- notion of time,
I think that, in this case, changing the documentation and adding the
functionality with a different name is the way to go.
Robby
On Tue, Nov 26, 2013 at 10:49 AM, Jay McCarthy wrote:
> I agree that it is different.
>
> I disagree that this is a problem.
>
> The documentation says that is exe
I agree that it is different.
I disagree that this is a problem.
The documentation says that is executes the code with a time
restriction. This implies to me that (call-with-limits X #f t) should
not use more than X secs of resources, but it is trivial to produce
counter-examples. Without this ch
My position is that regardless of how a package is implemented
(whether with require, dynamic-require, etc) it should "work" after
being installed, so things that are "necessary" should be listed as
dependencies.
If a package has additional optional features that make use of other
installed packag
In order for the OC button to only be shown in typed languages, their
`lang/reader.rkt' files [1] need to specify which buttons should be
shown by DrRacket, which requires `dynamic-require'ing OC.
If there's a better way to do it, I'd be happy to change that code.
Vincent
[1] e.g. pkgs/typed-ra
Oh, I see.
Robby
On Tue, Nov 26, 2013 at 7:43 AM, Sam Tobin-Hochstadt
wrote:
> I think TR is checking for, and then dynamic-requireing, the Optimization
> Coach implementation.
>
> Sam
> On Nov 26, 2013 8:36 AM, "Robby Findler"
> wrote:
>
>> Why does TR have to do something special for DrRacke
I think TR is checking for, and then dynamic-requireing, the Optimization
Coach implementation.
Sam
On Nov 26, 2013 8:36 AM, "Robby Findler"
wrote:
> Why does TR have to do something special for DrRacket? Can't it just
> depend on the (small) package drracket-plugin-lib? There should then be no
Why does TR have to do something special for DrRacket? Can't it just depend
on the (small) package drracket-plugin-lib? There should then be no need
for dynamic-requires.
Robby
On Tue, Nov 26, 2013 at 7:12 AM, Vincent St-Amour wrote:
> You could guard the `dynamic-require' with a dynamic check
You could guard the `dynamic-require' with a dynamic check for the
existence of what it's requiring. In the specific case of xrepl, the
dynamic check should probably guard command registration so that, e.g.
the macro stepper commands are not available if the macro stepper is not
installed.
That's
16 matches
Mail list logo