<div dir="ltr">On Fri, Nov 8, 2013 at 7:13 PM, Matthew Flatt <span dir="ltr"><<a href="mailto:mflatt@cs.utah.edu" target="_blank">mflatt@cs.utah.edu</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes. Even if (as in the future) the current ring-0 packages weren't all<br>
the same git repository, I'd certainly at least try building them with<br>
this change.<br>
<br>
I think that running all the tests in the same way that DrDr does is<br>
not yet easy, but I hope we're moving in the direction of making that<br>
easier, and then my process can improve.<br>
<br></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

For now: I build, run some tests, and then push --- hoping that I can<br>
fix or revert quickly when DrDr uncovers problems.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>Perhaps we should be thinking about generalizing the ring-0-based DrDr so we can ask to try out changes?</div><div><br></div><div>I see that travis tries out pull requests on our repo so there is maybe some prior art to exploit for ideas.</div>
<div><br>Robby</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
At Fri, 8 Nov 2013 13:39:25 -0600, Robby Findler wrote:<br>
> (I think it is okay.)<br>
><br>
> But here's a chance for me to point out something I heard about in a<br>
> conversation with Satnam Singh at OOPSLA about how Google works that it<br>
> seems like would be a nice fit for us. Here's my adaptation to our world:<br>
> when you push out what some might consider a change that breaks clients<br>
> (like this one where you also hope to avoid a new package) you are obliged<br>
> to submit pull requests on all ring-0 packages to (at a min) get all test<br>
> cases to pass.<br>
><br>
> I guess you did that here, at least for the ring-0 packages in the racket<br>
> git repo, which is where the "I found ..." comment comes from?<br>
><br>
> Robby<br>
><br>
><br>
> On Fri, Nov 8, 2013 at 12:35 PM, Matthew Flatt <<a href="mailto:mflatt@cs.utah.edu">mflatt@cs.utah.edu</a>> wrote:<br>
><br>
> > Currently, `(define-serializable-struct id ....)` expands to `(provide<br>
> > deserialize-info:id-v0)`. The `deserialize-info...` identifier needs to<br>
> > be exported to make things work, but the export is a hassle: the<br>
> > programmer doesn't care about it, it's not usually documented,<br>
> > re-exporting modules don't want to re-export it, and so on.<br>
> ><br>
> > I'm planning to change `define-serializable-struct` so that the export<br>
> > is put in a `deserialize-info` submodule, where it should cause less<br>
> > trouble. This is a slightly backward-incompatible change; I found a<br>
> > couple of modules that explicitly excluded `deserialize-info...` on<br>
> > import, and so those exclusions would have to be dropped.<br>
> ><br>
> > The change could also be backward-incompatible by changing the protocol<br>
> > for providers of deserialization other than `define-serializeable-struct`.<br>
> > That problem is easier to address: `deserialize` can try a<br>
> > `deserialze-info` submodule first, and if the export isn't found, then<br>
> > it can try the original module.<br>
> ><br>
> > Ok?<br>
> ><br>
> > _________________________<br>
> >   Racket Developers list:<br>
> >   <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a><br>
> ><br>
</div></div></blockquote></div><br></div></div>