What is Boost.Sync and why doesn't its repository have a master branch? -- Eric Niebler Boost.org http://www.boost.org
On Tuesday 14 January 2014 22:19:19 Eric Niebler wrote:
What is Boost.Sync and why doesn't its repository have a master branch?
That library is a split of Boost.Thread that only contains synchronization primitives. It's in an early development stage and not yet released, that's why it has no master.
On Wed, Jan 15, 2014 at 3:07 AM, Andrey Semashev <andrey.semashev@gmail.com>wrote:
On Tuesday 14 January 2014 22:19:19 Eric Niebler wrote:
What is Boost.Sync and why doesn't its repository have a master branch?
That library is a split of Boost.Thread that only contains synchronization primitives. It's in an early development stage and not yet released, that's why it has no master.
If it is an "early development stage", why is it in boostorg at all? Seems like it should be in the developer's own GitHub account. --Beman
What is Boost.Sync and why doesn't its repository have a master branch?
That library is a split of Boost.Thread that only contains synchronization primitives. It's in an early development stage and not yet released, that's why it has no master.
If it is an "early development stage", why is it in boostorg at all? Seems like it should be in the developer's own GitHub account.
it was in trunk, but not in release. therefore it has a develop branch, but no master. compare [1]. the functionality is not exactly new, but broken out of boost.thread with some additions. tim [1] http://thread.gmane.org/gmane.comp.lib.boost.devel/243511
On 1/15/2014 6:10 AM, Tim Blechmann wrote:
What is Boost.Sync and why doesn't its repository have a master branch?
That library is a split of Boost.Thread that only contains synchronization primitives. It's in an early development stage and not yet released, that's why it has no master.
If it is an "early development stage", why is it in boostorg at all? Seems like it should be in the developer's own GitHub account.
it was in trunk, but not in release. therefore it has a develop branch, but no master. compare [1]. the functionality is not exactly new, but broken out of boost.thread with some additions.
tim
[1] http://thread.gmane.org/gmane.comp.lib.boost.devel/243511
Can you please explain the purpose of splitting these libraries? The only reason given in that discussion is, "For example, one of the benefits I'd like to achieve with this is that synchronization primitives should become decoupled from the timing libraries.": Why is that desirable? Is that it? As a practical matter, the sync repo should not be in boostorg until it has a master branch. I discovered this anomaly by trying to check out every repo in the master branch with this git command:
git submodule foreach git checkout master
That command fails today because of sync. -- Eric Niebler Boost.org http://www.boost.org
What is Boost.Sync and why doesn't its repository have a master branch?
That library is a split of Boost.Thread that only contains synchronization primitives. It's in an early development stage and not yet released, that's why it has no master.
If it is an "early development stage", why is it in boostorg at all? Seems like it should be in the developer's own GitHub account.
it was in trunk, but not in release. therefore it has a develop branch, but no master. compare [1]. the functionality is not exactly new, but broken out of boost.thread with some additions.
tim
[1] http://thread.gmane.org/gmane.comp.lib.boost.devel/243511
Can you please explain the purpose of splitting these libraries? The only reason given in that discussion is, "For example, one of the benefits I'd like to achieve with this is that synchronization primitives should become decoupled from the timing libraries.":
Why is that desirable? Is that it?
one of the starting points for this library was the aim to unify some duplicate functionality. e.g. log, smart_ptr and atomic require spinlock implementations. personally, i'm maintaining spin-lock & semaphore implementations for 2 different projects. log contains an implementation of win32 events, i was submitting a patch for semaphores for boost.thread. one idea was to place these classes into boost.thread, though andrey, vicente and me had some discussions last summer and vicente proposed to move the synchronization primitives out of boost.thread into a boost.sync library. one of the reasons was also to have a lightweight library, (almost) header-only. there are arguments for and against having a separate boost.sync library or to have this functionality. personally i don't care at all, because it seems like a lovely source for a bikeshed discussion.
As a practical matter, the sync repo should not be in boostorg until it has a master branch. I discovered this anomaly by trying to check out every repo in the master branch with this git command:
iirc there used to be libraries in the past, which had been in trunk, but not in release.
git submodule foreach git checkout master
That command fails today because of sync.
iff you initialized the root project with the develop branch. but you will *always* run into troubles if you have a git repository with different branches if some branches contain a submodule which others don't. boost's use of submodules is a bit controversial anyway, but that's another discussion (one that i really don't want to start) cheers, tim
As a practical matter, the sync repo should not be in boostorg until it has a master branch. I discovered this anomaly by trying to check out every repo in the master branch with this git command:
iirc there used to be libraries in the past, which had been in trunk, but not in release.
Irrespective of whether a Boost.Synch spin-out is a good idea (sounds like it, but I don't know the details), any new library added to Boost, but not yet released will be in develop but not master (or at least master will be empty). Maybe the issue here is a transitional one due to the conversion - shouldn't synch be in master, albeit the directory will be empty? Perhaps creating an empty master branch would be a temporary fix - or would that mess up the release procedure? Whatever we need to figure out the right thing to do here so we know what happens when new libs are added, John.
On 15 January 2014 17:08, Eric Niebler <eniebler@boost.org> wrote:
As a practical matter, the sync repo should not be in boostorg until it has a master branch.
That's how the conversion set things up.
I discovered this anomaly by trying to check out every repo in the master branch with this git command:
git submodule foreach git checkout master
That command fails today because of sync.
It shouldn't, sync isn't a submodule of the master branch. Try using 'git submodule update --init'.
I discovered this anomaly by trying to check out every repo in the master branch with this git command:
git submodule foreach git checkout master
That command fails today because of sync.
It shouldn't, sync isn't a submodule of the master branch. Try using 'git submodule update --init'.
not sure if this will work: especially a user could have modifications to the submodule, but re-initializing all submodules to the state that the supermodule expects will require git to remove the submodule. i'm pretty sure that git will not like (read reject) this. in my personal experience, git submodules are references that one rarely wants to change and never wants to remove from the working copy, though the situation may have improved these days. an empty master branch may be a workaround, though. tim
On 01/15/2014 10:57 AM, Tim Blechmann wrote:
I discovered this anomaly by trying to check out every repo in the master branch with this git command:
git submodule foreach git checkout master
That command fails today because of sync.
It shouldn't, sync isn't a submodule of the master branch. Try using 'git submodule update --init'.
not sure if this will work: especially a user could have modifications to the submodule, but re-initializing all submodules to the state that the supermodule expects will require git to remove the submodule. i'm pretty sure that git will not like (read reject) this.
in my personal experience, git submodules are references that one rarely wants to change and never wants to remove from the working copy, though the situation may have improved these days.
an empty master branch may be a workaround, though.
This is probably now a discussion about best practices wrt testing modularized boost, but I want to test my libraries against what will comprise the next official boost release. To me, that suggests checking out develop on the super-project and master on all sub-projects. Have I got that all wrong? I admit to being a bit of a n00b here. Eric
Hi Eric, On Wednesday, 15. January 2014 11:21:50 Eric Niebler wrote:
On 01/15/2014 10:57 AM, Tim Blechmann wrote:
I discovered this anomaly by trying to check out
every repo in the master branch with this git command:
git submodule foreach git checkout master
Try git submodule foreach "git checkout master ||:" as this will simply skip the offending submodules. The "||:" also works for rebase etc.
This is probably now a discussion about best practices wrt testing modularized boost, but I want to test my libraries against what will comprise the next official boost release. To me, that suggests checking out develop on the super-project and master on all sub-projects. Have I got that all wrong? I admit to being a bit of a n00b here.
Well, I would checkout "master" on the super-project (as this contains what will be released, without "sync" in this case) and on all sub-projects. You most probably need to run "git submodule update --init" in this case. Then checkout "develop" on all the project that you want to compile against master. Note: completely untested :-) Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany
On 15 January 2014 19:38, Jürgen Hunold <jhunold@gmx.eu> wrote:
On Wednesday, 15. January 2014 11:21:50 Eric Niebler wrote:
This is probably now a discussion about best practices wrt testing modularized boost, but I want to test my libraries against what will comprise the next official boost release. To me, that suggests checking out develop on the super-project and master on all sub-projects. Have I got that all wrong? I admit to being a bit of a n00b here.
Well, I would checkout "master" on the super-project (as this contains what will be released, without "sync" in this case) and on all sub-projects. You most probably need to run "git submodule update --init" in this case. Then checkout "develop" on all the project that you want to compile against master.
I think that's right. It's a bit confusing, as there is a proposal to change the branches on the super project: https://svn.boost.org/trac/boost/wiki/SuperProjectWorkflow If we make that change, then 'develop' will be the branch to use - it'll be what 'master' currently is. But I doubt that it will happen until after the testing is ready.
On Wed, Jan 15, 2014 at 9:08 PM, Eric Niebler <eniebler@boost.org> wrote:
On 1/15/2014 6:10 AM, Tim Blechmann wrote:
What is Boost.Sync and why doesn't its repository have a master branch?
That library is a split of Boost.Thread that only contains synchronization primitives. It's in an early development stage and not yet released, that's why it has no master.
If it is an "early development stage", why is it in boostorg at all? Seems like it should be in the developer's own GitHub account.
it was in trunk, but not in release. therefore it has a develop branch, but no master. compare [1]. the functionality is not exactly new, but broken out of boost.thread with some additions.
tim
[1] http://thread.gmane.org/gmane.comp.lib.boost.devel/243511
Can you please explain the purpose of splitting these libraries? The only reason given in that discussion is, "For example, one of the benefits I'd like to achieve with this is that synchronization primitives should become decoupled from the timing libraries.":
Why is that desirable? Is that it?
Tim has already answered. I'll just mention that decoupling from the time units is desirable because (a) in many cases you don't need time units with synchronization yet you still introduce dependency on Boost.Chrono and Boost.DateTime and (b) there is no way to use use e.g. std::chrono with Boost.Thread without manually converting to Boost time units.
On 01/15/2014 02:06 PM, Andrey Semashev wrote:
... decoupling from the time units is desirable because (a) in many cases you don't need time units with synchronization yet you still introduce dependency on Boost.Chrono and Boost.DateTime
But in many cases you *do* care about time (e.g. wait with a time-out). How will you present a unified, consistent interface when you can't express some fundamental operations?
and (b) there is no way to use use e.g. std::chrono with Boost.Thread without manually converting to Boost time units.
This sounds like a failure of generic design to me. There should be a Duration concept, and the APIs should work with any concrete type that models that concept. That would also solve the dependency problem, since the actual concrete types don't need to be mentioned. Eric
On Thu, Jan 16, 2014 at 8:50 PM, Eric Niebler <eniebler@boost.org> wrote:
On 01/15/2014 02:06 PM, Andrey Semashev wrote:
... decoupling from the time units is desirable because (a) in many cases you don't need time units with synchronization yet you still introduce dependency on Boost.Chrono and Boost.DateTime
But in many cases you *do* care about time (e.g. wait with a time-out).
Yes, but why should these cases impose a mandatory dependency? I don't want to pay for that when e.g. I just need a mutex to synchronize access.
How will you present a unified, consistent interface when you can't express some fundamental operations?
and (b) there is no way to use use e.g. std::chrono with Boost.Thread without manually converting to Boost time units.
This sounds like a failure of generic design to me. There should be a Duration concept, and the APIs should work with any concrete type that models that concept. That would also solve the dependency problem, since the actual concrete types don't need to be mentioned.
It's a little more complicated than that because Boost.DateTime and Boost.Chrono implement different interfaces (as well as Boost.Thread wrt different time units). But basically, that's what "decoupling" means and what Boost.Sync does.
participants (7)
-
Andrey Semashev -
Beman Dawes -
Daniel James -
Eric Niebler -
John Maddock -
Jürgen Hunold -
Tim Blechmann