Re: [racket-dev] [racket] Implementing contracts for async channels
Ah: one other note. When you do something like this: ((contract (- (list/c (box/c integer?)) any) (λ (x) (unbox (car x))) 'pos 'neg) (list (box not an integer))) you get an error message that has this text in the middle: in: the content of the 1st element of the 1st argument of (- (list/c (box/c integer?)) any) This path information is collected in the blame records. So, instead of passing along just the blame record you got, call blame-add-context so you get some stuff in that portion of the error message. Maybe a value passed on or something like that would be a good phrase? I usually look at a few examples to pick something. Otherwise, this looks good to merge to me (but I don't use the generics as much as I should so if you wanted to you could try asking for someone specifically knowledgeable to look there). If you don't, I can push the commit to the appropriate repo. Let me know. Robby On Mon, Jan 19, 2015 at 5:44 PM, Alexis King lexi.lam...@gmail.com wrote: Yes, there are tests, and you can see them here. On Jan 19, 2015, at 13:29, Robby Findler ro...@eecs.northwestern.edu wrote: This seemed okay, but just a quick read of the code. But did I miss the test cases? (I just followed the link upthread -- sorry if I need to look somewhere else too.) Robby On Mon, Jan 19, 2015 at 3:15 PM, Alexis King lexi.lam...@gmail.com wrote: Any update on this? If there’s anything that still needs to be changed, let me know—otherwise, I’ll patiently wait for the process to run its course. Just checking in. On Jan 16, 2015, at 10:15, Alexis King lexi.lam...@gmail.com wrote: Ah, that makes sense, fixed. On Jan 16, 2015, at 05:37, Robby Findler ro...@eecs.northwestern.edu wrote: One comment. The contract combinators are curried so that you can do work on the partial applications. So don't write this: (define ho-val-first-projection impersonate/chaperone-async-channel) ctc) blame) val) instead try to do some work earlier, when you first can. (The most important thing is to minimize the work done after you get the 'val' argument.) Robby _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Implementing contracts for async channels
Oh, sorry I missed that. Robby On Mon, Jan 19, 2015 at 6:40 PM, Alexis King lexi.lam...@gmail.com wrote: I already used blame-add-context, but the message I used wasn’t very good, so I’ve improved it. If everything else looks good, feel free to merge this whenever you get the chance! On Jan 19, 2015, at 15:52, Robby Findler ro...@eecs.northwestern.edu wrote: Ah: one other note. When you do something like this: ((contract (- (list/c (box/c integer?)) any) (λ (x) (unbox (car x))) 'pos 'neg) (list (box not an integer))) you get an error message that has this text in the middle: in: the content of the 1st element of the 1st argument of (- (list/c (box/c integer?)) any) This path information is collected in the blame records. So, instead of passing along just the blame record you got, call blame-add-context so you get some stuff in that portion of the error message. Maybe a value passed on or something like that would be a good phrase? I usually look at a few examples to pick something. Otherwise, this looks good to merge to me (but I don't use the generics as much as I should so if you wanted to you could try asking for someone specifically knowledgeable to look there). If you don't, I can push the commit to the appropriate repo. Let me know. Robby On Mon, Jan 19, 2015 at 5:44 PM, Alexis King lexi.lam...@gmail.com wrote: Yes, there are tests, and you can see them here. On Jan 19, 2015, at 13:29, Robby Findler ro...@eecs.northwestern.edu wrote: This seemed okay, but just a quick read of the code. But did I miss the test cases? (I just followed the link upthread -- sorry if I need to look somewhere else too.) Robby On Mon, Jan 19, 2015 at 3:15 PM, Alexis King lexi.lam...@gmail.com wrote: Any update on this? If there’s anything that still needs to be changed, let me know—otherwise, I’ll patiently wait for the process to run its course. Just checking in. On Jan 16, 2015, at 10:15, Alexis King lexi.lam...@gmail.com wrote: Ah, that makes sense, fixed. On Jan 16, 2015, at 05:37, Robby Findler ro...@eecs.northwestern.edu wrote: One comment. The contract combinators are curried so that you can do work on the partial applications. So don't write this: (define ho-val-first-projection impersonate/chaperone-async-channel) ctc) blame) val) instead try to do some work earlier, when you first can. (The most important thing is to minimize the work done after you get the 'val' argument.) Robby _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Implementing contracts for async channels
Yes, there are tests, and you can see them here https://github.com/plt/racket/pull/860/files#diff-9383600c097f090324382317068c6187R1. On Jan 19, 2015, at 13:29, Robby Findler ro...@eecs.northwestern.edu wrote: This seemed okay, but just a quick read of the code. But did I miss the test cases? (I just followed the link upthread -- sorry if I need to look somewhere else too.) Robby On Mon, Jan 19, 2015 at 3:15 PM, Alexis King lexi.lam...@gmail.com wrote: Any update on this? If there’s anything that still needs to be changed, let me know—otherwise, I’ll patiently wait for the process to run its course. Just checking in. On Jan 16, 2015, at 10:15, Alexis King lexi.lam...@gmail.com wrote: Ah, that makes sense, fixed. On Jan 16, 2015, at 05:37, Robby Findler ro...@eecs.northwestern.edu wrote: One comment. The contract combinators are curried so that you can do work on the partial applications. So don't write this: (define ho-val-first-projection impersonate/chaperone-async-channel) ctc) blame) val) instead try to do some work earlier, when you first can. (The most important thing is to minimize the work done after you get the 'val' argument.) Robby _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Implementing contracts for async channels
I already used blame-add-context, but the message I used wasn’t very good, so I’ve improved it. If everything else looks good, feel free to merge this whenever you get the chance! On Jan 19, 2015, at 15:52, Robby Findler ro...@eecs.northwestern.edu wrote: Ah: one other note. When you do something like this: ((contract (- (list/c (box/c integer?)) any) (λ (x) (unbox (car x))) 'pos 'neg) (list (box not an integer))) you get an error message that has this text in the middle: in: the content of the 1st element of the 1st argument of (- (list/c (box/c integer?)) any) This path information is collected in the blame records. So, instead of passing along just the blame record you got, call blame-add-context so you get some stuff in that portion of the error message. Maybe a value passed on or something like that would be a good phrase? I usually look at a few examples to pick something. Otherwise, this looks good to merge to me (but I don't use the generics as much as I should so if you wanted to you could try asking for someone specifically knowledgeable to look there). If you don't, I can push the commit to the appropriate repo. Let me know. Robby On Mon, Jan 19, 2015 at 5:44 PM, Alexis King lexi.lam...@gmail.com wrote: Yes, there are tests, and you can see them here. On Jan 19, 2015, at 13:29, Robby Findler ro...@eecs.northwestern.edu wrote: This seemed okay, but just a quick read of the code. But did I miss the test cases? (I just followed the link upthread -- sorry if I need to look somewhere else too.) Robby On Mon, Jan 19, 2015 at 3:15 PM, Alexis King lexi.lam...@gmail.com wrote: Any update on this? If there’s anything that still needs to be changed, let me know—otherwise, I’ll patiently wait for the process to run its course. Just checking in. On Jan 16, 2015, at 10:15, Alexis King lexi.lam...@gmail.com wrote: Ah, that makes sense, fixed. On Jan 16, 2015, at 05:37, Robby Findler ro...@eecs.northwestern.edu wrote: One comment. The contract combinators are curried so that you can do work on the partial applications. So don't write this: (define ho-val-first-projection impersonate/chaperone-async-channel) ctc) blame) val) instead try to do some work earlier, when you first can. (The most important thing is to minimize the work done after you get the 'val' argument.) Robby _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Implementing contracts for async channels
Any update on this? If there’s anything that still needs to be changed, let me know—otherwise, I’ll patiently wait for the process to run its course. Just checking in. On Jan 16, 2015, at 10:15, Alexis King lexi.lam...@gmail.com wrote: Ah, that makes sense, fixed. On Jan 16, 2015, at 05:37, Robby Findler ro...@eecs.northwestern.edu wrote: One comment. The contract combinators are curried so that you can do work on the partial applications. So don't write this: (define ho-val-first-projection impersonate/chaperone-async-channel) ctc) blame) val) instead try to do some work earlier, when you first can. (The most important thing is to minimize the work done after you get the 'val' argument.) Robby _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Implementing contracts for async channels
This seemed okay, but just a quick read of the code. But did I miss the test cases? (I just followed the link upthread -- sorry if I need to look somewhere else too.) Robby On Mon, Jan 19, 2015 at 3:15 PM, Alexis King lexi.lam...@gmail.com wrote: Any update on this? If there’s anything that still needs to be changed, let me know—otherwise, I’ll patiently wait for the process to run its course. Just checking in. On Jan 16, 2015, at 10:15, Alexis King lexi.lam...@gmail.com wrote: Ah, that makes sense, fixed. On Jan 16, 2015, at 05:37, Robby Findler ro...@eecs.northwestern.edu wrote: One comment. The contract combinators are curried so that you can do work on the partial applications. So don't write this: (define ho-val-first-projection impersonate/chaperone-async-channel) ctc) blame) val) instead try to do some work earlier, when you first can. (The most important thing is to minimize the work done after you get the 'val' argument.) Robby _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Implementing contracts for async channels
Ah, that makes sense, fixed. On Jan 16, 2015, at 05:37, Robby Findler ro...@eecs.northwestern.edu wrote: One comment. The contract combinators are curried so that you can do work on the partial applications. So don't write this: (define ho-val-first-projection impersonate/chaperone-async-channel) ctc) blame) val) instead try to do some work earlier, when you first can. (The most important thing is to minimize the work done after you get the 'val' argument.) Robby _ Racket Developers list: http://lists.racket-lang.org/dev
