Date: Mon, 28 Aug 2017 09:22:18 -0400 From: Miles Fertel <milesfertel@college.harvard.edu> To: Brooks Davis <brooks@freebsd.org> Cc: gavin@freebsd.org, soc-status@freebsd.org Subject: Re: Week 12 Update: Message-ID: <CADoeuZ_ET_Edkx3eZUW8XO=gNRTLU=maAwaV_hQHyR-puG8ukQ@mail.gmail.com> In-Reply-To: <20170824181635.GF1667@spindle.one-eyed-alien.net> References: <CADoeuZ8iXxoy5k4GHBnxu-hzQOyBbqc_E5hO3e83q8bYcjG3tA@mail.gmail.com> <20170824181635.GF1667@spindle.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hey Brooks, I totally understand, thanks for the follow up. I've gone ahead and: - updated the documentation - moved the documentation to my wiki - added a readme and the necessary #! to the bench code - added to the makefile - added a summary of the status of the project - added ways people can contribute to the project - Miles On Aug 24, 2017 2:16 PM, "Brooks Davis" <brooks@freebsd.org> wrote: > Hi Miles, > > Apologies for the radio silence. I've been traveling and had some > major deadlines, but that's a poor excuse. I'll try to answer your > questions below. > > On Mon, Aug 21, 2017 at 08:50:53AM -0400, Miles Fertel wrote: > > I have not heard from @Brooks since the 4th of August, so I've been in > > contact with Gavin in order to try to get the necessary questions > answered > > to be in a good place for this last week of GSoC. > > > > It has been difficult making progress the last two weeks without Brooks > > > available. I am confident that the Test Cases and Benchmarking code are > > > very close to mergeable product, and I would like to see that completed > > > this week. With regards to Wikisort, that is a bigger challenge, and I > > > would like to get it to a workable place such that it could be improved > > > upon in the days past the end of GSOC. > > > > > > > ---------- Forwarded message ---------- > > From: Miles Fertel <milesfertel@college.harvard.edu> > > Date: Mon, Aug 21, 2017 at 8:42 AM > > Subject: Re: Summer of Code > > To: gavin@freebsd.org > > > > > > Hey Gavin, > > > > Sorry for the late response. I've been in crisis mode in and out of > > airports for the last 60 hours due to delays and cancellation of several > > flights. > > > > Unfortunately no, I haven't heard from brooks yet. I've been taking steps > > to solve several of the problems on my own, but I'd be thrilled if you > > could find someone to forward these questions to. > > > > Test Cases: <https://reviews.freebsd.org/D11621>; > > > > - Are the test cases prepared to merge? What must be done to merge > them? > > - I asked these questions on phabricator and pointed to them to brooks > > by email but received no response: > > - Added the canary for the bigstruct test. Unsure if DEADBEEF is > the > > right value to use but it's adjustable. > > A static DEADBEEF seems fine. In some what's a solution that varied > the canary would be better to make sure the contents are actually > being copied, but that's fine to start. > > >The only problem I have left is > > that of printing out the entire array on failure. I'm unsure of > > the proper > > way to do that. I could print both the input array and the > improperly > > sorted array to stderr, but I worry about if that would be very > > painful to > > look over and find the problem. Just the input array would > probably be > > enough to reproduce the bug, but should it be printed directly > > to STDOUT or > > STDERR or do I have to do it through some ATF_TC medium? > > I think you can just print it to stderr. There's not really any way to > make it pretty. The other option would be to remove the random code > entirely. While it is a good testing method, it doesn't fit the > regression test model. It might make more sense to have a separate > program in src/tools/tools that can store the bad outputs to files and > load them again for debugging. > > > > > Benchmark <https://reviews.freebsd.org/D11646>: > > > > - I've received no commentary on the makefile or the python driver > > script i've uploaded to reviews.freebsd.org. > > - Is there a FreeBSD python style guide to which I should be > adhering? > > We don't really have one. There's a tendency to follow style(9) > indentation, but I think that works badly and isn't necessary. > > > - Am I utilizing ministat properly? > > It looks like you are. The script could use some documentation of > expected outputs. It also wouldn't hurt to say what it's doing as it > runs. > > > - Is my Makefile correct? > > Pretty much. I just submitted a comment I wrote a couple weeks ago. > > > WikiSort: <https://reviews.freebsd.org/D11598>; > > > > - "I'd also appreciate if you could recommend what I might do about > the > > style of WikiSort. I know it's a bit of an undertaking, as it seems > to me > > the only way to make the code reasonably fit Style(9) would be to > break it > > down into functions, as the logic results in some statements starting > at > > the 70 column mark." > > - I've also received no comments either of the files on phabricator. > > It would be helpful to see a diff relative to the original as that > impacts the way we want to import the code. If a substantial portion of > the code is identical then we might want to do a vendor import and apply > your changes in src/contrib so we can apply future fixes from upstream. > > Either way, I'd be inclined to avoid touching the style of the code so > it's possible to diff with upstream. > > > Documentation: > > > > - I've located my documentation temporarily at > https://gist.github.com/ > > milesfertel/3f1210be9774d33d2e250a447a716261 > > <https://gist.github.com/milesfertel/3f1210be9774d33d2e250a447a716261 > >. > > - Is there a standard location I should be writing documentation? > > For GSoC, your wiki page would be the standard place. A writeup of the > performance of the new code vs the old would be would a good idea and a > short version will need to be included in the commit when the time comes. > > > - Should I be updating any man pages or writing one for Wikisort? > > You will want to update lib/libc/stdlib/qsort.1. > > > - Is there anything you'd have me do to make this project easy to work > > on going forward, as this is the last week of GSOC? > > > > It has been difficult making progress the last two weeks without Brooks > > available. I am confident that the Test Cases and Benchmarking code are > > very close to mergeable product, and I would like to see that completed > > this week. With regards to Wikisort, that is a bigger challenge, and I > > would like to get it to a workable place such that it could be improved > > upon in the days past the end of GSOC. > > I'm quite happy with where things stand today. If you remove the rand > tests or add the necessary ugly output I think we're ready to land > that part. It looks like the benchmarks mostly need a bit of > documentation and couple one line additions. > > For wikisort it self, a summary of results would be helpful. In > addition to performance, one things people will care about is code size. > You might look at the size of stripped object files a simple proxy One > thing > that does seem to be missing is an _b variant for blocks support. > > -- Brooks >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADoeuZ_ET_Edkx3eZUW8XO=gNRTLU=maAwaV_hQHyR-puG8ukQ>