Re: [racket-dev] [plt] Push #29098: master branch updated

2014-07-25 Thread Sam Tobin-Hochstadt
On Fri, Jul 25, 2014 at 10:39 AM, wrote: > > | As far as I can tell, we have to compute ourselves whether a > | date is in daylight-saving time based on specifications of > | when daylight and standard times start. That part seems tricky > | and could use extra review. >From a quick search of th

Re: [racket-dev] Racket hash tables vs. Python dicts - Performance

2014-07-25 Thread Jake Eakle
This is probably not responsible for much of the performance difference, but the racket code has (random 23) where it looks like it ought to be (random 26), resulting in a smaller space of possible random keys. This will cause the branch with the lookup to happen somewhat more often than in the pyt

Re: [racket-dev] A tricky chaperone puzzle

2014-07-25 Thread Sam Tobin-Hochstadt
I only thought of it because the first thing I tried was to break the chaperone invariant, thinking that 2 might already have been the behavior. I only came up with the access control variant when that didn't work. Sam On Jul 25, 2014 6:04 AM, "Matthew Flatt" wrote: > Unless I still have it wron

Re: [racket-dev] A tricky chaperone puzzle

2014-07-25 Thread Matthew Flatt
Unless I still have it wrong, the implementation of 2 was straightforward. I would have overlooked the need to restrict `chaperone-struct` to chaperones of accessors and mutators if you hadn't mentioned it. At Thu, 24 Jul 2014 15:45:18 -0400, Sam Tobin-Hochstadt wrote: > Consider the following mo

Re: [racket-dev] Racket hash tables vs. Python dicts - Performance

2014-07-25 Thread Laurent
Even more idiomatic: (time (for ([w words]) (hash-update! d w add1 0))) But it seems to be slightly slower that Robby's version. Laurent On Thu, Jul 24, 2014 at 11:26 AM, Robby Findler wrote: > Not an answer to your direction question, but this is the more > idiomatic way to write tha