profile
viewpoint
Andrew Gauger AndyGauge Cascade Computer Salem OR http://www.yetanother.site ❤ code

AndyGauge/gateway-guessor 4

First Rust program, attempts to guess network gateway given ip and mask.

AndyGauge/andygauge.github.io 0

Yetanother.site hosting

AndyGauge/api.socialconnect 0

json api for socialconnect

AndyGauge/AsCast 0

RSS syndicate for parsing election results

AndyGauge/awesome-mdbook 0

🗃️ a card catalog of mdbooks for your reading curiosity

AndyGauge/backtrace-rs 0

Backtraces in Rust

AndyGauge/bbsm 0

Craft CMS for beboldstreetministries.org

AndyGauge/BBSM-membership-api 0

Rails 6 Membership API application

AndyGauge/BBSM-membership-react 0

React Front End for Membership enrollment

AndyGauge/beboldstreetministries.org 0

A gem-based responsive simple texture styled Jekyll theme.

push eventAndyGauge/desk

Andrew Gauger

commit sha a70f53bb99c8520b348faec921e97d21d690cf7a

timetable in US

view details

Andrew Gauger

commit sha 76b8b44920505e4b540e76ed2f3944a4e502b979

Merge pull request #41 from AndyGauge/times timetable in US

view details

push time in 14 days

PR merged AndyGauge/desk

timetable in US
+4 -1

0 comment

2 changed files

AndyGauge

pr closed time in 14 days

PR opened AndyGauge/desk

timetable in US
+4 -1

0 comment

2 changed files

pr created time in 14 days

push eventAndyGauge/desk

Andrew Gauger

commit sha a70f53bb99c8520b348faec921e97d21d690cf7a

timetable in US

view details

push time in 14 days

push eventAndyGauge/desk

Andrew Gauger

commit sha f18e8856e4e4e91aa3a79dca59250f53528f570a

review

view details

Andrew Gauger

commit sha f75035ee7ba5dd0d1431984e25665838d321da5b

Merge pull request #40 from AndyGauge/times review

view details

push time in 14 days

PR merged AndyGauge/desk

review
+4 -4

0 comment

2 changed files

AndyGauge

pr closed time in 14 days

PR opened AndyGauge/desk

review
+4 -4

0 comment

2 changed files

pr created time in 14 days

push eventAndyGauge/desk

Andrew Gauger

commit sha f18e8856e4e4e91aa3a79dca59250f53528f570a

review

view details

push time in 14 days

push eventAndyGauge/desk

Andrew Gauger

commit sha 49e7cce5757c5224de9d6212e2dc370166af54f1

summary of changes when list is long, fix 0 pad, update end times explicit

view details

Andrew Gauger

commit sha a7e4837ffddadf42813e9438fc6efa7faf058243

Merge pull request #39 from AndyGauge/times summary of changes when list is long, fix 0 pad, update end times exp…

view details

push time in 14 days

PR merged AndyGauge/desk

summary of changes when list is long, fix 0 pad, update end times exp… hacktoberfest-accepted

…licit

+46 -23

0 comment

4 changed files

AndyGauge

pr closed time in 14 days

PR opened AndyGauge/desk

summary of changes when list is long, fix 0 pad, update end times exp…

…licit

+46 -23

0 comment

4 changed files

pr created time in 14 days

create barnchAndyGauge/desk

branch : times

created branch time in 14 days

push eventAndyGauge/desk

Andrew Gauger

commit sha b64aa520cd03f2fcab6a4c2467fc60beb5b06a4d

calendar

view details

Andrew Gauger

commit sha 7a221587647da632fbdc274ee8ff0863f628b33f

Merge pull request #38 from AndyGauge/timetable unstyled calendar

view details

push time in 15 days

PR merged AndyGauge/desk

unstyled calendar
+10 -1

0 comment

4 changed files

AndyGauge

pr closed time in 15 days

PR opened AndyGauge/desk

unstyled calendar
+10 -1

0 comment

4 changed files

pr created time in 15 days

push eventAndyGauge/desk

Andrew Gauger

commit sha b64aa520cd03f2fcab6a4c2467fc60beb5b06a4d

calendar

view details

push time in 15 days

push eventAndyGauge/desk

Andrew Gauger

commit sha a44cc3993f43c91d5f90b54f9d2063babc680a26

allow timetable when logged in

view details

Andrew Gauger

commit sha ec812075571fce6941fcbe01478b1877c096b35a

Merge pull request #37 from AndyGauge/timetable allow timetable when logged in

view details

push time in 15 days

PR merged AndyGauge/desk

allow timetable when logged in hacktoberfest-accepted
+10 -12

0 comment

3 changed files

AndyGauge

pr closed time in 15 days

PR opened AndyGauge/desk

allow timetable when logged in
+10 -12

0 comment

3 changed files

pr created time in 15 days

push eventAndyGauge/desk

Andrew Gauger

commit sha a44cc3993f43c91d5f90b54f9d2063babc680a26

allow timetable when logged in

view details

push time in 15 days

push eventAndyGauge/gateway-guessor

Andrew Gauger

commit sha a92e80cd671e2dee2ef97ef0bd1abbde5d24c74e

update readme

view details

push time in 16 days

push eventAndyGauge/gateway-guessor

Andrew Gauger

commit sha d3e86e0a9fb7768d2f915c65e1ac773ef6d3be56

update readme

view details

push time in 16 days

push eventAndyGauge/gateway-guessor

Andrew Gauger

commit sha ce90aa771153239a4e9b29534781b870001848ae

update readme

view details

push time in 16 days

push eventAndyGauge/rust

Andrew Gauger

commit sha dff4716c8448cb4753ce0510a8f4200d5960d515

return a measure of contractions

view details

push time in 24 days

pull request commentnetbox-community/netbox

#1503: Extend secrets assignment to virtual machines (DRAFT)

This is very exciting to see!

jeremystretch

comment created time in a month

push eventAndyGauge/desk

Andrew Gauger

commit sha f548680f365bbd9892314af5b9c014c3d27cebb8

30 days otp session

view details

Andrew Gauger

commit sha e8bd080c70ac1ac4bd9134047b055d3a3325dff6

Merge pull request #36 from AndyGauge/timetable 30 days otp session

view details

push time in a month

PR merged AndyGauge/desk

30 days otp session
+262 -4

0 comment

3 changed files

AndyGauge

pr closed time in a month

PR opened AndyGauge/desk

30 days otp session
+262 -4

0 comment

3 changed files

pr created time in a month

push eventAndyGauge/desk

Andrew Gauger

commit sha f548680f365bbd9892314af5b9c014c3d27cebb8

30 days otp session

view details

push time in a month

Pull request review commentrust-lang/rust

75521 rustdoc book improvements

 and finally provides a code example.  `rustdoc` is using the [commonmark markdown specification]. You might be interested into taking a look at their website to see what's possible to do.+ - [commonmark quick reference]+ - [current spec] -## Lints--To be sure that you didn't miss any item without documentation or code examples,-you can take a look at the rustdoc lints [here][rustdoc-lints].

I gave that section an entire chapter. I moved it into the what-to-include section, although I rewrote it to have details.

AndyGauge

comment created time in a month

PullRequestReviewEvent

Pull request review commentrust-lang/rust

75521 rustdoc book improvements

 CSS, and JavaScript.  ## Basic usage -Let's give it a try! Let's create a new project with Cargo:+Let us give it a try! Create a new project with Cargo:  ```bash $ cargo new docs $ cd docs ``` -In `src/lib.rs`, you'll find that Cargo has generated some sample code. Delete+In `src/lib.rs`, Cargo has generated some sample code. Delete it and replace it with this:  ```rust /// foo is a function fn foo() {} ``` -Let's run `rustdoc` on our code. To do so, we can call it with the path to+Now, run `rustdoc` on our code. To do so, we can call it with the path to our crate root like this:

I think I'm going to return a measure of contractions.

AndyGauge

comment created time in a month

PullRequestReviewEvent

push eventAndyGauge/rust

Andrew Gauger

commit sha 3b0e342046a730fa85d5b015981b714d18021de4

Update src/doc/rustdoc/src/how-to-write-documentation.md Co-authored-by: Joshua Nelson <joshua@yottadb.com>

view details

push time in a month

push eventAndyGauge/rust

Andrew Gauger

commit sha 7902f3527c3c1f5fa31ea335a2dfc4fb048143c9

Update src/doc/rustdoc/src/how-to-write-documentation.md Co-authored-by: Joshua Nelson <joshua@yottadb.com>

view details

push time in a month

push eventAndyGauge/rust

Andrew Gauger

commit sha 0328bc17a17d533d5b8cb9cc690b57fbfcf55430

Update src/doc/rustdoc/src/how-to-write-documentation.md Co-authored-by: Joshua Nelson <joshua@yottadb.com>

view details

push time in a month

pull request commentrust-lang/rust

75521 rustdoc book improvements

Thanks for the feedback. Looks like there was an accidental merging of 2 tasks, thanks for identifying that. I'm a bit swamped now, but maybe this weekend I'll put some time into this.

AndyGauge

comment created time in a month

fork AndyGauge/timetable.js

Vanilla javascript plugin for building nice responsive timetables

http://timetablejs.org

fork in a month

push eventAndyGauge/desk

Andrew Gauger

commit sha ad4d0f98507ea93ba5230bb063f6d8f4643fcdf9

Reworked two factor page added calendar for timetable

view details

Andrew Gauger

commit sha a57ee72f4a5efcdb8700897793a716fdc1d31f24

Merge pull request #35 from AndyGauge/timetable Reworked two factor page added calendar for timetable

view details

push time in a month

push eventAndyGauge/desk

dependabot[bot]

commit sha 1db11a981c5fb892d46832c15f963b015618b47e

Bump http-proxy from 1.18.0 to 1.18.1 Bumps [http-proxy](https://github.com/http-party/node-http-proxy) from 1.18.0 to 1.18.1. - [Release notes](https://github.com/http-party/node-http-proxy/releases) - [Changelog](https://github.com/http-party/node-http-proxy/blob/master/CHANGELOG.md) - [Commits](https://github.com/http-party/node-http-proxy/compare/1.18.0...1.18.1) Signed-off-by: dependabot[bot] <support@github.com>

view details

Andrew Gauger

commit sha 3cc3d79d266cb86e16def20e9fd8fd6cfa2e4e37

Merge pull request #34 from AndyGauge/dependabot/npm_and_yarn/http-proxy-1.18.1 Bump http-proxy from 1.18.0 to 1.18.1

view details

push time in a month

PR merged AndyGauge/desk

Bump http-proxy from 1.18.0 to 1.18.1 dependencies javascript

Bumps http-proxy from 1.18.0 to 1.18.1. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/http-party/node-http-proxy/blob/master/CHANGELOG.md">http-proxy's changelog</a>.</em></p> <blockquote> <h2><a href="https://github.com/http-party/node-http-proxy/compare/1.18.0...v1.18.1">v1.18.1</a> - 2020-05-17</h2> <h3>Merged</h3> <ul> <li>Skip sending the proxyReq event when the expect header is present <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1447"><code>#1447</code></a></li> <li>Remove node6 support, add node12 to build <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1397"><code>#1397</code></a></li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/http-party/node-http-proxy/commit/9b96cd725127a024dabebec6c7ea8c807272223d"><code>9b96cd7</code></a> 1.18.1</li> <li><a href="https://github.com/http-party/node-http-proxy/commit/335aeeba2f0c286dc89c402eeb76af47834c89a3"><code>335aeeb</code></a> Skip sending the proxyReq event when the expect header is present (<a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/issues/1447">#1447</a>)</li> <li><a href="https://github.com/http-party/node-http-proxy/commit/dba39668ba4c9ad461316e834b2d64b77e1ca88e"><code>dba3966</code></a> Remove node6 support, add node12 to build (<a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/issues/1397">#1397</a>)</li> <li>See full diff in <a href="https://github.com/http-party/node-http-proxy/compare/1.18.0...1.18.1">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+13 -15

0 comment

2 changed files

dependabot[bot]

pr closed time in a month

push eventAndyGauge/desk

dependabot[bot]

commit sha 49decc3dd8a5f01cdd2f64665a97a4261199803e

Bump node-sass from 4.13.0 to 4.14.1 Bumps [node-sass](https://github.com/sass/node-sass) from 4.13.0 to 4.14.1. - [Release notes](https://github.com/sass/node-sass/releases) - [Changelog](https://github.com/sass/node-sass/blob/master/CHANGELOG.md) - [Commits](https://github.com/sass/node-sass/compare/v4.13.0...v4.14.1) Signed-off-by: dependabot[bot] <support@github.com>

view details

Andrew Gauger

commit sha 0944d01aabede7154cf68410015f4b9046249527

Merge pull request #33 from AndyGauge/dependabot/npm_and_yarn/node-sass-4.14.1 Bump node-sass from 4.13.0 to 4.14.1

view details

push time in a month

PR merged AndyGauge/desk

Bump node-sass from 4.13.0 to 4.14.1 dependencies javascript

Bumps node-sass from 4.13.0 to 4.14.1. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/sass/node-sass/releases">node-sass's releases</a>.</em></p> <blockquote> <h2>v4.14.1</h2> <h3>Community</h3> <ul> <li>Add GitHub Actions for Alpine CI (<a href="https://github.com/nschonni">@nschonni</a>, <a href="https://github-redirect.dependabot.com/sass/node-sass/issues/2823">#2823</a>)</li> </ul> <h3>Fixes</h3> <ul> <li>Bump sass-graph@2.2.5 (<a href="https://github.com/xzyfer">@xzyfer</a>, <a href="https://github-redirect.dependabot.com/sass/node-sass/issues/2912">#2912</a>)</li> </ul> <h2>Supported Environments</h2> <table> <thead> <tr> <th>OS</th> <th>Architecture</th> <th>Node</th> </tr> </thead> <tbody> <tr> <td>Windows</td> <td>x86 & x64</td> <td>0.10, 0.12, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14</td> </tr> <tr> <td>OSX</td> <td>x64</td> <td>0.10, 0.12, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14</td> </tr> <tr> <td>Linux*</td> <td>x86 & x64</td> <td>0.10, 0.12, 1, 2, 3, 4, 5, 6, 7, 8**, 9**, 10**^, 11**^, 12**^, 13**^, 14**^</td> </tr> <tr> <td>Alpine Linux</td> <td>x64</td> <td>6, 8, 10, 11, 12, 13, 14</td> </tr> <tr> <td>FreeBSD</td> <td>i386 amd64</td> <td>10, 12, 13</td> </tr> </tbody> </table> <p>Linux support refers to Ubuntu, Debian, and CentOS 5+ ** Not available on CentOS 5 ^ Only available on x64</p> <h2>v4.14.0</h2> <h3>Features</h3> <ul> <li>Add Node 14 support (<a href="https://github.com/nschonni">@nschonni</a>, <a href="https://github-redirect.dependabot.com/sass/node-sass/issues/2895">#2895</a>)</li> </ul> <h3>Fixes</h3> <ul> <li>Reporting wrong LibSass version (<a href="https://github.com/saper">@saper</a>, <a href="https://github-redirect.dependabot.com/sass/node-sass/issues/2621">#2621</a>)</li> </ul> <h2>Supported Environments</h2> <table> <thead> <tr> <th>OS</th> <th>Architecture</th> <th>Node</th> </tr> </thead> <tbody> <tr> <td>Windows</td> <td>x86 & x64</td> <td>0.10, 0.12, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14</td> </tr> <tr> <td>OSX</td> <td>x64</td> <td>0.10, 0.12, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14</td> </tr> <tr> <td>Linux</td> <td>x86 & x64</td> <td>0.10, 0.12, 1, 2, 3, 4, 5, 6, 7, 8**, 9**, 10**^, 11**^, 12**^, 13**^, 14**^</td> </tr> <tr> <td>Alpine Linux</td> <td>x64</td> <td>6, 8, 10, 11, 12, 13, 14</td> </tr> <tr> <td>FreeBSD</td> <td>i386 amd64</td> <td>10, 12, 13</td> </tr> </tbody> </table> <p>*Linux support refers to Ubuntu, Debian, and CentOS 5+ ** Not available on CentOS 5 ^ Only available on x64</p> <h2>v4.13.1</h2> <h3>Community</h3> <ul> <li>Fix render example syntax (<a href="https://github.com/ZoranPandovski">@ZoranPandovski</a> , <a href="https://github-redirect.dependabot.com/sass/node-sass/issues/2787">#2787</a>)</li> </ul> <!-- raw HTML omitted --> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/sass/node-sass/blob/master/CHANGELOG.md">node-sass's changelog</a>.</em></p> <blockquote> <h2>v4.14.0</h2> <p><a href="https://github.com/sass/node-sass/releases/tag/v4.14.0">https://github.com/sass/node-sass/releases/tag/v4.14.0</a></p> <h2>v4.13.1</h2> <p><a href="https://github.com/sass/node-sass/releases/tag/v4.13.1">https://github.com/sass/node-sass/releases/tag/v4.13.1</a></p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/sass/node-sass/commit/0d6c3cc36a5362e83529d901484b0bbf3e96de81"><code>0d6c3cc</code></a> 4.14.1</li> <li><a href="https://github.com/sass/node-sass/commit/1cc626373196500b288f487e1507926066f3e406"><code>1cc6263</code></a> Bump sass-graph@2.2.5 (<a href="https://github-redirect.dependabot.com/sass/node-sass/issues/2915">#2915</a>)</li> <li><a href="https://github.com/sass/node-sass/commit/aa193f6334e45ae065cc64d67498acfad9fad4d9"><code>aa193f6</code></a> chore: Add GitHub Actions for Alpine CI</li> <li><a href="https://github.com/sass/node-sass/commit/eac343c6cc39abff153b2c8e9cc0d6b8351c8a8f"><code>eac343c</code></a> 4.14.0</li> <li><a href="https://github.com/sass/node-sass/commit/bbeb78cab873b12fc4b98358b62090e6fbc9b400"><code>bbeb78c</code></a> Update changelog</li> <li><a href="https://github.com/sass/node-sass/commit/1210aabc65ed445263dac5041ad735e3a35ae600"><code>1210aab</code></a> Fix <a href="https://github-redirect.dependabot.com/sass/node-sass/issues/2621">#2621</a>: Report libsass version 3.5.5 (<a href="https://github-redirect.dependabot.com/sass/node-sass/issues/2769">#2769</a>)</li> <li><a href="https://github.com/sass/node-sass/commit/5a4a48a4a45f41d66d55e2103496e886ec7ee5f1"><code>5a4a48a</code></a> feat: Add Node 14 support</li> <li><a href="https://github.com/sass/node-sass/commit/b54053a1b50fd97e951eb0311a7fb818683a8e99"><code>b54053a</code></a> Update changelog</li> <li><a href="https://github.com/sass/node-sass/commit/01db05182b69dccbd43be777e6808045e71af0b5"><code>01db051</code></a> 4.13.1</li> <li><a href="https://github.com/sass/node-sass/commit/338fd7a14d3b8bd374a382336df16f9c6792b884"><code>338fd7a</code></a> Merge pull request from GHSA-f6rp-gv58-9cw3</li> <li>Additional commits viewable in <a href="https://github.com/sass/node-sass/compare/v4.13.0...v4.14.1">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+305 -247

0 comment

2 changed files

dependabot[bot]

pr closed time in a month

PR opened AndyGauge/desk

Reworked two factor page added calendar for timetable
+69 -8

0 comment

8 changed files

pr created time in a month

push eventAndyGauge/desk

Andrew Gauger

commit sha ad4d0f98507ea93ba5230bb063f6d8f4643fcdf9

Reworked two factor page added calendar for timetable

view details

push time in a month

issue commentrust-lang/rust

rustdoc: source view appended newlines

Try adding git config --global core.eol lf and possibly git add --renormalize . to make those files end with the right character.

lzutao

comment created time in a month

create barnchAndyGauge/rust

branch : 75520-improve-rustdoc-book-visibility

created branch time in a month

push eventAndyGauge/desk

Andrew Gauger

commit sha 287214b0ad37aa3d4dcd770cd43f33d4eecbff11

styles and timeout change

view details

Andrew Gauger

commit sha 470e03c92af5907d700aadacc2643fe2f3eb3498

30 days

view details

Andrew Gauger

commit sha 220f8431b7ad589f40f24ed5b5809437dc3576c5

Merge pull request #32 from AndyGauge/timetable Timeout and styling

view details

push time in 2 months

PR merged AndyGauge/desk

Timeout and styling
+34 -9

0 comment

4 changed files

AndyGauge

pr closed time in 2 months

PR opened AndyGauge/desk

Timeout and styling
+34 -9

0 comment

4 changed files

pr created time in 2 months

push eventAndyGauge/desk

Andrew Gauger

commit sha 470e03c92af5907d700aadacc2643fe2f3eb3498

30 days

view details

push time in 2 months

push eventAndyGauge/desk

Andrew Gauger

commit sha 287214b0ad37aa3d4dcd770cd43f33d4eecbff11

styles and timeout change

view details

push time in 2 months

issue commentrust-lang/rust

Improve "visibility" of rustdoc books ("stable" and unstable ones)

See http://doc.rust-lang.org/rustdoc for more information
rustdoc [options] <input>

Options:```

I was able to get rustdoc to compile with a little tooltip!  
GuillaumeGomez

comment created time in 2 months

Pull request review commentrust-lang/rust

75521 rustdoc book improvements

 documentation; while you might think that a code example is trivial, the examples are really important because they can help users understand  what an item is, how it is used, and for what purpose it exists. -Let's see an example coming from the [standard library] by taking a look at the+Let us see an example coming from the [standard library] by taking a look at the

It was something I learned from Brian Anderson, during the lib blitz. It probably was personal preference.

AndyGauge

comment created time in 2 months

PullRequestReviewEvent

Pull request review commentrust-lang/rust

75521 rustdoc book improvements

 use a different convention than the rest of the rustdocs.  Lines should start with `//!` which indicate module-level or crate-level documentation. Here's a quick example of the difference: -```rust+```rust,ignore

The checks were failing. When I put that into a lib.rs file, I can compile it. When github actions compiles it, it fails. Maybe a bug?

AndyGauge

comment created time in 2 months

PullRequestReviewEvent

push eventAndyGauge/rust

Andrew Gauger

commit sha 2da78bcac8cc002907f1ab4becdbd7151039bfa4

documenting doc comments syntax

view details

Andrew Gauger

commit sha c5209a8dd564f922b4a9b57d3ead1ec98b69db8f

Merge branch '75521-rustdoc-book-improvements' of github.com:AndyGauge/rust into 75521-rustdoc-book-improvements

view details

push time in 2 months

push eventAndyGauge/rust

Andrew Gauger

commit sha e9e5b2a324c2063a0c5f9b74bf8a596a3d50f18e

Update how-to-write-documentation.md ironically, rustdoc book example fails to compile

view details

push time in 2 months

push eventAndyGauge/rust

Andrew Gauger

commit sha 5fff34e7be811190dbadc093a0d7ea1dbf99ccc3

Additional tidy for rustdoc book

view details

push time in 2 months

Pull request review commentrust-lang/rust

75521 rustdoc book improvements

 documentation; while you might think that a code example is trivial, the examples are really important because they can help users understand  what an item is, how it is used, and for what purpose it exists. -Let's see an example coming from the [standard library] by taking a look at the+Let us see an example coming from the [standard library] by taking a look at the

My first pass I let Let's survive. I went back and it seemed out of place suddenly and let us made more sense once all the other contractions were removed. It is funny that the original contraction that was pointed out only showed in the diff because I had inserted a new line (and a header). I personally avoid them at all cost. In fact, when I write documentation I make the code the subject rather than allowing a narrator and reader into the language. Therefore, let's to me violates 3 rules: contractions, first-person narrative, and speaking to the audience directly.

AndyGauge

comment created time in 2 months

PullRequestReviewEvent

Pull request review commentrust-lang/rust

75521 rustdoc book improvements

 then it should be documented. ## Getting Started  Documenting a crate should begin with front-page documentation.  As an-example, [hashbrown] crate level documentation summarizes the role of-the crate, provides links to explain technical details, and gives the -reason why to use the crate.  +example, the [`hashbrown`] crate level documentation summarizes the role of+the crate, provides links to explain technical details, and explains why you +would want to use the crate.   -After introducing the crate, it is important that within the front-page -an example be given how to use the crate in a real world setting.  The-example benefits from isolating the library's role from the implementation-details, but doing so without shortcuts also benefits users who may copy-and paste the example to get started. +After introducing the crate, it is important that the front-page gives +an example of how to use the crate in a real world setting.  Stick to the+library's role in the example, but do so without shortcuts to benefit users who+may copy and paste the example to get started.  -[futures] uses an approach of inline comments to explain line by line-the complexities of using a future, because often people's first exposure to -rust's future is this example.+[`futures`] uses inline comments to explain line by line+the complexities of using a [`Future`], because a person's first exposure to +rust's [`Future`] may be this example. -[backtrace] usage walks through the whole process, explaining changes made-to the `Cargo.toml` file, passing command line arguments to the compiler,-and shows a quick example of backtrace in the wild.  +The [`backtrace`] documentation walks through the whole process, explaining +changes made to the `Cargo.toml` file, passing command line arguments to the+compiler, and shows a quick example of backtrace in the wild.    Finally, the front-page can eventually become a comprehensive reference-how to ues a crate, like the usage found in [regex].  In this front page, all-the requirements are outlined, the gotchas are taught, then practical examples-are provided.  The front page goes on to show how to use regular expressions+how to use a crate, like [`regex`].  In this front page, all+requirements are outlined, the edge cases shown, and practical examples +provided.  The front page goes on to show how to use regular expressions then concludes with crate features. -Don't worry about comparing your crate that is just beginning to get-documentation to something more polished, just start incrementally and put-in an introduction, example, and features.  Rome wasn't built in a day!+Don't worry about comparing your crate, which is just beginning.  To get the

It came from reading regex front page and thinking wow, that's a bit overwhelming.

AndyGauge

comment created time in 2 months

PullRequestReviewEvent

Pull request review commentrust-lang/rust

75521 rustdoc book improvements

 for argument in env::args() { [`args_os`]: ./fn.args_os.html `````` +The first line of description will be reused when describing the component in+a higher level of the documentation.  For example, the function `std::env::args()`+above can be found within the [`std::env`] module documentation.++Because the type system does a good job of defining what is passed to a function+and what is returned from one, there is not a benefit of explicitly writing those+things into the documentation.  Rustdoc makes sure the links to the types included+in the signature are linked.++In the example above, a Panics section explains when the code might abruptly exit+which can help the reader build guards if required.  A panic section is recommended+every time edge cases in your code can be reached if known.

It is not enough to be easy to understand, but hard to confuse is the goal. I failed at clarity here. catch_unwind is definitely not something I want people to reach for.

AndyGauge

comment created time in 2 months

PullRequestReviewEvent

Pull request review commentrust-lang/rust

75521 rustdoc book improvements

 # How to write documentation +Good documentation is not natural.  There are opposing forces that make good+documentation difficult.  It requires expertise in the subject but also+requires writing to a novice perspective.  Documentation therefore often +glazes over implementation detail, or leaves an explain like I'm 5 response.++There are tenants to Rust documentation that can help guide anyone through+the process of documenting libraries so everyone has ample opportunity to+use the code.  + This chapter covers not only how to write documentation but specifically-how to write **good** documentation.  Something to keep in mind when-writing documentation is that your audience is not just yourself but others-who simply don't have the context you do.  It is important to be as clear+how to write **good** documentation.  It is important to be as clear as you can, and as complete as possible.  As a rule of thumb: the more documentation you write for your crate the better.  If an item is public then it should be documented. -## Basic structure+## Getting Started++Documenting a crate should begin with front-page documentation.  As an+example, [hashbrown] crate level documentation summarizes the role of+the crate, provides links to explain technical details, and gives the +reason why to use the crate.  ++After introducing the crate, it is important that within the front-page +an example be given how to use the crate in a real world setting.  The+example benefits from isolating the library's role from the implementation+details, but doing so without shortcuts also benefits users who may copy+and paste the example to get started. ++[futures] uses an approach of inline comments to explain line by line+the complexities of using a future, because often people's first exposure to +rust's future is this example.

I linked stable but good idea!

AndyGauge

comment created time in 2 months

PullRequestReviewEvent

push eventAndyGauge/rust

Andrew Gauger

commit sha 09c4204e89bc1825fb60def504da48f57d0fce6b

Add message in help for rustdoc book link

view details

Andrew Gauger

commit sha b7a4bd903490efc179149dff2d36385c3005da6a

introducing writing documentation added front page sample component documentation Added reference and include chapters

view details

Andrew Gauger

commit sha 0f605b0e46c522c3808eb25c3d7a140b1e542517

Rust Doc book improvements post-review

view details

push time in 2 months

Pull request review commentrust-lang/rust

75521 rustdoc book improvements

 # How to write documentation +Good documentation is not natural.  There are opposing forces that make good+documentation difficult.  It requires expertise in the subject but also+requires writing to a novice perspective.  Documentation therefore often +glazes over implementation detail, or leaves an explain like I'm 5 response.++There are tenants to Rust documentation that can help guide anyone through+the process of documenting libraries so everyone has ample opportunity to+use the code.  + This chapter covers not only how to write documentation but specifically-how to write **good** documentation.  Something to keep in mind when-writing documentation is that your audience is not just yourself but others-who simply don't have the context you do.  It is important to be as clear+how to write **good** documentation.  It is important to be as clear as you can, and as complete as possible.  As a rule of thumb: the more documentation you write for your crate the better.  If an item is public then it should be documented. -## Basic structure+## Getting Started++Documenting a crate should begin with front-page documentation.  As an+example, [hashbrown] crate level documentation summarizes the role of+the crate, provides links to explain technical details, and gives the +reason why to use the crate.  ++After introducing the crate, it is important that within the front-page +an example be given how to use the crate in a real world setting.  The+example benefits from isolating the library's role from the implementation+details, but doing so without shortcuts also benefits users who may copy+and paste the example to get started. ++[futures] uses an approach of inline comments to explain line by line+the complexities of using a future, because often people's first exposure to +rust's future is this example.++[backtrace] usage walks through the whole process, explaining changes made+to the `Cargo.toml` file, passing command line arguments to the compiler,+and shows a quick example of backtrace in the wild.  ++Finally, the front-page can eventually become a comprehensive reference+how to ues a crate, like the usage found in [regex].  In this front page, all

or did I mean sue? good catch.

AndyGauge

comment created time in 2 months

PullRequestReviewEvent

Pull request review commentrust-lang/rust

75521 rustdoc book improvements

 # How to write documentation +Good documentation is not natural.  There are opposing forces that make good+documentation difficult.  It requires expertise in the subject but also+requires writing to a novice perspective.  Documentation therefore often +glazes over implementation detail, or leaves an explain like I'm 5 response.++There are tenants to Rust documentation that can help guide anyone through+the process of documenting libraries so everyone has ample opportunity to+use the code.  + This chapter covers not only how to write documentation but specifically-how to write **good** documentation.  Something to keep in mind when-writing documentation is that your audience is not just yourself but others-who simply don't have the context you do.  It is important to be as clear+how to write **good** documentation.  It is important to be as clear as you can, and as complete as possible.  As a rule of thumb: the more documentation you write for your crate the better.  If an item is public then it should be documented. -## Basic structure+## Getting Started++Documenting a crate should begin with front-page documentation.  As an+example, [hashbrown] crate level documentation summarizes the role of+the crate, provides links to explain technical details, and gives the +reason why to use the crate.  ++After introducing the crate, it is important that within the front-page +an example be given how to use the crate in a real world setting.  The+example benefits from isolating the library's role from the implementation+details, but doing so without shortcuts also benefits users who may copy

Yeah, that was a copy-paste from my revision.

AndyGauge

comment created time in 2 months

PullRequestReviewEvent

Pull request review commentrust-lang/rust

75521 rustdoc book improvements

 # How to write documentation +Good documentation is not natural.  There are opposing forces that make good+documentation difficult.  It requires expertise in the subject but also+requires writing to a novice perspective.  Documentation therefore often +glazes over implementation detail, or leaves an explain like I'm 5 response.++There are tenants to Rust documentation that can help guide anyone through+the process of documenting libraries so everyone has ample opportunity to+use the code.  + This chapter covers not only how to write documentation but specifically-how to write **good** documentation.  Something to keep in mind when-writing documentation is that your audience is not just yourself but others-who simply don't have the context you do.  It is important to be as clear+how to write **good** documentation.  It is important to be as clear as you can, and as complete as possible.  As a rule of thumb: the more documentation you write for your crate the better.  If an item is public then it should be documented. -## Basic structure+## Getting Started++Documenting a crate should begin with front-page documentation.  As an+example, [hashbrown] crate level documentation summarizes the role of+the crate, provides links to explain technical details, and gives the +reason why to use the crate.  ++After introducing the crate, it is important that within the front-page +an example be given how to use the crate in a real world setting.  The+example benefits from isolating the library's role from the implementation+details, but doing so without shortcuts also benefits users who may copy

Stick to the library's role in the example, but do so without shortcuts to benefit users who may copy and paste the example to get started.

AndyGauge

comment created time in 2 months

PullRequestReviewEvent

Pull request review commentrust-lang/rust

75521 rustdoc book improvements

+# What to include (and exclude)++It is easy to say everything must be documented in a project and often times+that is correct, but how can we get there, and are there things that don't+belong?++At the top of the `src/lib.rs` or `main.rs` file in your binary project, include+the following attribute:++```rust+#![warn(missing_docs)]+```++Now run `cargo doc` and examine the output.  Here's a sample:++```text+ Documenting docdemo v0.1.0 (/Users/username/docdemo)+warning: missing documentation for the crate+ --> src/main.rs:1:1+  |+1 | / #![warn(missing_docs)]+2 | |+3 | | fn main() {+4 | |     println!("Hello, world!");+5 | | }+  | |_^+  |+note: the lint level is defined here+ --> src/main.rs:1:9+  |+1 | #![warn(missing_docs)]+  |         ^^^^^^^^^^^^++warning: 1 warning emitted++    Finished dev [unoptimized + debuginfo] target(s) in 2.96s+```++As a library author, adding the lint `#![deny(missing_docs)]` is a great way to+ensure the project does not drift away from being documented well, and warn is+a good way to move towards comprehensive documentation.++In our example above, the warning is resolved by adding crate level+documentation.  The `main` method does not need documentation, but it is +present in the output.  If your main method is doing anything special, like+returning a `Result`, it could use documentation!++```rust+#![warn(missing_docs)]++//! Run program to print Hello, world.++/// Allows unhandled errors to become program return values+fn main() -> std::io::Result<()> {+    print_it();+    Ok(())+}++/// Safely prints Hello, world!+fn print_it() {+    println!("Hello, world!");+}+```+There are more lints in the upcoming chapter [Lints][rustdoc-lints].++## Examples++Of course this is contrived to be simple, but part of the power of documentation+is showing code that is easy to follow, rather than being realistic.  Docs often+shortcut error handling because often examples become complicated to follow+with all the necessary set up required for a simple example.++`Async` is a good example of this.  In order to execute an `async` example, an+executor needs to be available.  Examples will often shortcut this, and leave+users to figure out how to put the `async` code into their own runtime.++It is preferred that `unwrap()` not be used inside an example, and some of the+error handling components be hidden if they make the example too difficult to+follow.  ++``````rust+/// Example+/// ```rust+/// let fourtytwo = "42".parse::<u32>()?;+/// println!("{} + 10 = {}", fourtytwo, fourtytwo+10);+/// ```+``````  ++When rustdoc wraps that in a main function, it will panic due to the +`ParseIntError` trait not implemented.  In order to help both your audience+and your test suite, this example needs to have additional work performed:++``````rust+/// Example+/// ```rust+/// # main() -> Result<(), std::num::ParseIntError> {+/// let fourtytwo = "42".parse::<u32>()?;+/// println!("{} + 10 = {}", fourtytwo, fourtytwo+10);+/// #     Ok(())+/// # }+/// ```+``````  ++The example is the same on the doc page, but has that extra information+available to anyone trying to use your crate.  More about tests in the +upcoming [Documentation tests] chapter.  ++## What to Exclude++Certain parts of your public interface may be included by default in the output+of rustdoc.  The attribute `#[doc(hidden)]` hides the non-public consumption+implementation details to facilitate idiomatic Rust.  ++Good examples are `impl From<Error>` for providing `?` usage, or `impl Display`.

I was attempting to include C-HIDDEN API guideline without really understanding it. I've reread the API guideline and I don't feel what I wrote relates to the guideline. I'll try again.

AndyGauge

comment created time in 2 months

PullRequestReviewEvent

push eventAndyGauge/rust

Andrew Gauger

commit sha d7c21ebb0958aac7cb3b92e360690bad408336aa

WIP review updates

view details

push time in 2 months

Pull request review commentrust-lang/rust

75521 rustdoc book improvements

 # How to write documentation +Good documentation is not natural.  There are opposing forces that make good+documentation difficult.  It requires expertise in the subject but also+requires writing to a novice perspective.  Documentation therefore often +glazes over implementation detail, or leaves an explain like I'm 5 response.++There are tenants to Rust documentation that can help guide anyone through+the process of documenting libraries so everyone has ample opportunity to+use the code.  + This chapter covers not only how to write documentation but specifically-how to write **good** documentation.  Something to keep in mind when-writing documentation is that your audience is not just yourself but others-who simply don't have the context you do.  It is important to be as clear+how to write **good** documentation.  It is important to be as clear as you can, and as complete as possible.  As a rule of thumb: the more documentation you write for your crate the better.  If an item is public then it should be documented. -## Basic structure+## Getting Started++Documenting a crate should begin with front-page documentation.  As an+example, [hashbrown] crate level documentation summarizes the role of+the crate, provides links to explain technical details, and gives the +reason why to use the crate.  ++After introducing the crate, it is important that within the front-page +an example be given how to use the crate in a real world setting.  The+example benefits from isolating the library's role from the implementation+details, but doing so without shortcuts also benefits users who may copy+and paste the example to get started. ++[futures] uses an approach of inline comments to explain line by line+the complexities of using a future, because often people's first exposure to +rust's future is this example.++[backtrace] usage walks through the whole process, explaining changes made+to the `Cargo.toml` file, passing command line arguments to the compiler,+and shows a quick example of backtrace in the wild.  ++Finally, the front-page can eventually become a comprehensive reference+how to ues a crate, like the usage found in [regex].  In this front page, all+the requirements are outlined, the gotchas are taught, then practical examples+are provided.  The front page goes on to show how to use regular expressions+then concludes with crate features.++Don't worry about comparing your crate that is just beginning to get+documentation to something more polished, just start incrementally and put+in an introduction, example, and features.  Rome wasn't built in a day!++The first lines within the `lib.rs` will compose the front-page, and they+use a different convention than the rest of the rustdocs.  Lines should+start with `//!` which designate the code to refer to module-level or crate-+level documentation.  Here's a quick example of the difference:++```rust+//! Fast and easy queue abstraction.+//!+//! Provides an abstraction over a queue.  When the abstraction is used+//! there are these advantages:+//! - Fast+//! - [`Easy`]+//!+//! [`Easy`]: http://thatwaseasy.example.com++/// This module makes it easy.+pub mod easy {++    /// Use the abstract function to do this specific thing.+    pub fn abstract {}

16 | pub fn abstract {} 3038 | ^^^^^^^^ expected identifier, found reserved keyword

AndyGauge

comment created time in 2 months

PullRequestReviewEvent

pull request commentrust-lang/rust

75521 rustdoc book improvements

I agree with the themes included in this PR. Should I adjust the title to include work in process?

AndyGauge

comment created time in 2 months

Pull request review commentrust-lang/rust

75521 rustdoc book improvements

+# What to include (and exclude)++It is easy to say everything must be documented in a project and often times+that is correct, but how can we get there, and are there things that don't+belong?++At the top of the `src/lib.rs` or `main.rs` file in your binary project, include+the following attribute:++```rust+#![warn(missing_docs)]+```++Now run `cargo doc` and examine the output.  Here's a sample:++```text+ Documenting docdemo v0.1.0 (/Users/username/docdemo)+warning: missing documentation for the crate+ --> src/main.rs:1:1+  |+1 | / #![warn(missing_docs)]+2 | |+3 | | fn main() {+4 | |     println!("Hello, world!");+5 | | }+  | |_^+  |+note: the lint level is defined here+ --> src/main.rs:1:9+  |+1 | #![warn(missing_docs)]+  |         ^^^^^^^^^^^^++warning: 1 warning emitted++    Finished dev [unoptimized + debuginfo] target(s) in 2.96s+```++As a library author, adding the lint `#![deny(missing_docs)]` is a great way to+ensure the project does not drift away from being documented well, and warn is+a good way to move towards comprehensive documentation.

will expand it to the whole attribute

AndyGauge

comment created time in 2 months

PullRequestReviewEvent

Pull request review commentrust-lang/rust

75521 rustdoc book improvements

+# What to include (and exclude)++It is easy to say everything must be documented in a project and often times+that is correct, but how can we get there, and are there things that don't+belong?++At the top of the `src/lib.rs` or `main.rs` file in your binary project, include+the following attribute:++```rust+#![warn(missing_docs)]+```++Now run `cargo doc` and examine the output.  Here's a sample:++```text+ Documenting docdemo v0.1.0 (/Users/username/docdemo)+warning: missing documentation for the crate+ --> src/main.rs:1:1+  |+1 | / #![warn(missing_docs)]+2 | |+3 | | fn main() {+4 | |     println!("Hello, world!");+5 | | }+  | |_^+  |+note: the lint level is defined here+ --> src/main.rs:1:9+  |+1 | #![warn(missing_docs)]+  |         ^^^^^^^^^^^^++warning: 1 warning emitted++    Finished dev [unoptimized + debuginfo] target(s) in 2.96s+```++As a library author, adding the lint `#![deny(missing_docs)]` is a great way to

I will add it here.

AndyGauge

comment created time in 2 months

PullRequestReviewEvent

Pull request review commentrust-lang/rust

75521 rustdoc book improvements

 $ rustdoc src/lib.rs This will create a new directory, `doc`, with a website inside! In our case, the main page is located in `doc/lib/index.html`. If you open that up in a web browser, you'll see a page with a search bar, and "Crate lib" at the-top, with no contents. There's two problems with this: first, why does it+top, with no contents. ++## Configuring rustdoc++There's two problems with this: first, why does it

I agree, I'll re-read it looking for more of these.

AndyGauge

comment created time in 2 months

PullRequestReviewEvent

Pull request review commentrust-lang/rust

75521 rustdoc book improvements

 # How to write documentation +Good documentation is not natural.  There are opposing forces that make good+documentation difficult.  It requires expertise in the subject but also+requires writing to a novice perspective.  Documentation therefore often +glazes over implementation detail, or leaves an explain like I'm 5 response.

I guess its a reddit idiom. I'll use natural langauge

AndyGauge

comment created time in 2 months

PullRequestReviewEvent

issue commentrust-lang/rust

Improve "visibility" of rustdoc books ("stable" and unstable ones)

I'm going to try to implement this.

GuillaumeGomez

comment created time in 2 months

PR opened rust-lang/rust

75521 rustdoc book improvements

Added some guidelines about documenting with rustdoc

+269 -22

0 comment

5 changed files

pr created time in 2 months

push eventAndyGauge/rust

Andrew Gauger

commit sha a72f297ba8be01c93cf83c4784fed49b8477d753

introducing writing documentation added front page sample component documentation Added reference and include chapters

view details

push time in 2 months

push eventAndyGauge/rust

Andrew Gauger

commit sha 8317bad69c9cbf6cd5349759d33a4fc643101b06

Added reference and include chapters

view details

push time in 2 months

create barnchAndyGauge/rust

branch : gh-pages

created branch time in 2 months

push eventAndyGauge/rust

Andrew Gauger

commit sha bdece583bf9ffa8e6813c15efd34f312e5618961

component documentation

view details

push time in 2 months

push eventAndyGauge/rust

Andrew Gauger

commit sha 58b019f7b5302d3467ebd185b99f7fd8e2b4b64b

added front page sample

view details

push time in 2 months

issue commentrust-lang/rust

Add more content into rustdoc book

Got started today on this. Here's a bit of the work: https://github.com/AndyGauge/rust/pull/1 Is it in the right direction?

GuillaumeGomez

comment created time in 2 months

more