See https://github.com/spf13/hugo/releases
What a pleasant surprise indeed!
How come I have never noticed them before?
And even `.deb` files are provided! How amazing!
Quote from @spf13: "I also think it's the better default
and should continue to be the case going forward."
Also mention the use of `hugo config` to check the current value
of `canonifyurls`, thanks to suggestion by @bep.
Fixes#802
- Clarify that Hugo may be built wherever Go is available;
- Add links to Git, Mercurial and Go;
- Unlist Bazaar: No libraries that Hugo depends on use it any more;
- Suggest the user to simply run `make` to build `hugo`
to get `hugo version` to display the commit hash.
Make sure that the file separator is added to the temp dir in all cases.
This prevents cache temp files being written to the root temp folder.
Fixes#910
Temporary workaround for the bug fix and resulting
behavioral change in purell.NormalizeURLString():
a leading '/' was inadvertently to relative links,
but no longer, see #878.
I think the real solution is to allow Hugo to
make relative URL with relative path,
e.g. "../../post/hello-again/", as wished by users
in issues #157, #622, etc., without forcing
relative URLs to begin with '/'.
Once the fixes are in, let's remove this kludge
and restore SanitizeUrl() to the way it was.
Fixes#878
Rationale: Test failing on Windows with errors like this:
utils_test.go:177: Error: Could not remove file "f".
Error: remove C:\Users\appveyor\AppData\Local\Temp\utils_test_747965610:
The process cannot access the file because it is being used by another
process.
This reverts commit 6b28e38cea.
Sorry for my premature merge of Pull Request #818.
And looks even faster:
Compared to previous attempt:
benchmark old ns/op new ns/op delta
BenchmarkAbsUrl 30902 27206 -11.96%
BenchmarkXmlAbsUrl 15389 14216 -7.62%
benchmark old allocs new allocs delta
BenchmarkAbsUrl 33 28 -15.15%
BenchmarkXmlAbsUrl 16 14 -12.50%
benchmark old bytes new bytes delta
BenchmarkAbsUrl 4167 3504 -15.91%
BenchmarkXmlAbsUrl 2057 2048 -0.44%
Compared to before I started all of this:
benchmark old ns/op new ns/op delta
BenchmarkAbsUrl 36219 27206 -24.88%
BenchmarkXmlAbsUrl 23903 14216 -40.53%
benchmark old allocs new allocs delta
BenchmarkAbsUrl 60 28 -53.33%
BenchmarkXmlAbsUrl 30 14 -53.33%
benchmark old bytes new bytes delta
BenchmarkAbsUrl 5842 3504 -40.02%
BenchmarkXmlAbsUrl 3754 2048 -45.44%
Fixes#816
This commit expands the test coverage for the utils/utils.go module.
The utils module uses the 'github.com/spf13/jwalterweatherman' (aka jww)
package for logging. The tests take the approach of examining the log
file that is produced by this module to verify correct behaviour. This
avoids refactoring the utils module.
The log file messages written by the jww module are of the form:
<log level>: yyyy/mm/dd <string|error message>
The checkLogFile function checks each of these parts in turn except for
the date string, which is currently ignored. The final part of the log
file format can either be a single error message, or a series of
strings followed by an error message. Both the error message and the
series of strings can be empty strings.
The log file is checked using a combination of the regex package,
along with the bufio scanner type. Each test logs to its own temporary
log file. This is achieved with standard test setup and teardown
functions.
One consequence of these tests is that StopOnErr has been refactored
into call a new unexported function doStopOnErr which contains the bulk
of the original logic. This allows the same testing approach to be used
with StopOnErr as with CheckErr and cutUsageMessage, rather than look at
the exit status code of the test itself.
An unfortunate side effect of this is that the author of the tests must
now know if a log file is expected or not. If doStopOnErr determines
that an empty error message would be written to the log file then
nothing is written. In the context of the tests this means that the log
file created by the test would have no contents. Consequently there
would be nothing for the test to examine. This situation is indicated by
the boolean flag logFileExoected in the testData struct, and processed
by the logFileIsExpectedAndValid function.
Although not ideal this was deemed a reasonable compromise.
Some variables are currently not documented and others are explained
across the document. So, I tried to pull an overview from the source.
Pls double check. I am not 100% sure, what the purpose of some variables
is or whether they are only relevant for previous versions. Thanks
