Re: [racket-dev] backwards incompatibility (was Re: `define-serializable-struct` and the `deserialize-info...` export)
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 > > > > 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 > > " 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
Re: [racket-dev] backwards incompatibility (was Re: `define-serializable-struct` and the `deserialize-info...` export)
At Fri, 8 Nov 2013 19:18:10 -0600, Robby Findler wrote: > On Fri, Nov 8, 2013 at 7:13 PM, Matthew Flatt 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 > " 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)
On Fri, Nov 8, 2013 at 7:13 PM, Matthew Flatt 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 " 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 > 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)
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 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)
I agree On Fri, Nov 8, 2013 at 12:39 PM, 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 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 Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] backwards incompatibility (was Re: `define-serializable-struct` and the `deserialize-info...` export)
(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 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
