[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-dev] call-backs, co-routines and inversion of control
- To: "sc-dev@xxxxxxxxxxxxxxxx" <sc-dev@xxxxxxxxxxxxxxxx>
- Subject: Re: [sc-dev] call-backs, co-routines and inversion of control
- From: Jonatan Liljedahl <lijon@xxxxxxxxxxxx>
- Date: Fri, 11 Jan 2013 12:10:33 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=p+3Kp+BHTB8be7d0g4G20gRwS2r2f/7tUBklD0R9zSs=; b=obofYpRD8cIq1M9EzrdspZoUwGRcbxPksPJ6y17jSfOVPN/mMnoMBt5A5Fvo/xYR+o gJ2pnIBgs2yRS6n1ElHOf9soORuMeQAV8+4WrPl+ZE75U5PnGSCPNZhqurXX3xe+hUtf 2hRrdnK6bTIQ4KrkMQMu+tVDwKZgBE8DZkwCCjm9ufowCnNerN0KfHts5j5nmjxZm42u QGbNHxg/mOk7ajZbTcMukJq+2W3fFZrhGit6bjK249dnru3CaDCqAzE+22fi5hxNOwQD g7+hFhQsqt6I1fDLEgMe6wIEH/2Xov38S5lMlWPzLkIJrGqh5ICNqBxYfG/vKTiPKoBZ jcgQ==
- In-reply-to: <319B9529-0791-40E3-A96D-281311DE84A1@musikundmedien.net>
- List-id: SuperCollider developers mailing list <sc-devel.create.ucsb.edu>
- References: <778221C9-492A-4DB9-BA09-EB1DEEAECB49@friendlyvirus.org> <50ABBC37.firstname.lastname@example.org> <A145DF2F-0446-498D-86EE-E5A8C9D7582E@bham.ac.uk> <1F4DC433-1998-48B1-BF7D-B139E2E6A88E@musikundmedien.net> <CALfiFhD_XXFG62jVvHE9D4wdKviZ8NMjXSdB1+7Sh8k+qfU5Jg@mail.gmail.com> <0D25C620-C6F3-4FA0-9386-F643B48B87E0@musikundmedien.net> <6970E904-41EB-4F4B-976F-7B8B25930B10@friendlyvirus.org> <2901865F-E435-4187-9EE8-88649F84CADA@musikundmedien.net> <CAFniQ7W4kKUsgmR1KwB+VL9O=LGB__wM2UgW=CP56QLB-9BhbQ@mail.gmail.com> <97E72E9E-6576-49D4-A51E-12C58EAA6B6F@musikundmedien.net> <CAFniQ7XbX_tuMVs7Oc1dKGy6aM8KotXYbY_3nPg=cfX3_XCJPQ@mail.gmail.com> <C3DC6B65-7432-4F81-97EB-DCDAF0D92EC8@musikundmedien.net> <79E883CF-EBAF-41BF-BC17-75146B15A206@friendlyvirus.org> <E3730DCA-1B98-42DF-AFA0-6FF6084D2436@musikundmedien.net> <E0FCBEE0-D9BF-4656-963C-5E3EA9E20045@musikundmedien.net> <1C65DD7F-62FC-4374-8F58-592533FC2880@friendlyvirus.org> <9F3E5205-3976-4A5D-946A-58BF3317E230@friendlyvirus.org> <CALfiFhDfmg_kvQ3G+6NNwR56qyOfmhyE5oYiWLqNpYrCLJmp_Q@mail.gmail.com> <319B9529-0791-40E3-A96D-281311DE84A1@musikundmedien.net>
- Reply-to: sc-dev@xxxxxxxxxxxxxxxx
- Sender: owner-sc-dev@xxxxxxxxxxxxxxxx
Well, if s.bind changes to always synching at the end, and it didn't
before, then it's a change in behavior that might break peoples code.
I haven't studied the code or your patch in detail so I don't really
know if this is the case or not.
However, using branches or keeping track of them are not hard.
git branch - shows a list of your branches
git checkout <the_branch> - switch to the branch
Anyone interested in this particular feature would check out the
branch while developing it into finished state, then people can test
it, then it can be merged back into master. Another good thing with
this approach is that the merge back can be compressed into one or a
few commits, instead of having half-finished work spread out over
multiple commits, making it hard to backtrack in case of discovered
bugs or regressions, etc.
On Fri, Jan 11, 2013 at 11:53 AM, Julian Rohrhuber
> On 08.01.2013, at 10:52, Jonatan Liljedahl <lijon@xxxxxxxxxxxx> wrote:
>> On Tue, Jan 8, 2013 at 12:59 AM, Miguel Negrao
>> <miguel.negrao-lists@xxxxxxxxxxxxxxxxx> wrote:
>>> A 06/01/2013, às 22:37, Julian Rohrhuber escreveu:
>>>> I still have those commits sitting around which would arguably make a good first step for a later more thorough implementation of this behaviour. I'd like to either push it or throw it away, because later on it will become useless - any suggestions? It currently mainly lacks an appropriately differentiated latency implementation (but this is the case with the current s.bind, too, so it doesn't take anything away.
>>>> For reference, here is the patch.
>>> I think it would be a good idea to commit this, because it already allows to have completely automatic syncing for the end user. The only issue perhaps is that it will not keep the old behavior of the the bind method, since it will always sync on each async action, but from what I was told, all the async actions are run in sequence in the server anyway, so it doesn’t make much difference perhaps.
>> But wouldn't that make a difference in the sclang context? If s.bind
>> now always syncs at the end, and previously did not? One might want to
>> send a bundle, do some langside stuff while the server is working, and
>> only then wait on a sync.
>> I haven't studied the code and don't know exactly what changes here,
>> but if indeed the behavior of s.bind/makeBundle is changed in this
>> regard, then I really think you should put it in a topic branch.
> The changes are not very intrusive, because already now the implementation of s.bind is very reductive (i.e. ignores timing etc.).
>> way we can test it more, experiment with it and develop it without
>> risk for introducing regressions in the master branch.
> While this is certainly the correct procedure in principle, I don't think that many of us would actually use this branch. I am still not using branches myself, simply because I'm not in the position to keep track of them. I suppose it would just hang there and dry out.
> sc-dev mailing list
> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: https://listarc.bham.ac.uk/marchives/sc-dev/
> search: https://listarc.bham.ac.uk/lists/sc-dev/search/
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml