Re: [racket-dev] [racket] Implementing contracts for async channels

[Alexis King]

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  wrote:
> 
> Ah, that makes sense, fixed.
> 
>> On Jan 16, 2015, at 05:37, Robby Findler  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

[Robby Findler]

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  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  wrote:
>>
>> Ah, that makes sense, fixed.
>>
>>> On Jan 16, 2015, at 05:37, Robby Findler  
>>> 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

[Alexis King]

Yes, there are tests, and you can see them here 
.

> On Jan 19, 2015, at 13:29, Robby Findler  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  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  wrote:
>>> 
>>> Ah, that makes sense, fixed.
>>> 
 On Jan 16, 2015, at 05:37, Robby Findler  
 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

[Robby Findler]

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  wrote:
> Yes, there are tests, and you can see them here.
>
> On Jan 19, 2015, at 13:29, Robby Findler 
> 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  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  wrote:
>
> Ah, that makes sense, fixed.
>
> On Jan 16, 2015, at 05:37, Robby Findler 
> 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

[Alexis King]

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  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  wrote:
>> Yes, there are tests, and you can see them here.
>> 
>> On Jan 19, 2015, at 13:29, Robby Findler 
>> 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  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  wrote:
>> 
>> Ah, that makes sense, fixed.
>> 
>> On Jan 16, 2015, at 05:37, Robby Findler 
>> 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

[Robby Findler]

Oh, sorry I missed that.

Robby

On Mon, Jan 19, 2015 at 6:40 PM, Alexis King  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  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  wrote:
>>> Yes, there are tests, and you can see them here.
>>>
>>> On Jan 19, 2015, at 13:29, Robby Findler 
>>> 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  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  wrote:
>>>
>>> Ah, that makes sense, fixed.
>>>
>>> On Jan 16, 2015, at 05:37, Robby Findler 
>>> 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