On Wed, May 4, 2016 at 5:36 PM, Sam Tobin-Hochstadt
wrote:
> On Wed, May 4, 2016 at 5:30 PM, 'John Clements' via Racket Users
> wrote:
>>
>> IIUC, it sounds like both you and Sam are suggesting the same
>> thing. I think this *could* cause
> On May 4, 2016, at 2:36 PM, Sam Tobin-Hochstadt wrote:
>
> On Wed, May 4, 2016 at 5:30 PM, 'John Clements' via Racket Users
> wrote:
>>
>>> On May 4, 2016, at 2:24 PM, Eli Barzilay wrote:
>>>
>>> On Wed, May 4, 2016
On Wed, May 4, 2016 at 5:30 PM, 'John Clements' via Racket Users
wrote:
>
>> On May 4, 2016, at 2:24 PM, Eli Barzilay wrote:
>>
>> On Wed, May 4, 2016 at 5:12 PM, John Clements
>> wrote:
>>>
>>> So, I’d say this is
> On May 4, 2016, at 2:24 PM, Eli Barzilay wrote:
>
> On Wed, May 4, 2016 at 5:12 PM, John Clements
> wrote:
>>
>> So, I’d say this is basically an ergonomics issue. If we change this
>> code to raise a new exception, then it might potentially
> On May 4, 2016, at 2:20 PM, Sam Tobin-Hochstadt wrote:
>
> I am opposed to breaking backwards compatibility for this.
>
> However, one possibility would be to do the thing I suggested _iff_
> the exception is non-transparent. Then everything that works would
> keep
On Wed, May 4, 2016 at 5:12 PM, John Clements wrote:
>
> So, I’d say this is basically an ergonomics issue. If we change this
> code to raise a new exception, then it might potentially confuse a
> handin-server-checker-writer, who expects (e.g.) to see a
>
I am opposed to breaking backwards compatibility for this.
However, one possibility would be to do the thing I suggested _iff_
the exception is non-transparent. Then everything that works would
keep working, and future issues like this would not arise.
Sam
On Wed, May 4, 2016 at 5:12 PM, 'John
On Wed, May 4, 2016 at 1:14 PM, John Clements wrote:
>
>> On May 4, 2016, at 9:59 AM, Sam Tobin-Hochstadt wrote:
>>
>> That seems fine, but the general approach the handin-server is taking
>> seems wrong to me. If it wants an exception with a
On Wed, May 4, 2016 at 1:14 PM, 'John Clements' via Racket Users
wrote:
>
>> On May 4, 2016, at 9:59 AM, Sam Tobin-Hochstadt wrote:
>>
>> That seems fine, but the general approach the handin-server is taking seems
>> wrong to me. If it wants
> On May 4, 2016, at 9:59 AM, Sam Tobin-Hochstadt wrote:
>
> That seems fine, but the general approach the handin-server is taking seems
> wrong to me. If it wants an exception with a different message, it should
> just create that, rather than assuming that all
That seems fine, but the general approach the handin-server is taking seems
wrong to me. If it wants an exception with a different message, it should
just create that, rather than assuming that all exception structures are
reasonable to modify.
Sam
On Wed, May 4, 2016, 12:52 PM 'John Clements'
Bump.
Okay if I make a pull request to make ‘match’ exceptions transparent? I see
that all of the ones listed in 10.2.5 are transparent.
John
> On Apr 27, 2016, at 3:08 PM, John Clements wrote:
>
>
>> On Apr 27, 2016, at 3:01 PM, Sam Tobin-Hochstadt
> On Apr 27, 2016, at 3:01 PM, Sam Tobin-Hochstadt wrote:
>
> The exceptions raised by `match` are indeed not transparent. But I
> don't understand why they need to be in order for the handin server to
> handle them properly.
(caveat: this is my reading of the code below)
The exceptions raised by `match` are indeed not transparent. But I
don't understand why they need to be in order for the handin server to
handle them properly.
Sam
On Wed, Apr 27, 2016 at 5:58 PM, 'John Clements' via Racket Users
wrote:
>
>> On Apr 22, 2016, at
> On Apr 22, 2016, at 1:47 PM, 'John Clements' via Racket Users
> wrote:
>
> Currently, the handin-server runs student expressions in an ‘eval’ which
> intercepts errors and re-raises them with a message that includes the failing
> expression. All good.
>
>
Currently, the handin-server runs student expressions in an ‘eval’ which
intercepts errors and re-raises them with a message that includes the failing
expression. All good.
However, it doesn’t catch all of them. Specifically, if the exception contains
any values that are opaque to
16 matches
Mail list logo