On Tue, Dec 8, 2009 at 11:25 AM, Jeremy Orlow jor...@chromium.org wrote:
Last Friday we recorded 4 tech talks based on the feedback we got on what
topics would be interestingand here they are!
http://www.youtube.com/watch?v=JFzC_Gx76E8
Darin Fisher talks about the recently upstreamed
In case it is not working for you, go to
http://groups.google.com/group/chromium-dev and make sure you are logged in
to your Google account, click on Edit membership and click on
Unsubscribe,
☆PhistucK
On Wed, Dec 9, 2009 at 10:36, njredhat njred...@163.com wrote:
--
Chromium Developers
Thanks pkasting@ for trying this with
http://src.chromium.org/viewvc/chrome?view=revrevision=34108
But as the page cyclers dashboard seem to confirm, this is still a
issue... :-(
http://build.chromium.org/buildbot/perf/xp-release-dual-core/moz/report.html?history=150
BYE
SAD :-(
On Dec 8,
On Dec 8, 10:49 pm, Paweł Hajdan Jr. phajdan...@chromium.org wrote:
Some ideas for
the next round of talks:
Would these interesting points not be better suited to be covered in a
wiki?
What Jeremy presented there as videos seems more like an appetizer.
With a growing wiki the experienced user
Fedora Linux host:
make: *** No rule to make target `third_party/yasm/source/patched-yasm/
modules/arch/x86/gen_x86_insn.py', needed by `out/Debug/obj/gen/
third_party/yasm/x86insns.c'. Stop.
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email
Try pasting a subphrase of that into a search engine. :)
On Wed, Dec 9, 2009 at 6:55 AM, Gary Thomas samoht.y...@gmail.com wrote:
Fedora Linux host:
make: *** No rule to make target `third_party/yasm/source/patched-yasm/
modules/arch/x86/gen_x86_insn.py', needed by `out/Debug/obj/gen/
Indeed, this is in thread:
http://groups.google.com/group/chromium-dev/browse_thread/thread/0053084fdb3f7742
However, there is no solution there. I have a brand new download/
checkout and I ran
'gclient sync' immediately thereafter. The thread implies the file
should exist; it does
not.
gclient sync --force
Gary Thomas wrote:
Indeed, this is in thread:
http://groups.google.com/group/chromium-dev/browse_thread/thread/0053084fdb3f7742
However, there is no solution there. I have a brand new download/
checkout and I ran
'gclient sync' immediately thereafter. The thread
I see this in the notes now (http://dev.chromium.org/developers/how-
tos/get-the-code modified 2009-12-09 1701Z)
Thanks
On Dec 9, 9:57 am, Mark Mentovai m...@chromium.org wrote:
gclient sync --force
Gary Thomas wrote:
Indeed, this is in thread:
Automatically closing tree for compile on Chromium Linux x64
http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Linux%20x64/builds/3337
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Linux%20x64
--= Automatically closing tree for compile on Chromium
Automatically closing tree for plugin_tests on XP Perf (dbg)
http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf%20%28dbg%29/builds/17030
http://build.chromium.org/buildbot/waterfall/waterfall?builder=XP%20Perf%20%28dbg%29
--= Automatically closing tree for plugin_tests on XP Perf
Apologies to all. This was caused by my checkin, which is now backed out.
On Wed, Dec 9, 2009 at 9:33 AM, build...@chromium.org wrote:
http://build.chromium.org/buildbot/waterfall/
Automatically closing tree for compile on Chromium Linux x64
Hi All,
I got the latest source for chrome browser using the following steps:
gclient config http://src.chromium.org/svn/trunk/src
export GYP_GENERATORS=make
export GYP_DEFINES=target_arch=arm armv7=1 sysroot=/home/adas/x-tools/
arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root
Personally, I really like the tech talk format as an introduction to a
topic, but you're right that some would prefer something in written form and
that a Wiki has many benefits that a video does not have. If you're willing
to transcribe the information, I'm sure it would help others.
On Wed,
On Wed, Dec 9, 2009 at 5:30 AM, MAD m...@chromium.org wrote:
Thanks pkasting@ for trying this with
http://src.chromium.org/viewvc/chrome?view=revrevision=34108
But as the page cyclers dashboard seem to confirm, this is still a
issue... :-(
Automatically closing tree for compile on Chromium Builder
http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder/builds/20161
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Builder
--= Automatically closing tree for compile on Chromium Builder =--
Is there documentation somewhere regarding gclient? I'd like to know more
about how hooks and other gclient features work.
On Tue, Dec 8, 2009 at 6:27 PM, Mark Mentovai mmento...@google.com wrote:
Igor Gatis wrote:
When I change a .gyp, do I need to call gyp or the build process does
that
Humm, that's a good question. Right now the only doc is gclient help
runhooks which is .. uh .. not really useful.
M-A
On Wed, Dec 9, 2009 at 3:28 PM, Igor Gatis igorga...@gmail.com wrote:
Is there documentation somewhere regarding gclient? I'd like to know more
about how hooks and other
There's better info in gclient.py, as a comment. Maybe we can just
rip this off and stick it in a web page somewhere on the developer
site.
Hooks
.gclient and DEPS files may optionally contain a list named hooks to
allow custom actions to be performed based on files that have changed in the
I'm trying to get my head around how our HTTPS status display (lock icon)
should work now that we support cross-window/cross-domain communication and
SharedWorkers.
Currently, if an HTTPS page loads a worker and that worker subsequently does
a non-HTTPS network operation, the parent window's UI
I've just published my talk. Since the bulk of it was verbal, the slides are
much more useful with the speaker's notes visible. (This also means it's not
so great as an embedded presentation. Oh well.)
http://docs.google.com/present/view?id=dcs84g92_1cjns9f73
My windows build has been broken for at least a day with the following
error:
base_nacl_win64.lib(string_util.obj) : fatal error LNK1112: module machine
type 'x64' conflicts with target machine type 'X86'
I've tried disabling nacl, gclient sync --force, clobbering the output
directory, removing
Automatically closing tree for compile on Webkit Linux (valgrind)
http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Linux%20%28valgrind%29/builds/7618
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20Linux%20%28valgrind%29
--= Automatically closing tree for
Automatically closing tree for update on Webkit Linux (dbg)(1)
http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Linux%20%28dbg%29%281%29/builds/12904
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20Linux%20%28dbg%29%281%29
--= Automatically closing tree
Automatically closing tree for compile on Chromium Linux Builder (valgrind)
http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Linux%20Builder%20%28valgrind%29/builds/4584
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Linux%20Builder%20%28valgrind%29
Lately I've been seeing more and more // NOLINT added to the code. It's
great that people are running lint to make sure that they're following the
guidelines, but I personally find adding comments or gibberish to our code
for tools that are supposed to make the code quality better happy/more
In principle, the correct thing to do is keep track of the mixed
content state of the shared worker and infect whichever windows
interact with the worker. However, I suspect this is one of those
cases where the perfect is the enemy of the good. For the time being,
I'm fine with having the
Agreed. There are certain situations where conforming to lint
expectations leads to messier code. I just checked in a CL that
contains a section of lines longer than 80 cols. Trying to wrap these
lines would make the definitions unreadable. It's one thing to have
lint report zero errors; it's
A recent change to use more system libs
(http://src.chromium.org/viewvc/chrome?view=revrevision=34195) might
break Linux builds. If you see messages about missing jpeg or xslt
headers, please install the relevant -dev packages. For instance, on
Hardy you would run:
sudo apt-get install -y
On Thu, Dec 10, 2009 at 05:14, Sofia Tahseen sofia.tahs...@gmail.com wrote:
/home/adas/0_Data/0_Lin/091203_Chromium_OS/toolchain/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld:
skipping incompatible
On Wed, Dec 9, 2009 at 3:48 PM, John Abd-El-Malek j...@chromium.org wrote:
Lately I've been seeing more and more // NOLINT added to the code. It's
great that people are running lint to make sure that they're following the
guidelines, but I personally find adding comments or gibberish to our
I didn't even know that I could disable the linter like that. Good to
know---dozens more NOLINTs coming up!
Jokes aside, I agree the linter seems a little draconian, especially as it
seems to apply to all code in the files you touch, not just your changes.
-- Evan Stade
--
Chromium Developers
btw I searched the code, almost all the instances are in code from different
repositories, like v8, gtest, gmock. I counted only 17 instances in
Chrome's code.
On Wed, Dec 9, 2009 at 4:08 PM, Evan Stade est...@chromium.org wrote:
I didn't even know that I could disable the linter like that.
Personally, I feel the opposite, and I'm not sure the perfect is the enemy
of good analogy doesn't really fit. If we erode the meaning of the secure
(as opposed to mixed) content icon, it seems like we're just going to need
to create UI in the future that says this is really super secure. I
On Wed, Dec 9, 2009 at 4:24 PM, John Abd-El-Malek j...@chromium.org wrote:
btw I searched the code, almost all the instances are in code from different
repositories, like v8, gtest, gmock. I counted only 17 instances in
Chrome's code.
Most of the Chrome NOLINTs look like the're around
If there are consistent patterns of NOLINT usage, I can suppress the
whole error class.
Also, the linter is only automatically run on chrome/ and app/, IIRC.
-- Elliot
On Wed, Dec 9, 2009 at 4:38 PM, Brett Wilson bre...@chromium.org wrote:
On Wed, Dec 9, 2009 at 4:24 PM, John Abd-El-Malek
Isn't the shared worker tied to the SOP? If so, then it seems to me
that you would want the secure status to change just as if the parent
window had done the request directly.
If I think I'm on a secure page, I certainly don't want my app doing
insecure activities behind my back.
I almost feel
To clarify my point about postMessage(), from my https://secure.com page, I
can do this:
var w = window.open(http://insecure.com;);
var channel = new MessageChannel();
w.postMessage(hello, channel.port1)
Now the insecure window can send messages to me via the port I just sent it.
Adam, do we
Automatically closing tree for test_shell_tests on Webkit Linux
http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Linux/builds/15242
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20Linux
--= Automatically closing tree for test_shell_tests on Webkit Linux
On Wed, Dec 9, 2009 at 4:33 PM, Jeremy Orlow jor...@chromium.org wrote:
Personally, I feel the opposite, and I'm not sure the perfect is the enemy
of good analogy doesn't really fit. If we erode the meaning of the secure
(as opposed to mixed) content icon, it seems like we're just going to
I saw this on Vista64 today as well. We don't have a Vista64 bot so it
wouldn't have made the tree red.
To fix, GYP_DEFINES='disable_nacl=1' gclient runhooks (in cygwin), then
build.
The right parties have been notified.
jrg
On Wed, Dec 9, 2009 at 2:00 PM, Steve VanDeBogart
41 matches
Mail list logo
