On Mon, Nov 2, 2009 at 10:27 PM, n179911 wrote:
>
> Hi,
>
> I have tried syncing up chromium HEAD by doing this (since i use git
> for chromium and webkit).
> $ git pull (update chromium)
> $ gclient sync
> $ tools/sync-webkit-git.py (update webkit)
>
> But i got the following errors when I compi
On Mon, Nov 2, 2009 at 10:27 PM, n179911 wrote:
>
> Hi,
>
> I have tried syncing up chromium HEAD by doing this (since i use git
> for chromium and webkit).
> $ git pull (update chromium)
> $ gclient sync
> $ tools/sync-webkit-git.py (update webkit)
>
Hi Samuel,
The error you're seeing might be
That's a good news. Can that info be put somewhere in the UsingGit wiki
page?
On Mon, Nov 2, 2009 at 23:56, Evan Martin wrote:
>
> On Mon, Nov 2, 2009 at 2:47 PM, Drew Wilson wrote:
> > I'm doing some refactoring in the chromium worker code, and I got the
> > following review feedback:
> > "sma
Hi,
I have tried syncing up chromium HEAD by doing this (since i use git
for chromium and webkit).
$ git pull (update chromium)
$ gclient sync
$ tools/sync-webkit-git.py (update webkit)
But i got the following errors when I compile it. It appears the
method 'CanvasRenderingContext3D::attachShade
That sounds interesting, but there are still two changes remaining and other
unrelated changes have gone in in the meantime, so it wouldn't be an apple
to apple comparison. I can let you know when I'm done though (when the bug
is marked fixed).
On Mon, Nov 2, 2009 at 10:09 PM, Huan Ren wrote:
>
Cool! I could compare the builds before and after these changes to see
what difference it makes. Of course it also prevents future issues.
Huan
On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek wrote:
> Over the last week, I've been making some changes to how threads are used in
> the browser p
Over the last week, I've been making some changes to how threads are used in
the browser process, with the goal of simplifying cross-thread access and
improving stability.
*The problem*
We were using a number of patterns that were problematic:
1) using ChromeThread::GetMessageLoop
-this isn't s
I'm sorry if my email came off as dismissive. I really would like to
see some serious study of user interfaces for certificate errors. I
think everyone agrees that the current designs can be improved. We
even know how to measure success (e.g.,
http://www.usenix.org/events/sec09/tech/full_papers
I now have a new response ready for the next "click to select all" thread:
"the best way to make your case is to write an academic paper and
conduct a user study that shows how the new UI out-performs the
current UI."
-- Evan Stade
--~--~-~--~~~---~--~~
Chromium
Just a reminder, this is happening now!
On Fri, Oct 30, 2009 at 1:14 PM, Tim Steele wrote:
> Hello!
>
> A heads-up that folks working on sync will be holding a test fixit next
> week, Nov 2 - 6. The motivation is to improve test coverage of our code, as
> there are many more chunks without any
S,o as it happens, I just had someone on nacl make the first use of multiple
inheritance this morning.
He hasn't checked it in yet, but the use case is:
'Common': {
# bunch of global stuff
'defines': [
# bunch of 32-bit defines.
],
},
'Debug': {
# bunch of general debug stuff assumes 3
We've got the "gypd" (d = debug) sorta-generator format as an option,
alongside xcode, msvs, make, etc. It dumps the dicts it receives as
.gypd files next to your .gyp files, so you can see what would be fed
to a generator. You might need to feed it some -D because it's not
tied to an OS by defa
> I was using dev. I think I just searched on Google and clicked
> through to whichever docs I found -- I didn't realize there were two
> sets. Should we always point users to trunk until extensions are in
> beta?
I don't think we can, since the generated API docs need to match
whatever the use
On Sun, Nov 1, 2009 at 3:26 PM, Bradley Nelson wrote:
> 1) Do you support multiple inheritance? I notice the "inherit_from" is
>> specified as an array. That's scaryish.
>>
> Multiple inheritance is supported, not sure it's wise to use, but well gyp
> has lots of features like that :-)
> I alm
On Mon, Nov 2, 2009 at 11:23 AM, Mike Hearn wrote:
> I'm concerned about the way Chromium displays SSL security indicators,
> which this blog post reminded me about:
>
> http://chrome.blogspot.com/2009/10/are-you-seeing-red.html
>
> There have been a few studies of SSL usability and the conclus
On Mon, Nov 2, 2009 at 2:47 PM, Drew Wilson wrote:
> I'm doing some refactoring in the chromium worker code, and I got the
> following review feedback:
> "small request: can the files that were branched from existing files be "svn
> copy'd" instead of copying manually and "svn added"? This will
Hi all,
I'm doing some refactoring in the chromium worker code, and I got the
following review feedback:
"small request: can the files that were branched from existing files be "svn
copy'd" instead of copying manually and "svn added"? This will preserve
history
and will make it easier to see wha
On Sat, Oct 31, 2009 at 3:41 PM, Aaron Boodman wrote:
>> - The docs are behind the code (had to read the code once or twice to
>> figure out what was going wrong).
>
> Were you using trunk or dev?
I was using dev. I think I just searched on Google and clicked
through to whichever docs I found
[repost with my actual signup address]
> Ah, I see. Yeah, I agree, that would clutter Chrome a bit.
>
> I'm not sure what direction to look in then. Things like SafeBrowsing
> suffer from the imperfect protection problem, but they are still worth
> doing. Only showing indicators when the site ide
On Mon, Nov 2, 2009 at 2:28 PM, Mike Hearn wrote:
> I disagree that the padlock animation would be adding visual noise,
>
I wasn't commenting about the animation, rather the presence of an indicator
on "normal" sites.
PK
--~--~-~--~~~---~--~~
Chromium Developers
> The malware and phishing system does a pretty good job of detecting
> phishing sites like this, which we get notified of via SafeBrowsing
SafeBrowsing is a great system, but it ultimately relies on savvy
users telling us that a site is phishing. Some scams are sufficiently
good that the majorit
On Mon, Nov 2, 2009 at 11:23 AM, Mike Hearn wrote:
> - Use of "cheap" negative trust indicators, for instance if a page
> matches the regex "Bank of America" and is not the well known site a
> small bar or bubble could appear that says "This website is not owned
> by Bank of America". This would
On Mon, Nov 2, 2009 at 1:10 PM, John Munro wrote:
> > I do think our host-versus-everything-else coloring in the address bar
> helps
> > with phishing URLs even if users can't articulate what the different
> colored
> > sections are.
>
> Would this be a good time to revisit this issue:
>
> http:/
> I do think our host-versus-everything-else coloring in the address bar helps
> with phishing URLs even if users can't articulate what the different colored
> sections are.
Would this be a good time to revisit this issue:
http://code.google.com/p/chromium/issues/detail?id=1971
Both Firefox and
Our goal for this Friday is to be able to count our Mac P1 M4 release
blocker bugs on one hand (we're in the 20s now).
To that end, everyone should have their P1 list practically at zero by
the end of this week. If you are not going to be able to reach this,
let me (or other triage folk) know ASA
+CC Ian Fette, our security PM.
None of the issues you raise are new; we've considered them for a couple of
years.
In general I agree that positive security indicators are designed around the
idea that users should be alarmed by something's _absence_, which doesn't
work well with how people proce
Paweł Hajdan Jr. wrote:
> scons: ***
> [/home/ph/chromium/src/sconsbuild/Debug/obj/yasm/genmacro/source/patched-yasm/tools/genmacro/genmacro.o]
> Source
> `/home/ph/chromium/src/third_party/yasm/source/patched-yasm/tools/genmacro/genmacro.c'
> not found, needed by target
> `/home/ph/chromium/s
Hiya,
I'm not sure if chromium-dev is the right place for this discussion as
it's a bit vague. Please don't hesitate to redirect me if not.
I'm concerned about the way Chromium displays SSL security indicators,
which this blog post reminded me about:
http://chrome.blogspot.com/2009/10/are-yo
I'm getting this compile error when compiling on Ubuntu 9.04 (scons):
Compiling
/home/ph/chromium/src/sconsbuild/Debug/obj/libxslt/libxslt/libxslt/xsltutils.o
Generating version information
Creating library /home/ph/chromium/src/sconsbuild/Debug/lib/libxslt.a
Indexing /home/ph/chromium/src/sconsbu
(CCing today's sheriffs + Jay)
I was thinking of marking the bug to P1, except that won't change much if no
one has the time to work on it now.
I think to keep tree green, the entire test should be disabled until
singletons are cleared between each test, or it's switched to browser_tests
launcher
If you have less than 1 GB of RAM, I wouldn't even try to link the biggest
binaries. 2 GB of RAM should be sufficient, although with 4 and more it's
better. And you will notice the change after switching to gold.
On Mon, Nov 2, 2009 at 18:58, Adam Langley wrote:
>
> On Fri, Oct 30, 2009 at 9:10
On Fri, Oct 30, 2009 at 10:10 AM, Akira wrote:
> I was building on Fedora 10 and was able to compile but the
> linking stage (see below) consumes more and more memory- the 500Mb of
> remaining memory, then another 1Gb of swap- before being killed.
Are you using gold (the new binutils linker)?
As Evan notes, things move quickly :)
What made the difference here is that Joel fixed that error and you
must have updated your tree.
--Craig
On Sun, Nov 1, 2009 at 5:01 PM, Alexander Teinum wrote:
>
> Success.
>
> Adding 'remove_webcore_debug_symbols' to include.gypi probably solved
> my pro
On Sun, Nov 1, 2009 at 8:01 AM, Alexander Teinum wrote:
> Success.
That's great! If you have any notes that would be useful to other
Arch users, please update the instructions on the wiki at
http://code.google.com/p/chromium/wiki/LinuxBuildInstructionsPrerequisites
(There's a section with dis
On Fri, Oct 30, 2009 at 9:10 AM, Akira wrote:
> I was building on Fedora 10 and was able to compile but the
> linking stage (see below) consumes more and more memory- the 500Mb of
> remaining memory, then another 1Gb of swap- before being killed.
Are you using gold?
http://code.google.com/p/
I'm trying to compile Chromium on 64-bit Arch Linux.
It did work fine with SCons in release mode, but it seems like make is
going to replace SCons from what I have read in the recent
discussions. I have had a lot of pain compiling Chromium in general,
because of gperf, generated code, strict alia
Hi,
I was building on Fedora 10 and was able to compile but the
linking stage (see below) consumes more and more memory- the 500Mb of
remaining memory, then another 1Gb of swap- before being killed.
.
Compiling /home/akira/chromium/src/sconsbuild/Debug/obj/chrome/chrome/
app/chrome_e
2009/11/2 Hironori Bono (坊野 博典) :
> 1. Creating a file "~/.gyp/inclulde.gypi'.
> 2. Adding a following lines to the file.
>
> {
>'variables': {
> 'no_strict_aliasing': 1
>}
> }
If you're only building chrome, not the unit_tests target, you can
instead define gcc_version to 44. Thi
Success.
Adding 'remove_webcore_debug_symbols' to include.gypi probably solved
my problem (although I did a debug build now). This is the first time
that I have had success compiling Chromium in Arch Linux with make.
And it's also the first time that I have gotten a debug build working
in Arch Li
I think that the right fix is to switch interactive_ui_tests to
browser_tests launcher (jcampan did some great work to make the launcher
more flexible, it may be quite simple to do the switch now - if there are no
UI tests in interactive_ui_tests).
I also suggest bumping the priority of http://crb
This is related to bug 25997. The tests are inherently flakey because
singeltons aren't released between runs, so cached MessageLoop pointers are
bogus. Sometimes they're ok when the order of construction/destruction of
MessageLoop pointers is the same. But if that changes, or other memory
alloc
41 matches
Mail list logo
