Re: [racket-dev] , en and enter! sometimes do nothing, and it's changing over releases?
IMO, DrRacket-like functionality would be nice to have in an Emacs setting and probably using a sandbox is the way to get it. You'd want to not use the default settings for the sandbox, tho, but give more permissions for file access (and probably a few other things). Robby On Mon, Feb 11, 2013 at 1:07 AM, Eli Barzilay e...@barzilay.org wrote: 9 hours ago, Greg Hendershott wrote: I'm inclined to add a new command to XREPL that takes that approach, to experiment. I was spelunking in DrRacket source but I'm slow to isolate that from what else is going on. It sounds like you understand it; is there a code sample you could share? I'm not sure what exactly you're after, but you can get most of that using a ,switch command to create a new namespace, then using it with a ! flag to reset it. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Speeding up sequence-list
The performance of `sequence-list' came up on this thread: http://thread.gmane.org/gmane.comp.lang.racket.user/16384 `sequence-list' uses the sequence API to make a copy of its input. This can dominate the running time of functions that look like this: (define (f xs) (let ([xs (sequence-list xs)]) ... simple O(n) computation using xs ...)) Also, it seems wasteful to make a copy if `xs' is already a list. I'd like to change the definition of `sequence-list' from this: (define (sequence-list s) (for/list ([v s]) v)) to this, to handle the two most common sequences specially: (define (my-sequence-list s) (cond [(list? s) s] [(vector? s) (vector-list s)] [else (for/list ([v s]) v)])) For vectors, I measure a 3x speedup. For lists, it's of course O(1). It's a semantic change, but I can't imagine anyone relying on this fact: (not (eq? xs (sequence-list xs))) If someone does, [(list? s) (map values s)] would preserve that fact, and is 3x faster in my measurements. Thoughts? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Speeding up sequence-list
No one should rely on eq? of lists. especially not in code that didn't exist in the pre-immutable cons days. On Mon, Feb 11, 2013 at 12:17 PM, Neil Toronto neil.toro...@gmail.comwrote: The performance of `sequence-list' came up on this thread: http://thread.gmane.org/gmane.**comp.lang.racket.user/16384http://thread.gmane.org/gmane.comp.lang.racket.user/16384 `sequence-list' uses the sequence API to make a copy of its input. This can dominate the running time of functions that look like this: (define (f xs) (let ([xs (sequence-list xs)]) ... simple O(n) computation using xs ...)) Also, it seems wasteful to make a copy if `xs' is already a list. I'd like to change the definition of `sequence-list' from this: (define (sequence-list s) (for/list ([v s]) v)) to this, to handle the two most common sequences specially: (define (my-sequence-list s) (cond [(list? s) s] [(vector? s) (vector-list s)] [else (for/list ([v s]) v)])) For vectors, I measure a 3x speedup. For lists, it's of course O(1). It's a semantic change, but I can't imagine anyone relying on this fact: (not (eq? xs (sequence-list xs))) If someone does, [(list? s) (map values s)] would preserve that fact, and is 3x faster in my measurements. Thoughts? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/**dev http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
