[from right address]
On Fri, Dec 11, 2009 at 11:37 AM, Steve VanDeBogart vand...@google.comwrote:
On Fri, Dec 11, 2009 at 11:23 AM, Scott Hess sh...@chromium.org wrote:
[[And now I'm waiting for someone to suggest the
--no-really-no-sandbox-i-like-being-insecure flag to suppress
My windows build has been broken for at least a day with the following
error:
base_nacl_win64.lib(string_util.obj) : fatal error LNK1112: module machine
type 'x64' conflicts with target machine type 'X86'
I've tried disabling nacl, gclient sync --force, clobbering the output
directory, removing
This afternoon I will update DEPS to pull in 170MB of profile data for
memory_test. Unless you run memory_test, you probably want to add the
following line to the custom_deps section of your .gclient file.
src/data/memory_test/membuster: None,
--
Steve
Apologies, this will only apply to committers from Google.
--
Steve
On Thu, Nov 5, 2009 at 11:16 AM, Steve VanDeBogart vand...@chromium.orgwrote:
This afternoon I will update DEPS to pull in 170MB of profile data for
memory_test. Unless you run memory_test, you probably want to add
If you plan to read the entire file, mmap()ing it, then faulting it in will
be slower than read()ing it, at least in some Linux versions. I never
pinned down exactly why, but I think the kernel read-ahead mechanism works
slightly differently.
--
Steve
On Thu, Oct 22, 2009 at 2:02 PM, Chris Evans
On Thu, Oct 22, 2009 at 2:06 PM, Steve Vandebogart vand...@chromium.org
wrote:
If you plan to read the entire file, mmap()ing it, then faulting it in
will
be slower than read()ing it, at least in some Linux versions. I never
pinned down exactly why, but I think the kernel read-ahead
should
just fix hunspell to be more efficient for our usage.]
-scott
On Thu, Oct 22, 2009 at 2:42 PM, Steve Vandebogart vand...@chromium.org
wrote:
It's been awhile since I looked at this, but the email I was able to dig
up
suggests that madvise is no faster than faulting in the mmap()ed
them into memory.
-scott
On Thu, Oct 22, 2009 at 3:01 PM, Steve Vandebogart vand...@chromium.org
wrote:
Probably a bit off topic at this point, but but your response confuses me
- MADV_WILLNEED and POSIX_FADV_WILLNEED will bring the pages into ram,
just
like faulting in mmap()'ed pages
On Fri, Oct 2, 2009 at 4:20 PM, Dan Kegel d...@kegel.com wrote:
(I think PIPE_BUF is 64K on modern Linux, but might be smaller elsewhere.)
I seem to recall that pipe buf is a page and /usr/include/linux/limits.h
says
#define PIPE_BUF4096
--
Steve
On Thu, Sep 24, 2009 at 1:49 PM, Yaar Schnitman y...@chromium.org wrote:
Yes.
With git:git try -b bot --webkit webkit branch chromium branch
With gcl:
Manually create a patch by concatenating two (chromium + webkit) patches.
Make sure that the webkit patches have the right prefixes by
I don't know if you've already looked at Doxygen, but to help bootstrap me
into the code, I ran it on the codebase minus third_party/webkit. It picked
up the doxygen specific formatting for V8, but the classes and files
sections are there: http://chrome.nerdbox.net (r21988)
I have also in the
11 matches
Mail list logo
