[chromium-dev] Re: Mozilla design challenge
I think you're somewhat right folks use tabs to enhance or partially replace poor history systems. Instead of going to the root to create a good history system and telling users to stop doing that, perhaps we should be asking how can we enhance what the user wants to do: *Use tabs (in their current highly evolved presentation and placement) to improve on history!* After all, tabs *are* a mechanisms for presenting a vast array of windows in a more usable and orderly fashion than the anarchy of a pseudo-randomly overlapping window set. Such a windowing anarchy is what we had in Netsacape and IE prior to tabbing. To put it another way, tabs *are* a clever history presentation mechanism, and not an abuse of a feature. Several of the videos provide alternate views of tabs. I think providing better views is a very worth-while goal, although I think too often demos abandoned the existing tab UI, and provided wholesale replacement. :-( Brian focused on a nice element, which showed how long tabs have been open. Fundamentally the ability to see tabs differently, rather that moving them automatically, may be a key way to help a user do what is most natural. When I search for a needle in a haystack, one of my goals is avoid moving much hay, as I have a lot of structure in the placement of the existing piles. One really nice element of gmail is that messages are sorted by tagged views, but not really moved (a giant stride when compared with pop and imap message replications in folders). I think we need ways to view the data (what's in a tab, and the history and relationships of tabs) without moving the tabs from where the user placed them. Perhaps we need to help the user achieve the integration, and provide more views of their tabs, that enhance their actions. The Best in Class: innovative sadly seems to discard the current tab view (providing a radial view), rather than work to enhance current tab placement and information presentation. For instance, perhaps a new-tab page should (optionally) have a view that graphically looks like a spread sheet descending from the tabs. Something like a tinderbox waterfall which shows history of build bots, should show some history of tabs. Perhaps we should have mouse-over thumbnails (as suggested in some of the videos)... all sorts of ideas spring to mind. Clever innovation such as Nsylvain's enhancement of waterfall presentation that warps time in a traditional waterfall may be applied to make views most useful for various search scenarios. ...but that UI thread seems quite orthogonal to the performance enhancing portions of this thread about how to transparently freeze-dry lingering tabs so that they don't impact performance. I think this freeze-drying can indeed be done well, if not perfectly by heuristics mentioned in this thread. It may be that the heuristics are conservative, but looking at my use cases, I'm convinced heuristics could do an excellent job on the bulk of my tabs, and still have zero lost content (re: lost edits and state) just by being conservative. The only way we'll see if such heuristics *could* cover the bulk of genuine users tabs is to do some data gathering on real users (example: We could sample at each UMA gathering point how many tabs could be conservatively freeze dried). Jim On Tue, Jul 21, 2009 at 8:28 AM, Dean McNamee de...@chromium.org wrote: I feel like people are using tabs as a replacement for a good history system. At least in all current browser implementations, tabs are running. Even if we can make the UI scale to 1000 tabs, the 500 flash instances that are likely running aren't really going to perform. The making tab performance scale is a separate technical issue that will hopefully also improve. Looking at a lot of these design videos, they looked more like good ideas to me for history navigation than tab navigation. If history was good, I think people wouldn't be so worried about losing something by closing a tab. Having had bad history systems for so many years, people are now trained to keep tabs open if they ever might want to look at that page again in the future :\ On Sat, Jul 18, 2009 at 1:16 AM, Peter Kastingpkast...@google.com wrote: http://design-challenge.mozilla.com/summer09/ The results of the Reinventing Tabs in the Browser challenge have been announced. Collapsible Tab Groups includes among others some things I've proposed, including grouping and collapsing groups. Favitabs reminds me of some old brainstorming ideas from pamg about converting certain tabs into favicon buttons. Folks considering the future of tabs (e.g. Ben, Glen, Scott) might do well to take a look at some of these. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: PSA: Consider upgrading to VS2008.
http://crbug.com/5022 http://crbug.com/5023 http://crbug.com/5024 http://crbug.com/5026 http://crbug.com/5027 Grab any of these. A lot of people complained but almost nobody dared (except tommi) contributing to reduce the dependency. So please stop talking about this unless this is to contribute changes. Until there is a good-enough replacement for CWindowImpl and CComCoClass, I'm against refusing to add more dependency on ATL. (hint hint start there) Thanks for not continuing this OT thread, M-A On Sun, Aug 2, 2009 at 1:19 AM, Dan Kegeld...@kegel.com wrote: Yeah. How about a presubmit check? (only half joking) On Sat, Aug 1, 2009 at 9:41 PM, PhistucKphist...@gmail.com wrote: I am either wrong or just out of context here, but O3D has added another mentioning of ATL in their code - http://www.google.com/codesearch/p?hl=ensa=Ncd=8ct=rc#h0RrPvyPu-c/o3d/plugin/npapi_host_control/win/stream_operation.hq=package:src.chromium.org%20atl Should any additions not be prevented? ☆PhistucK On Fri, Jul 31, 2009 at 22:32, Ben Goodger (Google) b...@chromium.org wrote: I would like to. It's just a matter of time and effort... and it's not been a top priority for me to date. Please feel free to gather requirements and develop a plan however. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Temporarily disable tcmalloc in build
On Sat, Aug 1, 2009 at 10:53 PM, Huan Ren hu...@google.com wrote: - The crash rates on chromebot are comparable for builds with and without tcmalloc. The crash rate for tcmalloc build is higher but it seems within error margin. - Wtih tcmalloc disabled, there are some promising data from Purify test run and ChromeBot run with full page heap enabled. These are still under further investigation. BTW, all the server guys have tcmalloc heap profiling enabled by default; they can pinpoint leaks at process exit by default on their servers (when I saw the tool recently, I was very impressed!) Jim and Will investigated with CraigS - turns out that this portion of tcmalloc isn't in the public-domain version of tcmalloc which we use. If we help Craig get this part of tcmalloc open sourced, we can get much of purify in 'by default'. - The performance results are same as last time we compared. With tcmalloc, the most perf gain is from page-cycler-moz: 15% improvement (with 25% more memory usage). The perfor gain on page-cycler-more-js is 4%, as we see tcmalloc has no perf impact on V8 benchmark. The performance gain on DOM is significant: from score 325 to 414. I thought it was also interesting to look at the tcmalloc benefits on XP vs Vista (we had observed this before too). It's clear that Microsoft substantially improved the heap on Vista - while the gains on XP were 8-9% for the intl page cyclers on XP, the gains were only 1-2% on Vista. Similarly for the DOM and other tests, Vista gains for tcmalloc are always substantially less than on XP. We might want to look more closely at Win7; I don't think the heap changed much from Vista to Win7, but maybe eventually tcmalloc won't be interesting. Or - if we can reduce webkit heap usage, maybe we can make it so that tcmalloc on vista doesn't improve anything. Mike r22251 re-enables tcmalloc on trunk. We can merge 22080 to dev branch if needed. Huan On Fri, Jul 31, 2009 at 6:51 PM, cpuc...@chromium.org wrote: What are the results of this experiment? On Jul 30, 12:15 pm, Huan Ren hu...@chromium.org wrote: I just submitted a change (22080) that disables tcmalloc used on Windows platform. The plan is keeping it in trunk for 24 hours and then reverting it. The intentions are - Having another round of performance comparison between build with and w/o tcmalloc. - Having a full run of UI test under purify with tcmalloc disabled. - Getting a verified CL in case we'd like to build an alternative dev build w/o tcmalloc for A/B test. As a head up, the performance, stability, and purify test results could be different during the period. Huan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Design Doc: out of process (v8) proxy resolving
Updated the names with some feedback from Darin: ProxyResolverV8::JSBindings -- ProxyResolverJSBindings OOPProxyResolverV8 -- IPCProxyResolver OOPProxyResolverV8Host -- IPCProxyResolverHost So the names are less V8 specific (could drop in a JSC backend on the proxy resolver process-side if you wanted). On Thu, Jul 30, 2009 at 5:03 PM, Evan Martine...@chromium.org wrote: On Thu, Jul 30, 2009 at 4:20 PM, Eric Romanero...@chromium.org wrote: Regarding the class naming in the Out of process design, the convention I've seen most often is to have FooHost classes run in the browser with Foo classes in child processes. Yeah, I always get confused on which endpoint should be called Host. My thinking was from the perspective of the consumer -- the local (in-process) component we talk to is named XXX. And then XXX vends the functionality of an out-of-process component named XXXHost. (At least that is how I always understood the relationship between ResourceDispatcher / ResourceDispatcherHost). I could be on crack, in which case I will flip the names. For renderers, plugins, and child processes in general, Host means the outer thing, in an ownership sense, which means the browser process side of it. I don't know anything about ResourceDispatcher though. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Temporarily disable tcmalloc in build
On Sun, Aug 2, 2009 at 11:12 AM, Carlos Pizano c...@google.com wrote: On Sun, Aug 2, 2009 at 10:43 AM, Mike Belshe mbel...@google.com wrote: On Sat, Aug 1, 2009 at 10:53 PM, Huan Ren hu...@google.com wrote: - The crash rates on chromebot are comparable for builds with and without tcmalloc. The crash rate for tcmalloc build is higher but it seems within error margin. - Wtih tcmalloc disabled, there are some promising data from Purify test run and ChromeBot run with full page heap enabled. These are still under further investigation. BTW, all the server guys have tcmalloc heap profiling enabled by default; they can pinpoint leaks at process exit by default on their servers (when I saw the tool recently, I was very impressed!) Jim and Will investigated with CraigS - turns out that this portion of tcmalloc isn't in the public-domain version of tcmalloc which we use. If we help Craig get this part of tcmalloc open sourced, we can get much of purify in 'by default'. - The performance results are same as last time we compared. With tcmalloc, the most perf gain is from page-cycler-moz: 15% improvement (with 25% more memory usage). The perfor gain on page-cycler-more-js is 4%, as we see tcmalloc has no perf impact on V8 benchmark. The performance gain on DOM is significant: from score 325 to 414. I thought it was also interesting to look at the tcmalloc benefits on XP vs Vista (we had observed this before too). It's clear that Microsoft substantially improved the heap on Vista - while the gains on XP were 8-9% for the intl page cyclers on XP, the gains were only 1-2% on Vista. Similarly for the DOM and other tests, Vista gains for tcmalloc are always substantially less than on XP. I have said this several times. Here it goes again. You can get the Vista heap goodness in XP + SP2. It is the LFH option which was (or is) in our code already. Both the extra speed boost and the extra memory bloat. The tricks are the same; we don't have a monopoly on cool heap tricks. Carlos - I believe your claims about LFH are false. Microsoft has documented Vista-specific heap improvements above and beyond using LFH for SMP scaling. LFH was tested. But it is slower than tcmalloc by ~12%. Here are the results for default heaps, lfh heaps, and tcmalloc heaps on XPSP2: http://dom-perf-backend.prom.corp.google.com/compare?ids=1058004,1056005,1058002 tcmalloc also has other benefits: - it's portable to other platforms - we have full source and can improve it The only reason I haven't opposed more strongly tcmalloc is because I hope it also helps the other platforms be fast. The thing I did not know and that floors me is that since then we have no diagnostics. I did know that we lost pageheap but I assumed all along we had the diagnostics of this page ( http://goog-perftools.sourceforge.net/doc/heap_checker.html). My current understanding is we have none. We have lots of diagnostics. The problem we're having here is a crash which is undetected by all tools with *or without* tcmalloc. Neither purify nor page heap have been able to detect this problem so far. Some heap corruption problems are hard to track - but blaming tcmalloc for them doesn't make any sense. The heap-checker tools you mention can probably be enabled with some amount of work - it's just work. There are other portions of tcmalloc which need still to be ported to windows. Whether they would help with locating this particular crash or not - I don't know. Given that none of our other tools are helping - I'm guessing the problem is that we're not testing the right things - not that our diagnostics don't work. I don't know what decision process we go for choosing the allocator but lack of diagnostics is a deal breaker to me. I hope we can go back to LFH on windows until such time the diagnostics are there. Maybe it is too much of a pain to have this difference. If you have specific examples of where tcmalloc has been hurting us on this front, please send me the examples. So far, while we've hoped that turning off tcmalloc would help with our diagnostics - it hasn't. We also run many of our tests without tcmalloc - so we're now getting the benefit of having different allocators test our code. I think this is good. Don't take this as a conclusion on my part that tcmalloc is perfect - it needs lots more work, and I'm certain we can still make huge memory improvements by continuing work on our allocator. We can also add more diagnostics support. But at this point it is faster and has not sacrificed debugging tools. Mike We might want to look more closely at Win7; I don't think the heap changed much from Vista to Win7, but maybe eventually tcmalloc won't be interesting. Or - if we can reduce webkit heap usage, maybe we can make it so that tcmalloc on vista doesn't improve anything. Mike r22251 re-enables tcmalloc on trunk. We can merge 22080 to dev branch if needed.
[chromium-dev] Can someone compile this patch for me?
Hi all,
I don't have the resources (disk space + tools) to compile my patch under
Windows and OSX, so can someone on this list quickly try it before I post it
for review? And on Windows, do a sanity check on the about:memory page.
Patch is attached.
Thanks,
- Anand
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
Index: base/process_util.h
===
--- base/process_util.h (revision 22256)
+++ base/process_util.h (working copy)
@@ -293,6 +293,7 @@
// shared :These pages (kbytes) are currently shared with at least one
// other process.
struct WorkingSetKBytes {
+ WorkingSetKBytes() : priv(0), shareable(0), shared(0) {}
size_t priv;
size_t shareable;
size_t shared;
@@ -305,6 +306,7 @@
// image: These pages are mapped into the view of an image section (backed by
// file system)
struct CommittedKBytes {
+ CommittedKBytes() : priv(0), mapped(0), image(0) {}
size_t priv;
size_t mapped;
size_t image;
Index: base/process_util_linux.cc
===
--- base/process_util_linux.cc (revision 22256)
+++ base/process_util_linux.cc (working copy)
@@ -326,6 +326,71 @@
return 0;
}
+void ProcessMetrics::GetCommittedKBytes(CommittedKBytes* usage) const {
+ FilePath stat_file =
+FilePath(/proc).Append(IntToString(process_)).Append(maps);
+ std::string maps;
+ size_t file_mapped_size = 0;
+ size_t anon_size = 0;
+ size_t private_size = 0;
+ if (!file_util::ReadFileToString(stat_file, maps))
+return;
+
+ std::vectorstd::string map_lines;
+ SplitString(maps, '\n', map_lines);
+ for (std::vectorstd::string::iterator iter = map_lines.begin();
+ iter != map_lines.end(); ++iter) {
+if (*iter == ) {
+ continue;
+}
+
+std::vectorstd::string fields;
+SplitString(*iter, ' ', fields);
+if (fields.size() 5) {
+ LOG(ERROR) Badly formatted /proc/*/maps line: *iter;
+ continue;
+}
+
+// First fields is memory range, which gives us size. Formatted as:
+// -
+unsigned int sep_pos = fields[0].find('-');
+if (sep_pos == std::string::npos) {
+ LOG(ERROR) Badly formatted address range: fields[0];
+ continue;
+}
+int address_begin = HexStringToInt(fields[0].substr(0, sep_pos));
+int address_end = HexStringToInt(fields[0].substr(sep_pos + 1));
+if (address_end address_begin)
+ continue;
+size_t size = address_end - address_begin;
+
+// Second field is permissions formatted as:
+// [r-][w-][x-][ps]
+// Where:
+// r = read
+// w = write
+// x = execute
+// p = private
+// s = shared
+if (fields[1][3] == 'p')
+ private_size += size;
+
+// Fifth field is inode. If non-zero, this memory region is mapped by a
+// file.
+int inode = 0;
+StringToInt(fields[4], inode);
+if (inode) {
+ file_mapped_size += size;
+} else {
+ anon_size += size;
+}
+ }
+
+ usage-priv = private_size / 1024;
+ usage-image = file_mapped_size / 1024;
+ usage-mapped = anon_size / 1024;
+}
+
// Private and Shared working set sizes are obtained from /proc/pid/smaps,
// as in http://www.pixelbeat.org/scripts/ps_mem.py
bool ProcessMetrics::GetWorkingSetKBytes(WorkingSetKBytes* ws_usage) const {
@@ -367,13 +432,14 @@
}
}
ws_usage-priv = private_kb;
- // Sharable is not calculated, as it does not provide interesting data.
- ws_usage-shareable = 0;
if (have_pss) {
- ws_usage-shared = pss_kb - private_kb;
+ws_usage-shared = pss_kb - private_kb;
} else {
ws_usage-shared = shared_kb;
}
+ // Shared pages are sharable, so even if this isn't that useful, fill it in
+ // with the most sensible value since the about:memory handler page needs it.
+ ws_usage-shareable = ws_usage-shared;
return true;
}
Index: chrome/browser/memory_details_linux.cc
===
--- chrome/browser/memory_details_linux.cc (revision 0)
+++ chrome/browser/memory_details_linux.cc (revision 0)
@@ -0,0 +1,106 @@
+// Copyright (c) 2006-2008 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include chrome/browser/memory_details.h
+
+#include app/l10n_util.h
+#include base/file_version_info.h
+#include base/string_util.h
+#include chrome/browser/browser_process.h
+#include chrome/browser/chrome_thread.h
+#include chrome/common/child_process_host.h
+#include chrome/common/url_constants.h
+#include grit/chromium_strings.h
+
+// Known browsers which we collect details for.
+enum _BrowserProcess {
+
[chromium-dev] Re: Can someone compile this patch for me?
Hello, thanks for the patch, but if you post it on the code review site, we can send it to the try servers where it will build / test it for you. It is easier to apply the patch through code review than manually. -- Mohamed Mansour On Sun, Aug 2, 2009 at 10:05 PM, Anand Mistry akmis...@gmail.com wrote: Hi all, I don't have the resources (disk space + tools) to compile my patch under Windows and OSX, so can someone on this list quickly try it before I post it for review? And on Windows, do a sanity check on the about:memory page. Patch is attached. Thanks, - Anand --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Can someone compile this patch for me?
Hello, On Mon, Aug 3, 2009 at 11:35, Anand Mistryakmis...@gmail.com wrote: Hi all, I don't have the resources (disk space + tools) to compile my patch under Windows and OSX, so can someone on this list quickly try it before I post it for review? And on Windows, do a sanity check on the about:memory page. Patch is attached. The linux memory reporting code is something I have been working on recently, thanks for taking it further. If you upload the patch to codereview.chromium.org, one of the chromium devs can submit it to the tryservers which build for all supported platforms. This process is also used for code review rather than submitting patches to the mailing list. http://dev.chromium.org/developers/contributing-code Cheers, Joel --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Can someone compile this patch for me?
Thanks to all. I didn't know about the try bot, so I've posted the patch for review and I'm watching the buildbot. On Mon, Aug 3, 2009 at 12:15 PM, Joel Stanley j...@jms.id.au wrote: Hello, On Mon, Aug 3, 2009 at 11:35, Anand Mistryakmis...@gmail.com wrote: Hi all, I don't have the resources (disk space + tools) to compile my patch under Windows and OSX, so can someone on this list quickly try it before I post it for review? And on Windows, do a sanity check on the about:memory page. Patch is attached. The linux memory reporting code is something I have been working on recently, thanks for taking it further. If you upload the patch to codereview.chromium.org, one of the chromium devs can submit it to the tryservers which build for all supported platforms. This process is also used for code review rather than submitting patches to the mailing list. http://dev.chromium.org/developers/contributing-code Cheers, Joel --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] 2 Questions about Npapi (and flash in particular)
This is mostly related to problems people have in the help forum 1- you fork a process for npapi plugins, but many people report that if they have a bookmark folder with loads of flash content, they get an 'Aw Snap' or the lucky ones get OUt of Script memory this only happens if they do it fast, my question is are you running out of Address space (this mostly happens for 64bit vista but also 32XP and vista) 2- you have the 'safe-plugins' option which seems to really work good, is it ok to recommend it to people ? it seems to work great for flash and silverlight --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: 2 Questions about Npapi (and flash in particular)
i have none. if i could do it on my machine i would debug it and (fopefully) find the root cause my intention in posting it here is that maybe the person who wrote NPAPI will say oh, this makes sense or maybe this thread will die .. anyways, the address space issue seems to make sense in a way, but then again, i never wrote anything with flash or anything like it, so i don't know how they handle the Address space issues (they really have only one process for the plugin) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: 2 Questions about Npapi (and flash in particular)
On Sun, Aug 2, 2009 at 8:17 PM, nakroyoav.zilberb...@gmail.com wrote: This is mostly related to problems people have in the help forum 1- you fork a process for npapi plugins, but many people report that if they have a bookmark folder with loads of flash content, they get an 'Aw Snap' or the lucky ones get OUt of Script memory Got any actual repro cases? :) That would be very helpful. :DG --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Copy URL as plain text instead of HTML
On Sat, Aug 1, 2009 at 9:53 AM, ptr727 pieter.vilj...@gmail.com wrote: I looked at the defect filing, and the immediate reply that it was as designed. Maybe pointing to this thread would provide more details around the expected behavior, and why, i.e. why copying URL should only place text in the clipboard. I commented on the duplicate this bug was merged into. I think there's been a lack of clarity in the request here. The problem is not that the text is a link; the problem is that the text is keeping its font, color, etc. There may be a way to eliminate one and preserve the other. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Copy URL as plain text instead of HTML
On Sun, Aug 2, 2009 at 8:35 PM, Peter Kastingpkast...@google.com wrote: I commented on the duplicate this bug was merged into. I think there's been a lack of clarity in the request here. The problem is not that the text is a link; the problem is that the text is keeping its font, color, etc. There may be a way to eliminate one and preserve the other. Yeah, the font color issue is a long-standing bug. I looked into it for a few hours a while ago. I think we're not intercepting the copy event properly in the omnibox. Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Can someone compile this patch for me?
Very nice, it passed all the try bot! I am adding Evan Marting and Evan Stade to the reviewers! Thanks for your patch! -- Mohamed Mansour On Sun, Aug 2, 2009 at 11:11 PM, Anand Mistry akmis...@gmail.com wrote: Thanks to all. I didn't know about the try bot, so I've posted the patch for review and I'm watching the buildbot. On Mon, Aug 3, 2009 at 12:15 PM, Joel Stanley j...@jms.id.au wrote: Hello, On Mon, Aug 3, 2009 at 11:35, Anand Mistryakmis...@gmail.com wrote: Hi all, I don't have the resources (disk space + tools) to compile my patch under Windows and OSX, so can someone on this list quickly try it before I post it for review? And on Windows, do a sanity check on the about:memory page. Patch is attached. The linux memory reporting code is something I have been working on recently, thanks for taking it further. If you upload the patch to codereview.chromium.org, one of the chromium devs can submit it to the tryservers which build for all supported platforms. This process is also used for code review rather than submitting patches to the mailing list. http://dev.chromium.org/developers/contributing-code Cheers, Joel --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: new hunspell has tons of valgrind warnings... revert?
On Sat, Aug 1, 2009 at 4:34 PM, Dan Kegeld...@kegel.com wrote: I suppose you could try running the hunspell test suite itself under valgrind. Their README tells how to do it, but when I tried, I couldn't get it to work. (Wonder if that means they haven't run it, either?) Hi Dan, Purify has some problems with tracking memory that the OS memory maps, and it ends up giving uninitialized memory reads for any 0xCCs that the OS memory maps (since it doesn't see the write). Does Valgrind have a similar problem? Most of the data is memory mapped. It seems unlikely to me given we didn't have this problem before, but it's worth checking. My main concern is: who is working on this? It's OK like this for a couple of days I guess, but this seems like a potentially serious problem we don't want to file a bug and get to it later. It also seems like Mohammed will need help, and I'll be out part of next week (still figuring out the days). If we can't fond somebody to look at this soon, we should probably back out until there is somebody. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: 2 Questions about Npapi (and flash in particular)
On Sun, Aug 2, 2009 at 8:17 PM, nakroyoav.zilberb...@gmail.com wrote: This is mostly related to problems people have in the help forum 1- you fork a process for npapi plugins, but many people report that if they have a bookmark folder with loads of flash content, they get an 'Aw Snap' or the lucky ones get OUt of Script memory Sounds like a race. If someone would submit the list of bookmarks in such a folder I bet John could reproduce it. this only happens if they do it fast, my question is are you running out of Address space (this mostly happens for 64bit vista but also 32XP and vista) 1) Address space is per-process. 2) We use a single process for all Flash content, so it should be comparable to the way it works in a single-process browser. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Can someone compile this patch for me?
On Sun, Aug 2, 2009 at 7:15 PM, Joel Stanleyj...@jms.id.au wrote: On Mon, Aug 3, 2009 at 11:35, Anand Mistryakmis...@gmail.com wrote: Hi all, I don't have the resources (disk space + tools) to compile my patch under Windows and OSX, so can someone on this list quickly try it before I post it for review? And on Windows, do a sanity check on the about:memory page. Patch is attached. The linux memory reporting code is something I have been working on recently, thanks for taking it further. If you upload the patch to codereview.chromium.org, one of the chromium devs can submit it to the tryservers which build for all supported platforms. This process is also used for code review rather than submitting patches to the mailing list. http://codereview.chromium.org/159777 Your feedback on it would be helpful too, Joel. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: 2 Questions about Npapi (and flash in particular)
Evan thanx, but the 2nd part of the --safe-plugins, i know it works on dev, and it does seem to create the plugininside the sandbox, so is this a good solution security wise to suggest to people ? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: 2 Questions about Npapi (and flash in particular)
On Sun, Aug 2, 2009 at 10:39 PM, yoav zilberbergyoav.zilberb...@gmail.com wrote: Evan thanx, but the 2nd part of the --safe-plugins, i know it works on dev, and it does seem to create the plugin inside the sandbox, so is this a good solution security wise to suggest to people ? I don't know this flag, but one reason we don't do plugin sandboxing is that it disables security updates for plugins. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
