Hi,
We have a work item, https://issues.apache.org/jira/browse/MESOS-8064, which
discusses programmatically decoding .tar, .tar.gz, .zip, and other common file
compression schemes.
I have an initial implementation for this (rough only), and I wanted to reach
out to the development community
profiling solutions if they want. On the other hand, if we
decide on some obscure malloc, there is a much higher chance of accidentally
introducing subtle bugs for the people who enable the feature.
Best regards,
Benno
On Thu, Aug 31, 2017 at 5:41 PM, Jeff Coffler <
jeff.c
uspect that it should or shouldn't work?
>
> Best regards,
> Benno
>
> On Wed, Aug 23, 2017 at 6:16 PM, Jeff Coffler <
> jeff.coff...@microsoft.com.invalid> wrote:
>
>> Hi Benno,
>>
>> What's the availability of both jemalloc and tcmalloc on the Windo
have more experience with memory management on windows, is
there a reason to suspect that it should or shouldn't work?
Best regards,
Benno
On Wed, Aug 23, 2017 at 6:16 PM, Jeff Coffler <
jeff.coff...@microsoft.com.invalid> wrote:
> Hi Benno,
>
> What's the availability of both j
Looks like Andy didn't answer this, so I will.
Currently Linux builds still use autotools but can use cmake. Buildbot uses
autotools for Linux. Windows builds exclusively uses cmake.
End result: For now, reviewers should insure that changes which affect files
(new source files, new header
Hi Benno,
What's the availability of both jemalloc and tcmalloc on the Windows platform?
Do the products work there properly?
There are solutions that I know work on Windows (from past work I've done). I'm
unsure about either jemalloc and tcmalloc, however.
Thanks,
/Jeff
-Original
still accurate, except that precompiled headers are no
>longer "upcoming".
>
>On Wed, Jun 21, 2017 at 4:42 PM, Jeff Coffler <
>jeff.coff...@microsoft.com.invalid> wrote:
>
>> Hi Aaron,
>>
>> I'd like to expand on what Andy said:
>>
>> If y
Hi Aaron,
I'd like to expand on what Andy said:
If you want cross-platform development, then cmake is the only way to go. For
example, if you want to build on Windows, you MUST use cmake. We anticipate,
over time, that cmake will replace the autotools build (we do not want to
maintain two
I had previously send an E-Mail to the Mesos DEV list on Tue 2/14/2017 11:29
AM. I've attached that message here for reference (hopefully the attachment
will make it across).
Work has proceeded, and I'm working out some commits to apply to the changes
for Windows (cmake only).
While I was
I'm planning on prototyping this just to generate numbers. I don't think I need
permission to do that! But, of course, to incorporate any changes into the code
base, we need consensus.
I agree that stout optimizations are outside of the scope of this discussion.
Any stout optimizations are
uary 15, 2017 11:13 AM
To: dev <dev@mesos.apache.org>
Subject: Re: Proposal for Mesos Build Improvements
On Tue, Feb 14, 2017 at 11:28 AM, Jeff Coffler
<jeff.coff...@microsoft.com.invalid> wrote:
> For efficiency purposes, if a header file is included by 50% or more of the
> source
curious to hear more about how using PCH compares with making stout a
non-header-only library. Is PCH easier to implement, or is it expected to offer
a more dramatic improvement in compile times? Would making both changes
eventually make sense?
Neil
On Tue, Feb 14, 2017 at 11:28 AM
Proposal For Build Improvements
The Mesos build process is in dire need of some build infrastructure
improvements. These improvements will improve speed and ease of work in
particular components, and dramatically improve overall build time, especially
in the Windows environment, but likely in
13 matches
Mail list logo
