May 2013 - Boost - lists.preview.boost.org

[Atomic] Rationale for preventing copy construction/assignment?
by Collin Dauphinee 31 May '13

31 May '13

I've recently noticed that boost::atomic<T> prevents assignment from boost::atomic<T>, as well as copy construction. I'm having trouble understanding why this decision was made, as it makes boost::atomic<T> (and classes with a boost::atomic<T> member) very hard to store in containers, and I can't immediately see any safety issues that would be caused by allowing copy operations. What is the rationale for not allowing assignment or copy construction from another boost::atomic<T>?

6 10

Re: [boost] Git Modularization Review no vote heads-up
by "Jürgen Hunold" 30 May '13

30 May '13

Hi Dave, > Gesendet: Donnerstag, 23. Mai 2013 um 07:28 Uhr > Von: "Dave Abrahams" <dave(a)boostpro.com> > An: boost(a)lists.boost.org > Betreff: Re: [boost] Git Modularization Review no vote heads-up > > > on Wed May 22 2013, Jürgen Hunold <jhunold-AT-gmx.eu> wrote: > > > But this can easily be done after the conversion. > > > > I think we already lost too much time with failed rewrite attempts, so let us > > get a working repository first. Then Volodya can test git mv v2/* . and report > > results. Afterwards, we can always try rewriting in a separate clone. Done this myself yesterday. Works like a charm, git blame shows undisrupted history after git commit shows "rename" with 100% on each file moved. > Rewriting _published_ history is most strongly discouraged by the Git > people, for several good reasons. *If* there is to be any > rearrangement, it should happen before the switchover, so it doesn't > bork people who are doing work based on the history originally > published. Yes, the basic rule of git. > However, I am loath to do any rearrangement that doesn't (reasonably) > faithfully reflect how things were set up in the past. Otherwise, > someone will check out an old state of the super-module and find that > things have the wrong path relationships. Of course, path relationships > will not match SVN anyway (because we don't have a modular layout in > SVN), but people on this list made it quite clear that modularizing > history was important to them, so I presume they want the Git history to > reflect reality with maximal fidelity. Correct. > That said, if the consensus is that things should be rearranged in the > build repository, we can do that. We just need clear and explicit > instructions that cover what to do with *all* the paths that have been > used in Boost.Build (including branches and tags) throughout time. As > you can see from > https://github.com/ryppl/Boost2Git/blob/master/repositories.txt#L2261 > and following lines, just preserving the existing structure was > nontrivial. That one starts with repository build : common_branches { submodule of "boost" : "tools/build"; content { "tools/build/" : "build"; "tools/jam/" : "jam"; } right? So, this now creates "tools/build/build" with the contents of "tools/build" and "tools/build/jam" with the contents of "tools/jam" which is long gone. The former is wrong, as it does not preserve the current structure despite the thing you wrote above. I think that a one-to-one mapping like: repository build : common_branches { submodule of "boost" : "tools/build"; content { "tools/build/" ; } is the way to go now. If something goes wrong, please put "tools/jam/" somewhere else. Btw. would repository build : common_branches { submodule of "boost" : "tools/build"; content { "tools/build/v2" ; } be the right way to move v2 one directory up? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! juergen.hunold(a)gmx.eu * voice: 0049 4257 300 ! Fährstraße 1 * fax : 0049 4257 300 ! 31609 Balge/Sebbenhausen * mobil: 0049 178 186 1566 ! Germany

10 36

Re: [boost] [gsoc] Getting started with a repository (Was: Re: Live read-only GIT mirrors of Boost trunk SVN)
by Niall Douglas 30 May '13

30 May '13

> > I think the GIT team should make a decision NOW about whether GSOC > > students should use GIT or not. > > > I think I'm against this, on the grounds that there is a lot to go > > wrong, and much critical students Google-time, especially with those > > who may be even ranker amateurs than me ;-) > > +1 > > > Unless there is a firm commitment from the GIT team to support > > students using GIT, then I think they should stick to boost-sandbox > > and do things "the old way". > > > Views from the GIT team? > > Paul > > ...Or their mentors! > > I'm mentoring a project and I'm a total, absolute git-beginner (used it, like, only > sporadically for one small repo). > > Is there any way to send git newbies like me and my student to the sandbox, at > least one more year? GSoC Boost.AFIO lives at https://github.com/ned14/boost.afio but will auto mirror itself into Boost Sandbox once Paul registers for Boost SVN commit privs. If there's interest on how I configured this, do let me know. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

3 3

Re: [boost] [ASIO] Issue with epoll reactor? Callback handler not executed.
by Marat Abrarov 30 May '13

30 May '13

Hi, Arpan. > Everything works fine till async_write. You forgot that free functions like asio::async_write(_until)/asio::async_read(_until)/etc. are composed operations (http://www.boost.org/doc/libs/1_53_0/doc/html/boost_asio/reference/async_re ad/overload1.html): ... This operation is implemented in terms of zero or more calls to the stream's async_read_some function, and is known as a composed operation. ... Any composed operation (failed to find documentation for this) is implemented by means of multiple simple asynchronous operations. For example asio::async_read is implemented in terms of multiple calls of AsyncStream::async_read_some. So during any composed operation there are multiple (>=1) completions of simple asynchronous operations each of those has its own (intermediate) completion handler. Each of such intermediate completion handlers is dispatched like bound completion handler (http://www.boost.org/doc/libs/1_53_0/doc/html/boost_asio/reference/asynchro nous_operations.html) by the means of the same instance of asio::io_service as AsyncStream provides. So this code: > async_write(socket, buffer(command.c_str()), &write_handler); > io_service.reset(); > io_service.run_one(); will implement only one completions handler. That completion handler may be the intermediate completion handler if async_write needs to make more than one call to async_write_some (may be this needs to be explicitly described in Boost.Asio documentation?). That is the reason why your write_handler is not called sometimes. May be this can solve the problem: async_write(socket, buffer(command.c_str()), &write_handler); io_service.reset(); io_service.run(); async_read_until(socket, response, '\n', &read_handler); io_service.reset(); io_service.run(); Regards, Marat Abrarov.

3 6

Patch for Identification of NVCC with Changing Backends
by ryo-nishimura＠hpc.co.jp 30 May '13

30 May '13

Dear Members, I often program CUDA applications and use Boost with comforts. And I found Boost did not work fine when NVCC used a user-defined backend C++ compiler with the -ccbin option. The current implementation of Boost only identifies GCC and Visual C++ that are the default backend compilers of NVCC. So I wrote a patch for other backend compilers. It ports the generic identification routine of select_compiler_config.hpp to nvcc.hpp. Best regards, Ryohei

1 0

[gsoc] Getting started with a repository (Was: Re: Live read-only GIT mirrors of Boost trunk SVN)
by Darren Garvey 29 May '13

29 May '13

Following on from an earlier discussion... On 4 May 2013 20:00, Stefan Seefeld <stefan(a)seefeld.name> wrote: > On 05/04/2013 01:25 PM, Dave Abrahams wrote: > > on Sat May 04 2013, Stefan Seefeld <stefan-AT-seefeld.name> wrote: > > > >> it would be great if the sandbox could be converted quickly, so GSoC > >> students can use it ? > > We don't expect anyone to commit to https://github.com/boostorg/sandbox > > once the transition is complete. In fact, it would be good to stop now. > > Instead, people should use individual Git repositories. > > OK, that makes sense. So sanbox projects become entirely independent > with the only dependency being some upstream boost version (which may > correspond to either a release or a development version). > So, students can assume that users have boost installed on their machine in a standard location, and can set up a separate git repository for their project. Great. I remember there used to be a template in the sandbox for getting started; all I see right now is this: http://svn.boost.org/svn/boost/sandbox/template_under_construction/ It looks like it's the right kind of thing, but is this still under_construction (cc'ing Stjepan)? It seems to produce a basic set of directories, Jamfiles, etc. when following these steps: svn co http://svn.boost.org/svn/boost/sandbox/template_under_construction/ cd template_under_construction python file_template.py sandbox # Answer some question prompts >> It would be great if they didn't need to learn a thousand tools before > >> being able to focus on the project itself, and so having a > >> well-defined and -documented process to set things up and get started > >> would be very helpful. > > I don't know what you mean here, sorry. > > Never mind. I was thinking of a mix of versioning tools used for sandbox > projects, boost trunk, etc., causing an unnecessarily steep learning > curve. But if individual projects are to be hosted separately anyhow, > that's much less of a concern (though it would still be useful to have > clear and up-to-date guidelines for directory layout, build system, > etc., to make it easier to merge to trunk should we ever get this far). > Is setting up Jamroot / Jamfiles still the recommended way of getting started? Cheers, Darren

6 12

SIMD implementation of uBLAS
by Aditya Avinash 29 May '13

29 May '13

Hi, i have developed vector addition algorithm which exploits the hardware parallelism (SSE implementation). -- ---------------- Atluri Aditya Avinash, India.

9 28

Migrating boostcon.boost.org
by DongInn Kim 29 May '13

29 May '13

Hi, Can we move "boostcon.boost.org" to the new server sometime this week? If there is no particular activities on boostcon.boost.org, can we update the DNS entry for boostcon.boost.org to point to 129.79.13.33 at 2pm (E.T.) tomorrow (May 29th, 2013)? Beman, do you think that we can update the DNS entry tomorrow? Regards, -- - DongInn

2 2

Apologies for accidental repeat-mailings
by Nathan Bliss 29 May '13

29 May '13

Apologies for accidental repeat-mailings; been having problems with hotmail/outlook.com hanging over last 2 days...

1 0

Apologies for accidental repeat-mailings
by Nathan Bliss 29 May '13

29 May '13

Apologies for accidental repeat-mailings; been having problems with hotmail/outlook.com hanging over last 2 days...

1 0