Firefox behaves terribly upon update on Linux because
they didn't bother even trying to make distro updates
work well, and everybody uses distro packages for Firefox.
Let's avoid this same problem on Chrome for Linux.
Does that sound like a reasonable goal? We're
early enough in the port that it
If file structure on Linux is anywhere like Windows than the shared library
(chrome.dll on Windows) would be versioned (the dll is kept inside a version
directory on Windows) but the executable itself (chrome.exe) will always
live at the same place.
On Linux are we going to allow Chrome updates to
Are there any implications for sandboxing on the fork vs exec ? I
don't want us to paint ourselves in a corner when we implement the
sandbox.
On Feb 5, 9:57 am, Rahul Kuchhal kuch...@chromium.org wrote:
If file structure on Linux is anywhere like Windows than the shared library
(chrome.dll on
I think the current plan is to have a zygote used to spawn sub processes
in which case it should be safe to change the chrome executable while it
is running. The running chrome process won't depend on disk for anything
(all data files are mmapped at process start up).
On Thu, 5 Feb 2009, cpu
I've gone through the code and removed all such occurrences. This
speeds up the build from 15 to 13 minutes (using /MP on quadcore with
SSD). It also means that editing that file only rebuilds 36 files
instead of 200.
There shouldn't be any reason to include that file from a header. The
reason
I know that user scripts has a known meaning, but in the context of
this code it is a rather strange name.
// these two are loaded into the extension process
chrome_scripts: [chrome/main.js],
toolstrip: chrome/toolstrip.html,
// this is loaded into renderers
user_scripts: {
Have you
(arg. reposting again)
One thing that scons is very good at is dependency analysis. Is it
possible to get it to spit out a dependency report (which files depend
on each file in the project)? I wonder if we might find that files
like npapi.h don't actually need to touch everything, etc.
Erik
On Thu, Feb 5, 2009 at 11:29 AM, Matt Perry mpcompl...@chromium.org wrote:
On Thu, Feb 5, 2009 at 10:35 AM, John Abd-El-Malek j...@chromium.org wrote:
Looks good, one comment: previously there's been some high level
comments about how workers can be used to give extensions a long lived
Will it be possible to create Chrome extensions with binary components? For
instance, Mozilla extensions can distribute and access XPCOM components.
On Wed, Feb 4, 2009 at 8:49 PM, Matt Perry mpcompl...@chromium.org wrote:
I wrote up a short design doc covering what our extension process model
On Thu, Feb 5, 2009 at 11:51 AM, Marshall Greenblatt
magreenbl...@gmail.com wrote:
Will it be possible to create Chrome extensions with binary components? For
instance, Mozilla extensions can distribute and access XPCOM components.
We were thinking that you could use NPAPI for binary
Since I don't know how zygote works I will just throw it out there - what
will happen if Chrome gets updated while it is already running and user
tries to launch another instance of Chrome browser (from a shortcut or from
command line)? I am guessing if its the same profile the new chrome will
Hi Erik--
It depends on what you really want. SCons does have all of the
dependencies, but it doesn't keep the #include tree.
Tangible example: if foo.c #includes inc.h, and inc.h also #includes
both a.h and b.h, the resulting dependency list actually looks like:
foo.o: foo.c inc.h a.h b.h
(sorry for repost, gmail sucks and I have a short memory)
On Thu, Feb 5, 2009 at 2:51 PM, Steven Knight s...@chromium.org wrote:
Hi Erik--
It depends on what you really want. SCons does have all of the
dependencies, but it doesn't keep the #include tree.
Tangible example: if foo.c
On Thu, Feb 05, 2009 at 04:04:58PM -0800, Peter Kasting wrote:
On Thu, Feb 5, 2009 at 4:02 PM, Erik Kay erik...@chromium.org wrote:
$ scons_deps -v target
foo.c:inc.h:a.h
foo.c:inc.h:b.h
bar.c:bar.h
etc.
Does such a script (or something similar) exist? From what you're
saying,
On Thu, Feb 5, 2009 at 4:21 PM, James Vega vega.ja...@gmail.com wrote:
On Thu, Feb 05, 2009 at 04:04:58PM -0800, Peter Kasting wrote:
On Thu, Feb 5, 2009 at 4:02 PM, Erik Kay erik...@chromium.org wrote:
$ scons_deps -v target
foo.c:inc.h:a.h
foo.c:inc.h:b.h
bar.c:bar.h
etc.
Does
On Thu, Feb 5, 2009 at 4:35 PM, Lei Zhang thes...@chromium.org wrote:
I did the same with -MM and parsed the results. Assuming I did it
right, the average .cc file in src/chrome/ includes about 135 header
files. The files with the most number of includes:
440 about_chrome_view.o
470
FYI, on windows, you use --wait-for-debugger and use the macro at
http://code.google.com/p/chromium/wiki/WindowsVisualStudioMacros#Automatically_grab_chromium_child_processes
If XCode can be automated, you could probably achieve the same thing.
M-A
On Thu, Feb 5, 2009 at 4:57 PM, Jeremy
On Thu, Feb 5, 2009 at 9:29 PM, Ian Fette i...@chromium.org wrote:
Once again, my laptop is refusing to stand by and Windows is throwing up
warning dialogs about Insufficient system resources exist to complete the
API. Currently Chrome is sucking down a healthy 1043 gdi handles according
to
Across all. The most of any one process (I think it was the browser process,
but not 100% sure, could be a long-lived renderer) was something like 300
total handles, 150 of which were font.
On Thu, Feb 5, 2009 at 10:11 PM, Brett Wilson bre...@chromium.org wrote:
On Thu, Feb 5, 2009 at 9:29 PM,
19 matches
Mail list logo
