Re: Review Request 19117: Deprecated use of MESOS_NATIVE_LIBRARY for JVM frameworks

5c92fcd Diff: https://reviews.apache.org/r/19117/diff/ Testing --- make check Thanks, Till Toenshoff

Re: Review Request 19117: Deprecated use of MESOS_NATIVE_LIBRARY for JVM frameworks

- bin/mesos-slave-flags.sh.in dc73aef src/java/generated/org/apache/mesos/MesosNativeLibrary.java.in 231d1e2 src/slave/containerizer/containerizer.cpp d0a1023 src/tests/environment.cpp 5c92fcd Diff: https://reviews.apache.org/r/19117/diff/ Testing --- make check Thanks, Till

Review Request 19117: Deprecated use of MESOS_NATIVE_LIBRARY for JVM frameworks

src/java/generated/org/apache/mesos/MesosNativeLibrary.java.in 231d1e2 src/slave/containerizer/containerizer.cpp d0a1023 src/tests/environment.cpp 5c92fcd Diff: https://reviews.apache.org/r/19117/diff/ Testing --- make check Thanks, Till Toenshoff

[jira] [Commented] (MESOS-855) Move JNI code to separate library

[ https://issues.apache.org/jira/browse/MESOS-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13931628#comment-13931628 ] Till Toenshoff commented on MESOS-855: -- This approach has been reconsidered and

Re: Review Request 18946: Moved JNI code to separate library

lly generated e-mail. To reply, visit: https://reviews.apache.org/r/18946/#review36897 ------- On March 12, 2014, 12:56 a.m., Till Toenshoff wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://revie

Re: Review Request 18910: Removal of python-boto from the repo and add configure checks.

nt to make the need for python-boto it a bit more explicit? pip would be commonly used for installing python modules and that is AFAIK the only non tarball distribution for our OSX users. - Till Toenshoff On March 7, 2014, 10:58 p.m., Timothy St.

Re: building meso-0.17.0 failing on maverick

Would you mind sharing your config.log via https://gist.github.com/? Would be a bit easier for us and also for you as you would not have to manually accept access for each and everyone that tries to help. cheers! Till On Mar 12, 2014, at 1:21 AM, haja gecko wrote: > hi vinod/till > > i am

Re: Review Request 19077: Only darwin/clang needs GTEST to supply its own tr1 tuple

077/#comment68066> Not yours, but CPPFLAGS would most likely be a better place for this. - Till Toenshoff On March 11, 2014, 11 p.m., Dominic Hamon wrote: > > --- > This is an automatically generated e-mail. To reply,

Re: Review Request 18946: Moved JNI code to separate library

---- On March 12, 2014, 12:56 a.m., Till Toenshoff wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/18946/ > -

Re: Review Request 18946: Moved JNI code to separate library

/tests/environment.cpp 5c92fcd Diff: https://reviews.apache.org/r/18946/diff/ Testing --- make check and functional testing with external, java based frameworks Thanks, Till Toenshoff

Re: Review Request 18311: Adds await on a tuple of futures.

/ Testing --- make check (clang c++11, gcc) Thanks, Till Toenshoff

Re: Review Request 18311: Adds await on a tuple of futures.

gt; one? If not, how about we kill it? Future::after indeed makes that one pretty pointless, I guess. - Till --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/18311/#review36738 ---

Re: Review Request 18311: Adds await on a tuple of futures.

, gcc) Thanks, Till Toenshoff

Re: Review Request 19068: Fix for build failure of Python-Egg on OSX clang 3.4

make check (clang and gcc, osx and linux) Thanks, Till Toenshoff

[jira] [Commented] (MESOS-1079) Mesos python egg build failure on OS X Mavericks (Xcode 5.1)

[ https://issues.apache.org/jira/browse/MESOS-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13930971#comment-13930971 ] Till Toenshoff commented on MESOS-1079: --- https://reviews.apache.org/r/1

Review Request 19068: Fix for build failure of Python-Egg on OSX clang 3.4

with clang 3.4 (Xcode 5.1) and Apple's default Python. Diffs - configure.ac 390f11b src/Makefile.am 384b312 Diff: https://reviews.apache.org/r/19068/diff/ Testing --- make check (clang and gcc, osx and linux) Thanks, Till Toenshoff

[jira] [Commented] (MESOS-1079) Mesos python egg build failure on OS X Mavericks (Xcode 5.1)

[ https://issues.apache.org/jira/browse/MESOS-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13930773#comment-13930773 ] Till Toenshoff commented on MESOS-1079: --- The proper fix here would be that A

[jira] [Commented] (MESOS-1079) Mesos python egg build failure on OS X Mavericks (Xcode 5.1)

[ https://issues.apache.org/jira/browse/MESOS-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13930707#comment-13930707 ] Till Toenshoff commented on MESOS-1079: --- Some more information on this sub

[jira] [Created] (MESOS-1079) Mesos python egg build failure on OS X Mavericks (Xcode 5.1)

Till Toenshoff created MESOS-1079: - Summary: Mesos python egg build failure on OS X Mavericks (Xcode 5.1) Key: MESOS-1079 URL: https://issues.apache.org/jira/browse/MESOS-1079 Project: Mesos

Re: Review Request 18946: Moved JNI code to separate library

d0a1023 src/tests/environment.cpp 5c92fcd Diff: https://reviews.apache.org/r/18946/diff/ Testing --- make check and functional testing with external, java based frameworks Thanks, Till Toenshoff

Re: Review Request 18946: Moved JNI code to separate library

d0a1023 src/tests/environment.cpp 5c92fcd Diff: https://reviews.apache.org/r/18946/diff/ Testing --- make check and functional testing with external, java based frameworks Thanks, Till Toenshoff

Re: Review Request 18946: Moved JNI code to separate library

src/slave/containerizer/containerizer.cpp d0a1023 src/tests/environment.cpp 5c92fcd Diff: https://reviews.apache.org/r/18946/diff/ Testing --- make check and functional testing with external, java based frameworks Thanks, Till Toenshoff

Re: Review Request 18946: Moved JNI code to separate library

--- On March 11, 2014, 12:32 p.m., Till Toenshoff wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/18946/ > ---

Re: Review Request 18946: Moved JNI code to separate library

functional testing with external, java based frameworks Thanks, Till Toenshoff

[jira] [Commented] (MESOS-1071) Enable building against installed third-party dependencies.

[ https://issues.apache.org/jira/browse/MESOS-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13926151#comment-13926151 ] Till Toenshoff commented on MESOS-1071: --- I'll go ahead and acquire

Re: building meso-0.17.0 failing on maverick

) as I missed your original post and the archives seem to have removed your attachment. On Mar 10, 2014, at 7:43 PM, Benjamin Mahler wrote: > Is there anything we can do to enforce this compatibility matrix at configure > time? > > -- Forwarded message ------ > From:

Re: building meso-0.17.0 failing on maverick

Hey there - I did unfortunately miss the initial question, hence I have to do a bit of guess-work here. Forgive me if that is entirely off. That flag is not explicitly set by Mesos, as Vinod mentioned. It is however implicitly done by distutils extraction the cflags out of the existing python

[jira] [Assigned] (MESOS-550) Python compilation fails when trying to compile without included zookeeper libs

[ https://issues.apache.org/jira/browse/MESOS-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Till Toenshoff reassigned MESOS-550: Assignee: Till Toenshoff > Python compilation fails when trying to compile without inclu

Re: Review Request 17567: Pluggable Containerizer

p PRE-CREATION src/slave/containerizer/pluggable_containerizer.cpp PRE-CREATION src/slave/flags.hpp c9a627b src/tests/pluggable_containerizer_test.cpp PRE-CREATION Diff: https://reviews.apache.org/r/17567/diff/ Testing --- make check and functional testing. Thanks, Till Toenshoff

Re: Review Request 18595: Added overloaded killtree for process trees.

at belong to a process tree root which > might shutdown before its children. With the current killtree implementation, > it seems to me that this would fail (the pid can't be resolved to a process > and returns). Till mentioned that we might end up killing new processes same &

Re: Review Request 18957: Added --without-included-leveldb flag

sit: https://reviews.apache.org/r/18957/#review36642 --- On March 10, 2014, 10:36 a.m., Till Toenshoff wrote: > > --- > This is an automatically generated

Re: Review Request 17567: Pluggable Containerizer

make check and functional testing. Thanks, Till Toenshoff

Re: Review Request 17567: Pluggable Containerizer

e/mesos/mesos.proto 37f8a7f src/Makefile.am 384b312 src/slave/containerizer/containerizer.cpp d0a1023 src/slave/flags.hpp c9a627b Diff: https://reviews.apache.org/r/17567/diff/ Testing --- make check and functional testing. Thanks, Till Toenshoff

Re: Review Request 17567: Pluggable Containerizer

gable_containerizer.hpp PRE-CREATION src/slave/containerizer/pluggable_containerizer.cpp PRE-CREATION src/slave/flags.hpp e4d98a5 src/tests/pluggable_containerizer_test.cpp PRE-CREATION Diff: https://reviews.apache.org/r/17567/diff/ Testing --- make check and functional testing. Thanks, Till Toenshoff

Re: Review Request 18595: Added overloaded killtree for process trees.

> On March 7, 2014, 3:35 a.m., Ben Mahler wrote: > > 3rdparty/libprocess/3rdparty/stout/include/stout/os/killtree.hpp, line 51 > > > > > > This seems a little strange, because we'll be trying to signal multiple > > tim

Re: Review Request 18594: Added liveProcesses to process tree abstraction.

> On Feb. 28, 2014, 6:43 p.m., Ben Mahler wrote: > > Did you still want this now that r/18604/ is submitted? > > Niklas Nielsen wrote: > Till has been using them in a reworked version of signal escalation in > PluggableContainerizer::destroy(). We wanted to give the external program a > ch

Re: Review Request 18311: Adds await on a tuple of futures.

e899aed Diff: https://reviews.apache.org/r/18311/diff/ Testing --- make check (clang c++11, gcc) Thanks, Till Toenshoff

[jira] [Commented] (MESOS-1071) Enable building against installed third-party dependencies.

[ https://issues.apache.org/jira/browse/MESOS-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925636#comment-13925636 ] Till Toenshoff commented on MESOS-1071: --- As small step in the hopefully cor

Review Request 18957: Added --without-included-leveldb flag

/include LDFLAGS=-L/usr/local/lib LIBS="-lleveldb -lsnappy" make check linux: manually installed leveldb without libsnappy ../configure --without-included-leveldb CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib LIBS=-lleveldb make check Thanks, Till Toenshoff

Re: Review Request 18946: Moved JNI code to separate library

Diff: https://reviews.apache.org/r/18946/diff/ Testing --- make check and functional testing with external, java based frameworks Thanks, Till Toenshoff

Re: Review Request 18946: Moved JNI code to separate library

rchive contents... > > /usr/bin/ld: cannot find -lmesos > > collect2: ld returned 1 exit status > > make[2]: *** [libmesos_java.la] Error 1 > > make[2]: *** Waiting for unfinished jobs > > make[1]: *** [check] Error 2 > > make: *** [check-recursive] Error 1 &g

Re: Review Request 18947: Fixed Python-Egg to adhere to --without-included-zookeeper

/usr/local/lib LIBS=-lzookeeper_mt make check and ../configure make check Thanks, Till Toenshoff

Re: Review Request 18947: Fixed Python-Egg to adhere to --without-included-zookeeper

; > make[2]: *** Waiting for unfinished jobs > > make[1]: *** [check] Error 2 > > make: *** [check-recursive] Error 1 > > Interesting failure. Seems to be caused when LDFLAGS are getting stuffed into EXTRA_LINK_ARGS - not on OSX but only on linux systems. Workaro

[jira] [Commented] (MESOS-550) Python compilation fails when trying to compile without included zookeeper libs

[ https://issues.apache.org/jira/browse/MESOS-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925352#comment-13925352 ] Till Toenshoff commented on MESOS-550: -- https://reviews.apache.org/r/18947/ >

Review Request 18947: Fixed Python-Egg to adhere to --without-included-zookeeper

02f00ef Diff: https://reviews.apache.org/r/18947/diff/ Testing --- ../configure CPPFLAGS=-I/usr/local/include/zookeeper LDFLAGS=-L/usr/local/lib --without-included-zookeeper make check and ../configure make check Thanks, Till Toenshoff

[jira] [Commented] (MESOS-855) Move JNI code to separate library

[ https://issues.apache.org/jira/browse/MESOS-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925286#comment-13925286 ] Till Toenshoff commented on MESOS-855: -- https://reviews.apache.org/r/18946/ &g

Review Request 18946: Moved JNI code to separate library

frameworks Thanks, Till Toenshoff

Re: Review Request 18722: Removed define for gtests to use its own tr1 tuple.

l.cc:39: In file included from gmock-1.6.0/gtest/include/gtest/gtest.h:57: In file included from gmock-1.6.0/gtest/include/gtest/internal/gtest-internal.h:40: gmock-1.6.0/gtest/include/gtest/internal/gtest-port.h:499:13: fatal error: 'tr

[jira] [Commented] (MESOS-1071) Enable building against installed third-party dependencies.

[ https://issues.apache.org/jira/browse/MESOS-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13922972#comment-13922972 ] Till Toenshoff commented on MESOS-1071: --- Good point, indeed. I have proposed a

[jira] [Commented] (MESOS-550) Python compilation fails when trying to compile without included zookeeper libs

[ https://issues.apache.org/jira/browse/MESOS-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13922966#comment-13922966 ] Till Toenshoff commented on MESOS-550: -- MESOS-1071 proposes using the &quo

[jira] [Commented] (MESOS-1071) Enable building against installed third-party dependencies.

[ https://issues.apache.org/jira/browse/MESOS-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13922948#comment-13922948 ] Till Toenshoff commented on MESOS-1071: --- This touches https://issues.apache

Re: Review Request 18835: Removed unneeded boost::tuple include

This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/18835/#review36369 --- On March 6, 2014, 4:32 a.m., Till Toenshoff wrote: > > -

Re: Review Request 18723: Prevent gflags detection from glog configuration phase

prevent us from having to run autoreconf on this bundle by default. Diffs - 3rdparty/libprocess/3rdparty/glog-0.3.3.patch 76b8c0f Diff: https://reviews.apache.org/r/18723/diff/ Testing --- make check (while having gflags previously installed). Thanks, Till Toenshoff

Re: Review Request 18725: Prevent snappy and tcmalloc detection from leveldb configuration phase

PRE-CREATION Diff: https://reviews.apache.org/r/18725/diff/ Testing --- make check (with snappy installed) Thanks, Till Toenshoff

Review Request 18836: Exchanged uses of boost::tuple with tuples::tuple

. Repository: mesos-git Description --- see summary. Diffs - src/zookeeper/zookeeper.cpp f90515d Diff: https://reviews.apache.org/r/18836/diff/ Testing --- make check Thanks, Till Toenshoff

Review Request 18835: Removed unneeded boost::tuple include

. Repository: mesos-git Description --- see summary. Diffs - 3rdparty/libprocess/3rdparty/stout/include/stout/foreach.hpp d64e2a4 Diff: https://reviews.apache.org/r/18835/diff/ Testing --- make check Thanks, Till Toenshoff

Review Request 18833: Tuples::tuple pre C++11 variant pulls from tr1 instead of boost

--- see summary. Diffs - 3rdparty/libprocess/3rdparty/stout/include/stout/tuple.hpp 469c159 Diff: https://reviews.apache.org/r/18833/diff/ Testing --- make check Thanks, Till Toenshoff

Re: Review Request 18360: Include std::tuple or boost::tuples::tuple within a tuples namespace of stout.

ailable? > > > > This is what the other headers do: > > > > lambda.hpp > > memory.hpp > > > > I can't tell from the discussion on this review, was there a reason to > > do it differently for tuple? > > Till Toens

Re: Review Request 18360: Include std::tuple or boost::tuples::tuple within a tuples namespace of stout.

This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/18360/#review36278 --- On Feb. 24, 2014, 6:48 p.m., Till Toenshoff wrote: > > -

[jira] [Commented] (MESOS-855) Move JNI code to separate library

[ https://issues.apache.org/jira/browse/MESOS-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13921527#comment-13921527 ] Till Toenshoff commented on MESOS-855: -- The path forward that I would like to pu

[jira] [Commented] (MESOS-550) Python compilation fails when trying to compile without included zookeeper libs

[ https://issues.apache.org/jira/browse/MESOS-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13921502#comment-13921502 ] Till Toenshoff commented on MESOS-550: -- Yes, good point. Why having dedicated p

Re: Review Request 18311: Adds await on a tuple of futures.

ests on those new overrides. > > > Diffs > - > > 3rdparty/libprocess/include/process/collect.hpp 2a73bc9 > 3rdparty/libprocess/src/tests/process_tests.cpp e899aed > > Diff: https://reviews.apache.org/r/18311/diff/ > > > Testing > --- > > make check (clang c++11, gcc) > > > Thanks, > > Till Toenshoff > >

[jira] [Commented] (MESOS-550) Python compilation fails when trying to compile without included zookeeper libs

[ https://issues.apache.org/jira/browse/MESOS-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13921216#comment-13921216 ] Till Toenshoff commented on MESOS-550: -- I would like to propose a new approach

Re: Mesos ReviewBot

> Just wanted to give you guys a heads up about a new feature/bot that we > built. The bot (Mesos ReviewBot) is run via Apache Jenkins and polls Review > Board for any pending mesos reviews. > > All such pending reviews are verified by applying (recursively if they > depend on other reviews) them

Re: Review Request 17567: Pluggable Containerizer

- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/17567/#review36075 --- On March 4, 2014, 5:46 a.m., Till Toenshoff wrote: > > ---

Re: Review Request 17567: Pluggable Containerizer

ache.org/r/17567/diff/ Testing --- make check and functional testing. Thanks, Till Toenshoff

[jira] [Commented] (MESOS-1010) Python extension build is broken if gflags-dev is installed

[ https://issues.apache.org/jira/browse/MESOS-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13918990#comment-13918990 ] Till Toenshoff commented on MESOS-1010: --- As glog's has no way of overr

[jira] [Commented] (MESOS-1054) Java extension build is broken if libsnappy is installed

[ https://issues.apache.org/jira/browse/MESOS-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13918987#comment-13918987 ] Till Toenshoff commented on MESOS-1054: --- There is no option during

Review Request 18725: Prevent snappy and tcmalloc detection from leveldb configuration phase

://reviews.apache.org/r/18725/diff/ Testing --- make check (with snappy installed) Thanks, Till Toenshoff

[jira] [Created] (MESOS-1054) Java extension build is broken if libsnappy is installed

Till Toenshoff created MESOS-1054: - Summary: Java extension build is broken if libsnappy is installed Key: MESOS-1054 URL: https://issues.apache.org/jira/browse/MESOS-1054 Project: Mesos

Review Request 18723: Prevent gflags detection from glog configuration phase

this bundle by default. Diffs - 3rdparty/libprocess/3rdparty/glog-0.3.3.patch 76b8c0f Diff: https://reviews.apache.org/r/18723/diff/ Testing --- make check (while having gflags previously installed). Thanks, Till Toenshoff

[jira] [Comment Edited] (MESOS-1010) Python extension build is broken if gflags-dev is installed

[ https://issues.apache.org/jira/browse/MESOS-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13918877#comment-13918877 ] Till Toenshoff edited comment on MESOS-1010 at 3/4/14 1:1

[jira] [Commented] (MESOS-1010) Python extension build is broken if gflags-dev is installed

[ https://issues.apache.org/jira/browse/MESOS-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13918877#comment-13918877 ] Till Toenshoff commented on MESOS-1010: --- I currently see two options to fix thi

[jira] [Comment Edited] (MESOS-1010) Python extension build is broken if gflags-dev is installed

[ https://issues.apache.org/jira/browse/MESOS-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13918623#comment-13918623 ] Till Toenshoff edited comment on MESOS-1010 at 3/4/14 1:1

[jira] [Commented] (MESOS-1010) Python extension build is broken if gflags-dev is installed

[ https://issues.apache.org/jira/browse/MESOS-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13918623#comment-13918623 ] Till Toenshoff commented on MESOS-1010: --- The issue is indeed nasty - ran int

Review Request 18667: Incorrect include in mesos-execute

--- make check Thanks, Till Toenshoff

Re: Review Request 18608: Fix incorrect stderr to stdout pipe routing in configuration phase.

troduced this bug in the first place... SORRY! - Till --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/18608/#review35761 --- On F

Review Request 18608: Fix incorrect stderr to stdout pipe routing in configuration phase.

g --- bootstrap, configure, make check Thanks, Till Toenshoff

Re: Review Request 17567: Pluggable Containerizer

sion? > > The external containerizer might want to make note of "pending" resource > > changes and apply them once the container is up (or wait for the container > > to come up). > > Till Toenshoff wrote: > That could indeed be a valid and still per

Re: Review Request 17567: Pluggable Containerizer

pluggable_containerizer.cpp PRE-CREATION > src/slave/flags.hpp e4d98a5 > src/tests/pluggable_containerizer_test.cpp PRE-CREATION > > Diff: https://reviews.apache.org/r/17567/diff/ > > > Testing > --- > > make check and functional testing. > > > Thanks, > > Till Toenshoff > >

Re: Review Request 17567: Pluggable Containerizer

----- On Feb. 28, 2014, 1:23 a.m., Till Toenshoff wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/17567/ >

Re: Review Request 17567: Pluggable Containerizer

make check and functional testing. Thanks, Till Toenshoff

[jira] [Created] (MESOS-1046) Use of leading underscore in names (global symbols and defines)

Till Toenshoff created MESOS-1046: - Summary: Use of leading underscore in names (global symbols and defines) Key: MESOS-1046 URL: https://issues.apache.org/jira/browse/MESOS-1046 Project: Mesos

Re: Review Request 18311: Adds await on a tuple of futures.

https://reviews.apache.org/r/18311/diff/ Testing --- make check (clang c++11, gcc) Thanks, Till Toenshoff

Re: Review Request 18311: Adds await on a tuple of futures.

++11, gcc) Thanks, Till Toenshoff

[jira] [Commented] (MESOS-51) Add an API for listing the nodes in the cluster

[ https://issues.apache.org/jira/browse/MESOS-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13912039#comment-13912039 ] Till Toenshoff commented on MESOS-51: - [~vinodkone] assuming that you did not find

[jira] [Commented] (MESOS-972) bootstrap script is broken on distributions.

[ https://issues.apache.org/jira/browse/MESOS-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911913#comment-13911913 ] Till Toenshoff commented on MESOS-972: -- This issue persists in 0.17rc2 when b

Re: Review Request 18311: Adds await on a tuple of futures.

/ Testing --- make check (clang c++11, gcc) Thanks, TILL TOENSHOFF

Re: Review Request 18311: Adds await on a tuple of futures.

of this header > > with the type changed, would it be possible to just typedef > > 'process::tuple' or add a 'stout::tuple' that is either a > > boost::tuples::tuple or std::tuple? > > TILL TOENSHOFF wrote: > There is a point in what you say, but

Re: Review Request 18311: Adds await on a tuple of futures.

Diff: https://reviews.apache.org/r/18311/diff/ Testing --- make check (clang c++11, gcc) Thanks, TILL TOENSHOFF

Re: Review Request 18360: Include std::tuple or boost::tuples::tuple within a tuples namespace of stout.

/stout/Makefile.am 5d5a760 3rdparty/libprocess/3rdparty/stout/include/stout/tuple.hpp PRE-CREATION Diff: https://reviews.apache.org/r/18360/diff/ Testing --- make check (clang c++11, gcc), functional testing Thanks, TILL TOENSHOFF

Re: Review Request 18311: Adds await on a tuple of futures.

> On Feb. 20, 2014, 7:37 p.m., Vinod Kone wrote: > > 3rdparty/libprocess/include/process/collect.hpp, lines 323-326 > > <https://reviews.apache.org/r/18311/diff/1/?file=498993#file498993line323> > > > > Why is this .then? What happens if await() returns a f

Re: Review Request 18311: Adds await on a tuple of futures.

of this header > > with the type changed, would it be possible to just typedef > > 'process::tuple' or add a 'stout::tuple' that is either a > > boost::tuples::tuple or std::tuple? > > TILL TOENSHOFF wrote: > There is a point in what you say, but

Re: Review Request 18311: Adds await on a tuple of futures.

2a73bc9 3rdparty/libprocess/src/tests/process_tests.cpp e899aed Diff: https://reviews.apache.org/r/18311/diff/ Testing --- make check (clang c++11, gcc) Thanks, TILL TOENSHOFF

Re: Review Request 18360: Include std::tuple or boost::tuples::tuple within a tuples namespace of stout.

1, gcc), functional testing Thanks, TILL TOENSHOFF

[jira] [Updated] (MESOS-1026) Pull std::tuple / boost::tuples::tuple into tuples namespace of stout

[ https://issues.apache.org/jira/browse/MESOS-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Till Toenshoff updated MESOS-1026: -- Description: For allowing a smooth transition into the C++11 world, I would like to propose

[jira] [Updated] (MESOS-1026) Pull std::tuple / boost::tuples::tuple into tuples namespace of stout

[ https://issues.apache.org/jira/browse/MESOS-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Till Toenshoff updated MESOS-1026: -- Summary: Pull std::tuple / boost::tuples::tuple into tuples namespace of stout (was: Pull std

[jira] [Commented] (MESOS-1026) Pull std::tuple / boost::tuples::tuple into Process::tuples namespace

[ https://issues.apache.org/jira/browse/MESOS-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908929#comment-13908929 ] Till Toenshoff commented on MESOS-1026: --- I never realized that this was the

Review Request 18360: Include std::tuple or boost::tuples::tuple within the process::tuples namespace.

tuples/tuples.hpp and tuples/details.hpp. Diffs - 3rdparty/libprocess/Makefile.am a7d199f 3rdparty/libprocess/include/process/tuples/tuple.hpp PRE-CREATION Diff: https://reviews.apache.org/r/18360/diff/ Testing --- make check (clang c++11, gcc), functional testing Thanks, TILL TOENSHOFF

[jira] [Commented] (MESOS-1026) Pull std::tuple / boost::tuples::tuple into Process::tuples namespace

[ https://issues.apache.org/jira/browse/MESOS-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908608#comment-13908608 ] Till Toenshoff commented on MESOS-1026: --- Unfortunately, stout can not be

<    3   4   5   6   7   8   9   >