Re: [racket-dev] Removing Xexpr preference from Web Server
On Sat, Dec 4, 2010 at 10:29 PM, Jay McCarthy jay.mccar...@gmail.comwrote: The Web Server will define response/c as (dynamic/c any/c current-response/c response?) and provide the current-response/c parameter for customization. The default will be no coercion, but Xexpr conversion will be easily accessible. A compatibility library will automatically set current-response/c appropriately. This looks great! And again thanks for taking the time to go through a vetting process - appreciated. Cheers, yc _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Fixing uncertified context error in in-vector
It looks like a problem with certificates, the custom expander for `define-sequence-syntax', and fact that `make-in-vector-like' originates from a module other than the one containing the `define-sequence-syntax'. For now, just export `normalise-inputs'. Ryan and I are looking to an overhaul of syntax certificates. Also, you're using `unsafe-fx...' on numbers that haven't been checked to be fixnums (i.e., `exact-nonnegative-integer?' does not imply fixnum). I think you should just use generic arithmetic. The bug fix and documentation improvements are much appreciated! At Sun, 5 Dec 2010 08:28:08 +, Noel Welsh wrote: While doing my last change to in-vector I discovered a bug (that has been there for a long time, I think). To fix it I refactored the code and changed the invariants slightly, so start, stop, and step are now checked before the sequence runs. (The bug was the use of unsafe-vector-ref without checking the indices were in range). I now get this error in the tests: Section(fixnum) ERROR: compile: access from an uncertified context to unexported variable from module: /usr/local/plt-head/collects/racket/private/for.rkt in: normalise-inputs I have no clue how to fix it. Diff is attached. Any suggestions would be great. N. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
You've made a contract that isn't a projection, but does a coercion? I'd be happier if you instead made your own separate wrappers and didn't use /c and didn't call this a contract. Robby On Sun, Dec 5, 2010 at 12:29 AM, Jay McCarthy jay.mccar...@gmail.com wrote: Giving special consideration to Eli and YC's perspectives, I've come up with the following way out of this problem. I found a way to provide a global hook that is tasteful to me. I've created dynamic/c. Here's a little example: Examples: (define p (make-parameter any/c)) (define c (dynamic/c string? p number?)) (contract c 123 'pos 'neg) pos broke the contract (dynamic string? #procedure:parameter-procedure number?) on eval:5:0; expected number?, given: 123 (p (coerce/c string-number)) (contract c 123 'pos 'neg) 123 (contract c 123a 'pos 'neg) pos broke the contract (dynamic string? #procedure:parameter-procedure number?) on eval:8:0; Coercion failed The Web Server will define response/c as (dynamic/c any/c current-response/c response?) and provide the current-response/c parameter for customization. The default will be no coercion, but Xexpr conversion will be easily accessible. A compatibility library will automatically set current-response/c appropriately. Attached is the new compatibility README. I hope this will satisfy all. Jay -- 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 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
All dynamic/c does is apply three contracts in a particular order where one is dynamic. coerce/c strongly implies that the function is coercion, but its implementation is similar to how the contract system must already use projection functions (ie it cannot confirm that are actually projections; it just applies them and uses the result) The default value of current-response/c is a projection (any/c) The compatibility library does not provide anything with the /c suffix that is a coercion --- it gives normalize-response and automatically sets current-response/c, but doesn't give anything that implies it is a contract Thus, the only thing that IMHO should irk you is xexpr-response/c that has the /c suffix and uses coerce/c with an actual coercion. Is that the case? What do you want me to call it? Jay On Sun, Dec 5, 2010 at 6:46 AM, Robby Findler ro...@eecs.northwestern.eduwrote: You've made a contract that isn't a projection, but does a coercion? I'd be happier if you instead made your own separate wrappers and didn't use /c and didn't call this a contract. Robby On Sun, Dec 5, 2010 at 12:29 AM, Jay McCarthy jay.mccar...@gmail.com wrote: Giving special consideration to Eli and YC's perspectives, I've come up with the following way out of this problem. I found a way to provide a global hook that is tasteful to me. I've created dynamic/c. Here's a little example: Examples: (define p (make-parameter any/c)) (define c (dynamic/c string? p number?)) (contract c 123 'pos 'neg) pos broke the contract (dynamic string? #procedure:parameter-procedure number?) on eval:5:0; expected number?, given: 123 (p (coerce/c string-number)) (contract c 123 'pos 'neg) 123 (contract c 123a 'pos 'neg) pos broke the contract (dynamic string? #procedure:parameter-procedure number?) on eval:8:0; Coercion failed The Web Server will define response/c as (dynamic/c any/c current-response/c response?) and provide the current-response/c parameter for customization. The default will be no coercion, but Xexpr conversion will be easily accessible. A compatibility library will automatically set current-response/c appropriately. Attached is the new compatibility README. I hope this will satisfy all. Jay -- 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 -- 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
Re: [racket-dev] Removing Xexpr preference from Web Server
On Sun, Dec 5, 2010 at 8:00 AM, Jay McCarthy jay.mccar...@gmail.com wrote: All dynamic/c does is apply three contracts in a particular order where one is dynamic. coerce/c strongly implies that the function is coercion, but its implementation is similar to how the contract system must already use projection functions (ie it cannot confirm that are actually projections; it just applies them and uses the result) The default value of current-response/c is a projection (any/c) The compatibility library does not provide anything with the /c suffix that is a coercion --- it gives normalize-response and automatically sets current-response/c, but doesn't give anything that implies it is a contract Thus, the only thing that IMHO should irk you is xexpr-response/c that has the /c suffix and uses coerce/c with an actual coercion. Is that the case? What do you want me to call it? It also slightly bothers me that you use it with the other contracts, even though it isn't a contract. (In case it wasn't clear, this is a coding guidelines issue, fwiw.) I don't care what else you call it. Coercion seems like a good word, if you want a suggestion. Robby Jay On Sun, Dec 5, 2010 at 6:46 AM, Robby Findler ro...@eecs.northwestern.edu wrote: You've made a contract that isn't a projection, but does a coercion? I'd be happier if you instead made your own separate wrappers and didn't use /c and didn't call this a contract. Robby On Sun, Dec 5, 2010 at 12:29 AM, Jay McCarthy jay.mccar...@gmail.com wrote: Giving special consideration to Eli and YC's perspectives, I've come up with the following way out of this problem. I found a way to provide a global hook that is tasteful to me. I've created dynamic/c. Here's a little example: Examples: (define p (make-parameter any/c)) (define c (dynamic/c string? p number?)) (contract c 123 'pos 'neg) pos broke the contract (dynamic string? #procedure:parameter-procedure number?) on eval:5:0; expected number?, given: 123 (p (coerce/c string-number)) (contract c 123 'pos 'neg) 123 (contract c 123a 'pos 'neg) pos broke the contract (dynamic string? #procedure:parameter-procedure number?) on eval:8:0; Coercion failed The Web Server will define response/c as (dynamic/c any/c current-response/c response?) and provide the current-response/c parameter for customization. The default will be no coercion, but Xexpr conversion will be easily accessible. A compatibility library will automatically set current-response/c appropriately. Attached is the new compatibility README. I hope this will satisfy all. Jay -- 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 -- 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
Re: [racket-dev] Fixing uncertified context error in in-vector
On Sun, Dec 5, 2010 at 1:38 PM, Matthew Flatt mfl...@cs.utah.edu wrote: ... For now, just export `normalise-inputs'. Ryan and I are looking to an overhaul of syntax certificates. An easy fix. I'll do that. Also, you're using `unsafe-fx...' on numbers that haven't been checked to be fixnums (i.e., `exact-nonnegative-integer?' does not imply fixnum). I think you should just use generic arithmetic. You can't allocate more than a fixnum number of bytes, I believe. So start and stop must be fixnums if they're to be valid. This leaves only step. I'll check over the code and tighten up the checks before submitting. Or just use generic arithmetic. Thanks. N. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
Jay, coercions aka casts in our world are compound words with - in between them. Why do you need a new name? (There is an inconsistency in their behavior. To wit Welcome to Racket v5.0.99.4. (integer-char 1000) integer-char: expects argument of type exact integer in [0,#x10], not in [#xD800,#xDFFF]; given 1000 === context === /Users/matthias/plt/collects/racket/private/misc.rkt:78:7 (string-number a10) #f But that is a historical problem.) ;; --- I am also reluctant to throw contracts at dynamic places. Contract boundaries should be syntactically distinct, e.g., module boundaries or define/contract. ;; --- I think you're really just checking an assertion. So perhaps you want to go with /a as a suffix. -- Matthias _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Fixing uncertified context error in in-vector
At Sun, 5 Dec 2010 15:33:06 +, Noel Welsh wrote: On Sun, Dec 5, 2010 at 1:38 PM, Matthew Flatt mfl...@cs.utah.edu wrote: Also, you're using `unsafe-fx...' on numbers that haven't been checked to be fixnums (i.e., `exact-nonnegative-integer?' does not imply fixnum). I think you should just use generic arithmetic. You can't allocate more than a fixnum number of bytes, I believe. So start and stop must be fixnums if they're to be valid. Yes, but the `unsafe-fx' operations that I'm concerned about are the ones checking whether an index is valid: (unless (and (exact-nonnegative-integer? start) (unsafe-fx start len)) (raise-type-error who (format exact non-negative integer in [0,~a) len) start)) (unless (and (integer? stop) (unsafe-fx= -1 stop) (unsafe-fx= stop len)) (raise-type-error who (format exact integer in [-1,~a] or #f len) stop)) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Fixing uncertified context error in in-vector
Ah, I'll fix that up. That's 3 bugs in the code so far. AFAIK none have yet been found in practice! N. On Sun, Dec 5, 2010 at 4:31 PM, Matthew Flatt mfl...@cs.utah.edu wrote: Yes, but the `unsafe-fx' operations that I'm concerned about are the ones checking whether an index is valid: (unless (and (exact-nonnegative-integer? start) (unsafe-fx start len)) (raise-type-error who (format exact non-negative integer in [0,~a) len) start)) (unless (and (integer? stop) (unsafe-fx= -1 stop) (unsafe-fx= stop len)) (raise-type-error who (format exact integer in [-1,~a] or #f len) stop)) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
