[racket-users] Re: date->seconds complaining about a supposedly non-existent date

[Jack Firth]

There's also the Gregor package 
(https://docs.racket-lang.org/gregor/index.html?q=gregor), which gives a much 
more comprehensive interface to dates and times. In particular, Gregor allows 
you to specify an "offset resolver" for these sorts of time-holes.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Error ("assignment disallowed") when deserializing class-based objects

[Philip McGrath]

I'm looking into whether Racket's class/object system might be useful for
one of my projects, and I am stumped by an error when deserializing
objects. I've managed to produce the error a few different ways, but here
is a fairly minimal example:
> (define-serializable-class ok% object%
  (inspect #f)
  (init-field [my-field null])
  (super-new))
> (define-serializable-class broken% object%
  (inspect #f)
  (super-new)
  (init-field [my-field null]))
> (deserialize (serialize (new ok%)))
(object:ok% '())
> (deserialize (serialize (new broken%)))
my-field: assignment disallowed;
  cannot assign field before initialization
I am guessing there is some subtlety of the way new instances are
initialized that I don't properly understand. Can anyone explain what is
going wrong? (and, ideally, how to avoid the problem in other situations?)
Many thanks,
Philip

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] proposed minor improvement to stepper semantics

[Matthias Felleisen]

BSL’s IA doesn’t even do definitions. That’s the whole point. 


> On Oct 20, 2016, at 5:13 PM, Sam Tobin-Hochstadt  wrote:
> 
> That seems to me to be an issue with navigation in the stepper (which
> I'd also love to have improved). But I wouldn't want to fix that by
> asking people to first copy-and-paste things to the interactions
> window.
> 
> Sam
> 
> On Thu, Oct 20, 2016 at 5:01 PM, Robby Findler
>  wrote:
>> I don't agree with this at all.
>> 
>> Being forced to step through N check-expressions to get to the one you
>> care about it is not a feature to be preserved.
>> 
>> Robby
>> 
>> 
>> On Thu, Oct 20, 2016 at 4:00 PM, Sam Tobin-Hochstadt
>>  wrote:
>>> I wouldn't want to give up stepping the definitions window. When a
>>> student has a question about how something they've written works, it's
>>> usually written down in the definitions window, and I like being able
>>> to just start stepping that. More generally, I just don't use the
>>> interactions window that much, and so moving stepping to only there
>>> would be a big change that I don't see a pedagogical upside to.
>>> 
>>> What is the "check-syntax problem", by the way?
>>> 
>>> Sam
>>> 
>>> On Thu, Oct 20, 2016 at 4:56 PM, Matthias Felleisen
>>>  wrote:
 
 The difference is that we can simplify the stepper if all we ever evaluate 
 are expressions in the IA. For example, the check-syntax problem could go 
 away.
 
 I suspect the simplified presentation would also become more accessible to 
 most students than the current evaluation of many little expressions that 
 they forgot where expressions in the first place.
 
 But yes, from the perspective of (1) minimal work and (2) ease of use, 
 this works fine, too.
 
 
 
 
 
 
> On Oct 20, 2016, at 4:52 PM, Sam Tobin-Hochstadt  
> wrote:
> 
> I was thinking that the button at the top works the same as now, and
> that while it's open, everything goes to the stepper. That would work
> well for me in class.
> 
> Sam
> 
> On Thu, Oct 20, 2016 at 4:52 PM, Matthias Felleisen
>  wrote:
>> 
>> How do you open the stepper window in the first place? I think the 
>> stepper button for the DA could go away. That would simplify John’s life 
>> a bit. But if you are saying
>> 
>> — the button in the IA opens the stepper window
>> — and the stepper works until closed
>> 
>> I am fine with that too.
>> 
>> 
>> 
>> 
>>> On Oct 20, 2016, at 4:49 PM, Sam Tobin-Hochstadt  
>>> wrote:
>>> 
>>> What if entering expressions at the interactions window _while the
>>> stepper window is open_ caused them to be stepped?
>>> 
>>> Sam
>>> 
>>> On Thu, Oct 20, 2016 at 4:48 PM, Matthias Felleisen
>>>  wrote:
 
> On Oct 20, 2016, at 4:44 PM, John Clements 
>  wrote:
> 
>> 
>> On Oct 20, 2016, at 12:32 PM, Matthias Felleisen 
>>  wrote:
>> 
>> 
>>> On Oct 20, 2016, at 3:20 PM, John Clements 
>>>  wrote:
>>> 
>>> I think you probably want an interface that steps a single 
>>> expression and then reverts to the standard mode.
>> 
>> 
>> Exactly.
>> 
>> My preference would be to have a ‘button’ like feature at the 
>> top-right of the IA for *SLs. By default, it is disabled. If a 
>> programmer clicks on it, the evaluations in the REPL show the steps 
>> from now on until either the next click or the next RUN of the DA.
> 
> It doesn’t *sound* like we’re in agreement :)… I’m thinking that the 
> mode should revert to RUN after the next expression is entered in the 
> interactions window.
> 
> Let me see if I can hack something together.
 
 
 :-)
 
 I think we’re in agreement on (1) it’s easy to switch and (2) it 
 reverts ‘soon-ish’ to the normal run mode. The little grey scale of 
 ‘soon-ish’ is a minor hickup in our decades-long search for common 
 ground :))
 
 --
 You received this message because you are subscribed to the Google 
 Groups "Racket Users" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to racket-users+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
>> 
>> --
>> You received this message because you are subscribed to the Google 
>> Groups "Racket Users" group.
>> To unsubscribe from this group and stop receiving 

Re: [racket-users] proposed minor improvement to stepper semantics

[Sam Tobin-Hochstadt]

That seems to me to be an issue with navigation in the stepper (which
I'd also love to have improved). But I wouldn't want to fix that by
asking people to first copy-and-paste things to the interactions
window.

Sam

On Thu, Oct 20, 2016 at 5:01 PM, Robby Findler
 wrote:
> I don't agree with this at all.
>
> Being forced to step through N check-expressions to get to the one you
> care about it is not a feature to be preserved.
>
> Robby
>
>
> On Thu, Oct 20, 2016 at 4:00 PM, Sam Tobin-Hochstadt
>  wrote:
>> I wouldn't want to give up stepping the definitions window. When a
>> student has a question about how something they've written works, it's
>> usually written down in the definitions window, and I like being able
>> to just start stepping that. More generally, I just don't use the
>> interactions window that much, and so moving stepping to only there
>> would be a big change that I don't see a pedagogical upside to.
>>
>> What is the "check-syntax problem", by the way?
>>
>> Sam
>>
>> On Thu, Oct 20, 2016 at 4:56 PM, Matthias Felleisen
>>  wrote:
>>>
>>> The difference is that we can simplify the stepper if all we ever evaluate 
>>> are expressions in the IA. For example, the check-syntax problem could go 
>>> away.
>>>
>>> I suspect the simplified presentation would also become more accessible to 
>>> most students than the current evaluation of many little expressions that 
>>> they forgot where expressions in the first place.
>>>
>>> But yes, from the perspective of (1) minimal work and (2) ease of use, this 
>>> works fine, too.
>>>
>>>
>>>
>>>
>>>
>>>
 On Oct 20, 2016, at 4:52 PM, Sam Tobin-Hochstadt  
 wrote:

 I was thinking that the button at the top works the same as now, and
 that while it's open, everything goes to the stepper. That would work
 well for me in class.

 Sam

 On Thu, Oct 20, 2016 at 4:52 PM, Matthias Felleisen
  wrote:
>
> How do you open the stepper window in the first place? I think the 
> stepper button for the DA could go away. That would simplify John’s life 
> a bit. But if you are saying
>
> — the button in the IA opens the stepper window
> — and the stepper works until closed
>
> I am fine with that too.
>
>
>
>
>> On Oct 20, 2016, at 4:49 PM, Sam Tobin-Hochstadt  
>> wrote:
>>
>> What if entering expressions at the interactions window _while the
>> stepper window is open_ caused them to be stepped?
>>
>> Sam
>>
>> On Thu, Oct 20, 2016 at 4:48 PM, Matthias Felleisen
>>  wrote:
>>>
 On Oct 20, 2016, at 4:44 PM, John Clements  
 wrote:

>
> On Oct 20, 2016, at 12:32 PM, Matthias Felleisen 
>  wrote:
>
>
>> On Oct 20, 2016, at 3:20 PM, John Clements 
>>  wrote:
>>
>> I think you probably want an interface that steps a single 
>> expression and then reverts to the standard mode.
>
>
> Exactly.
>
> My preference would be to have a ‘button’ like feature at the 
> top-right of the IA for *SLs. By default, it is disabled. If a 
> programmer clicks on it, the evaluations in the REPL show the steps 
> from now on until either the next click or the next RUN of the DA.

 It doesn’t *sound* like we’re in agreement :)… I’m thinking that the 
 mode should revert to RUN after the next expression is entered in the 
 interactions window.

 Let me see if I can hack something together.
>>>
>>>
>>> :-)
>>>
>>> I think we’re in agreement on (1) it’s easy to switch and (2) it 
>>> reverts ‘soon-ish’ to the normal run mode. The little grey scale of 
>>> ‘soon-ish’ is a minor hickup in our decades-long search for common 
>>> ground :))
>>>
>>> --
>>> You received this message because you are subscribed to the Google 
>>> Groups "Racket Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to racket-users+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "Racket Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, 

Re: [racket-users] proposed minor improvement to stepper semantics

[Matthias Felleisen]

The old interface to the stepper could be preserved as a package. 



> On Oct 20, 2016, at 5:01 PM, Robby Findler  
> wrote:
> 
> I don't agree with this at all.
> 
> Being forced to step through N check-expressions to get to the one you
> care about it is not a feature to be preserved.
> 
> Robby
> 
> 
> On Thu, Oct 20, 2016 at 4:00 PM, Sam Tobin-Hochstadt
>  wrote:
>> I wouldn't want to give up stepping the definitions window. When a
>> student has a question about how something they've written works, it's
>> usually written down in the definitions window, and I like being able
>> to just start stepping that. More generally, I just don't use the
>> interactions window that much, and so moving stepping to only there
>> would be a big change that I don't see a pedagogical upside to.
>> 
>> What is the "check-syntax problem", by the way?
>> 
>> Sam
>> 
>> On Thu, Oct 20, 2016 at 4:56 PM, Matthias Felleisen
>>  wrote:
>>> 
>>> The difference is that we can simplify the stepper if all we ever evaluate 
>>> are expressions in the IA. For example, the check-syntax problem could go 
>>> away.
>>> 
>>> I suspect the simplified presentation would also become more accessible to 
>>> most students than the current evaluation of many little expressions that 
>>> they forgot where expressions in the first place.
>>> 
>>> But yes, from the perspective of (1) minimal work and (2) ease of use, this 
>>> works fine, too.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
 On Oct 20, 2016, at 4:52 PM, Sam Tobin-Hochstadt  
 wrote:
 
 I was thinking that the button at the top works the same as now, and
 that while it's open, everything goes to the stepper. That would work
 well for me in class.
 
 Sam
 
 On Thu, Oct 20, 2016 at 4:52 PM, Matthias Felleisen
  wrote:
> 
> How do you open the stepper window in the first place? I think the 
> stepper button for the DA could go away. That would simplify John’s life 
> a bit. But if you are saying
> 
> — the button in the IA opens the stepper window
> — and the stepper works until closed
> 
> I am fine with that too.
> 
> 
> 
> 
>> On Oct 20, 2016, at 4:49 PM, Sam Tobin-Hochstadt  
>> wrote:
>> 
>> What if entering expressions at the interactions window _while the
>> stepper window is open_ caused them to be stepped?
>> 
>> Sam
>> 
>> On Thu, Oct 20, 2016 at 4:48 PM, Matthias Felleisen
>>  wrote:
>>> 
 On Oct 20, 2016, at 4:44 PM, John Clements  
 wrote:
 
> 
> On Oct 20, 2016, at 12:32 PM, Matthias Felleisen 
>  wrote:
> 
> 
>> On Oct 20, 2016, at 3:20 PM, John Clements 
>>  wrote:
>> 
>> I think you probably want an interface that steps a single 
>> expression and then reverts to the standard mode.
> 
> 
> Exactly.
> 
> My preference would be to have a ‘button’ like feature at the 
> top-right of the IA for *SLs. By default, it is disabled. If a 
> programmer clicks on it, the evaluations in the REPL show the steps 
> from now on until either the next click or the next RUN of the DA.
 
 It doesn’t *sound* like we’re in agreement :)… I’m thinking that the 
 mode should revert to RUN after the next expression is entered in the 
 interactions window.
 
 Let me see if I can hack something together.
>>> 
>>> 
>>> :-)
>>> 
>>> I think we’re in agreement on (1) it’s easy to switch and (2) it 
>>> reverts ‘soon-ish’ to the normal run mode. The little grey scale of 
>>> ‘soon-ish’ is a minor hickup in our decades-long search for common 
>>> ground :))
>>> 
>>> --
>>> You received this message because you are subscribed to the Google 
>>> Groups "Racket Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to racket-users+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>>> 
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "Racket Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to racket-users+unsubscr...@googlegroups.com.
>>> For more options, visit 

Re: [racket-users] proposed minor improvement to stepper semantics

[Robby Findler]

I don't agree with this at all.

Being forced to step through N check-expressions to get to the one you
care about it is not a feature to be preserved.

Robby


On Thu, Oct 20, 2016 at 4:00 PM, Sam Tobin-Hochstadt
 wrote:
> I wouldn't want to give up stepping the definitions window. When a
> student has a question about how something they've written works, it's
> usually written down in the definitions window, and I like being able
> to just start stepping that. More generally, I just don't use the
> interactions window that much, and so moving stepping to only there
> would be a big change that I don't see a pedagogical upside to.
>
> What is the "check-syntax problem", by the way?
>
> Sam
>
> On Thu, Oct 20, 2016 at 4:56 PM, Matthias Felleisen
>  wrote:
>>
>> The difference is that we can simplify the stepper if all we ever evaluate 
>> are expressions in the IA. For example, the check-syntax problem could go 
>> away.
>>
>> I suspect the simplified presentation would also become more accessible to 
>> most students than the current evaluation of many little expressions that 
>> they forgot where expressions in the first place.
>>
>> But yes, from the perspective of (1) minimal work and (2) ease of use, this 
>> works fine, too.
>>
>>
>>
>>
>>
>>
>>> On Oct 20, 2016, at 4:52 PM, Sam Tobin-Hochstadt  
>>> wrote:
>>>
>>> I was thinking that the button at the top works the same as now, and
>>> that while it's open, everything goes to the stepper. That would work
>>> well for me in class.
>>>
>>> Sam
>>>
>>> On Thu, Oct 20, 2016 at 4:52 PM, Matthias Felleisen
>>>  wrote:

 How do you open the stepper window in the first place? I think the stepper 
 button for the DA could go away. That would simplify John’s life a bit. 
 But if you are saying

 — the button in the IA opens the stepper window
 — and the stepper works until closed

 I am fine with that too.




> On Oct 20, 2016, at 4:49 PM, Sam Tobin-Hochstadt  
> wrote:
>
> What if entering expressions at the interactions window _while the
> stepper window is open_ caused them to be stepped?
>
> Sam
>
> On Thu, Oct 20, 2016 at 4:48 PM, Matthias Felleisen
>  wrote:
>>
>>> On Oct 20, 2016, at 4:44 PM, John Clements  
>>> wrote:
>>>

 On Oct 20, 2016, at 12:32 PM, Matthias Felleisen 
  wrote:


> On Oct 20, 2016, at 3:20 PM, John Clements 
>  wrote:
>
> I think you probably want an interface that steps a single expression 
> and then reverts to the standard mode.


 Exactly.

 My preference would be to have a ‘button’ like feature at the 
 top-right of the IA for *SLs. By default, it is disabled. If a 
 programmer clicks on it, the evaluations in the REPL show the steps 
 from now on until either the next click or the next RUN of the DA.
>>>
>>> It doesn’t *sound* like we’re in agreement :)… I’m thinking that the 
>>> mode should revert to RUN after the next expression is entered in the 
>>> interactions window.
>>>
>>> Let me see if I can hack something together.
>>
>>
>> :-)
>>
>> I think we’re in agreement on (1) it’s easy to switch and (2) it reverts 
>> ‘soon-ish’ to the normal run mode. The little grey scale of ‘soon-ish’ 
>> is a minor hickup in our decades-long search for common ground :))
>>
>> --
>> You received this message because you are subscribed to the Google 
>> Groups "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send 
>> an email to racket-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

 --
 You received this message because you are subscribed to the Google Groups 
 "Racket Users" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to racket-users+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to racket-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received 

Re: [racket-users] proposed minor improvement to stepper semantics

[Sam Tobin-Hochstadt]

I wouldn't want to give up stepping the definitions window. When a
student has a question about how something they've written works, it's
usually written down in the definitions window, and I like being able
to just start stepping that. More generally, I just don't use the
interactions window that much, and so moving stepping to only there
would be a big change that I don't see a pedagogical upside to.

What is the "check-syntax problem", by the way?

Sam

On Thu, Oct 20, 2016 at 4:56 PM, Matthias Felleisen
 wrote:
>
> The difference is that we can simplify the stepper if all we ever evaluate 
> are expressions in the IA. For example, the check-syntax problem could go 
> away.
>
> I suspect the simplified presentation would also become more accessible to 
> most students than the current evaluation of many little expressions that 
> they forgot where expressions in the first place.
>
> But yes, from the perspective of (1) minimal work and (2) ease of use, this 
> works fine, too.
>
>
>
>
>
>
>> On Oct 20, 2016, at 4:52 PM, Sam Tobin-Hochstadt  
>> wrote:
>>
>> I was thinking that the button at the top works the same as now, and
>> that while it's open, everything goes to the stepper. That would work
>> well for me in class.
>>
>> Sam
>>
>> On Thu, Oct 20, 2016 at 4:52 PM, Matthias Felleisen
>>  wrote:
>>>
>>> How do you open the stepper window in the first place? I think the stepper 
>>> button for the DA could go away. That would simplify John’s life a bit. But 
>>> if you are saying
>>>
>>> — the button in the IA opens the stepper window
>>> — and the stepper works until closed
>>>
>>> I am fine with that too.
>>>
>>>
>>>
>>>
 On Oct 20, 2016, at 4:49 PM, Sam Tobin-Hochstadt  
 wrote:

 What if entering expressions at the interactions window _while the
 stepper window is open_ caused them to be stepped?

 Sam

 On Thu, Oct 20, 2016 at 4:48 PM, Matthias Felleisen
  wrote:
>
>> On Oct 20, 2016, at 4:44 PM, John Clements  
>> wrote:
>>
>>>
>>> On Oct 20, 2016, at 12:32 PM, Matthias Felleisen  
>>> wrote:
>>>
>>>
 On Oct 20, 2016, at 3:20 PM, John Clements  
 wrote:

 I think you probably want an interface that steps a single expression 
 and then reverts to the standard mode.
>>>
>>>
>>> Exactly.
>>>
>>> My preference would be to have a ‘button’ like feature at the top-right 
>>> of the IA for *SLs. By default, it is disabled. If a programmer clicks 
>>> on it, the evaluations in the REPL show the steps from now on until 
>>> either the next click or the next RUN of the DA.
>>
>> It doesn’t *sound* like we’re in agreement :)… I’m thinking that the 
>> mode should revert to RUN after the next expression is entered in the 
>> interactions window.
>>
>> Let me see if I can hack something together.
>
>
> :-)
>
> I think we’re in agreement on (1) it’s easy to switch and (2) it reverts 
> ‘soon-ish’ to the normal run mode. The little grey scale of ‘soon-ish’ is 
> a minor hickup in our decades-long search for common ground :))
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "Racket Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to racket-users+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] proposed minor improvement to stepper semantics

[Matthias Felleisen]

The difference is that we can simplify the stepper if all we ever evaluate are 
expressions in the IA. For example, the check-syntax problem could go away. 

I suspect the simplified presentation would also become more accessible to most 
students than the current evaluation of many little expressions that they 
forgot where expressions in the first place. 

But yes, from the perspective of (1) minimal work and (2) ease of use, this 
works fine, too. 






> On Oct 20, 2016, at 4:52 PM, Sam Tobin-Hochstadt  wrote:
> 
> I was thinking that the button at the top works the same as now, and
> that while it's open, everything goes to the stepper. That would work
> well for me in class.
> 
> Sam
> 
> On Thu, Oct 20, 2016 at 4:52 PM, Matthias Felleisen
>  wrote:
>> 
>> How do you open the stepper window in the first place? I think the stepper 
>> button for the DA could go away. That would simplify John’s life a bit. But 
>> if you are saying
>> 
>> — the button in the IA opens the stepper window
>> — and the stepper works until closed
>> 
>> I am fine with that too.
>> 
>> 
>> 
>> 
>>> On Oct 20, 2016, at 4:49 PM, Sam Tobin-Hochstadt  
>>> wrote:
>>> 
>>> What if entering expressions at the interactions window _while the
>>> stepper window is open_ caused them to be stepped?
>>> 
>>> Sam
>>> 
>>> On Thu, Oct 20, 2016 at 4:48 PM, Matthias Felleisen
>>>  wrote:
 
> On Oct 20, 2016, at 4:44 PM, John Clements  
> wrote:
> 
>> 
>> On Oct 20, 2016, at 12:32 PM, Matthias Felleisen  
>> wrote:
>> 
>> 
>>> On Oct 20, 2016, at 3:20 PM, John Clements  
>>> wrote:
>>> 
>>> I think you probably want an interface that steps a single expression 
>>> and then reverts to the standard mode.
>> 
>> 
>> Exactly.
>> 
>> My preference would be to have a ‘button’ like feature at the top-right 
>> of the IA for *SLs. By default, it is disabled. If a programmer clicks 
>> on it, the evaluations in the REPL show the steps from now on until 
>> either the next click or the next RUN of the DA.
> 
> It doesn’t *sound* like we’re in agreement :)… I’m thinking that the mode 
> should revert to RUN after the next expression is entered in the 
> interactions window.
> 
> Let me see if I can hack something together.
 
 
 :-)
 
 I think we’re in agreement on (1) it’s easy to switch and (2) it reverts 
 ‘soon-ish’ to the normal run mode. The little grey scale of ‘soon-ish’ is 
 a minor hickup in our decades-long search for common ground :))
 
 --
 You received this message because you are subscribed to the Google Groups 
 "Racket Users" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to racket-users+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to racket-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] proposed minor improvement to stepper semantics

[Sam Tobin-Hochstadt]

I was thinking that the button at the top works the same as now, and
that while it's open, everything goes to the stepper. That would work
well for me in class.

Sam

On Thu, Oct 20, 2016 at 4:52 PM, Matthias Felleisen
 wrote:
>
> How do you open the stepper window in the first place? I think the stepper 
> button for the DA could go away. That would simplify John’s life a bit. But 
> if you are saying
>
>  — the button in the IA opens the stepper window
>  — and the stepper works until closed
>
> I am fine with that too.
>
>
>
>
>> On Oct 20, 2016, at 4:49 PM, Sam Tobin-Hochstadt  
>> wrote:
>>
>> What if entering expressions at the interactions window _while the
>> stepper window is open_ caused them to be stepped?
>>
>> Sam
>>
>> On Thu, Oct 20, 2016 at 4:48 PM, Matthias Felleisen
>>  wrote:
>>>
 On Oct 20, 2016, at 4:44 PM, John Clements  
 wrote:

>
> On Oct 20, 2016, at 12:32 PM, Matthias Felleisen  
> wrote:
>
>
>> On Oct 20, 2016, at 3:20 PM, John Clements  
>> wrote:
>>
>> I think you probably want an interface that steps a single expression 
>> and then reverts to the standard mode.
>
>
> Exactly.
>
> My preference would be to have a ‘button’ like feature at the top-right 
> of the IA for *SLs. By default, it is disabled. If a programmer clicks on 
> it, the evaluations in the REPL show the steps from now on until either 
> the next click or the next RUN of the DA.

 It doesn’t *sound* like we’re in agreement :)… I’m thinking that the mode 
 should revert to RUN after the next expression is entered in the 
 interactions window.

 Let me see if I can hack something together.
>>>
>>>
>>> :-)
>>>
>>> I think we’re in agreement on (1) it’s easy to switch and (2) it reverts 
>>> ‘soon-ish’ to the normal run mode. The little grey scale of ‘soon-ish’ is a 
>>> minor hickup in our decades-long search for common ground :))
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "Racket Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to racket-users+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] proposed minor improvement to stepper semantics

[Matthias Felleisen]

How do you open the stepper window in the first place? I think the stepper 
button for the DA could go away. That would simplify John’s life a bit. But if 
you are saying 

 — the button in the IA opens the stepper window 
 — and the stepper works until closed 

I am fine with that too. 




> On Oct 20, 2016, at 4:49 PM, Sam Tobin-Hochstadt  wrote:
> 
> What if entering expressions at the interactions window _while the
> stepper window is open_ caused them to be stepped?
> 
> Sam
> 
> On Thu, Oct 20, 2016 at 4:48 PM, Matthias Felleisen
>  wrote:
>> 
>>> On Oct 20, 2016, at 4:44 PM, John Clements  
>>> wrote:
>>> 
 
 On Oct 20, 2016, at 12:32 PM, Matthias Felleisen  
 wrote:
 
 
> On Oct 20, 2016, at 3:20 PM, John Clements  
> wrote:
> 
> I think you probably want an interface that steps a single expression and 
> then reverts to the standard mode.
 
 
 Exactly.
 
 My preference would be to have a ‘button’ like feature at the top-right of 
 the IA for *SLs. By default, it is disabled. If a programmer clicks on it, 
 the evaluations in the REPL show the steps from now on until either the 
 next click or the next RUN of the DA.
>>> 
>>> It doesn’t *sound* like we’re in agreement :)… I’m thinking that the mode 
>>> should revert to RUN after the next expression is entered in the 
>>> interactions window.
>>> 
>>> Let me see if I can hack something together.
>> 
>> 
>> :-)
>> 
>> I think we’re in agreement on (1) it’s easy to switch and (2) it reverts 
>> ‘soon-ish’ to the normal run mode. The little grey scale of ‘soon-ish’ is a 
>> minor hickup in our decades-long search for common ground :))
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to racket-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] proposed minor improvement to stepper semantics

[Sam Tobin-Hochstadt]

What if entering expressions at the interactions window _while the
stepper window is open_ caused them to be stepped?

Sam

On Thu, Oct 20, 2016 at 4:48 PM, Matthias Felleisen
 wrote:
>
>> On Oct 20, 2016, at 4:44 PM, John Clements  wrote:
>>
>>>
>>> On Oct 20, 2016, at 12:32 PM, Matthias Felleisen  
>>> wrote:
>>>
>>>
 On Oct 20, 2016, at 3:20 PM, John Clements  
 wrote:

 I think you probably want an interface that steps a single expression and 
 then reverts to the standard mode.
>>>
>>>
>>> Exactly.
>>>
>>> My preference would be to have a ‘button’ like feature at the top-right of 
>>> the IA for *SLs. By default, it is disabled. If a programmer clicks on it, 
>>> the evaluations in the REPL show the steps from now on until either the 
>>> next click or the next RUN of the DA.
>>
>> It doesn’t *sound* like we’re in agreement :)… I’m thinking that the mode 
>> should revert to RUN after the next expression is entered in the 
>> interactions window.
>>
>> Let me see if I can hack something together.
>
>
> :-)
>
> I think we’re in agreement on (1) it’s easy to switch and (2) it reverts 
> ‘soon-ish’ to the normal run mode. The little grey scale of ‘soon-ish’ is a 
> minor hickup in our decades-long search for common ground :))
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] proposed minor improvement to stepper semantics

[Matthias Felleisen]

> On Oct 20, 2016, at 4:44 PM, John Clements  wrote:
> 
>> 
>> On Oct 20, 2016, at 12:32 PM, Matthias Felleisen  
>> wrote:
>> 
>> 
>>> On Oct 20, 2016, at 3:20 PM, John Clements  
>>> wrote:
>>> 
>>> I think you probably want an interface that steps a single expression and 
>>> then reverts to the standard mode. 
>> 
>> 
>> Exactly. 
>> 
>> My preference would be to have a ‘button’ like feature at the top-right of 
>> the IA for *SLs. By default, it is disabled. If a programmer clicks on it, 
>> the evaluations in the REPL show the steps from now on until either the next 
>> click or the next RUN of the DA. 
> 
> It doesn’t *sound* like we’re in agreement :)… I’m thinking that the mode 
> should revert to RUN after the next expression is entered in the interactions 
> window.
> 
> Let me see if I can hack something together.


:-)

I think we’re in agreement on (1) it’s easy to switch and (2) it reverts 
‘soon-ish’ to the normal run mode. The little grey scale of ‘soon-ish’ is a 
minor hickup in our decades-long search for common ground :)) 

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Handin required file

[mattsap]

Hello,

Thanks for all the help in the past! I'm still working on the handin-server and 
getting it up and ready.

My students in their submission require an extra file called 'extra.rkt'. This 
extra.rkt is about 20MB so I wouldn't really wanted it to be submitted with 
each student in a multi-file submission.

I'm wondering what's the best way to have the student's file graded. I can't 
drop the extra.rkt into my checker.rkt directory and reference it from the 
student submission directory because of the permissions (which is a good 
thing!). 

Any suggestions?

Thanks in advance! =)
-Matt

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] date->seconds complaining about a supposedly non-existent date

[Dmitry Pavlov]

That was more intended as a rant about things that drive me batty than 
actual instruction -- I hope it didn't come across as patronizing.

No, not at all.

One of the things that surprised me the most is that prior to 1925, 
astronomers kept timestamps of their observations where day started at 
noon, not at midnight---for keeping the day constant through the 
observation session.


By the way, a question to Racket developers: is Racket ready for year 2038?

Best regards,

Dmitry

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] proposed minor improvement to stepper semantics

[Matthias Felleisen]

> On Oct 20, 2016, at 3:20 PM, John Clements  wrote:
> 
> I think you probably want an interface that steps a single expression and 
> then reverts to the standard mode. 


Exactly. 

My preference would be to have a ‘button’ like feature at the top-right of the 
IA for *SLs. By default, it is disabled. If a programmer clicks on it, the 
evaluations in the REPL show the steps from now on until either the next click 
or the next RUN of the DA. 

— Matthias

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] proposed minor improvement to stepper semantics

['John Clements' via Racket Users]

> On Oct 20, 2016, at 12:08 PM, Matthias Felleisen  wrote:
> 
> 
> p.s. The only reason we cope with this at all is only because we don’t launch 
> the stepper from the REPL. If we could set the Interactions Window to ‘RUN’ 
> or ‘STEP’ mode and then say 
> 
>> (f 10)
> 
> and the stepper would pop up to show this (in an appropriate, evaluated 
> definition context) we could easily avoid the discrepancy between the two 
> systems. 

What interface would be best for switching between these two modes? 

Actually, I bet you’d forget and leave it in the stepper mode a lot, leading to 
wasted time and frustration.

I think you probably want an interface that steps a single expression and then 
reverts to the standard mode. 

One obvious way would just be to have a top-level-only-form like

(:step (+ 3 4))

… but I can also see how it feels like it ought to be “outside” of the window, 
at a higher level.

John


> 
> 
> 
> 
> 
>> On Oct 20, 2016, at 3:02 PM, 'John Clements' via Racket Users 
>>  wrote:
>> 
>> 
>>> On Oct 20, 2016, at 11:44 AM, Sam Tobin-Hochstadt  
>>> wrote:
>>> 
>>> When teaching, I've personally found the reduction to #true confusing,
>>> and something that I can't explain to my students. So I'd prefer that
>>> it go away entirely, rather than happening more.
>> 
>> Before implementing this, one note: if you were actually formulating this as 
>> a semantics, in redex, say, your semantics would look pretty nasty if you 
>> had to follow this rule, so that e.g.
>> 
>> (check-expect 7 7)
>> (check-expect 9 9)
>> (check-expect (+ 4 6) 10)
>> 
>> reduced in one step to
>> 
>> (check-expect 10 10)
>> 
>> You’d have to have some kind of top-level sweeper, right? And would the 
>> disappeared check-expects appear in purple? Generally, we like to claim that 
>> anything not highlighted in purple will not change in the output.
>> 
>> John
>> 
>> 
>>> 
>>> Sam
>>> 
>>> On Thu, Oct 20, 2016 at 2:35 PM, Vincent St-Amour
>>>  wrote:
 Reducing to something, rather than disappearing, does sound like a good
 idea to me.
 
 On the other hand, one may expect something that reduces to `#true` to
 print `#true` to the interactions window, which isn't what happens.
 
 Vincent
 
 
 
 On Thu, 20 Oct 2016 13:33:19 -0500,
 Racket Users wrote:
> 
> I’m trying to clean up some code near where Mike Sperber discovered a 
> stepper bug, and I accidentally made a change that I think actually 
> improves the stepper.
> 
> Specifically, in the past, the step from, e.g.,  (check-expect 13 13) to 
> #true was silently omitted. So, for instance, if you wrote this program:
> 
> (check-expect 13 13) (check-expect (+ 4 5) 9)
> 
> The first step would be from
> 
> #true
> (check-expect (+ 4 5) 9)
> 
> to
> 
> #true
> (check-expect 9 9)
> 
> … and there would be no other steps.
> 
> Turning off reduction hiding around the application of the 
> check-expect-checker-fun instead appears to yield a sequence of three 
> steps:
> 
> from
> 
> (check-expect 13 13) (check-expect (+ 4 5) 9)
> 
> to
> 
> #true (check-expect (+ 4 5) 9)
> 
> then the step that I mentioned before, then finally a step from
> 
> #true (check-expect 9 9)
> 
> to
> 
> #true #true
> 
> I regard this as an improvement, but please let me know if you disagree.
> 
> Thanks!
> 
> John
> 
> 
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
 
 --
 You received this message because you are subscribed to the Google Groups 
 "Racket Users" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to racket-users+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
>> 
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to racket-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
You received this message because you are subscribed to the Google Groups 

Re: [racket-users] proposed minor improvement to stepper semantics

[Matthias Felleisen]

p.s. The only reason we cope with this at all is only because we don’t launch 
the stepper from the REPL. If we could set the Interactions Window to ‘RUN’ or 
‘STEP’ mode and then say 

 > (f 10)

and the stepper would pop up to show this (in an appropriate, evaluated 
definition context) we could easily avoid the discrepancy between the two 
systems. 





> On Oct 20, 2016, at 3:02 PM, 'John Clements' via Racket Users 
>  wrote:
> 
> 
>> On Oct 20, 2016, at 11:44 AM, Sam Tobin-Hochstadt  
>> wrote:
>> 
>> When teaching, I've personally found the reduction to #true confusing,
>> and something that I can't explain to my students. So I'd prefer that
>> it go away entirely, rather than happening more.
> 
> Before implementing this, one note: if you were actually formulating this as 
> a semantics, in redex, say, your semantics would look pretty nasty if you had 
> to follow this rule, so that e.g.
> 
> (check-expect 7 7)
> (check-expect 9 9)
> (check-expect (+ 4 6) 10)
> 
> reduced in one step to
> 
> (check-expect 10 10)
> 
> You’d have to have some kind of top-level sweeper, right? And would the 
> disappeared check-expects appear in purple? Generally, we like to claim that 
> anything not highlighted in purple will not change in the output.
> 
> John
> 
> 
>> 
>> Sam
>> 
>> On Thu, Oct 20, 2016 at 2:35 PM, Vincent St-Amour
>>  wrote:
>>> Reducing to something, rather than disappearing, does sound like a good
>>> idea to me.
>>> 
>>> On the other hand, one may expect something that reduces to `#true` to
>>> print `#true` to the interactions window, which isn't what happens.
>>> 
>>> Vincent
>>> 
>>> 
>>> 
>>> On Thu, 20 Oct 2016 13:33:19 -0500,
>>> Racket Users wrote:
 
 I’m trying to clean up some code near where Mike Sperber discovered a 
 stepper bug, and I accidentally made a change that I think actually 
 improves the stepper.
 
 Specifically, in the past, the step from, e.g.,  (check-expect 13 13) to 
 #true was silently omitted. So, for instance, if you wrote this program:
 
 (check-expect 13 13) (check-expect (+ 4 5) 9)
 
 The first step would be from
 
 #true
 (check-expect (+ 4 5) 9)
 
 to
 
 #true
 (check-expect 9 9)
 
 … and there would be no other steps.
 
 Turning off reduction hiding around the application of the 
 check-expect-checker-fun instead appears to yield a sequence of three 
 steps:
 
 from
 
 (check-expect 13 13) (check-expect (+ 4 5) 9)
 
 to
 
 #true (check-expect (+ 4 5) 9)
 
 then the step that I mentioned before, then finally a step from
 
 #true (check-expect 9 9)
 
 to
 
 #true #true
 
 I regard this as an improvement, but please let me know if you disagree.
 
 Thanks!
 
 John
 
 
 
 --
 You received this message because you are subscribed to the Google Groups 
 "Racket Users" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to racket-users+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
>>> 
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "Racket Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to racket-users+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] proposed minor improvement to stepper semantics

[Matthias Felleisen]

We need to differentiate between ‘semantics’ (calculations) and ‘rendering the 
result’ (printing at the repl). I suspect that the reduction from (check-expect 
7 7) to #true might be overkill for students, though not something they will 
spend much time on. We could also say that (c-e 9 9) reduces to void (my 
preference) and neither the stepper nor the evaluator display this ‘stupid’ 
result. 

I guess I am fine w/ the old way, and I can deal with the new one, too. 

— Matthias








> On Oct 20, 2016, at 3:02 PM, 'John Clements' via Racket Users 
>  wrote:
> 
> 
>> On Oct 20, 2016, at 11:44 AM, Sam Tobin-Hochstadt  
>> wrote:
>> 
>> When teaching, I've personally found the reduction to #true confusing,
>> and something that I can't explain to my students. So I'd prefer that
>> it go away entirely, rather than happening more.
> 
> Before implementing this, one note: if you were actually formulating this as 
> a semantics, in redex, say, your semantics would look pretty nasty if you had 
> to follow this rule, so that e.g.
> 
> (check-expect 7 7)
> (check-expect 9 9)
> (check-expect (+ 4 6) 10)
> 
> reduced in one step to
> 
> (check-expect 10 10)
> 
> You’d have to have some kind of top-level sweeper, right? And would the 
> disappeared check-expects appear in purple? Generally, we like to claim that 
> anything not highlighted in purple will not change in the output.
> 
> John
> 
> 
>> 
>> Sam
>> 
>> On Thu, Oct 20, 2016 at 2:35 PM, Vincent St-Amour
>>  wrote:
>>> Reducing to something, rather than disappearing, does sound like a good
>>> idea to me.
>>> 
>>> On the other hand, one may expect something that reduces to `#true` to
>>> print `#true` to the interactions window, which isn't what happens.
>>> 
>>> Vincent
>>> 
>>> 
>>> 
>>> On Thu, 20 Oct 2016 13:33:19 -0500,
>>> Racket Users wrote:
 
 I’m trying to clean up some code near where Mike Sperber discovered a 
 stepper bug, and I accidentally made a change that I think actually 
 improves the stepper.
 
 Specifically, in the past, the step from, e.g.,  (check-expect 13 13) to 
 #true was silently omitted. So, for instance, if you wrote this program:
 
 (check-expect 13 13) (check-expect (+ 4 5) 9)
 
 The first step would be from
 
 #true
 (check-expect (+ 4 5) 9)
 
 to
 
 #true
 (check-expect 9 9)
 
 … and there would be no other steps.
 
 Turning off reduction hiding around the application of the 
 check-expect-checker-fun instead appears to yield a sequence of three 
 steps:
 
 from
 
 (check-expect 13 13) (check-expect (+ 4 5) 9)
 
 to
 
 #true (check-expect (+ 4 5) 9)
 
 then the step that I mentioned before, then finally a step from
 
 #true (check-expect 9 9)
 
 to
 
 #true #true
 
 I regard this as an improvement, but please let me know if you disagree.
 
 Thanks!
 
 John
 
 
 
 --
 You received this message because you are subscribed to the Google Groups 
 "Racket Users" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to racket-users+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
>>> 
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "Racket Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to racket-users+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] proposed minor improvement to stepper semantics

[Robby Findler]

I think that the reduction is good, but the #true appearing is bad. Right?

Robby

On Thu, Oct 20, 2016 at 1:44 PM, Sam Tobin-Hochstadt
 wrote:
> When teaching, I've personally found the reduction to #true confusing,
> and something that I can't explain to my students. So I'd prefer that
> it go away entirely, rather than happening more.
>
> Sam
>
> On Thu, Oct 20, 2016 at 2:35 PM, Vincent St-Amour
>  wrote:
>> Reducing to something, rather than disappearing, does sound like a good
>> idea to me.
>>
>> On the other hand, one may expect something that reduces to `#true` to
>> print `#true` to the interactions window, which isn't what happens.
>>
>> Vincent
>>
>>
>>
>> On Thu, 20 Oct 2016 13:33:19 -0500,
>> Racket Users wrote:
>>>
>>> I’m trying to clean up some code near where Mike Sperber discovered a 
>>> stepper bug, and I accidentally made a change that I think actually 
>>> improves the stepper.
>>>
>>> Specifically, in the past, the step from, e.g.,  (check-expect 13 13) to 
>>> #true was silently omitted. So, for instance, if you wrote this program:
>>>
>>> (check-expect 13 13) (check-expect (+ 4 5) 9)
>>>
>>> The first step would be from
>>>
>>> #true
>>> (check-expect (+ 4 5) 9)
>>>
>>> to
>>>
>>> #true
>>> (check-expect 9 9)
>>>
>>> … and there would be no other steps.
>>>
>>> Turning off reduction hiding around the application of the 
>>> check-expect-checker-fun instead appears to yield a sequence of three steps:
>>>
>>> from
>>>
>>> (check-expect 13 13) (check-expect (+ 4 5) 9)
>>>
>>> to
>>>
>>> #true (check-expect (+ 4 5) 9)
>>>
>>> then the step that I mentioned before, then finally a step from
>>>
>>> #true (check-expect 9 9)
>>>
>>> to
>>>
>>> #true #true
>>>
>>> I regard this as an improvement, but please let me know if you disagree.
>>>
>>> Thanks!
>>>
>>> John
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "Racket Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to racket-users+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to racket-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] proposed minor improvement to stepper semantics

[Sam Tobin-Hochstadt]

When teaching, I've personally found the reduction to #true confusing,
and something that I can't explain to my students. So I'd prefer that
it go away entirely, rather than happening more.

Sam

On Thu, Oct 20, 2016 at 2:35 PM, Vincent St-Amour
 wrote:
> Reducing to something, rather than disappearing, does sound like a good
> idea to me.
>
> On the other hand, one may expect something that reduces to `#true` to
> print `#true` to the interactions window, which isn't what happens.
>
> Vincent
>
>
>
> On Thu, 20 Oct 2016 13:33:19 -0500,
> Racket Users wrote:
>>
>> I’m trying to clean up some code near where Mike Sperber discovered a 
>> stepper bug, and I accidentally made a change that I think actually improves 
>> the stepper.
>>
>> Specifically, in the past, the step from, e.g.,  (check-expect 13 13) to 
>> #true was silently omitted. So, for instance, if you wrote this program:
>>
>> (check-expect 13 13) (check-expect (+ 4 5) 9)
>>
>> The first step would be from
>>
>> #true
>> (check-expect (+ 4 5) 9)
>>
>> to
>>
>> #true
>> (check-expect 9 9)
>>
>> … and there would be no other steps.
>>
>> Turning off reduction hiding around the application of the 
>> check-expect-checker-fun instead appears to yield a sequence of three steps:
>>
>> from
>>
>> (check-expect 13 13) (check-expect (+ 4 5) 9)
>>
>> to
>>
>> #true (check-expect (+ 4 5) 9)
>>
>> then the step that I mentioned before, then finally a step from
>>
>> #true (check-expect 9 9)
>>
>> to
>>
>> #true #true
>>
>> I regard this as an improvement, but please let me know if you disagree.
>>
>> Thanks!
>>
>> John
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to racket-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] proposed minor improvement to stepper semantics

['John Clements' via Racket Users]

> On Oct 20, 2016, at 11:35 AM, Vincent St-Amour 
>  wrote:
> 
> Reducing to something, rather than disappearing, does sound like a good
> idea to me.
> 
> On the other hand, one may expect something that reduces to `#true` to
> print `#true` to the interactions window, which isn't what happens.

To clarify: it doesn’t currently disappear. The boolean value is still 
displayed, it’s just that the reduction to the boolean is skipped over.

Perhaps it would be better to hide the output altogether, to match the behavior 
of the interactions window?

John



-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] proposed minor improvement to stepper semantics

[Vincent St-Amour]

Reducing to something, rather than disappearing, does sound like a good
idea to me.

On the other hand, one may expect something that reduces to `#true` to
print `#true` to the interactions window, which isn't what happens.

Vincent



On Thu, 20 Oct 2016 13:33:19 -0500,
Racket Users wrote:
> 
> I’m trying to clean up some code near where Mike Sperber discovered a stepper 
> bug, and I accidentally made a change that I think actually improves the 
> stepper. 
> 
> Specifically, in the past, the step from, e.g.,  (check-expect 13 13) to 
> #true was silently omitted. So, for instance, if you wrote this program:
> 
> (check-expect 13 13) (check-expect (+ 4 5) 9)
> 
> The first step would be from 
> 
> #true
> (check-expect (+ 4 5) 9)
> 
> to
> 
> #true
> (check-expect 9 9)
> 
> … and there would be no other steps.
> 
> Turning off reduction hiding around the application of the 
> check-expect-checker-fun instead appears to yield a sequence of three steps:
> 
> from 
> 
> (check-expect 13 13) (check-expect (+ 4 5) 9)
> 
> to 
> 
> #true (check-expect (+ 4 5) 9)
> 
> then the step that I mentioned before, then finally a step from 
> 
> #true (check-expect 9 9)
> 
> to
> 
> #true #true
> 
> I regard this as an improvement, but please let me know if you disagree.
> 
> Thanks!
> 
> John
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] proposed minor improvement to stepper semantics

['John Clements' via Racket Users]

I’m trying to clean up some code near where Mike Sperber discovered a stepper 
bug, and I accidentally made a change that I think actually improves the 
stepper. 

Specifically, in the past, the step from, e.g.,  (check-expect 13 13) to #true 
was silently omitted. So, for instance, if you wrote this program:

(check-expect 13 13) (check-expect (+ 4 5) 9)

The first step would be from 

#true
(check-expect (+ 4 5) 9)

to

#true
(check-expect 9 9)

… and there would be no other steps.

Turning off reduction hiding around the application of the 
check-expect-checker-fun instead appears to yield a sequence of three steps:

from 

(check-expect 13 13) (check-expect (+ 4 5) 9)

to 

#true (check-expect (+ 4 5) 9)

then the step that I mentioned before, then finally a step from 

#true (check-expect 9 9)

to

#true #true

I regard this as an improvement, but please let me know if you disagree.

Thanks!

John



-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] date->seconds complaining about a supposedly non-existent date

[Robby Findler]

Date rants are the best :)

http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time

Robby

On Thu, Oct 20, 2016 at 1:06 PM, David Storrs  wrote:
> That was more intended as a rant about things that drive me batty than
> actual instruction -- I hope it didn't come across as patronizing.
>
> On Thu, Oct 20, 2016 at 12:32 PM, Dmitry Pavlov  wrote:
>>
>> David,
>>
>> Yes, I deal with most of this at work, except daylight savings.
>> (Timestamps in astronomical observations are predominantly in UTC or rarely
>> TT/TDB, I never saw local time.)
>>
>> Best regards,
>>
>> Dmitry
>>
>>
>>
>> On 10/20/2016 07:26 PM, David Storrs wrote:
>>
>> Also be aware that once you start getting into date math you need to deal
>> with:
>>
>> *) Minutes that might have 61 seconds in them.  Yes, hh:mm:60 is a real
>> time.
>>
>> *) Hours that don't exist.
>>
>> *) Hours that happen twice in the same day.
>>
>> *) Februaries that have 28 or 29 days on a weird schedule.  (If the year
>> is divisible by 4, unless it's divisible by 100, unless it's divisible by
>> 400.)
>>
>> *) Two weeks that didn't exist due to calendars switching over.
>>
>> *) The modern calendar being adopted at different points in different
>> countries.  Greece didn't start using it until 1923.
>>
>> On Thu, Oct 20, 2016 at 12:13 PM, Matthew Flatt 
>> wrote:
>>>
>>> Did you timezone use daylight saving in 1996?
>>>
>>> In U.S. timezones, March (it used to be April) has a 1-hour hole due to
>>> the switch to daylight saving time, where the clock skips forward from
>>> 1:59am to 3:00am. For example, 2:47:59am on March 13, 2016 really did
>>> not exist in my timezone.
>>>
>>> At Thu, 20 Oct 2016 19:05:38 +0300, Dmitry Pavlov wrote:
>>> > Hello,
>>> >
>>> > The surprise of the day for me is date->seconds
>>> > rejecting a particular time on a particular date.
>>> >
>>> > (date->seconds (date 59 47 2 31 3 1996 0 0 #f 0))
>>> >
>>> > This should be 1996, March 31, 02:47:59 am, correct?
>>> >
>>> >
>>> > It reports the following error:
>>> >
>>> > find-seconds: non-existent date
>>> >wanted: (59 47 2 31 3 1996)
>>> >nearest below: 828226799 is (59 59 1 31 3 1996)
>>> >nearest above: 828226800 is (0 0 3 31 3 1996)
>>> >context...:
>>> > /opt/racket/collects/racket/date.rkt:234:0: date->seconds
>>> >
>>> > /opt/racket/collects/racket/contract/private/arrow-val-first.rkt:306:25
>>> > /opt/racket/collects/racket/private/misc.rkt:88:7
>>> >
>>> >  From the message, I can suppose that it misses a whole hour inside.
>>> >
>>> > What can be done?
>>> >
>>> > This is Racket 6.6 on Linux.
>>> >
>>> >
>>> > Best regards,
>>> >
>>> > Dmitry
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> > Groups
>>> > "Racket Users" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send
>>> > an
>>> > email to racket-users+unsubscr...@googlegroups.com.
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Racket Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to racket-users+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] date->seconds complaining about a supposedly non-existent date

[David Storrs]

That was more intended as a rant about things that drive me batty than
actual instruction -- I hope it didn't come across as patronizing.

On Thu, Oct 20, 2016 at 12:32 PM, Dmitry Pavlov  wrote:

> David,
>
> Yes, I deal with most of this at work, except daylight savings.
> (Timestamps in astronomical observations are predominantly in UTC or rarely
> TT/TDB, I never saw local time.)
>
> Best regards,
>
> Dmitry
>
>
>
> On 10/20/2016 07:26 PM, David Storrs wrote:
>
> Also be aware that once you start getting into date math you need to deal
> with:
>
> *) Minutes that might have 61 seconds in them.  Yes, hh:mm:60 is a real
> time.
>
> *) Hours that don't exist.
>
> *) Hours that happen twice in the same day.
>
> *) Februaries that have 28 or 29 days on a weird schedule.  (If the year
> is divisible by 4, unless it's divisible by 100, unless it's divisible by
> 400.)
>
> *) Two weeks that didn't exist due to calendars switching over.
>
> *) The modern calendar being adopted at different points in different
> countries.  Greece didn't start using it until 1923.
>
> On Thu, Oct 20, 2016 at 12:13 PM, Matthew Flatt 
> wrote:
>
>> Did you timezone use daylight saving in 1996?
>>
>> In U.S. timezones, March (it used to be April) has a 1-hour hole due to
>> the switch to daylight saving time, where the clock skips forward from
>> 1:59am to 3:00am. For example, 2:47:59am on March 13, 2016 really did
>> not exist in my timezone.
>>
>> At Thu, 20 Oct 2016 19:05:38 +0300, Dmitry Pavlov wrote:
>> > Hello,
>> >
>> > The surprise of the day for me is date->seconds
>> > rejecting a particular time on a particular date.
>> >
>> > (date->seconds (date 59 47 2 31 3 1996 0 0 #f 0))
>> >
>> > This should be 1996, March 31, 02:47:59 am, correct?
>> >
>> >
>> > It reports the following error:
>> >
>> > find-seconds: non-existent date
>> >wanted: (59 47 2 31 3 1996)
>> >nearest below: 828226799 is (59 59 1 31 3 1996)
>> >nearest above: 828226800 is (0 0 3 31 3 1996)
>> >context...:
>> > /opt/racket/collects/racket/date.rkt:234:0: date->seconds
>> > /opt/racket/collects/racket/contract/private/arrow-val-firs
>> t.rkt:306:25
>> > /opt/racket/collects/racket/private/misc.rkt:88:7
>> >
>> >  From the message, I can suppose that it misses a whole hour inside.
>> >
>> > What can be done?
>> >
>> > This is Racket 6.6 on Linux.
>> >
>> >
>> > Best regards,
>> >
>> > Dmitry
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "Racket Users" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to racket-users+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to racket-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] date->seconds complaining about a supposedly non-existent date

[Dmitry Pavlov]

David,

Yes, I deal with most of this at work, except daylight savings. 
(Timestamps in astronomical observations are predominantly in UTC or 
rarely TT/TDB, I never saw local time.)


Best regards,

Dmitry


On 10/20/2016 07:26 PM, David Storrs wrote:
Also be aware that once you start getting into date math you need to 
deal with:


*) Minutes that might have 61 seconds in them.  Yes, hh:mm:60 is a 
real time.


*) Hours that don't exist.

*) Hours that happen twice in the same day.

*) Februaries that have 28 or 29 days on a weird schedule. (If the 
year is divisible by 4, unless it's divisible by 100, unless it's 
divisible by 400.)


*) Two weeks that didn't exist due to calendars switching over.

*) The modern calendar being adopted at different points in different 
countries.  Greece didn't start using it until 1923.


On Thu, Oct 20, 2016 at 12:13 PM, Matthew Flatt > wrote:


Did you timezone use daylight saving in 1996?

In U.S. timezones, March (it used to be April) has a 1-hour hole
due to
the switch to daylight saving time, where the clock skips forward from
1:59am to 3:00am. For example, 2:47:59am on March 13, 2016 really did
not exist in my timezone.

At Thu, 20 Oct 2016 19:05:38 +0300, Dmitry Pavlov wrote:
> Hello,
>
> The surprise of the day for me is date->seconds
> rejecting a particular time on a particular date.
>
> (date->seconds (date 59 47 2 31 3 1996 0 0 #f 0))
>
> This should be 1996, March 31, 02:47:59 am, correct?
>
>
> It reports the following error:
>
> find-seconds: non-existent date
>wanted: (59 47 2 31 3 1996)
>nearest below: 828226799 is (59 59 1 31 3 1996)
>nearest above: 828226800 is (0 0 3 31 3 1996)
>context...:
> /opt/racket/collects/racket/date.rkt:234:0: date->seconds
>   
 /opt/racket/collects/racket/contract/private/arrow-val-first.rkt:306:25

> /opt/racket/collects/racket/private/misc.rkt:88:7
>
>  From the message, I can suppose that it misses a whole hour inside.
>
> What can be done?
>
> This is Racket 6.6 on Linux.
>
>
> Best regards,
>
> Dmitry
>
> --
> You received this message because you are subscribed to the
Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from
it, send an
> email to racket-users+unsubscr...@googlegroups.com
.
> For more options, visit https://groups.google.com/d/optout
.

--
You received this message because you are subscribed to the Google
Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to racket-users+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/d/optout
.




--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] date->seconds complaining about a supposedly non-existent date

[David Storrs]

Also be aware that once you start getting into date math you need to deal
with:

*) Minutes that might have 61 seconds in them.  Yes, hh:mm:60 is a real
time.

*) Hours that don't exist.

*) Hours that happen twice in the same day.

*) Februaries that have 28 or 29 days on a weird schedule.  (If the year is
divisible by 4, unless it's divisible by 100, unless it's divisible by 400.)

*) Two weeks that didn't exist due to calendars switching over.

*) The modern calendar being adopted at different points in different
countries.  Greece didn't start using it until 1923.

On Thu, Oct 20, 2016 at 12:13 PM, Matthew Flatt  wrote:

> Did you timezone use daylight saving in 1996?
>
> In U.S. timezones, March (it used to be April) has a 1-hour hole due to
> the switch to daylight saving time, where the clock skips forward from
> 1:59am to 3:00am. For example, 2:47:59am on March 13, 2016 really did
> not exist in my timezone.
>
> At Thu, 20 Oct 2016 19:05:38 +0300, Dmitry Pavlov wrote:
> > Hello,
> >
> > The surprise of the day for me is date->seconds
> > rejecting a particular time on a particular date.
> >
> > (date->seconds (date 59 47 2 31 3 1996 0 0 #f 0))
> >
> > This should be 1996, March 31, 02:47:59 am, correct?
> >
> >
> > It reports the following error:
> >
> > find-seconds: non-existent date
> >wanted: (59 47 2 31 3 1996)
> >nearest below: 828226799 is (59 59 1 31 3 1996)
> >nearest above: 828226800 is (0 0 3 31 3 1996)
> >context...:
> > /opt/racket/collects/racket/date.rkt:234:0: date->seconds
> > /opt/racket/collects/racket/contract/private/arrow-val-
> first.rkt:306:25
> > /opt/racket/collects/racket/private/misc.rkt:88:7
> >
> >  From the message, I can suppose that it misses a whole hour inside.
> >
> > What can be done?
> >
> > This is Racket 6.6 on Linux.
> >
> >
> > Best regards,
> >
> > Dmitry
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to racket-users+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] date->seconds complaining about a supposedly non-existent date

[Dmitry Pavlov]

Matthew,



Did you timezone use daylight saving in 1996?



Oh, right.

I need UTC date and time; I assumed it is UTC since I passed #f for dst? 
and 0 for time-zone-offset in (date). I missed the local-time? flag in 
date->seconds, which is true by default.


So the corrected version of my code
(date->seconds (date 59 47 2 31 3 1996 0 0 #f 0) #f)
works fine.

Thank you for such a fast response.

Best regards,

Dmitry

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] date->seconds complaining about a supposedly non-existent date

[Matthew Flatt]

Did you timezone use daylight saving in 1996?

In U.S. timezones, March (it used to be April) has a 1-hour hole due to
the switch to daylight saving time, where the clock skips forward from
1:59am to 3:00am. For example, 2:47:59am on March 13, 2016 really did
not exist in my timezone.

At Thu, 20 Oct 2016 19:05:38 +0300, Dmitry Pavlov wrote:
> Hello,
> 
> The surprise of the day for me is date->seconds
> rejecting a particular time on a particular date.
> 
> (date->seconds (date 59 47 2 31 3 1996 0 0 #f 0))
> 
> This should be 1996, March 31, 02:47:59 am, correct?
> 
> 
> It reports the following error:
> 
> find-seconds: non-existent date
>wanted: (59 47 2 31 3 1996)
>nearest below: 828226799 is (59 59 1 31 3 1996)
>nearest above: 828226800 is (0 0 3 31 3 1996)
>context...:
> /opt/racket/collects/racket/date.rkt:234:0: date->seconds
> /opt/racket/collects/racket/contract/private/arrow-val-first.rkt:306:25
> /opt/racket/collects/racket/private/misc.rkt:88:7
> 
>  From the message, I can suppose that it misses a whole hour inside.
> 
> What can be done?
> 
> This is Racket 6.6 on Linux.
> 
> 
> Best regards,
> 
> Dmitry
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] date->seconds complaining about a supposedly non-existent date

[Dmitry Pavlov]

Hello,

The surprise of the day for me is date->seconds
rejecting a particular time on a particular date.

(date->seconds (date 59 47 2 31 3 1996 0 0 #f 0))

This should be 1996, March 31, 02:47:59 am, correct?


It reports the following error:

find-seconds: non-existent date
  wanted: (59 47 2 31 3 1996)
  nearest below: 828226799 is (59 59 1 31 3 1996)
  nearest above: 828226800 is (0 0 3 31 3 1996)
  context...:
   /opt/racket/collects/racket/date.rkt:234:0: date->seconds
   /opt/racket/collects/racket/contract/private/arrow-val-first.rkt:306:25
   /opt/racket/collects/racket/private/misc.rkt:88:7

From the message, I can suppose that it misses a whole hour inside.

What can be done?

This is Racket 6.6 on Linux.


Best regards,

Dmitry

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] web-server response/output contract errors

[Craig Allen]

Gah, I knew it'd be something simple. 

Thanks for that, I assumed it'd return void.

Craig

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] web-server response/output contract errors

[Craig Allen]

Hi guys,

I'm trying to serve a file using a restful API via dispatcher. The file is 
being served but I'm also getting some funky contract errors that I don't 
really understand.

The function is 

(define (generate-zip-response zip-path)
  (let* ([size-bs   (string->bytes/utf-8 (number->string (file-size 
zip-path)))]
 [zip-binary(file->bytes zip-path)]
 [patch-name-bs (string->bytes/utf-8 patch-name)])
(response/output
 #:mime-type #"application/octet-stream"
 #:headers
 (list (make-header #"Content-Disposition"
(bytes-append #"attachment; filename=\"" patch-name-bs 
#".zip\""))
   (make-header #"Content-Transfer-Encoding" #"binary")
   (make-header #"Content-Length" size-bs))
 (lambda (output) (write-bytes zip-binary output)

and the contract error which is printed whenever a file is served is:

response/output: contract violation
  expected: void?
  given: 2113471
  in: the range of
  the 1st argument of
  (->*
   ((-> output-port? void?))
   (#:code
number?
#:headers
(listof header?)
#:message
bytes?
#:mime-type
(or/c bytes? #f)
#:seconds
number?)
   response?)
  contract from: 
  /web-server-lib/web-server/http/response-structs.rkt
  blaming: C:\builder\server-dispatch.rkt
   (assuming the contract is correct)
  at: /web-server-lib/web-server/http/response-structs.rkt:41.2

where 2113471 is the size of the file I am serving.

Any pointers would be helpful,

Cheers,

Craig

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.