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

On Fri, Nov 8, 2013 at 7:13 PM, Matthew Flatt <mflatt at 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 <mflatt at 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
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20131108/c792b0a6/attachment-0001.html>