I got it.
Thanks
On Wed, Jul 8, 2009 at 12:49 AM, Thiago Farinathiago.far...@gmail.com wrote:
Lei can you review this patch for me?
http://codereview.chromium.org/155078
On Jul 6, 11:56 pm, Lei Zhang thes...@chromium.org wrote:
You didn't give enough context. It'll be more helpful if you
First off, i am not complaining, just suggesting as the build
(especially link gets slower and slower)
I contribed code before to chrome, and plan to do so in the future,
however
even changing one line of Code in say browser.vcproj leads to 10+ mins
of linking (yes TEN)
what i did was wrote
CXX /.../out/Debug/obj/webkit/glue/temporary_glue.o
In file included from ./base/timer.h:49,
from ./webkit/glue/resource_fetcher.h:19,
from ./webkit/glue/image_resource_fetcher.h:9,
from ./webkit/glue/webview_impl.h:16,
from
Hi Dean,
Thanks for commiting this patch to me.
On Jul 8, 6:33 am, Dean McNamee de...@chromium.org wrote:
I got it.
Thanks
On Wed, Jul 8, 2009 at 12:49 AM, Thiago Farinathiago.far...@gmail.com wrote:
Lei can you review this patch for me?
http://codereview.chromium.org/155078
On
I noticed that the Issue 7863, that me and jcampan, we fixed, are
available until now. I saw there are some other Issues are with the
status: Available, but already well fixed.
So some issues are being fixed but are not being updated in the Issue
List.
I wonder if it would be possible to have a conditional flag, maybe in
common.gypi, that you would flip to turn on incremental linking, with
still non-incremental linking being the default.
On Wed, Jul 8, 2009 at 05:00, nakroyoav.zilberb...@gmail.com wrote:
First off, i am not complaining, just
Pawel, since i have it working on my machine (or i really could not
code with chrome)
i can tell you it is much more than a flag
just as an example the name of chrome_dll.vcproj produces chrome.dll,
but the incremental files would clash with chrome.vcproj who does the
exe
another example : you
As a general observation on large development teams, infrastructure
can get less love, because everyone comes to the team to work on the
exciting main product, not the more mundane build infrastructure. If
you have ideas on how to fix this stuff, I think it would be perfectly
reasonable to put
On Wed, Jul 8, 2009 at 11:14 AM, nakro yoav.zilberb...@gmail.com wrote:
Pawel, since i have it working on my machine (or i really could not
code with chrome)
i can tell you it is much more than a flag
just as an example the name of chrome_dll.vcproj produces chrome.dll,
but the incremental
On Wed, Jul 8, 2009 at 11:03 AM, Paweł Hajdan Jr.
phajdan...@chromium.orgwrote:
I wonder if it would be possible to have a conditional flag, maybe in
common.gypi, that you would flip to turn on incremental linking, with
still non-incremental linking being the default.
Something like this
So... do you think it will make things quicker on Visual Studio 2005 also?(Will
the incremental linking work there, too, or do these changes require some
2008 features?)
☆PhistucK
On Wed, Jul 8, 2009 at 18:43, nakro yoav.zilberb...@gmail.com wrote:
Ok, i am happy it catches your attention
Yeah, I guess so, but they are not going to invest too much time on the
build system, as they have stated in this thread.
☆PhistucK
On Wed, Jul 8, 2009 at 19:05, nakro yoav.zilberb...@gmail.com wrote:
Phistuck, this is Exactly why this issue is best handled by chrome ppl
and not outsides
This is probably due to my change. I'll look into it if someone hasn't
already.
-Darin
On Wed, Jul 8, 2009 at 5:46 AM, Dean McNamee de...@chromium.org wrote:
CXX /.../out/Debug/obj/webkit/glue/temporary_glue.o
In file included from ./base/timer.h:49,
from
I noticed that browser_tests run on the Chromium XP buildbot, but I
couldn't see them on other official (non-FYI) buildbots, and they
don't run on trybots. What's blocking us from enabling these tests on
more buildbots?
--~--~-~--~~~---~--~~
Chromium Developers
On Wed, Jul 8, 2009 at 9:42 AM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote:
I noticed that browser_tests run on the Chromium XP buildbot, but I
couldn't see them on other official (non-FYI) buildbots, and they
don't run on trybots. What's blocking us from enabling these tests on
more
On Wed, Jul 8, 2009 at 8:43 AM, nakro yoav.zilberb...@gmail.com wrote:
Ok, i am happy it catches your attention
sadly, i cannot submit patches for it as i wrote an external tool who
does it automatically for me
by patching the sln and vcproj/vsprops (i can pass the source code to
anyone if
Jeremy, First off, i will be happy to share the code or exe or
whatever you will wish
the thing is this, i am very interested in chrome (code wise) but i
never took a stab with all your gyp
and scripts... and while i know enough python to read your scripts (i
learned it for it) i have no access
On Wed, Jul 8, 2009 at 10:46 AM, nakroyoav.zilberb...@gmail.com wrote:
the reason i think one from chrome is the best is because these
changes could affect MAC and UNIX as well
Regarding incremental linking: I don't believe it exists on Linux, but
gold is quite fast. My links take around ~5s,
Currently we use JsTemplate
(http://code.google.com/p/google-jstemplate/) to do our l10n of the
DOMUI. JST has been working well but it is a bit of an overkill to do
l10n of our UI. It has a couple of features that makes it slow down
the UI:
1. It uses eval for every single RHS
2. It uses two
This time from a Chromium account:
It would be nice if we didn't have to use JS and could just embed the
strings live so that they could be cached, etc. Our CSS (and maybe
even JS) files could use something like this, (currently we're just
doing $0-$9 replacement).
This may be separate to what
On Wed, Jul 8, 2009 at 11:05, Glen Murphyg...@chromium.org wrote:
This time from a Chromium account:
It would be nice if we didn't have to use JS and could just embed the
strings live so that they could be cached, etc. Our CSS (and maybe
even JS) files could use something like this,
What are the more advanced things that we use JST for? Off the top of
my head, all I can think of is bulleted lists.
I think we went with a JS solution because it seemed easier and safer
at the time.
I'm ok with doing string injection in the front end (i.e., a C++ HTML
templating library), I'm
I'm not sure what you mean be embed the strings live so that they
could be cached?
Sorry. For things like CSS, it's convenient that we do all the string
injection in the backend so that the frontend can cache the result and
not have to do any work the next time the resource is requested. This
On Wed, Jul 8, 2009 at 11:13, Tony Changt...@chromium.org wrote:
What are the more advanced things that we use JST for? Off the top of
my head, all I can think of is bulleted lists.
jsselect - which allows iteration. This is used for bulleted lists and the like
eval/switch - this is used
This seems like a reasonable plan.
It would be cool if whatever mechanism you chose could be leveraged by
extensions as well (see the earlier extensions i18n proposal that was sent
around last week). For this reason I'd prefer that if we moved to a C++
solution (as others in this thread have
On Wed, Jul 8, 2009 at 11:29, Erik Kayerik...@chromium.org wrote:
This seems like a reasonable plan.
It would be cool if whatever mechanism you chose could be leveraged by
extensions as well (see the earlier extensions i18n proposal that was sent
around last week). For this reason I'd prefer
No objections from me-- a faster new tab page sounds great! A couple
side goals to consider:
- Maybe move this new js code into a pseudo protocol rather than
appending the js blob into every html file. I think e.g., the
devtools does this already.
- It would be nice if this would some day
Ideally we would use an existing library instead of rolling our own.
One major benefit of using existing code is that all the XSS holes
will have been worked out already.
Adam
On Wed, Jul 8, 2009 at 11:36 AM, Tony Changt...@chromium.org wrote:
No objections from me-- a faster new tab page
I reread the thread and the design doc and it does not really cover
when string replacements should happen.
Doing a JST lite for l10n is something that can be used in extensions
but I think the long term solution is to do this on the front end.
On Wed, Jul 8, 2009 at 11:33, Erik
On Wed, Jul 8, 2009 at 12:00 PM, Aaron Boodmana...@chromium.org wrote:
Agree with Erik that it seems like we should share this code between
DOMUI and the extensions system.
(Erik Kay)
--~--~-~--~~~---~--~~
Chromium Developers mailing list:
On Wed, Jul 8, 2009 at 11:51, Adam Barthaba...@chromium.org wrote:
Ideally we would use an existing library instead of rolling our own.
One major benefit of using existing code is that all the XSS holes
will have been worked out already.
Replacing JST with something custom is something I am
Sure, but how should I do that in gyp (properly)? I have some idea,
but it would be good to verify.
On Wed, Jul 8, 2009 at 12:18, Evan Martine...@chromium.org wrote:
The missing files are part of ICU, so probably need to depend on that
somewhere.
The missing files are part of ICU, so probably need to depend on that somewhere.
http://www.google.com/codesearch?q=rbbi.h+package:chromium
On Wed, Jul 8, 2009 at 12:12 PM, Paweł Hajdan
Jr.phajdan...@chromium.org wrote:
I'm adding a browser test on linux, and it uses app/l10n_util.h. I'm
Issue 7863 is fixed now. We can ask the fix committers to review the
status of other unfixed issues.
Do you have the issue numbers of other such issues? You can list them
individually like: http://crbug.com/N
On Jul 8, 7:45 am, Thiago Farina thiago.far...@gmail.com wrote:
I noticed that
Actually, my idea failed. I added dependencies for
+'../third_party/icu38/icu38.gyp:icui18n',
+'../third_party/icu38/icu38.gyp:icuuc',
but it now complains even more, like:
/chromium/src/third_party/icu38/public/i18n/unicode/ucol.h:1152:
error: expected constructor,
It seems like we want to do the string replacing in the front-end.
Does anyone have any experience with C++ l10n/template libraries that
we might want to use?
On Wed, Jul 8, 2009 at 12:00, Aaron Boodmana...@chromium.org wrote:
On Wed, Jul 8, 2009 at 12:00 PM, Aaron Boodmana...@chromium.org
Looks like the tests don't run on the mac, I'll look into that.
TVL
On Wed, Jul 8, 2009 at 3:17 PM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote:
Hmmm. They do run on try bots.
Oh, indeed. But only on Windows. But I noticed you're working on this,
so - seems good.
They also do run in
2009/7/8 Erik Arvidsson a...@chromium.org
It seems like we want to do the string replacing in the front-end.
Does anyone have any experience with C++ l10n/template libraries that
we might want to use?
I don't have, but I just came across a few:
http://www.clearsilver.net/ (Apache
Looks like the tests don't run on the mac, I'll look into that.
TVL
On Wed, Jul 8, 2009 at 3:17 PM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote:
Hmmm. They do run on try bots.
Oh, indeed. But only on Windows. But I noticed you're working on this,
so - seems good.
They also do run in
Thanks for the answers. I got test_shell to link with my copy of
fontconfig, but it doesn't show line numbers in valgrind's stacktrace.
I compiled with CFLAGS=-m32 -ggdb3 CXXFLAGS=-m32 -ggdb3.
What should I do to make valgrind display the line numbers?
I uploaded a CL of what I initially had in mind.
http://codereview.chromium.org/155245
I realized now that JST is used for non l10n templating so the name
needs to change. Still, I think this is such a small change with such
a big win that I want to continue down this path until we have some
On Wed, Jul 8, 2009 at 2:32 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote:
Thanks for the answers. I got test_shell to link with my copy of
fontconfig, but it doesn't show line numbers in valgrind's stacktrace.
I compiled with CFLAGS=-m32 -ggdb3 CXXFLAGS=-m32 -ggdb3.
Not really sure. I
On Wed, Jul 8, 2009 at 15:35, Adam Langleya...@chromium.org wrote:
On Wed, Jul 8, 2009 at 2:32 PM, Paweł Hajdan Jr.phajdan...@chromium.org
wrote:
Thanks for the answers. I got test_shell to link with my copy of
fontconfig, but it doesn't show line numbers in valgrind's stacktrace.
I compiled
There are a handful of changes in the tree intended for Chrome OS.
They are wrapped in the LINUX2 ifdef, which will shortly change to
CHROME_OS. While you can certainly build this configuration on Linux
now, running it outside of Chrome OS isn't particularly interesting.
-Scott
On Wed, Jul 8,
On Wed, Jul 8, 2009 at 3:45 PM, Scott Violet s...@chromium.org wrote:
While you can certainly build this configuration on Linux
now, running it outside of Chrome OS isn't particularly interesting.
(Since I was curious, I asked more about this)
In particular, this configuration makes use of
brave is between boring and broken
On Wed, Jul 8, 2009 at 3:48 PM, Peter Kastingpkast...@google.com wrote:
On Wed, Jul 8, 2009 at 3:45 PM, Scott Violet s...@chromium.org wrote:
While you can certainly build this configuration on Linux
now, running it outside of Chrome OS isn't particularly
On Wed, Jul 8, 2009 at 3:43 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote:
I'm attaching the output of strings. I'm not sure if it has symbols...
The size of the lib is 226K, compared to 169K from my Goobuntu 32-bit
fontconfig.
It's not clear. objdump -x maybe?
AGL
It says no symbols. :-/
Do you have an idea how can I get them?
On Wed, Jul 8, 2009 at 16:15, Adam Langleya...@chromium.org wrote:
On Wed, Jul 8, 2009 at 3:43 PM, Paweł Hajdan Jr.phajdan...@chromium.org
wrote:
I'm attaching the output of strings. I'm not sure if it has symbols...
The size
On Wed, Jul 8, 2009 at 4:22 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote:
It says no symbols. :-/
Do you have an idea how can I get them?
When you're building fontconfig, you're building it with no
optimization and -g for debugging symbols, right?
-- Elliot
For consistency the define is going to be OS_CHROMEOS.
-Scott
On Wed, Jul 8, 2009 at 3:45 PM, Scott Violets...@chromium.org wrote:
There are a handful of changes in the tree intended for Chrome OS.
They are wrapped in the LINUX2 ifdef, which will shortly change to
CHROME_OS. While you can
Got it working!
The steps I used:
make clean
CFLAGS=-m32 -g -ggdb3 CXXFLAGS=-m32 -g -ggdb3 ./configure
--host=i686-pc-linux-gnu --enable-debug --with-debug
--prefix=/home/phajdan/local
CFLAGS=-m32 -g -ggdb3 CXXFLAGS=-m32 -g -ggdb3 make
make install
I think that not all of the flags are
Please don't forget to update
http://code.google.com/p/chromium/wiki/LinuxDebugging :)
On Wed, Jul 8, 2009 at 5:04 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote:
Got it working!
The steps I used:
make clean
CFLAGS=-m32 -g -ggdb3 CXXFLAGS=-m32 -g -ggdb3 ./configure
On Wed, Jul 8, 2009 at 6:45 PM, Scott Violet s...@chromium.org wrote:
There are a handful of changes in the tree intended for Chrome OS.
They are wrapped in the LINUX2 ifdef, which will shortly change to
CHROME_OS. While you can certainly build this configuration on Linux
now, running it
On Wed, Jul 8, 2009 at 5:12 PM, Marshall Greenblatt
magreenbl...@gmail.comwrote:
I imagine this could require complex controls like tree views, icon lists,
date pickers, etc. Will we see these controls as native extensions to
Chromium and WebKit, or is a JavaScript toolkit layer more likely?
Problem resolved. Maybe I forgot to re-gyp at some point, or maybe it
was something else...
2009/7/8 Paweł Hajdan Jr. phajdan...@chromium.org:
Actually, my idea failed. I added dependencies for
+ '../third_party/icu38/icu38.gyp:icui18n',
+
Note: this finds the Rietveld issue number by looking for the last
http://codereview.chromium.org/ url in the email. So make sure to leave
that url in the email, and if you add another url to a different issue,
don't put it at the end.
On Mon, Jul 6, 2009 at 9:11 PM, John Abd-El-Malek
Hm...I wonder how mondrian (an internal Google tool) does it...
Maybe the chromium-revi...@googlegroups.com could be changed to
chromium-reviews+the review number@googlegroups.com and that could be used
instead?
On Wed, Jul 8, 2009 at 5:44 PM, John Abd-El-Malek j...@chromium.org wrote:
Note:
On Wed, Jul 8, 2009 at 8:19 PM, Peter Kasting pkast...@google.com wrote:
On Wed, Jul 8, 2009 at 5:12 PM, Marshall Greenblatt
magreenbl...@gmail.com wrote:
I imagine this could require complex controls like tree views, icon lists,
date pickers, etc. Will we see these controls as native
They put the id in the subject, but I wanted to avoid doing that. The
smaller the subject, the more chance of seeing the lgtm or objections of
others without reading the email.
On Wed, Jul 8, 2009 at 6:17 PM, Jeremy Orlow jor...@chromium.org wrote:
Hm...I wonder how mondrian (an internal
On Wed, Jul 8, 2009 at 6:21 PM, Marshall Greenblatt
magreenbl...@gmail.comwrote:
On Wed, Jul 8, 2009 at 8:19 PM, Peter Kasting pkast...@google.com wrote:
On Wed, Jul 8, 2009 at 5:12 PM, Marshall Greenblatt
magreenbl...@gmail.com wrote:
I imagine this could require complex controls like
There is a place I can find a list which the teams of chromium and the
names of their members?
For example:
UI Team: member's name;
Extensions Team: member's name;
Security Team:member's name;
I'm asking this because I was writting a patch that changed the UI,
and Glen said this have to be
I think it's good maintain the things simple, and I agree that all UI
changes needs to be approved before starting code. Because I didn't
know about that I started writting the patch without the approval. I
think this feature is a good addition to chrome, because the firefox
has this feature,
On Wed, Jul 8, 2009 at 9:01 PM, Thiago Farina thiago.far...@gmail.comwrote:
I think it's good maintain the things simple, and I agree that all UI
changes needs to be approved before starting code. Because I didn't
know about that I started writting the patch without the approval. I
think
Ok, let me make question simple.
I get some ERRORs on my DOS while running layout-test, such as :
090706 15:37:19 __init__.py:1032 ERROR
LayoutTests/fast/backgrounds/svg-as-mask.html failed:
Text diff mismatch
Image mismatch
These ERRORs are made of two kinds: expected and unexpected,
On Wed, Jul 8, 2009 at 9:05 PM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Jul 8, 2009 at 9:01 PM, Thiago Farina thiago.far...@gmail.comwrote:
I think it's good maintain the things simple, and I agree that all UI
changes needs to be approved before starting code. Because I didn't
know
Thanks for your clarification Matt. I agree with you that in a long
run a more comprehensive regression test would be helpful. Similar
regression happened in a previous release that broke another part of
extension (i.e., deleting a bookmark item would crash Chrome) that is
still hanging around.
66 matches
Mail list logo
