Re: [racket-users] Narrow radix of string->number.

I'm skeptical of an unbounded cache. If we go by the sample from DrRacket's start up, then we don't really need a cache to do better than the built-in number->string. Below is some code that takes the version I had earlier with what I understood to be Gustavo's suggestions and then just does

Re: [racket-users] Errors in (Dr)Racket

I mostly agree with Matthias, but wanted to add two things: 1) I've certainly experienced, many times, (both as the producer and consumer (and sometimes simultaneously)) contracts that were added because of runtime errors. But I do agree it is not as common as we had hoped it would be. And

Re: [racket-users] Errors in (Dr)Racket

> On Jan 1, 2017, at 1:17 PM, Stephen De Gabrielle > wrote: > > Hi All, > > I occasionally write code with errors* that cause the DrRacket error message > to link to an internal Racket file, rather than my own incorrect code. > > The last time I did this it was

[racket-users] Errors in (Dr)Racket

Hi All, I occasionally write code with errors* that cause the DrRacket error message to link to an internal Racket file, rather than my own incorrect code. The last time I did this it was doing web server code, but I've also managed it with GUI code.(and playing with DrRacket Plugins) I've not

Re: [racket-users] Narrow radix of string->number.

> On Dec 31, 2016, at 12:05 PM, Robby Findler > wrote: > > But this introduces an additional cost that's a little bit more > troublesome to measure. Specifically, each namespace that instantiates > `racket/base` will now take a tiny bit more space and take a tiny