[racket-dev] `define-serializable-struct` and the `deserialize-info...` export
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)
(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)
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)
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)
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)
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)
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