From owner-soc-status@freebsd.org Mon Aug 28 13:22:19 2017 Return-Path: Delivered-To: soc-status@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC250E0D6BC for ; Mon, 28 Aug 2017 13:22:19 +0000 (UTC) (envelope-from milesfertel@college.harvard.edu) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BD9237718F for ; Mon, 28 Aug 2017 13:22:19 +0000 (UTC) (envelope-from milesfertel@college.harvard.edu) Received: by mail-oi0-x235.google.com with SMTP id t75so3562913oie.3 for ; Mon, 28 Aug 2017 06:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=college-harvard-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lEeHgIeag7wSDq4UPJhqMI0wK6qHHHXklapWvpx9eds=; b=y3CtYS/jQtCFUSPvYWDWRzfrfkmvvKd6UuMrshSO58zG1HbRkSCvU4PNB2W3Q/yFVg Es3NxnBPEqBsNFFan8glF0CzUTZqYr54L6rPcrSr+J81kIet4p7z7JecjRzgVf/A7EzT hhsmEzI4SL5HOT5Jg9YoFTuqF8XXWdWTS3atQOkTpORKKAm8z8M2eJ0i+9TY0iZ7IMnw 05iWy5DC/iuYl5YeDnY9sD2lBbhJ/EEGiFQ7rnBLZeQSgJ1rUgXgVc8XJSt7LoNGeqHI RUu9iPOCLQubLzzhbktsLm64Lrb5AcRaGDfnJw6OVsCEcXnkQ6A/Qn3YWmSZ3F/EZ4sW 9JLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lEeHgIeag7wSDq4UPJhqMI0wK6qHHHXklapWvpx9eds=; b=NVm1eC05MA/OT0HQNm2d6Y/EeEbdZp4/KoVyiJiEG7uc5MZQDICtsZV1HyOG9guNu2 OV9d8vt1IlpXpPcLiHRmGfH862qIvL+YkQhRDAhUocSrV7R0ZwcAKC3nyxLLqBM1zp+a iGeeH+8IhtymOXJjRUeXraQQgoG0BbLFwTOOg61WM1y5Kl42Qe8O6jlzVvXDMbx+qP19 K91oHnH1gXD4cAn9GnwLy6g+JK9I9UPFR0xtH7JmttrYVcen11eYQ8VdtrGx/ELWNcDm bLPn1VaL9m01ZJrtXn1D7jOyx0f+ymXHuMDWgM8EXz48jHG++Xs0U7nAbNKLKH6C8Z/J UXXQ== X-Gm-Message-State: AHYfb5jNwZz3jttQfV91DdbmlHkH7iVXasEwpUTHA1+jpeTKi3EW2rXD ZJK8D4OgWj3N/5eZgSJ0AIjo308zSKLH X-Received: by 10.202.234.196 with SMTP id i187mr449505oih.244.1503926538662; Mon, 28 Aug 2017 06:22:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.148.33 with HTTP; Mon, 28 Aug 2017 06:22:18 -0700 (PDT) In-Reply-To: <20170824181635.GF1667@spindle.one-eyed-alien.net> References: <20170824181635.GF1667@spindle.one-eyed-alien.net> From: Miles Fertel Date: Mon, 28 Aug 2017 09:22:18 -0400 Message-ID: Subject: Re: Week 12 Update: To: Brooks Davis Cc: gavin@freebsd.org, soc-status@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 13:22:20 -0000 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" 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 > > 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: > > > > - 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 : > > > > - 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: > > > > - "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 > > >. > > - 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 >