Is the zero versioned executable intentional?I mean, when you look at the
properties for chrome.exe, it always has 0.0.0.0 as a version.
Now, I know the executable is not always changing (f I understand correctly,
most of the changes are in the DLL), so perhaps it should have its own
versioning
This also broke building from the command line.
I usually never open Visual Studio as an IDE. I build on the command
line with something like:
devenv chrome\\chrome.sln /Build release /Project test_shell
It looks like project names like test_shell now have complicated names
like test_shell
Additionally it seems like I'm getting no parallelism. I checked my
visual studio settings and everything seems fine. Attached is a
screenshot of how my CPU usage has looked for the entire processing of
building test_shell (from chrome.sln).
-- dean
On Fri, Jun 19, 2009 at 12:10 PM, Dean
http://crbug.com/14609 ...
In the renderer we need to run Cocoa on a non-main thread. To pump
windowserver events we need to pump on the main thread. And when we do so
timers and notifications fire, screwing us over. I think the timers and
notifications were not fired before, right?
In the short
On Fri, Jun 19, 2009 at 6:44 AM, Avi Drissmana...@google.com wrote:
In the long term, I think this is yet another reminder about getting Cocoa
out of the renderer... :)
What do you use Cocoa in the renderer for?
Does that include Core Graphics?
Or is it just for widget rendering?
Core Graphics is a level lower than Cocoa, and as the main way to draw on
the Mac would be OK to use. I don't know what we use Cocoa for. I think
widget rendering but I could be wrong.
Avi
On Fri, Jun 19, 2009 at 10:58 AM, Evan Martin e...@chromium.org wrote:
On Fri, Jun 19, 2009 at 6:44 AM,
[resend to chromium-dev from correct address; apologies if you get a dup.]
I just landed a change (r18813) that may take care of a good number of the
spurious rebuilds.
Some of the .dll files are built as 'loadable_module' targets, which
basically means they don't have any actual code (e.g. only
Our team has had somewhat of an ad-hoc approach to organizing code
that's different across platforms. In many cases our approach has been
quite good. In others, less so, and there have also been questions
about what the preferred method for writing a certain component in a
cross-platform way.
Hi folks,
I'm currently investigating the possibility of using SSBs (Site
Specific Browsers, another example is mozilla's Prism) to ship
alongside a commercial web application, the application does not
depend on the SSB in any way just makes it more acceptable to
corporations who are opposed to
In
http://dev.chromium.org/developers/design-documents/multi-process-resource-loading,
all I/O in Render Process (WebKit code) is sent to Browser Process and
Browser process is download the resource from the source.
But what about Plugins (flash) which runs inside RenderProcess? How can
those I/O
Developers would surely appreciate some kind of developer mode. Safari
makes it nearly impossible to remove an appcache. Refreshing, emptying
the cache nor resetting the browser helps in this. MobileSafari
behaves about the same -- something like a notice with a force refresh
option its developer
Pi, If you've tested this on a Vista lemme know.Plz check on WinRC6 coz
there might be
changes in the latest Vista RC; not to mention chrome version changes.
This looks like a k00l bug :P
On Thu, Jun 18, 2009 at 1:53 PM, pi zhu.she...@gmail.com wrote:
Thank Nicolas for your clarify.
Today I
This is awesome! A great read and a good use of examples from our code.
Is it worth being more explicit about using MVC to design a new
component? Right now it's exemplified in the context of how to
allocate memory for the various objects, but a concrete example (the
TabStripModel is a good
I am not a lawyer, but that is the intent.
(In some sense Google Chrome is just a commercial consumer of the code
base as well. As I understand it, contributors retain copyright on
their contributions, so it's not even the case that Google owns all
the code that mentions Google in the
Ah! That did the trick; thanks.
On Jun 19, 10:24 am, Dimitri Glazkov dglaz...@google.com wrote:
Since Audio object will be instantiated via JS, we need to add extra 2
lines to that huge switch statement in V8Proxy::GetTemplate:
case V8ClassIndex::HTMLIMAGEELEMENT:
Just a heads-up, I imagine the various pages such as
http://dev.chromium.org/developers/how-tos/build-instructions-windows
will now need updating, I managed to do my first build of chrome last
night, and my second one this morning, until I read this post I
thought I was going insane g
- cj.
On
See http://dev.chromium.org/developers/design-documents/plugin-architecturefor
some more details.
TVL
On Fri, Jun 19, 2009 at 1:51 PM, Evan Martin e...@chromium.org wrote:
On Thu, Jun 18, 2009 at 12:15 AM, n179911n179...@gmail.com wrote:
In
You may also want to say something about TODO(port) and
NOTIMPLEMENTED()s vs. bugs. Just some conventions patterns I could
think about.
On Fri, Jun 19, 2009 at 18:42, Brett Wilsonbre...@chromium.org wrote:
Last night Ben and I wrote a document that tries to clarify this. It's
a combination of
This is a great overview! Thanks for writing this up.
I wonder if it's worth giving some more guidance about when to use
#ifdef vs. say splitting out a couple of methods into a
platform-specific file. For example: if you find yourself wrapping
the entire body of a function in platform #ifdefs,
On Fri, Jun 19, 2009 at 9:42 AM, Brett Wilson bre...@chromium.org wrote:
Our team has had somewhat of an ad-hoc approach to organizing code
that's different across platforms. In many cases our approach has been
quite good. In others, less so, and there have also been questions
about what the
On Fri, Jun 19, 2009 at 11:07 AM, Nicolas Sylvain nsylv...@chromium.orgwrote:
We should say that we prefer #if defined(OS_WIN) over #ifdef OS_WIN.
In general, you should always prefer #if defined(FOO) over #ifdef FOO,
e.g. because you can add || defined(BAR) to the former later.
PK
On Fri, Jun 19, 2009 at 2:11 PM, Peter Kastingpkast...@google.com wrote:
On Fri, Jun 19, 2009 at 11:07 AM, Nicolas Sylvain nsylv...@chromium.org
wrote:
We should say that we prefer #if defined(OS_WIN) over #ifdef OS_WIN.
In general, you should always prefer #if defined(FOO) over #ifdef
On Fri, Jun 19, 2009 at 11:15 AM, Mike Pinkerton pinker...@chromium.orgwrote:
This is already documented in our Chromium coding style guide. Do we
need to replicate it?
No, I was just mentioning that it was a broad principle, not restricted to
cross-platform ifdefs.
PK
On Fri, Jun 19, 2009 at 11:15 AM, Mike Pinkerton pinker...@chromium.orgwrote:
On Fri, Jun 19, 2009 at 2:11 PM, Peter Kastingpkast...@google.com wrote:
On Fri, Jun 19, 2009 at 11:07 AM, Nicolas Sylvain nsylv...@chromium.org
wrote:
We should say that we prefer #if defined(OS_WIN) over
I think this is a really good idea, something Maciej has been doing
for us in bugs.webkit.org:
Anytime you create a WebKit bug that's specific to Chromium port,
please add [Chromium] prefix to the bug title.
:DG
--~--~-~--~~~---~--~~
Chromium Developers mailing
On Fri, Jun 19, 2009 at 11:51 AM, Dimitri Glazkov dglaz...@google.comwrote:
Anytime you create a WebKit bug that's specific to Chromium port,
please add [Chromium] prefix to the bug title.
Note:
DON'T do this is this is a cross-platform fix that happens to have
been found by/affect Chromium.
I'm hoping to be able to add Icelandic spelling check to Chrome Before I
invest a lot of time I have some quick questions/observations:
I found an myspell/aspell dictionary for Open Office here:
http://wiki.services.openoffice.org/wiki/Dictionaries#Icelandic_.28Iceland.29
and converted
it to
On Fri, Jun 19, 2009 at 1:15 PM, Sverrir Á. Bergsver...@chromium.org wrote:
I'm hoping to be able to add Icelandic spelling check to Chrome Before I
invest a lot of time I have some quick questions/observations:
I found an myspell/aspell dictionary for Open Office
here:
On Fri, Jun 19, 2009 at 1:15 PM, Sverrir Á. Bergsver...@chromium.org wrote:
Distribution: If I get this to more or less work - how would it possible to
distribute it? I want of course the Language Selection UI to have Icelandic
and support automatic download of the dictionary.
Sounds like a
Ok so I've tracked down the issue with 'test_shell' not working as a command
line target.The issue is that folders in the solution hierarchy apparently
cause an ambiguity so devenv doesn't know which one you're referring to, the
test_shell folder or the test_shell project.
So for instance
Is building the folder expected behaviour, or something we should file with
Microsoft? Could just be me but Build project name seems pretty
unambiguous that I want to build a project and not a folder...
Thanks for looking into the issue!
Andrew
On Fri, Jun 19, 2009 at 1:53 PM, Bradley Nelson
I wonder if it would suffice to reorder the project blocks:
Project({2150E333-8FDC-42A3-9474-1A3956D46DE8}) = test_shell,
webkit\tools\test_shell, {6CB66C51-6A84-2C9C-0561-7D059D26064E}
Project({8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}) = test_shell,
..\webkit\tools\test_shell\test_shell.vcproj,
It doesn't seem to, am I missing something?-BradN
On Fri, Jun 19, 2009 at 3:06 PM, Nick Carter n...@chromium.org wrote:
I wonder if it would suffice to reorder the project blocks:
Project({2150E333-8FDC-42A3-9474-1A3956D46DE8}) = test_shell,
webkit\tools\test_shell,
If you didn't see my other mail to chromium-dev, I'll be trying to whack the
tr1 dependency next week. That should hopefully fix the issue you were
having. Will update this thread again when the patch is committed.
-Albert
On Mon, Jun 15, 2009 at 9:11 AM, Albert J. Wong (王重傑)
34 matches
Mail list logo
