Re: [racket-dev] Refactoring in-vector and friends
I've merged the changes back into for.rkt and pushed the changes. This is just refactoring the in-vector code. I'll do a separate commit when I modify in-fXvector. And yes, tests all pass :) N. On Fri, Dec 3, 2010 at 1:22 AM, Eli Barzilay e...@barzilay.org wrote: 1. At this level, I think that the costs are very important -- and there's two possible costs here: (a) it adds more files to racket/base which adds some overhead to starting up; (b) more importantly, there is no inlining across module boundaries, ... _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Refactoring in-vector and friends
Since merging with HEAD I get repeatable segfaults in the prompt tests: ... and 19526 exception field tests. Errors were: (Section (got expected (call))) ((syntax) (9 10 (#procedure:dynamic-require (quote set-local-dfs) ten))) (Other messages report successful tests of error-handling behavior.) Section(prompt) Seg fault (internal error) at 0x1c0 Bus error These errors didn't appear with my changes before merging. I went back to the revision before my commit and I still get this segfault. I've rebuilt (raco setup) numerous times. Is this a known problem? If it is, I can push the rest of my changes. If not, I guess I better rebuild from source. N. On Fri, Dec 3, 2010 at 10:38 AM, Noel Welsh noelwe...@gmail.com wrote: I've merged the changes back into for.rkt and pushed the changes. This is just refactoring the in-vector code. I'll do a separate commit when I modify in-fXvector. And yes, tests all pass :) N. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Refactoring in-vector and friends
That's the problem -- doing a full rebuild has fixed it. in-flvector and in-fxvector have been extended (and doc'ed and tested), and I also optimised some of the code to use unsafe ops. The vector defns in ffi/vector.rkt should probably use these tools to provide sequence abstractions, but I'm out of steam for now. (This process makes testing changes so time consuming I don't know how y'all ever get anything done. Maybe rebuild once a day or something.) N. On Fri, Dec 3, 2010 at 1:20 PM, Matthew Flatt mfl...@cs.utah.edu wrote: Is it possible that your binary didn't get rebuilt? The test failure and crash seem to be in recently added tests to go with recent repairs to the Racket binary. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Refactoring in-vector and friends
I've read the commit and it looks like a good change. I presume you've re-run the tests and you'll write new tests for the new vector types? Jay On Wed, Dec 1, 2010 at 8:41 AM, Noel Welsh noelwe...@gmail.com wrote: Hi all, I spent (far too much) time this morning refactoring the definition of in-vector to expose the building blocks to compose these macro/functions. After refactoring the code for defining in-vector is: (define-:vector-like-gen :vector-gen unsafe-vector-ref) (define-in-vector-like in-vector vector vector? vector-length :vector-gen) (define-sequence-syntax *in-vector (lambda () #'in-vector) (make-in-vector-like #'vector? #'unsafe-vector-length #'in-vector #'unsafe-vector-ref)) This could obviously be made smaller but it sufficient to enable reuse for in-flvector (my goal), in-f64vector etc. In doing so I split for.rkt into three (I couldn't handle refactoring the 1000+ lines of for.rkt; I needed something smaller to understand it all). Since this is a moderately large change I'm looking for comments/objections before committing. If you have objections please let me know -- if I don't hear any I'll commit tomorrow. Diff is attached. N. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Refactoring in-vector and friends
Hi all, I spent (far too much) time this morning refactoring the definition of in-vector to expose the building blocks to compose these macro/functions. After refactoring the code for defining in-vector is: (define-:vector-like-gen :vector-gen unsafe-vector-ref) (define-in-vector-like in-vector vector vector? vector-length :vector-gen) (define-sequence-syntax *in-vector (lambda () #'in-vector) (make-in-vector-like #'vector? #'unsafe-vector-length #'in-vector #'unsafe-vector-ref)) This could obviously be made smaller but it sufficient to enable reuse for in-flvector (my goal), in-f64vector etc. In doing so I split for.rkt into three (I couldn't handle refactoring the 1000+ lines of for.rkt; I needed something smaller to understand it all). Since this is a moderately large change I'm looking for comments/objections before committing. If you have objections please let me know -- if I don't hear any I'll commit tomorrow. Diff is attached. N. vector.diff Description: Binary data _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
