linting & documentation

Updated versioning and dates for release.

CHANGELOG.md

@@ -13,7 +13,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 > - **Fixed**: for any bug fixes.
 > - **Security**: in case of vulnerabilities.
 
-## [4.0.0] 2020-06-07 (PENDING)
+## [4.0.0] 2020-06-07
 
 **Command line options have changed.**
 
@@ -62,6 +62,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Compile errors on FreeBSD due to golang.org/x/sys API breakages
 - Key bindings now work in FreeBSD (#95)
 - Only report battery sensor errors once (reduce noise in the log, #117)
+- Fixes a very small memory leak from the spark and histograph widgets (#128)
 
 ## [3.5.3] - 2020-05-30
 

README.md

@@ -12,7 +12,7 @@ Join us in [\#gotop:matrix.org](https://riot.im/app/#/room/#gotop:matrix.org) ([
 ![](https://github.com/xxxserxxx/gotop/workflows/Build%20Go%20binaries/badge.svg)
 ![](https://github.com/xxxserxxx/gotop/workflows/Create%20pre-release/badge.svg)
 
-![](https://raw.githubusercontent.com/xxxserxxx/gotop/master/docs/release.svg)
+<div align="center">Current release: <a href="https://github.com/xxxserxxx/gotop/releases/tag/v4.0.0">v4.0.0</a></div>
 
 See the [mini-blog](https://github.com/xxxserxxx/gotop/wiki/Micro-Blog) for updates on the build status, and the [change log](/CHANGELOG.md) for release updates.
 
@@ -135,9 +135,9 @@ I obviously think gotop is the Bee's Knees, but there are many alternatives. Man
 
 ### A comment on clones
 
-In a chat room I heard someone refer to gotop as "another one of those fancy language rewrites people do."  I'm not the original author of gotop, so it's easy to not take offense, but I'm going on record as saying that I think these are valuable and useful. They increase software diversity at very little cost, and are a sort of evolutionary mechanism: as people do rewrites, some are worse, but some are better, and users benefit.  As importantly, most developers are really only fluent in a couple of programming languages. We all have *familiarity* with a dozen, and may even have extensive experience with a half-dozen, but if you don't constantly use a language, you start to forget the extended library APIs, your development environment isn't tuned, you're rusty with using the tool sets, and you may have forgotten a lot of the language peculiarities and gotchas. The barrier to entry for contributing to a software project -- to just finding and fixing a bug -- in a language you're not intimate with can be very high. It gets much worse if the project owner is a stickler for quality and style.  So the original gotop author's decision to rewrite his project in Rust is a great thing. He probably made fewer design mistakes in ytop (we always do, on the second rewrite), and Rust developers -- who may have hesitated learning or brushing up on Go to submit an improvement -- have another project to which they can contribute.
+In a chat room I heard someone refer to gotop as "another one of those fancy language rewrites people do."  I'm not the original author of gotop, so it's easy to not take offense, but I'm going on record as saying that I disagree with that sentiment: I think these rewrites are valuable, useful, and healthy to the community. They increase software diversity at very little [cost to users](https://en.wikipedia.org/wiki/Information_overload), and are a sort of evolutionary mechanism: as people do rewrites, some are worse, but some are better, and users benefit.  Rewrites provide options, which fight against [monocultures](https://github.com). As importantly, most developers are really only fluent in a couple of programming languages. We all have *familiarity* with a dozen, and may even have extensive experience with a half-dozen, but if you don't constantly use a language, you tend to forget the extended library APIs, your development environment isn't tuned, you're rusty with using the tool sets, and you may have forgotten a lot of the language peculiarities and gotchas. The barrier to entry for contributing to a software project -- to simply finding and fixing a bug -- in a language you're not intimate with can be very high. It gets much worse if the project owner is a stickler for quality and style.  So I believe that gotop's original author's decision to rewrite his project in Rust is a net positive. He probably made fewer design mistakes in ytop (we always do, on the second rewrite), and Rust developers -- who may have hesitated learning or brushing up on Go to submit an improvement -- have another project to which they can contribute.
 
-Diversity is good. Don't knock free stuff.
+Diversity is good. Don't knock the free stuff.
 
 
 ## Stargazers over time

cmd/gotop/main.go

@@ -478,7 +478,7 @@ func getLayout(conf gotop.Config) (io.Reader, error) {
 	}
 }
 
-func runTests(conf gotop.Config) int {
+func runTests(_ gotop.Config) int {
 	fmt.Printf("PASS")
 	return 0
 }

colorschemes/registry.go

@@ -17,6 +17,9 @@ func init() {
 	}
 }
 
+// FromName loads a Colorscheme by name; confDir is used to search
+// directories for a scheme matching the name.  The search order
+// is the same as for config files.
 func FromName(confDir configdir.ConfigDir, c string) (Colorscheme, error) {
 	if cs, ok := registry[c]; ok {
 		return cs, nil

colorschemes/template.go

@@ -1,46 +1,68 @@
 package colorschemes
 
-/*
-	The standard 256 terminal colors are supported.
-
-	-1 = clear
-
-	You can combine a color with 'Bold', 'Underline', or 'Reverse' by using bitwise OR ('|') and the name of the Color.
-	For example, to get Bold red Labels, you would do 'Labels: 2 | Bold'.
-
-	Once you've created a colorscheme, add an entry for it in the `handleColorscheme` function in 'main.go'.
-*/
-
+//revive:disable
 const (
 	Bold int = 1 << (iota + 9)
 	Underline
 	Reverse
 )
 
+//revive:enable
+
+/*
+Colorscheme defines colors and fonts used by TUI elements. The standard
+256 terminal colors are supported.
+
+For int values, -1 = clear
+
+Colors may be combined with 'Bold', 'Underline', or 'Reverse' by using
+bitwise OR ('|') and the name of the Color. For example, to get bold red
+labels, you would use 'Labels: 2 | Bold'
+*/
 type Colorscheme struct {
-	Name   string
+	// Name is the key used to look up the colorscheme, e.g. as provided by the user
+	Name string
+	// Who created the color scheme
 	Author string
 
+	// Foreground color
 	Fg int
+	// Background color
 	Bg int
 
+	// BorderLabel is the color of the widget title label
 	BorderLabel int
-	BorderLine  int
+	// BorderLine is the color of the widget border
+	BorderLine int
 
-	// should add at least 8 here
+	// CPULines define the colors used for the CPU activity graph, in
+	// order, for each core. Should add at least 8 here; they're
+	// selected in order, with wrapping.
 	CPULines []int
 
+	// BattLines define the colors used for the battery history graph.
+	// Should add at least 2; they're selected in order, with wrapping.
 	BattLines []int
 
+	// MemLines define the colors used for the memory histograph.
+	// Should add at least 2 (physical & swap); they're selected in order,
+	// with wrapping.
 	MemLines []int
 
+	// ProcCursor is used as the color for the color bar in the process widget
 	ProcCursor int
 
+	// SparkLine determines the color of the data line in spark graphs
 	Sparkline int
 
+	// DiskBar is the color of the disk gauge bars (currently unused,
+	// as there's no disk gauge widget)
 	DiskBar int
 
-	// colors the temperature number a different color if it's over a certain threshold
-	TempLow  int
+	// TempLow determines the color of the temperature number when it's under
+	// a certain threshold
+	TempLow int
+	// TempHigh determines the color of the temperature number when it's over
+	// a certain threshold
 	TempHigh int
 }

config_test.go

@@ -16,35 +16,22 @@ func TestParse(t *testing.T) {
 		f func(c Config, e error)
 	}{
 		{
-			i: "logdir",
+			i: "graphhorizontalscale",
 			f: func(c Config, e error) {
-				assert.Error(t, e, "invalid config syntax")
+				assert.Error(t, e, "invalid graphhorizontalscale syntax")
 			},
 		},
 		{
-			i: "logdir=foo=bar",
+			i: "helpvisible=true=false",
 			f: func(c Config, e error) {
 				assert.NotNil(t, e)
 			},
 		},
 		{
-			i: "foo=bar",
-			f: func(c Config, e error) {
-				assert.NotNil(t, e)
-			},
-		},
-		{
-			i: "configdir=abc\nlogdir=bar\nlogfile=errors",
-			f: func(c Config, e error) {
-				assert.Nil(t, e, "unexpected error")
-				assert.Equal(t, "abc", c.ConfigDir)
-			},
-		},
-		{
-			i: "CONFIGDIR=abc\nloGdir=bar\nlogFILe=errors",
+			i: "GRAPHHORIZONTALSCALE=1\nhelpVisible=true",
 			f: func(c Config, e error) {
 				assert.Nil(t, e, "unexpected error")
-				assert.Equal(t, "abc", c.ConfigDir)
+				assert.Equal(t, 1, c.GraphHorizontalScale)
 			},
 		},
 		{
@@ -60,14 +47,14 @@ func TestParse(t *testing.T) {
 			},
 		},
 		{
-			i: "helpvisible=true\nupdateinterval=30\naveragecpu=true\nPerCPULoad=true\ntempscale=100\nstatusbar=true\nnetinterface=eth0\nlayout=minimal\nmaxlogsize=200",
+			i: "helpvisible=true\nupdateinterval=30\naveragecpu=true\nPerCPULoad=true\ntempscale=F\nstatusbar=true\nnetinterface=eth0\nlayout=minimal\nmaxlogsize=200",
 			f: func(c Config, e error) {
 				assert.Nil(t, e, "unexpected error")
 				assert.Equal(t, true, c.HelpVisible)
 				assert.Equal(t, time.Duration(30), c.UpdateInterval)
 				assert.Equal(t, true, c.AverageLoad)
 				assert.Equal(t, true, c.PercpuLoad)
-				assert.Equal(t, widgets.TempScale(100), c.TempScale)
+				assert.Equal(t, widgets.TempScale(70), c.TempScale)
 				assert.Equal(t, true, c.Statusbar)
 				assert.Equal(t, "eth0", c.NetInterface)
 				assert.Equal(t, "minimal", c.Layout)
@@ -77,7 +64,7 @@ func TestParse(t *testing.T) {
 	}
 	for _, tc := range tests {
 		in := strings.NewReader(tc.i)
-		c := Config{}
+		c := NewConfig()
 		e := load(in, &c)
 		tc.f(c, e)
 	}

docs/releasing.md

@@ -2,7 +2,6 @@
 
 1. Update Version in main.go 
 2. Update CHANGELOG.md
-3. Update docs/release.svg
 4. Tag
 5. Push everything
 6. When the github workflows complete, finish the draft release and publish.

logging/logging.go

@@ -15,6 +15,10 @@ const (
 	LOGFILE = "errors.log"
 )
 
+// New creates a new logger in the default cache directory; the returned
+// WriteCloser should be closed when the program exits. If an error is
+// encountered during file creation, a nil WriteCloser and appropriate
+// error are returned.
 func New(c gotop.Config) (io.WriteCloser, error) {
 	// create the log directory
 	cache := c.ConfigDir.QueryCacheFolder()

logging/logging_test.go

@@ -2,22 +2,21 @@ package logging
 
 import (
 	"io/ioutil"
-	//"log"
 	"os"
-	"path/filepath"
 	"testing"
 
+	"github.com/shibukawa/configdir"
 	"github.com/stretchr/testify/assert"
-	"github.com/xxxserxxx/gotop/v4"
+	gotop "github.com/xxxserxxx/gotop/v4"
 )
 
 func TestLogging(t *testing.T) {
-	tdn := "testdir"
-	path, err := filepath.Abs(tdn)
+	c := gotop.NewConfig()
+	c.ConfigDir = configdir.New("", "gotoptest")
+	c.MaxLogSize = 300
+	path := c.ConfigDir.QueryCacheFolder().Path
+	var err error
 	defer os.RemoveAll(path)
-	c := gotop.Config{
-		MaxLogSize: 300,
-	}
 	wc, err := New(c)
 	assert.NoError(t, err)
 	if err != nil {

scripts/quality.sh

@@ -0,0 +1,8 @@
+#!/bin/bash
+
+go test -covermode=count -coverprofile=docs/coverage.out ./...
+go tool cover -html=docs/coverage.out -o docs/quality.html
+
+revive -config .revive.toml ./... > docs/lint.txt
+
+abcgo -path . -sort -no-test | sed 's%^/home/ser/workspace/gotop.d/gotop/%%' > docs/abcgo.txt