From 568d1fd5d7795c75cd2dda89aa26190638477cbd Mon Sep 17 00:00:00 2001 From: Michael Kuchnik Date: Mon, 15 Apr 2019 03:25:30 -0400 Subject: [PATCH 1/2] Fix missing parenthesis --- setup.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/setup.py b/setup.py index 8e0d54f..f3293f8 100755 --- a/setup.py +++ b/setup.py @@ -13,4 +13,4 @@ ('/etc/gpsuite.d', ['gpsuite.conf']), ('/usr/share/doc/gptools',['getting-started.txt','RELEASE-gptools','Introduction.pdf']), ('/usr/share/man/man1',['getput.1', 'gpmulti.1', 'gpsuite.1', 'gpsum.1', 'gpwhere.1'])] - + ) From 8c7569d5b729e30f8218c4fb46db08199fbedf49 Mon Sep 17 00:00:00 2001 From: Michael Kuchnik Date: Mon, 15 Apr 2019 03:36:40 -0400 Subject: [PATCH 2/2] Fix manpage typo --- getput.1 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/getput.1 b/getput.1 index 1dfde26..368fccd 100644 --- a/getput.1 +++ b/getput.1 @@ -209,7 +209,7 @@ start of the object as comma separated pairs, noting the first byte is byte 0. When there are multiple puts/gets, the same get-by-range will apply to each object. There is an interesting behavior with ranged GETs and that is when benchmarking -using many processes with which you wish to push swift to its max. IYou can +using many processes with which you wish to push swift to its max. You can easily find yourself in a situation where you can run many more processes for GETs than PUTs since the object being retrieved may be much smaller and therefore able to sustain higher levels of parallelism. Say you created a bunch of 100MB