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
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 `ra
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-expo
I think so, though it's possible that I've gotten lost in the different
variants of the problem.
At Tue, 3 May 2011 16:57:25 -0500, Robby Findler wrote:
> 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
> com
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 wrote:
> The parallel build has been changed again to use places by default. (The
> p
On Tue, May 3, 2011 at 4:55 PM, Matthew Flatt 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
> the SRFI-19 impl
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 -0700
It was driving me crazy that srfi-19 had no way to convert seconds to times,
especially given the fact that it appears that the internal representation used
by srfi 19's time-utc was the result of (current-seconds) so I added
seconds->time-utc and time-utc->seconds, along with test cases.
U
The parallel build has been changed again to use places by default. (The
previous memory leak problems have been fixed.)
This means that parallel zo and doc builds will use places instead of
processes.
Please look out for any unusual behavior and report bugs as usual
Thanks,
Kevin
Thanks for the careful analysis.
The best solution sounds to me like a form of backtracking so that the
matcher can skip clauses when it reaches cycles.
In the meantime, Stephen can manage with the suggestions below.
-- Matthias
On May 3, 2011, at 10:10 AM, Casey Klein wrote:
> On Mon, Ma
On Mon, May 2, 2011 at 8:45 PM, Stephen Chang 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
(in-hole (L e) (λ x ho
11 matches
Mail list logo
