We could make fully self-sufficient tarballs, but then we'd need three
separate ones, since the three platforms have different dependencies. (Or
we'd need to stick Mac and Linux developers with downloading a bigger
tarball than they need.) I think it's fair to require a sync after
downloading
The end result here sounds good to me. Just a few side comments:
* If we ever set up a directory for baselines common to all Chromium
platforms, it should be called 'chromium'. This matches the WebKit side,
where they have mac-tiger, mac-leopard, and mac. In fact, the layout-test
script is
Hey Evan,
I apologize for missing this discussion, I'm sure that I'm not seeing
the entire picture and the pros of this argument. I mentioned before
that I'm in support of utf-8 everywhere we can get it.
We are obviously going to have platform specific code for the UI
(win32 /
On Wed, Feb 4, 2009 at 6:53 AM, Dean McNamee de...@chromium.org wrote:
I apologize for missing this discussion, I'm sure that I'm not seeing
the entire picture and the pros of this argument. I mentioned before
that I'm in support of utf-8 everywhere we can get it.
I lost this argument, so I
The proposal was to search-n-replace std::wstring to string16. We would
have to invent a macro to replace L usage. Most usages of string literals
are in unit tests, so it doesn't seem to matter if there is cost associated
with the macro.
My belief is that there isn't much fruit to be had by
On Wed, Feb 4, 2009 at 6:11 PM, Darin Fisher da...@chromium.org wrote:
The proposal was to search-n-replace std::wstring to string16. We would
have to invent a macro to replace L usage. Most usages of string literals
are in unit tests, so it doesn't seem to matter if there is cost associated
Trying to remember what came up along the discussion.
UTF16 is what Mac/win use, so there we can avoid a batch of conversions on
those two platforms. (Mac can take UTF8, but the system would still be
doing conversions to get things into a form it prefers)
Didn't someone say ICU needs things in
On Wed, Feb 4, 2009 at 9:35 AM, Dean McNamee de...@chromium.org wrote:
On Wed, Feb 4, 2009 at 6:11 PM, Darin Fisher da...@chromium.org wrote:
The proposal was to search-n-replace std::wstring to string16. We would
have to invent a macro to replace L usage. Most usages of string
literals
The big string area is webkit, of course. If webkit were 100% UTF-8
already, we might take a different stance on this issue as well.
If it is our goal to get to UTF-8 everywhere, then laying the plumbing for
utf8 strings rather than string16 strings seems like the right thing to do.
Mike
On
I didn't ask for plans before touching views/, so maybe I'll start doing it
now. So, I'd have just two questions (if the answer is Paweł, don't touch
browser/views for now that's an answer too):
- what does it mean for base/keyboard_codes.h (I checked this in shortly
before the discussion about
On Wed, Feb 4, 2009 at 10:31 AM, noemata ma...@noemata.org wrote:
Surely, it's not that hard to have three sets of archives that provide
a complete snapshot of a working build environment. Internal to
Google, you must gen these anyways, so what's the issue? All such
archives should deliver
[Reposting from wrong mailing list, sorry for dupe.]
On Mac/Linux, IPC::Channel uses socketpairs (or in some cases named
pipes), with one end passed through the spawn to the child process.
Right now the interfaces don't expose this dependency, so I'm thinking
of refactoring things a bit to do
On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess sh...@chromium.org wrote:
Adam mentioned on the wrong-mailing-list version of this thread that
it's accepted to wire file descriptors into fixed places. Either way,
my goal is to make sure that launching Chrome-internal helper tasks is
distinct
On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess sh...@chromium.org wrote:
[Reposting from wrong mailing list, sorry for dupe.]
On Mac/Linux, IPC::Channel uses socketpairs (or in some cases named
pipes), with one end passed through the spawn to the child process.
Right now the interfaces don't
On Wed, Feb 4, 2009 at 2:02 PM, Darin Fisher da...@chromium.org wrote:
On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess sh...@chromium.org wrote:
[Reposting from wrong mailing list, sorry for dupe.]
On Mac/Linux, IPC::Channel uses socketpairs (or in some cases named
pipes), with one end passed
On Wed, Feb 4, 2009 at 11:02 AM, Darin Fisher da...@chromium.org wrote:
On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess sh...@chromium.org wrote:
On Mac/Linux, IPC::Channel uses socketpairs (or in some cases named
pipes), with one end passed through the spawn to the child process.
Right now the
On Wed, Feb 4, 2009 at 11:10 AM, Thomas Van Lenten
thoma...@chromium.org wrote:
On Wed, Feb 4, 2009 at 2:02 PM, Darin Fisher da...@chromium.org wrote:
On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess sh...@chromium.org wrote:
[Reposting from wrong mailing list, sorry for dupe.]
On Mac/Linux,
+1 for Renderer/PluginLauncher()
+1 for moving IPC out of /chrome/common, in very own library.
Stoyan
On Wed, Feb 4, 2009 at 11:30 AM, Scott Hess sh...@chromium.org wrote:
On Wed, Feb 4, 2009 at 11:10 AM, Thomas Van Lenten
thoma...@chromium.org wrote:
On Wed, Feb 4, 2009 at 2:02 PM, Darin
I recently tried to port chrome/browser/safe_browsing/protocol_manager.cc to
Linux, but there's one problem. ProtocolManager uses hash_map of
URLFetcher*-s, and GCC needs a hash function for it.
I see many ways we can deal with that, and I discussed some of them on irc
and in review. The result
2009/2/4 Paweł Hajdan Jr. phajdan...@chromium.org:
I recently tried to port chrome/browser/safe_browsing/protocol_manager.cc to
Linux, but there's one problem. ProtocolManager uses hash_map of
URLFetcher*-s, and GCC needs a hash function for it.
I see many ways we can deal with that, and I
I had a similar problem. I used an svn checkout. The entrire
third_party/cygwin directory went missing in the tarball.
Also, I suggest aria2c to download the tarball in the future which is
better than the browser.
On Feb 4, 10:33 am, Evan Martin e...@chromium.org wrote:
On Wed, Feb 4, 2009 at
We don't launch renderers using LaunchApp, we use broker_service-
SpawnTarget(). I guess in other platforms that don't have a sandbox
you can replace that for whatever you want.
You can see BrowserRenderProcessHost::Init() for all the cruft that we
need to launch a renderer, I don't see a good
+1 to string16
I can't make performance or memory saving claims with a straight face
for any. We just don't process enough strings for us to matter.
On Feb 4, 9:57 am, Mike Belshe mbel...@google.com wrote:
The big string area is webkit, of course. If webkit were 100% UTF-8
already, we might
On Wed, Feb 4, 2009 at 5:12 PM, cpu c...@chromium.org wrote:
We don't launch renderers using LaunchApp, we use broker_service-
SpawnTarget(). I guess in other platforms that don't have a sandbox
you can replace that for whatever you want.
You can see BrowserRenderProcessHost::Init() for all
If you've ever tried running strace on our binaries, you've probably
noticed the Ubuntu version messes up a lot because it cannot decode
the 32-bit structures correctly. For example:
[pid 21205] ... recvmsg resumed {msg_name(-11664)=NULL,
msg_iov(18446693667973365760)=0x8254b28,
On Wed, Feb 4, 2009 at 2:58 PM, Adam Langley a...@chromium.org wrote:
If you've ever tried running strace on our binaries, you've probably
noticed the Ubuntu version messes up a lot because it cannot decode
the 32-bit structures correctly. For example:
[pid 21205] ... recvmsg resumed
On Wed, Feb 4, 2009 at 3:56 PM, Evan Martin e...@chromium.org wrote:
Probably this one is good:
http://code.google.com/p/chromium/wiki/LinuxBuild64Bit
Since it's where we put all of the hacks you need to do for 64-bit.
Done
AGL
--~--~-~--~~~---~--~~
In r9193, I made a change that will require you to force rebuild your
test_shell.pak file. You can either clobber your whole tree or
just delete all .pak files in your Hammer dir (find Hammer -name *.pak
| xargs rm) and rebuild.
I will try to fix the SCons dependencies so this doesn't happen in
I wrote up a short design doc covering what our extension process model will
look like. Feedback welcome.
http://dev.chromium.org/developers/design-documents/extensions/process-model
--~--~-~--~~~---~--~~
Chromium Developers mailing list:
This seems good-- I like the fact that the chrome parts of each extension
are isolated from page content and have to use message passing. That will
make it easier to understand which extensions actually need to access page
content.
One small wording question, just be sure I'm clear:
Process
On Wed, Feb 4, 2009 at 6:07 PM, Charles Reis cr...@chromium.org wrote:
This seems good-- I like the fact that the chrome parts of each extension
are isolated from page content and have to use message passing. That will
make it easier to understand which extensions actually need to access page
31 matches
Mail list logo
