[racket-dev] `define-serializable-struct` and the `deserialize-info...` export

2013-11-08 Thread Matthew Flatt
Currently, `(define-serializable-struct id )` expands to `(provide
deserialize-info:id-v0)`. The `deserialize-info...` identifier needs to
be exported to make things work, but the export is a hassle: the
programmer doesn't care about it, it's not usually documented,
re-exporting modules don't want to re-export it, and so on.

I'm planning to change `define-serializable-struct` so that the export
is put in a `deserialize-info` submodule, where it should cause less
trouble. This is a slightly backward-incompatible change; I found a
couple of modules that explicitly excluded `deserialize-info...` on
import, and so those exclusions would have to be dropped.

The change could also be backward-incompatible by changing the protocol
for providers of deserialization other than `define-serializeable-struct`.
That problem is easier to address: `deserialize` can try a
`deserialze-info` submodule first, and if the export isn't found, then
it can try the original module.

Ok?

_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] backwards incompatibility (was Re: `define-serializable-struct` and the `deserialize-info...` export)

2013-11-08 Thread Robby Findler
(I think it is okay.)

But here's a chance for me to point out something I heard about in a
conversation with Satnam Singh at OOPSLA about how Google works that it
seems like would be a nice fit for us. Here's my adaptation to our world:
when you push out what some might consider a change that breaks clients
(like this one where you also hope to avoid a new package) you are obliged
to submit pull requests on all ring-0 packages to (at a min) get all test
cases to pass.

I guess you did that here, at least for the ring-0 packages in the racket
git repo, which is where the I found ... comment comes from?

Robby


On Fri, Nov 8, 2013 at 12:35 PM, Matthew Flatt mfl...@cs.utah.edu wrote:

 Currently, `(define-serializable-struct id )` expands to `(provide
 deserialize-info:id-v0)`. The `deserialize-info...` identifier needs to
 be exported to make things work, but the export is a hassle: the
 programmer doesn't care about it, it's not usually documented,
 re-exporting modules don't want to re-export it, and so on.

 I'm planning to change `define-serializable-struct` so that the export
 is put in a `deserialize-info` submodule, where it should cause less
 trouble. This is a slightly backward-incompatible change; I found a
 couple of modules that explicitly excluded `deserialize-info...` on
 import, and so those exclusions would have to be dropped.

 The change could also be backward-incompatible by changing the protocol
 for providers of deserialization other than `define-serializeable-struct`.
 That problem is easier to address: `deserialize` can try a
 `deserialze-info` submodule first, and if the export isn't found, then
 it can try the original module.

 Ok?

 _
   Racket Developers list:
   http://lists.racket-lang.org/dev

_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] backwards incompatibility (was Re: `define-serializable-struct` and the `deserialize-info...` export)

2013-11-08 Thread Jay McCarthy
I agree

On Fri, Nov 8, 2013 at 12:39 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 (I think it is okay.)

 But here's a chance for me to point out something I heard about in a
 conversation with Satnam Singh at OOPSLA about how Google works that it
 seems like would be a nice fit for us. Here's my adaptation to our world:
 when you push out what some might consider a change that breaks clients
 (like this one where you also hope to avoid a new package) you are obliged
 to submit pull requests on all ring-0 packages to (at a min) get all test
 cases to pass.

 I guess you did that here, at least for the ring-0 packages in the racket
 git repo, which is where the I found ... comment comes from?

 Robby


 On Fri, Nov 8, 2013 at 12:35 PM, Matthew Flatt mfl...@cs.utah.edu wrote:

 Currently, `(define-serializable-struct id )` expands to `(provide
 deserialize-info:id-v0)`. The `deserialize-info...` identifier needs to
 be exported to make things work, but the export is a hassle: the
 programmer doesn't care about it, it's not usually documented,
 re-exporting modules don't want to re-export it, and so on.

 I'm planning to change `define-serializable-struct` so that the export
 is put in a `deserialize-info` submodule, where it should cause less
 trouble. This is a slightly backward-incompatible change; I found a
 couple of modules that explicitly excluded `deserialize-info...` on
 import, and so those exclusions would have to be dropped.

 The change could also be backward-incompatible by changing the protocol
 for providers of deserialization other than `define-serializeable-struct`.
 That problem is easier to address: `deserialize` can try a
 `deserialze-info` submodule first, and if the export isn't found, then
 it can try the original module.

 Ok?

 _
   Racket Developers list:
   http://lists.racket-lang.org/dev



 _
   Racket Developers list:
   http://lists.racket-lang.org/dev




-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] backwards incompatibility (was Re: `define-serializable-struct` and the `deserialize-info...` export)

2013-11-08 Thread Matthew Flatt
Yes. Even if (as in the future) the current ring-0 packages weren't all
the same git repository, I'd certainly at least try building them with
this change.

I think that running all the tests in the same way that DrDr does is
not yet easy, but I hope we're moving in the direction of making that
easier, and then my process can improve.

For now: I build, run some tests, and then push --- hoping that I can
fix or revert quickly when DrDr uncovers problems.

At Fri, 8 Nov 2013 13:39:25 -0600, Robby Findler wrote:
 (I think it is okay.)
 
 But here's a chance for me to point out something I heard about in a
 conversation with Satnam Singh at OOPSLA about how Google works that it
 seems like would be a nice fit for us. Here's my adaptation to our world:
 when you push out what some might consider a change that breaks clients
 (like this one where you also hope to avoid a new package) you are obliged
 to submit pull requests on all ring-0 packages to (at a min) get all test
 cases to pass.
 
 I guess you did that here, at least for the ring-0 packages in the racket
 git repo, which is where the I found ... comment comes from?
 
 Robby
 
 
 On Fri, Nov 8, 2013 at 12:35 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
 
  Currently, `(define-serializable-struct id )` expands to `(provide
  deserialize-info:id-v0)`. The `deserialize-info...` identifier needs to
  be exported to make things work, but the export is a hassle: the
  programmer doesn't care about it, it's not usually documented,
  re-exporting modules don't want to re-export it, and so on.
 
  I'm planning to change `define-serializable-struct` so that the export
  is put in a `deserialize-info` submodule, where it should cause less
  trouble. This is a slightly backward-incompatible change; I found a
  couple of modules that explicitly excluded `deserialize-info...` on
  import, and so those exclusions would have to be dropped.
 
  The change could also be backward-incompatible by changing the protocol
  for providers of deserialization other than `define-serializeable-struct`.
  That problem is easier to address: `deserialize` can try a
  `deserialze-info` submodule first, and if the export isn't found, then
  it can try the original module.
 
  Ok?
 
  _
Racket Developers list:
http://lists.racket-lang.org/dev
 
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] backwards incompatibility (was Re: `define-serializable-struct` and the `deserialize-info...` export)

2013-11-08 Thread Robby Findler
On Fri, Nov 8, 2013 at 7:13 PM, Matthew Flatt mfl...@cs.utah.edu wrote:

 Yes. Even if (as in the future) the current ring-0 packages weren't all
 the same git repository, I'd certainly at least try building them with
 this change.

 I think that running all the tests in the same way that DrDr does is
 not yet easy, but I hope we're moving in the direction of making that
 easier, and then my process can improve.


Well, if you've built them, then can't just you just run raco test -xp
put package names here and come back in a bit?


 For now: I build, run some tests, and then push --- hoping that I can
 fix or revert quickly when DrDr uncovers problems.


Perhaps we should be thinking about generalizing the ring-0-based DrDr so
we can ask to try out changes?

I see that travis tries out pull requests on our repo so there is maybe
some prior art to exploit for ideas.

Robby


 At Fri, 8 Nov 2013 13:39:25 -0600, Robby Findler wrote:
  (I think it is okay.)
 
  But here's a chance for me to point out something I heard about in a
  conversation with Satnam Singh at OOPSLA about how Google works that it
  seems like would be a nice fit for us. Here's my adaptation to our world:
  when you push out what some might consider a change that breaks clients
  (like this one where you also hope to avoid a new package) you are
 obliged
  to submit pull requests on all ring-0 packages to (at a min) get all test
  cases to pass.
 
  I guess you did that here, at least for the ring-0 packages in the racket
  git repo, which is where the I found ... comment comes from?
 
  Robby
 
 
  On Fri, Nov 8, 2013 at 12:35 PM, Matthew Flatt mfl...@cs.utah.edu
 wrote:
 
   Currently, `(define-serializable-struct id )` expands to `(provide
   deserialize-info:id-v0)`. The `deserialize-info...` identifier needs to
   be exported to make things work, but the export is a hassle: the
   programmer doesn't care about it, it's not usually documented,
   re-exporting modules don't want to re-export it, and so on.
  
   I'm planning to change `define-serializable-struct` so that the export
   is put in a `deserialize-info` submodule, where it should cause less
   trouble. This is a slightly backward-incompatible change; I found a
   couple of modules that explicitly excluded `deserialize-info...` on
   import, and so those exclusions would have to be dropped.
  
   The change could also be backward-incompatible by changing the protocol
   for providers of deserialization other than
 `define-serializeable-struct`.
   That problem is easier to address: `deserialize` can try a
   `deserialze-info` submodule first, and if the export isn't found, then
   it can try the original module.
  
   Ok?
  
   _
 Racket Developers list:
 http://lists.racket-lang.org/dev
  

_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] backwards incompatibility (was Re: `define-serializable-struct` and the `deserialize-info...` export)

2013-11-08 Thread Matthew Flatt
At Fri, 8 Nov 2013 19:18:10 -0600, Robby Findler wrote:
 On Fri, Nov 8, 2013 at 7:13 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
 
  Yes. Even if (as in the future) the current ring-0 packages weren't all
  the same git repository, I'd certainly at least try building them with
  this change.
 
  I think that running all the tests in the same way that DrDr does is
  not yet easy, but I hope we're moving in the direction of making that
  easier, and then my process can improve.
 
 
 Well, if you've built them, then can't just you just run raco test -xp
 put package names here and come back in a bit?

I encounter two problems with that strategy:

 * figuring out which of the 200+ package names to write; and

 * many things fail immediately and most things are skipped, because
   `raco test` doesn't use the test customizations in props the way
   DrDr does.

I would like to say `raco test -p main-distribution` to get essentially
DrDr's results on my machine.

  For now: I build, run some tests, and then push --- hoping that I can
  fix or revert quickly when DrDr uncovers problems.
 
 
 Perhaps we should be thinking about generalizing the ring-0-based DrDr so
 we can ask to try out changes?

Yes, it would be great if you work on that. I think the way forward is
to split out props information into info.rkt files, but I haven't
had time to pursue that direction myself.

_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] backwards incompatibility (was Re: `define-serializable-struct` and the `deserialize-info...` export)

2013-11-08 Thread Robby Findler
On Friday, November 8, 2013, Matthew Flatt wrote:

 At Fri, 8 Nov 2013 19:18:10 -0600, Robby Findler wrote:
  On Fri, Nov 8, 2013 at 7:13 PM, Matthew Flatt 
  mfl...@cs.utah.edujavascript:;
 wrote:
 
   Yes. Even if (as in the future) the current ring-0 packages weren't all
   the same git repository, I'd certainly at least try building them with
   this change.
  
   I think that running all the tests in the same way that DrDr does is
   not yet easy, but I hope we're moving in the direction of making that
   easier, and then my process can improve.
  
  
  Well, if you've built them, then can't just you just run raco test -xp
  put package names here and come back in a bit?

 I encounter two problems with that strategy:

  * figuring out which of the 200+ package names to write; and

  * many things fail immediately and most things are skipped, because
`raco test` doesn't use the test customizations in props the way
DrDr does.

 I would like to say `raco test -p main-distribution` to get essentially
 DrDr's results on my machine.


That sounds nice.


   For now: I build, run some tests, and then push --- hoping that I can
   fix or revert quickly when DrDr uncovers problems.
  
  
  Perhaps we should be thinking about generalizing the ring-0-based DrDr so
  we can ask to try out changes?

 Yes, it would be great if you work on that. I think the way forward is
 to split out props information into info.rkt files, but I haven't
 had time to pursue that direction myself.


That sounds like a better approach. It also seems likely to mesh better
with the snapshot infrastructure you've built.

I would like to try that but I don't think I will get to it for several
weeks, so if someone else wanted to give it a try that'd be fantastic.

Robby
_
  Racket Developers list:
  http://lists.racket-lang.org/dev