On Mon, May 2, 2011 at 8:45 PM, Stephen Chang stch...@ccs.neu.edu wrote:
Hmm, or maybe you've found a bug in my model. Either way, thanks for
looking into this.
I couldn't resist taking another look.
Here's how I'd like to define it:
(define-language unfortunate-loop
(L hole
I think it's a bad idea to extend the SRFI modules with new functions.
Would it make sense to move functionality from SRFI-19 into
`racket/date' and then add the new functions there (and maybe change
the SRFI-19 implementation to re-export part of `racket/date')?
At Tue, 3 May 2011 14:48:42
On Tue, May 3, 2011 at 4:55 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
I think it's a bad idea to extend the SRFI modules with new functions.
I agree with this.
Would it make sense to move functionality from SRFI-19 into
`racket/date' and then add the new functions there (and maybe change
Have you fixed the freezing problem I reported under windows? If not,
maybe we should re-disable it there (since I rarely get builds to
complete with it enabled).
Robby
On Tue, May 3, 2011 at 4:20 PM, Kevin Tew t...@cs.utah.edu wrote:
The parallel build has been changed again to use places by
On May 3, 2011, at 2:55 PM, Matthew Flatt wrote:
I think it's a bad idea to extend the SRFI modules with new functions.
Would it make sense to move functionality from SRFI-19 into
`racket/date' and then add the new functions there (and maybe change
the SRFI-19 implementation to re-export
15 minutes ago, Matthew Flatt wrote:
I think it's a bad idea to extend the SRFI modules with new functions.
Would it make sense to move functionality from SRFI-19 into
`racket/date' and then add the new functions there (and maybe change
the SRFI-19 implementation to re-export part of
On Wednesday, Danny Yoo wrote:
I've isolated a performance issue on form-urlencoded-alist. On
strings with very long key/values, the code appears to consume an
unusual amount of memory. Does the following look ok?
I made a different change that simplifies the code and should be as
fast as
7 matches
Mail list logo
