Yes, that is right, PCHs would probably introduce some additional
dependencies for some object files, and if those PCHs become bloated
over time, then you can expect this to be expressed as diminishing time
savings.
This does imply that maintaining PCHs will require at least some work.
__
Trans
I don't think Joris is saying we should do this instead of PCHs, I think
he's just saying that it seems that a sizable performance improvement
can be made just by organizing Stout like a normal, not-header-only
library.
Taking stock briefly, based on what you've said here and elsewhere, it
seems
Just to add a bit of context, the history of the issue of build time is
tracked in MESOS-1582[1], and most recently[2].
Speaking personally, I'm excited about _any_ progress in this area,
because (1) the Windows build times are completely unbearable, and (2)
because getting the build times down b
e of: `int`, `HANDLE`, and `SOCKET`, and tries its best to
provide the same API as the POSIX `int` file descriptor. Notably, the
comparison
operators are implemented to support expressions such as `fd < 0` and `fd
!= -1`.
Thanks to Daniel Pravat, Alex Clemmer, and Benjamin Hindman for helping
urce dir:
cmake ../mesos
and then, make:
make
This will generate the agent, if you want to test it,
make check.
Cheers!
On 18 May 2016 at 15:06, Frank Scholten wrote:
Ok, thx. I pinged Alex on Twitter and I will ask him how I can help.
On Wed, May 18, 2016 at 2:40 PM, Jan Schlicht wrote:
Hey folks. Back from the insanity of //build.
Just wanted to poke my head in here and say: we will need to improve
the documentation here, but you actually *do* need to run the
`./bootstrap` for the CMake stuff. That is actually copying the git
post-commit hooks and stuff like that, and setting up
nk #6 FAILED at 145.
> 2> 6 out of 6 hunks FAILED -- saving rejects to file
> src/c/zookeeper.vcxproj.rej
> 2> patching file src/c/zookeeper-vs2015.sln
> 2> patching file src/c/include/winconfig.h
> 2> patching file src/c/include/winstdint.h
>
> Any kind of advice would b
library.
>
> And in Mesos repository, we only need to maintain the
> support/3rdparty.config file and the .patch files.
>
>
> On Tue, Mar 8, 2016 at 2:05 AM, Alex Clemmer
> wrote:
>
>> So, at this point we have a bunch of different reviews open for
>> this[1],
iews.apache.org/r/44257/
[2] https://github.com/3rdparty/mesos-3rdparty
On Tue, Mar 1, 2016 at 10:48 AM, Alex Clemmer
wrote:
> It doesn't seem to be the case that these things are mutually
> exclusive -- it is well within our purview to accept only a specific
> range of version
Looks like the relevant review is this one:
https://reviews.apache.org/r/40418/diff/3#4
I _suspect_ this will work with Windows, but am not positive.
Optimistically, it's not clear to me whether it makes sense to add it
as a dependency, because I don't know how to get its location reliably
on Wind
tforms we care about.
> Are there important use-cases that aren't supported by this scheme?
>
> Neil
>
> [1]
> https://github.com/apache/mesos/commit/c2d496ed430eaf7daee3e57edefa39c25af2aa43
>
> On Tue, Mar 1, 2016 at 10:00 AM, Alex Clemmer
> wrote:
>> I guess
ve to do this for
WIndows, into a more general solution that is useful to other exotic
platforms, rather than just Windows.
As always, super interested to hear feedback, I'd love to know if I
missed something.
On Tue, Mar 1, 2016 at 9:58 AM, Alex Clemmer
wrote:
> This is a great time t
This is a great time to discuss the Mesos dependency channel story in
general, because it has had to evolve a bit to fit the requirements of
Windows, and some of the issues you describe are issues we had to
resolve (at least partially) to support the Windows integration work.
More particularly, ou
e CDT any day).
>
> Also, please let me know whether there's anything you'd like me to try out
> and report back.
>
> Thanks!
>
> --
> *Marco Massenzio*
> http://codetrips.com
>
> On Fri, Feb 26, 2016 at 11:44 AM, Alex Clemmer
> wrote:
>
>> A
`include`.
And that's about it. Everything else is just moving.
On Fri, Feb 26, 2016 at 11:36 AM, Alex Clemmer
wrote:
> Folks:
>
> Took about 30 minutes to put together a prototype of the great
> `3rdparty` flattening. Please see the (extremely preliminary)
> review[1] or my wo
Folks:
Took about 30 minutes to put together a prototype of the great
`3rdparty` flattening. Please see the (extremely preliminary)
review[1] or my working branch[2] for a really close approximation of
the number of changes to the CMake build system we'd need to support
this flattening.
Overall,
CMake support is not quite mature yet. I think we're at least a couple
months out before it's really ready to rely on, but I'm quite happy to
hear about your bugs! Feel free to file them against me (I'm
`hausdorff` on the JIRA), and I'll make sure they get routed properly.
On Wed, Nov 25, 2015 at
the slave on windows?
>
> 2015-11-24 16:49 GMT+08:00 Alex Clemmer :
>
>> The short answer is that the Windows integration work we have planned
>> currently is aimed specifically at getting the agent/slave working and
>> production-worthy on Windows. This plan does not spec
The short answer is that the Windows integration work we have planned
currently is aimed specifically at getting the agent/slave working and
production-worthy on Windows. This plan does not specifically aim to
add Windows support to the master.
That said, there are _provisional_ plans to add Windo
ether to push the design further forward. I’m a big
> fan of an error infrastructure because it gives us a centralized location
> in the code to add debugging hooks and apply various policies such as
> logging and formatting.
>
> On Fri, Nov 6, 2015 at 1:56 PM, Alex Clemmer
> wro
And, please do the same for the CMake configuration. :)
On Fri, Nov 20, 2015 at 7:40 AM, Benjamin Mahler
wrote:
> Did you forget to replace 0.26.0 with 0.27.0 in configure.ac? Ideally all
> commits with configure.ac pointing to 0.26.0 land in 0.26.0.
>
> Please move configure.ac to 0.27.0 if you'
It's worth noting that `os::strerror` does break the Windows build. I
have a fix here: https://reviews.apache.org/r/40382/ although it's in
my review chain, it actually doesn't have any dependencies.
On Thu, Nov 19, 2015 at 12:18 PM, James Peach wrote:
> This commit reverts MESOS-3708. Can we ple
Just a data point, I always apply reviews, not only to compile, but
also just because I like using my existing toolset to interact with
the code and understand it.
On Thu, Nov 12, 2015 at 12:59 AM, Artem Harutyunyan wrote:
> Interesting, I always thought that people apply, compile and try out
> p
I like this proposal a lot, as I often end up making a point to
mention the MESOS- number in the comment anyway. I would rather
have the format `TODO(MESOS-XXX)` though, because (1) the JIRA should
capture the reporter as well as the assignee, and (2) it's not
immediately clear from the structu
bottom most callee failure, but it would be great to think about
> how to produce better messages as well (given MESOS-785 lands us in the
> same boat for Try,Result,etc).
>
> Typed errors/failures has come up before as well, but might be orthogonal
> enough to discuss separately.
nd to use that option (in the future) to reduce the noise on
> the mailing list.
>
> Thanks,
>
> On Thu, Nov 5, 2015 at 10:16 PM, Alex Clemmer (JIRA)
> wrote:
>>
>>
>> [
>> https://issues.apache.org/jira/browse/MESOS-3645?page=com.atlassian.jira.plugin
I'm strongly in favor of moving down this path, or a path like it.
As Mesos becomes increasingly important as core distributed systems
infrastructure, it will become correspondingly helpful and important
to have things like excellent core error reporting facilities, even if
they come at the cost o
The contribution documentation for the Mesos codebase is here:
http://mesos.apache.org/documentation/latest/submitting-a-patch/
That said, it is not clear (to me at least) what you mean. It sounds like
you've written a framework. Is that right? If so, the it seems like it might
not fit in the sc
Just for closure, it looks like a stunning 78% of these are due to me
(they are Windows integration-related). Since probably all of these
are not actually blocking 0.26, I will un/re-tag as appropriate today.
Also, I do apologize for making the issue graph a hockey stick.
On Thu, Nov 5, 2015 at 9
Ry7-KSj1B-02Rp8Jt4ZUkkM2fH6uhbwR=i...@mail.gmail.com%3E>
>
>
>> On 05 Nov 2015, at 06:36, Alex Clemmer wrote:
>>
>> Hey folks.
>>
>> In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
>> brought up the issue of moving away from #include gu
Hey folks.
In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
brought up the issue of moving away from #include guards and towards
`#pragma once`.
As this has been brought up before, I will be brief: we think it's
revisiting because the primary objection in previous threads appears
+1. Additional note is that this is now the de facto syntax for code
snippets on the rest of our tools, too, including RB and JIRA.
On Mon, Nov 2, 2015 at 10:32 AM, Greg Mann wrote:
> Hey folks!
> I wanted to bring up a style issue that I noticed recently. In some
> comments in the codebase, back
(Sorry, just out of ignorance: is anyone allowed to come to the
community sync? I googled around and it looks like the answer is yes,
but I don't see a living schedule anywhere... If the answer is indeed
yes, is there a form where I can sign up for the calendar invite?)
On Fri, Oct 16, 2015 at 5:3
Another update, as of this weekend, we've checked in CMake changes
that will allow you to build a pretty wide swath of the master!
You can try it for yourself:
```
mkdir build && cd build
cmake .. && make -j 8
```
On Sun, Oct 4, 2015 at 9:50 AM, Alex Clemmer
wrote:
&
t it's not allowed to modify
> makefile.am without touching CMakeLists and that any new file should
> trigger touching CMakeLists? I think this can be part of reveiw r/38827.
>
> On Tue, Sep 29, 2015 at 6:46 PM, Alex Clemmer
> wrote:
>
>> Just as an update, we have expanded su
try it on their favorite platform. We've tried it on Windows
10, OS X 10.10, Ubuntu 14.04, and Ubuntu 15.04.
[1] https://reviews.apache.org/r/38827/
On Mon, Aug 10, 2015 at 12:13 PM, Alex Clemmer
wrote:
> [... weeks later ...]
>
> Alex, I think that's a great idea, actually!
ukletsov/mesos-modules/blob/master/cmake-modules/FindMesos.cmake
>
> My original idea was to support not only system Mesos, but also custom
> builds, so that writers of Mesos Modules can use the script as well.
>
> Alex, as CMake expert, let me know what you think!
>
> On Mon, J
ff: http://git-wip-us.apache.org/repos/asf/mesos/diff/d018eb71
Branch: refs/heads/master
Commit: d018eb712000888a996046fb9b5d8bb8e79e23e9
Parents: d144fc7
Author: Alex Clemmer < clemmer.alexan...@gmail.com>
Authored: Fri Jul 31 11:37:57 2015 -0
it, but
to be safe we've developed with 2.8 in mind, because it's easier to go
from 2.8 to 3 than the reverse.
On Mon, Jul 27, 2015 at 9:37 AM, James Peach wrote:
>
>> On Jul 23, 2015, at 12:40 PM, Alex Clemmer
>> wrote:
>>
>> A fix is up for review here[
Are you asking about the standard documentation (which is here[1]), or
are you asking about the design documents for every epic that has been
added historically?
[1] http://mesos.apache.org/documentation/latest/
On Sat, Jul 25, 2015 at 5:53 PM, Klaus Ma wrote:
> Hi team,
> I can get design docum
.. (cached) gnu
>
> configure: error: GCC 4.8 or higher required (found 4.1.2)
>
> [vinod@smfd-atr-11-sr1 build-cmake]$ echo $?
>
> 1
>
> On Thu, Jul 23, 2015 at 12:17 PM, Alex Clemmer
> wrote:
>
>> We can easily change that to be a FATAL_ERROR or a WARNING. I
>> re
- Found SVN lib: /usr/lib64/libsvn_delta-1.so
>
> -- Found SVN lib: /usr/lib64/libsvn_diff-1.so
>
> -- Found SVN lib: /usr/lib64/libsvn_fs-1.so
>
> -- Found SVN lib: /usr/lib64/libsvn_fs_base-1.so
>
>
>
>
> On Thu, Jul 23, 2015 at 12:07 PM, Alex Clemmer
> wrote:
>
>&
X 10.10. Seems OS X don't have librt, don't add rt when the
> operate system is OSX?
>
> On Thu, Jul 23, 2015 at 6:22 PM, Alex Clemmer
> wrote:
>
>> Thanks for reporting the issue! I appreciate it.
>>
>> This code is trying to find librt, which provides th
ready, and `find_library` is the
CMake-standard function to find it, so it is not immediately clear to
me what went wrong here.
Do you mind if I ask what system you are running?
On Thu, Jul 23, 2015 at 1:16 AM, haosdent wrote:
> Hi, @Alex Clemmer I try to build it on OS X 10.10
>
> ```
, 2015 9:50 AM, "haosdent" wrote:
>
>> cool!
>> On Jul 23, 2015 5:12 AM, "Alex Clemmer"
>> wrote:
>>
>>> Hey folks.
>>>
>>> For some time there has been vestigial interest in a CMake[1]-based
>>> alternative to th
On Wed, Jul 22, 2015 at 3:47 PM, Vinod Kone wrote:
> This is exciting! Thanks for sharing the progress Alex.
>
> Mind sending us instructions on how to build/test with cmake for noobs like
> me?
Ah, rats, I knew I was forgetting something.
It actually looks pretty much like the autotools build s
Hey folks.
For some time there has been vestigial interest in a CMake[1]-based
alternative to the autotools-based build system that Mesos currently
depends on (cf. MESOS-898[2]). In the near future we expect to start
thinking about supporting little-known platforms such as "Windows",
(where a full
47 matches
Mail list logo
