gmane.comp.lib.boost.devel

Re: [filesystem] fixrecur_dir_itr_imp::increment(system::error_code* ec) in 1.54.0

Rob Stewart — 2013-05-23T09:10:37


I'll speculate that Beman has been focused on the Filesystem proposal, endian, etc., not to mention recovering from a recent injury.


___
Rob

(Sent from my portable computation engine)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Git Modularization Review no vote heads-up

Jürgen Hunold — 2013-05-23T08:30:04

Hi Daniel,


Well, odeint is a rather new library. And for those it makes sense to
just add the existing repository as a submodule on acceptance.
AFAIK the odeint maintainers are just waiting for this to be possible.

Yours,

Jürgen
--
* Dipl.-Math. Jürgen Hunold  ! juergen.hunold< at >gmx.eu
* voice: 0049 4257 300       ! Fährstraße 1
* fax  : 0049 4257 300       ! 31609 Balge/Sebbenhausen
* mobil: 0049 178 186 1566   ! Germany

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [circular_buffer] Volunteer(s) needed

Paul A. Bristow — 2013-05-23T08:27:23

OK - thanks - I'll do that and provide a jamfile too.


Paul

---
Paul A. Bristow,
Prizet Farmhouse, Kendal LA8 8AB  UK
+44 1539 561830  07714330204
pbristow< at >hetp.u-net.com





_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Git Modularization Review no vote heads-up

Daniel James — 2013-05-23T08:12:48

Maybe that could be avoided by having two repositories: the historical
repo, which would retain perfect history, and the working repo, which
would have the desired layout. The working repo could be created after
the conversion, and have enough history to be useful for general
development. The meta project could switch its reference over once the
new repository has been set up. Would also prevent any extra delay to
deal with this.

Since the odeint developers want to use their git repository
(https://github.com/headmyshoulder/odeint-v2) rather than the one
created by the conversion, that distinction might be required there
anyway.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Git Modularization Review no vote heads-up

Jürgen Hunold — 2013-05-23T07:04:50

Hi Dave,


Done this myself yesterday. Works like a charm, git blame shows undisrupted history after git commit shows "rename" with 100% on each file moved.


Yes, the basic rule of git.


Correct.


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 rig

Re: [Fusion] another nil issue

Rich E — 2013-05-23T06:15:50

Thanks, I do understand the frustration when having to deal with these
petty issues that are rooted in flaws of a core language.  But while I
don't agree with many choices apple made in their usage of the global
namespace in obj-c, many of us have to live with it and still hope to take
advantage of the good work done in boost as well as Cocoa.  In the end,
after many decisions have already been made, we would just like all these
tools to work in harmony.

cheers,
Rich

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Is there any interest in a library foractorprogramming?

Vicente Botet — 2013-05-23T05:37:08

Max Skvortsov wrote

Sorry, I would maintain some context . THis was a replay to the post on
libcppa :(

Best,
Vicente



--
View this message in context: http://boost.2283326.n4.nabble.com/Is-there-any-interest-in-a-library-for-actor-programming-tp4647465p4647715.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Git Modularization Review no vote heads-up

Dave Abrahams — 2013-05-23T05:28:55

on Wed May 22 2013, Jürgen Hunold <jhunold-AT-gmx.eu> wrote:


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.

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.

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

Re: [githelp] modular boost instructions?

Dave Abrahams — 2013-05-23T05:11:40

on Wed May 22 2013, Jürgen Hunold <jhunold-AT-gmx.eu> wrote:


It's not actually doing less path rewriting for Boost.Build than for
almost any other repository.  Currently, we simply take the
subdirectories of tools/ that are part of Boost.Build (i.e. tools/jam
and tools/build) and put them at the top level of the Boost.Build Git
repo.  It's like taking the tools directory but throwing out everything
that's not part of Boost.Build.  That seemed to me to be the most
faithful representation of what was happening in SVN.


It sort of was, for a while... but not for the reasons you think.

Re: Git Modularization Review no vote heads-up

Dave Abrahams — 2013-05-23T05:13:46

on Wed May 22 2013, Daniel James <daniel-AT-calamity.org.uk> wrote:


Daniel is correct.

Re: [githelp] modular boost instructions?

Dave Abrahams — 2013-05-23T05:12:12

on Wed May 22 2013, Nasos Iliopoulos <nasos_i-AT-hotmail.com> wrote:


You're welcome.  It truly is a massive undertaking.

Re: [MPL] Bug with default lambda expressions?

Jeffrey Lee Hellrung, Jr. — 2013-05-23T05:20:39


+1

- Jeff

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [MPL] Bug with default lambda expressions?

Jeffrey Lee Hellrung, Jr. — 2013-05-23T05:19:14

[...]

[...]

[...]

Quick note: might as well use quote2<is_same> rather than
lambda<is_same<_,_>>::type...at least, I think so, I've never actually used
mpl::_ myself.

- Jeff

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [test]: heap tests broken in release

Tim Blechmann — 2013-05-23T04:28:03

it seems to crash before the test cases are executed ... somewhere in
the setup phase ... the initial posting contained a backtrace, is this
somehow helpful?

thnx, tim


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Is there any interest in a library for actorprogramming?

Max Skvortsov — 2013-05-23T01:31:21


And you probably know about this [1] interesting library

[1] https://github.com/Neverlord/libcppa


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [Fusion] another nil issue

Michael Caisse — 2013-05-22T23:23:15

Hi Rich -

I believe your patch will get merged. I'm sure you can appreciate the 
lack of enthusiasm to fix bad vendor choices... like indiscriminate use 
of macros  (o;

michael

Re: [Fusion] another nil issue

Rich E — 2013-05-22T23:01:47

Is there anyone on this list responsible for Boost.Fusion, or interested in
it working on Mac OS X?  The silence is somewhat disconcerting..

Best,
Rich


On Sun, May 19, 2013 at 8:07 PM, Rich E <reakinator< at >gmail.com> wrote:


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [type_erasure][release] okay to add to release?

Marshall Clow — 2013-05-22T21:43:54


It's pretty easy to run the inspection report locally.
The sources (and Jamfile) are in /tools.

Here's how I run it:
cd $BOOST/trunk; $BOOST/trunk/dist/bin/inspect > $BOOST/snapshots/trunk-inspect.html ; open $BOOST/snapshots/trunk-inspect.html

Re: [mpl] some msvc-11.0 tests failing on release branch

Daniel James — 2013-05-22T21:37:08

It looks like this change by Steven Watanabe needs to be merged:

https://svn.boost.org/trac/boost/changeset/81027/

Hopefully he'll chime in soon? Although the use of BOOST_WORKAROUND
should be made more consistent. It's sometimes '==', sometimes '>='
(fixing that can wait until after the beta if necessary).

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [MPL] Bug with default lambda expressions?

Louis Dionne — 2013-05-22T21:33:57

[...]
[...]

Sorry for taking so long to reply. I created a ticket and uploaded a test 
case, code fix and documentation fix for the issue:
https://svn.boost.org/trac/boost/ticket/8608

However, I do not fully understand the implications of my code fix (changing 
the arity supplied to BOOST_MPL_AUX_NA_SPEC and BOOST_MPL_AUX_LAMBDA_SUPPORT), 
so it would be best for someone familiar with these to review my changes
before anything is applied.

Also, if I uncovered a real problem and if we have a good fix for it, we 
should make sure that no other higher order algorithm suffer from the same
issue.


Louis



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[mpl] some msvc-11.0 tests failing on release branch

Edward Diener — 2013-05-22T21:26:42

I have noticed 3 tests of mpl for msvc-11.0 failing on the release 
branch but succeeding on the trunk. So some change must have been made 
between the trunk and the release branch to cause this failure. These 
are affecting 'tti' and I imagine other libraries that depends on mpl.

The failures are the 'contains', 'equal', and 'lambda' tests. I am not 
seeing any failures for msvc-8.0, 9.0, or 10.0 and mpl on the release 
branch. Here are the details ( pretty long ):

----------------------------------------------------------------

file 
..\..\..\bin.v2\libs\mpl\test\contains.test\msvc-11.0\debug\contains.obj.rsp
"contains.cpp" 
-Fo"..\..\..\bin.v2\libs\mpl\test\contains.test\msvc-11.0\debug\contains.obj" 
    -TP /Z7 /Od /Ob0 /W3 /GR /MDd /Zc:forScope /Zc:wchar_t /wd4675 /EHs -c
-DBOOST_ALL_NO_LIB=1
"-I..\..\.."
compile-c-c++ 
..\..\..\bin.v2\libs\mpl\test\contains.test\msvc-11.0\debug\contains.obj

     call "C:\Program Files (x86)\Microsoft Visual Studio 
11.0\vc\vcvarsall.bat" x86 >nul
cl /Zm800 -nologo