Merge pull request #4259 from supercollider/master

master -> develop
supercollider · Jan 19, 2019 · ed3f9f1 · ed3f9f1
2 parents bf30889 + 8597bef
commit ed3f9f1
Show file tree

Hide file tree

Showing 6 changed files with 71 additions and 18 deletions.
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -13,10 +13,12 @@ Release dates of 3.x versions:
 - 3.9: 2018-01-13
 - 3.10: 2018-11-24
 
-3.10.1-rc1 (2019-01-13)
-=======================
+3.10.1 (2019-01-17)
+===================
 
-Fixed an infinite hang in `SerialPort.devices` affecting macOS ([#4180](https://github.com/supercollider/supercollider/pull/4180)). **Testers:** the correctness of this fix is not fully certain, please try `SerialPort.devices` if you are on macOS.
+Fixed an infinite hang in `SerialPort.devices` affecting macOS ([#4180](https://github.com/supercollider/supercollider/pull/4180)).
+
+Fixed `ServerOptions` producing eight channels instead of two channels when explicitly setting `numOutputBusChannels` or `numInputBusChannels` ([#4251](https://github.com/supercollider/supercollider/pull/4251)).
 
 Fixed a build issue on OpenBSD ([#4203](https://github.com/supercollider/supercollider/pull/4203)).
 

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -67,10 +67,9 @@ When an issue involves a crashing or unresponsive executable and you don't know
 
 	- If you have created the fork before, bring it up-to-date with the SuperCollider repository. See [Updating your fork](#Updating-your-fork) below for details.
 - Create a topic branch from where you want to base your work.
-	- Your topic branch should be based on `develop`.
+	- Your topic branch should be based on `develop`, unless it is a trivial bug fix or documentation change, in which case it should be based on the latest release (`3.x`) branch.
 	- Our branch naming convention is `topic/branch-description`: for example, `topic/fix-sinosc` or `topic/document-object`.
 	- To quickly create a topic branch based on develop: `git checkout -b topic/my-fix develop`.
-	- Please avoid working directly on the `develop` branch.
 	- Please do not work off of the `master` branch, which is stable and only includes releases.
 - As time passes, make sure to keep your fork updated - see [Updating your fork](#Updating-your-fork) below.
 
@@ -133,13 +132,31 @@ In order to keep your fork up-to-date, you need to point it to the main SuperCol
 	- If you've already created your topic branch, you can update it with the changes in `develop` by either rebasing or pulling - see [Notes on rebasing](#Notes-on-rebasing).
 	- If you haven't yet created your topic branch, proceed to creating it as described in the [Pull Requests](#Pull-Requests) section.
 
-### Notes on rebasing
+### Notes on rebasing and merge conflicts
 
-Rebasing is one way to integrate changes from one branch onto another, in this case `develop` onto your `topic/branch-description`. You don't usually need to `rebase` unless there have been changes to the code you're working on in `upstream/develop`. If you need to rebase, use `git rebase develop topic/branch-description`. Note that if you rebase after already having pushed your branch, it will make your local branch diverge from the remote `origin` copy. In that case you have two options:
-- rebase, after which you'll need to force push: `git checkout topic/branch-description` followed by `git push origin -f`
-	- This will change the commit history and is not recommended if there is more than one person working on the branch; however, it will create a clean commit history with only your commits in the pull request.
-- don't rebase, but instead `git checkout topic/branch-description`, then `git pull`, followed by `git push origin`
-	- The result will be that your pull request will include your commits in addition to all other commits to `develop` since your branch was created (without changing the commit history).
+It is almost never a good idea to resolve merge conflicts via the GitHub interface or by merging the main branch in locally. This creates noise in commit history and makes it more difficult to perform other operations on branches later. In the SuperCollider project, the preferred way to resolve merge conflicts in a pull request is by rebasing.
+
+See `git help rebase` for `rebase` usage examples that include graphical representations.
+
+Rebasing (`git help rebase`) is a very useful command for four scenarios in particular:
+
+1. If you'd like to incorporate new commits on the base branch that contain relevant fixes or
+   features into your topic branch.
+2. If you'd like to resolve merge conflicts.
+3. If you'd like to change the branch your topic branch is based on. This may happen if, for instance, a maintainer requests that you make your bug fix merge request against a release branch (e.g. 3.9, 3.10) instead of develop. You will then need to rebase your topic branch onto the appropriate release branch.
+4. If you'd like to rewrite your commit history by combining or reordering some commits (not recommended for those newer to git).
+
+Rebase has an interactive mode (`git rebase -i`) which will show exactly which commits will be applied to the new base, and the order in which they will be applied. This can be very helpful when you're not completely sure what the result of a rebase will be.
+
+For scenarios (1) and (2), suppose that the current branch is `topic`, which is based on an old commit from the `develop` branch. To rebase, you can execute `git rebase -i develop`. You can examine the change list to make sure it's correct before continuing. Git will stop if it encounters a merge conflict, and give instructions on how to resolve it and continue the rebase.
+
+For scenario (3), suppose that there are three branches: `develop`, the release branch `3.10`, and the topic branch `topic` which is based on `develop`. Suppose that `topic` is currently checked out.  You would like it to be based on `3.10` instead of `develop`. An easy way to do this is with `git rebase -i --onto 3.10 develop topic`. Beware that you may need to resolve merge conflicts during this rebase.
+
+After rebasing, you may find it helpful to display the pretty-printed commit log with `git log --oneline --graph --decorate` to make sure all is well.
+
+In any case, after rebasing your local branch will now be out of sync with your remote branch. You will have to resolve this by force pushing: `git push --force origin topic`. If you realize later that you made a mistake with your rebase, it's always possible to go back to your previous local state using `git reflog`.
+
+For scenario (4), `git help rebase`'s section "Interactive mode" has extensive documentation on how to reorder and recombine commits. Also refer to the section on `--autosquash` for ideas on how to combine these features into a streamlined rebase-oriented workflow.
 
 ## Generating a crash report
 

diff --git a/SCClassLibrary/Common/Control/Server.sc b/SCClassLibrary/Common/Control/Server.sc
@@ -130,10 +130,12 @@ ServerOptions {
 			numControlBusChannels = numControlBusChannels.asInteger;
 			o = o ++ " -c " ++ numControlBusChannels;
 		});
-		if (numInputBusChannels != defaultValues[\numInputBusChannels], {
+		// scsynth and supernova default to 8 input channels
+		if (numInputBusChannels != 8, {
 			o = o ++ " -i " ++ numInputBusChannels;
 		});
-		if (numOutputBusChannels != defaultValues[\numOutputBusChannels], {
+		// scsynth and supernova default to 8 output channels
+		if (numOutputBusChannels != 8, {
 			o = o ++ " -o " ++ numOutputBusChannels;
 		});
 		if (numBuffers !== defaultValues[\numBuffers], {

diff --git a/SCVersion.txt b/SCVersion.txt
@@ -3,7 +3,7 @@
 
 set(PROJECT_VERSION_MAJOR 3)
 set(PROJECT_VERSION_MINOR 10)
-set(PROJECT_VERSION_PATCH .1-rc1)
+set(PROJECT_VERSION_PATCH .1)
 
 if(EXISTS "${CMAKE_SOURCE_DIR}/.git")
 

diff --git a/common/SC_Filesystem_macos.cpp b/common/SC_Filesystem_macos.cpp
@@ -43,6 +43,8 @@
 #include <glob.h> // ::glob, glob_t
 #include <mach-o/dyld.h> // _NSGetExecutablePath
 
+#include <algorithm> // std::mismatch
+
 using Path = SC_Filesystem::Path;
 using DirName = SC_Filesystem::DirName;
 using DirMap = SC_Filesystem::DirMap;
@@ -72,7 +74,7 @@ Path SC_Filesystem::resolveIfAlias(const Path& p, bool& isAlias)
 		// Previously, used bookmarkDataWithContentsOfURL. But for some reason, the call would hang
 		// endlessly on certain files (e.g. /dev/auditsessions with mode crw-r--r--). So, we do the
 		// less reliable thing and try to resolve it forcefully. If it is an alias, the resulting
-		// path will be different. See issue #4131.
+		// path will be different (not always true, see below). See issue #4131.
 		NSURL* resolvedURL = [NSURL URLByResolvingAliasFileAtURL: aliasURL
                                     options: NSURLBookmarkResolutionWithoutMounting | NSURLBookmarkResolutionWithoutUI
                                     error: &error];
@@ -94,9 +96,18 @@ Path SC_Filesystem::resolveIfAlias(const Path& p, bool& isAlias)
 			return Path();
 		}
 
-		auto resolvedPath = Path(resolvedNsPath);
-		isAlias = resolvedPath != p;
-		return resolvedPath;
+		// #4252 - URLByResolvingAliasFileAtURL will remove last trailing slash ('/Users/' ->
+		// '/Users', '/Users///' -> '/Users//'). Protect against this case.
+		auto * pEnd = p.c_str() + p.size();
+		const auto * mismatchPos = std::mismatch(p.c_str(), pEnd, resolvedNsPath).first;
+		// note that p.size() >= 1 because empty string would fail 'fileExistsAtPath'
+		if (mismatchPos == pEnd || (mismatchPos == pEnd - 1 && *mismatchPos == '/')) {
+			isAlias = false;
+			return p;
+		} else {
+			isAlias = true;
+			return Path(resolvedNsPath);
+		}
 	}
 
 	isAlias = false;

diff --git a/testsuite/classlibrary/TestString.sc b/testsuite/classlibrary/TestString.sc
@@ -94,6 +94,27 @@ TestString : UnitTest {
 		this.assertEquals("dir" +/+ 'file', "dir%file".format(sep));
 	}
 
+	// regression tests for #4252
+	test_standardizePath_withTrailingSlash_shouldNotRemove {
+		var result = "~/".standardizePath;
+		var expected = "~".standardizePath ++ "/";
+		this.assertEquals(result, expected);
+	}
+
+	test_standardizePath_withTwoTrailingSlashes_shouldNotRemove {
+		var result = "~//".standardizePath;
+		var expected = "~".standardizePath ++ "//";
+		this.assertEquals(result, expected);
+	}
+
+	test_standardizePath_tilde_expandsToHome {
+		var result = "~".standardizePath;
+		var expected = Platform.userHomeDir;
+		this.assertEquals(result, expected);
+	}
+
+	// ------- time-related operations -----------------------------------------------
+
 	test_asSecs_stringDddHhMmSsSss_convertsToSeconds {
 		var result = "001:01:01:01.001".asSecs;
 		var expected = 90061.001;