date:20090722

I need to find a way to know when a context menu is closed, either via a
menu item selection, or via hitting escape, opening a new menu, unfocusing
the window, etc.
Ideally, there'd be some sort of menu closed function or event that is
called when the menu stops being displayed.  On the gtk port, I see
a RenderViewContextMenuGtk::StoppedShowing(), but nothing similar for
Windows and Mac.

Can anyone give me a pointer on how to do something like this for mac, and
windows?

Thanks,
Albert

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Anyone know ScriptObjectQuarantine.cpp?

2009-07-22 Thread Adam Barth


If you know what WebCore/bindings/v8/ScriptObjectQuarantine.cpp is
supposed to do, can you reply to me privately?  There's some code in
there that doesn't make sense to me, and I'd like to understand what
it's trying to accomplish.

Thanks,
Adam

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Mozilla design challenge

2009-07-22 Thread Evan Martin


On Wed, Jul 22, 2009 at 10:08 AM, Brian Rakowskibr...@chromium.org wrote:
 I also still like the idea of to read tabs. The challenge is finding a
 simple gesture that would allow users to identify tabs or links that should
 go in the to read queue. I feel like this would dramatically cut down on
 the number of open tabs and also remove my fear of losing interesting pages
 that I wanted to get back to.

Since we already use dragging tabs for other actions (like managing
window layout), perhaps when you start dragging a tab we provide an
extra drop spot.  Conceptually, you're dropping the tab into your
backpack to look at later.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: FYI: Upcoming O3D integration changes.

2009-07-22 Thread Nicolas Sylvain

On Tue, Jul 21, 2009 at 4:30 PM, Greg Spencer gspen...@google.com wrote:

 Hello Chromium Devs,
 The O3D team is working on getting O3D integrated into the Chromium build,
 and we're close to being able to complete our first step towards
 integration:  To build the O3D plugin as part of the Chromium code base, and
 link it into Chromium DLL.  It will still be a plugin, but will be added
 to the internal plugins list so that its entry points are found in the
 Chromium DLL, instead of loading a separate plugin DLL.  This is a small
 step, and makes little practical difference except that 1) it will be
 bundled with Chromium, and 2) it opens the door to start integrating more
 fully.

 To achieve this first step, we have converted the O3D plugin to build using
 GYP, and have migrated to using all of the third_party libraries that we
 have in common at the same revision levels as Chromium is using.

 The next thing to do is to change Chromium's DEPS file to include the few
 remaining necessary dependencies that O3D uses and Chromium does not.

 These are:  A vector math library (vectormath), Nixysa: an NPAPI IDL
 generator, gflags (the python parts, for nixysa), and native client (for the
 nacl imc libraries).

Overall it looks good to me, with some comments/questions:


 I'm planning to map these like this:
 --
   src/third_party/vectormath:
 
 http://o3d.googlecode.com/svn/trunk/googleclient/third_party/vectormath@;
 + Var(o3d_code_rev),

   src/third_party/nixysa/files:

why in a subdir called files?

 http://nixysa.googlecode.com/svn/trunk/nixysa@; + Var(nixysa_rev),

   src/third_party/npapi/files:

same here?

 http://nixysa.googlecode.com/svn/trunk/third_party/npapi@; +
 Var(nixysa_rev),

   src/third_party/ply/files:

same here?

 http://nixysa.googlecode.com/svn/trunk/third_party/ply-3.1@; +
 Var(nixysa_rev),

   # NACL has to be in this weird directory because it looks for
   # googleclient two levels above it.
   src/third_party/native_client/googleclient/native_client:

Looks like they should change their code to make it work without assuming
all these directories.

and this code is already fetched in src/native_client, we don't want it
twice.


 
 http://nativeclient.googlecode.com/svn/trunk/nacl/googleclient/native_cli...@188
 ,

And if we really can't, then this path does not exist on head for this
repo. Any change we can sync to a later revision so we don't have to change
the path later on?



   src/third_party/gflags/:
 http://google-gflags.googlecode.com/svn/tr...@30;,
 --

 In addition, I'll be making the Windows build of Chromium be dependent upon
 building O3D as part of the build process.

 This is really just a heads up! announcement to prompt heated discussions
 about the ensuing calamities that this will cause, so please feel free to
 comment.


For those who are curious :

$ du -h --max-depth=1 .
4.1M./gflags
34M ./native_client
1.3M./nixysa
251K./npapi
2.1M./ply-3.1
24M ./vectormath
64M .


Nicolas


 -Greg.

 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Mozilla design challenge

There are heuristics we can come up with that are fairly safe. They might be
too conservative to be useful though. For example, it should almost always
be safe to kill a page that:-has no unload/beforeunload listeners registered
-has had no user-interaction that caused JS to execute
-has had no user-interaction that changed form field values

If we're really worried, we could get arbitrarily strict, e.g. never kill a
page with any form fields. But the stricter we get, the less useful this
becomes.

My definition of safe here is that there generally won't be enough page
state lost that the user will notice or care if we kill it.

That said, I don't quite get what happens when the user finally switches
back to that tab, do we refetch it from the network? What if I was
intentionally loading tabs to read because I knew I was going to be
disconnected from the network soon (e.g. getting on an airplane)? What if
I'm on a bad connection and pages aren't loading well? etc.

Ojan

On Wed, Jul 22, 2009 at 10:27 AM, David Levin le...@google.com wrote:

 There is one internal site that I go to enter some feedback.  (It has auto
 save now but didn't at one point.)
 Recently I don't go there very often.  It is entirely possible (and
 frequently happens) that I get interrupted while entering feedback and have
 to look up other information (during which I look up information from lots
 of sources).  Then I go back and expect my feedback to still be there.  I
 would be highly annoyed at any browser that tossed my feedback (which takes
 me a while to write).

 An external example of this is the review tool for WebKit (which doesn't
 have auto-save and doesn't have a manual draft save mode even).

 dave


  On Wed, Jul 22, 2009 at 9:54 AM, Linus Upson li...@google.com wrote:

 With a good heuristic, I think it will be very unlikely that we'll kill a
 renderer that has useful state. What are the chances that a tab on a site
 that I don't go to often, and that I opened 30 tabs ago has js/dom state
 that is critical for me? Mobile browsers already euthanize unused
 tabs aggressively. Since so few users have 20+ tabs open at once perhaps we
 can just reset their expectations for what happens if they accumulate a
 large number of tabs. Perhaps the heuristic could be tied to the mythical
 great overflow UI. For all of these heavy users I suspect they would prefer
 chrome to remain zippy fast with large tab sets rather than paging a
 renderer that 99.9% of the time doesn't have any interesting state.
 Linus


 On Tue, Jul 21, 2009 at 2:03 PM, Scott Hess sh...@chromium.org wrote:


 I don't think it's reasonable to require the user to specify which
 tabs to suspend, except, perhaps, if we develop a metric for
 power-hungry tabs and expose that.

 I think there is some potential for UI geared towards particular
 use-cases which could be overloaded to also allow more aggressive
 suspend.  For instance, WRT my earlier posting, I would expect my
 pinned tabs to be given stronger priority, and my on-deck-to-read tabs
 to be treated more like preloaded/rendered bookmarks.  There could be
 other UI advantages in there, like the on-deck tabs for a particular
 project could group under a single tab with other UI widgets to select
 which document within the group.

 -scott


 On Tue, Jul 21, 2009 at 1:50 PM, Ryosuke Niwarn...@google.com wrote:
  Is it possible to provide an intuitive UI that allows users to choose
 which
  tabs to be suspended?
  For example, just like users can click buttons on taskbar to pop up a
  particular window, we could provide a small window that pop-in tabs /
  windows.  And then we can suspend all windows / tab that
 are popped into.
  Ryosuke
 
  On Tue, Jul 21, 2009 at 9:32 AM, Erik Kay erik...@chromium.org
 wrote:
 
  You may be on to something, but I think it's more complex than this.
  For
  example bookmark systems don't work because people use them for a
 number of
  conflicting purposes (my list of things to read every day, a simple
 history
  system, a 'to read' list, a collection of links for research), which
 have
  different UI requirements.  I think the same thing has happened with
 tabs
  (and there's a surprising amount of overlap).  Here are the use cases
 I know
  I wind up using:
  - a few long running apps that need to keep running, potentially
 notifying
  me of new events (calendar, mail, chat, buildbot, etc.)
  - a few pages that I'm currently actively using (a screenshot from a
 bug
  I'm looking at, some reference documentation, a writely page I'm
 editing
  between compiles, etc.)
  - a to read list of pages that I started reading but didn't finish
 yet
  (sometimes this is a collection of related pages when researching
 something)
  - I'm sure there are others.
  In my use case, 80% of my tabs could easily be killed / suspended (or
 even
  hidden altogether) without any downside to me.  The problem is that
 there
  isn't a way to automatically figure out which ones are which.  Which
 ones

[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium

2009-07-22 Thread Anthony LaForge

(Warning: TPM perspective) The main problem with the current system is that
it's a very time consuming process to parse through ~1000 revisions each
week.  Even with filter tools which parse the SVN logs and look for
revisions with closed bugs, specific keywords in the logs, specific files,
auto-discarding reverts, etc... that still brings us down to about 150
entries that require manual review.  Of those, a good portion are
not immediately clear from either the bug title or the SVN summary as to
exactly what the fix was for, which requires extra detective work.  Once
that's done we end up re-writing/ clarifying the text.  Even with all that
effort I'm not 100% satisfied that we're coming up with what I'd call good
results (we hit most things, but it's easy to miss lots of important stuff).

Given the labor intensiveness and the so so yield, it seems like this
process is an excellent candidate for applying some distributed labor and
automation.  I understand the resistance to ChangeLogs, but it doesn't seem
unreasonable to ask committers, who have the best sense of the nature of
their work, to take an extra minute to put a single line descriptive comment
along side their SVN commit (and for reviewers to check it).

Kind Regards,

Anthony Laforge
Technical Program Manager
Mountain View, CA
External Phone: 1-650-214-4055


On Wed, Jul 22, 2009 at 10:09 AM, Peter Kasting pkast...@google.com wrote:

 On Wed, Jul 22, 2009 at 10:03 AM, Adam Langley a...@chromium.org wrote:

 On Wed, Jul 22, 2009 at 4:52 PM, Anthony LaForgelafo...@google.com
 wrote:
  Ok, I know when to stop pushing, that's reasonable and appreciated
 feedback.
 So shifting gears, it seems like everyone would be comfortable with
 using
  RELEASE_NOTES tag in SVN comments.  Any thoughts from the group on best
  practices for using that the tag gets used effectively?


 Who said everyone was comfortable?  I'm probably not going to bother
 writing RELEASE_NOTES pretty much ever.  (In exchange, I frequently edit our
 release notes to be more complete or accurate.)

 If the goal is pointing people at something that lists all changes, we can
 do it with a script.  If the goal is making the release notes for releases
 better, a ChangeLog wouldn't have helped you anyway.  I'm not sure there is
 much advantage in modifications to the current system -- even if
 RELEASE_NOTES get written sometimes, you're still going to need to parse all
 the rest of the changes and decide what to say.

 * When reverting, the log is reverted as well:

 Actually, I've never been too sure about reverting in WebKit: does one
 revert the ChangeLog file too or add another ChangeLog entry at the
 top describing the revert?


 Unless my memory is faulty, according to the Apple folks who have guided me
 through reverts (in particular, bdash), you add a new entry at top saying
 you're reverting; you never remove the old CL entry.

 But, the commit message should match the change message on the code
 review, so our reviewers can already critique it. So, this would
 appear to be a review issue rather than a technological issue.


 Yes, and if reviewers aren't complaining about poor descriptions here, they
 should be.

 PK


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium

On Wed, Jul 22, 2009 at 11:33 AM, Anthony LaForge lafo...@google.comwrote:

 Even with filter tools which parse the SVN logs and look for revisions with
 closed bugs, specific keywords in the logs, specific files, auto-discarding
 reverts, etc... that still brings us down to about 150 entries that require
 manual review.  Of those, a good portion are not immediately clear from
 either the bug title or the SVN summary as to exactly what the fix was for,
 which requires extra detective work.  Once that's done we end up re-writing/
 clarifying the text.


I'm not terribly sympathetic here.  My home machine lacks all those tools
and I was able to write up a set of detailed release notes (for a release
that had been given near none) in my spare time in about two hours one
evening.

Even with all that effort I'm not 100% satisfied that we're coming up with
 what I'd call good results (we hit most things, but it's easy to miss lots
 of important stuff).


So?

Or to be less brief, what's the impact of the release notes missing some
changes?  No one is going to die.  The audience here is curious enthusiasts
who like to read What's New items.  Our past release notes have missed
tons of big things.

it doesn't seem unreasonable to ask committers, who have the best sense of
 the nature of their work, to take an extra minute to put a single line
 descriptive comment along side their SVN commit (and for reviewers to check
 it).


Committers already should be writing a description of their work and
reviewers should be checking it.  If it's not clear enough, I don't think
the solution is to ask for two descriptions.  I think we should instead ask
people to take more time to write a clearer description that hits the high
points in the first sentence.  (Notorious bad messages: This fixes bug
12345.  Fix some problems.  .)

PK

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium

2009-07-22 Thread Scott Hess


The stuff I'm implementing is important to _me_, but is it important
enough to be in the release notes?

Maybe we should have a tag for the issue-tracker which indicates that
the issue is release-note-worthy, and we could use action on those
bugs to help figure out which items are worthy of being in the release
notes?  Then if someone complains that their change didn't make the
release notes, we can tell them how to arrange for that in the future.
 From there, regular bug triage activities may suffice to work it down
to a reasonable volume.

-scott


On Wed, Jul 22, 2009 at 11:33 AM, Anthony LaForgelafo...@google.com wrote:
 (Warning: TPM perspective) The main problem with the current system is that
 it's a very time consuming process to parse through ~1000 revisions each
 week.  Even with filter tools which parse the SVN logs and look for
 revisions with closed bugs, specific keywords in the logs, specific files,
 auto-discarding reverts, etc... that still brings us down to about 150
 entries that require manual review.  Of those, a good portion are
 not immediately clear from either the bug title or the SVN summary as to
 exactly what the fix was for, which requires extra detective work.  Once
 that's done we end up re-writing/ clarifying the text.  Even with all that
 effort I'm not 100% satisfied that we're coming up with what I'd call good
 results (we hit most things, but it's easy to miss lots of important stuff).
 Given the labor intensiveness and the so so yield, it seems like this
 process is an excellent candidate for applying some distributed labor and
 automation.  I understand the resistance to ChangeLogs, but it doesn't seem
 unreasonable to ask committers, who have the best sense of the nature of
 their work, to take an extra minute to put a single line descriptive comment
 along side their SVN commit (and for reviewers to check it).
 Kind Regards,

 Anthony Laforge
 Technical Program Manager
 Mountain View, CA
 External Phone: 1-650-214-4055


 On Wed, Jul 22, 2009 at 10:09 AM, Peter Kasting pkast...@google.com wrote:

 On Wed, Jul 22, 2009 at 10:03 AM, Adam Langley a...@chromium.org wrote:

 On Wed, Jul 22, 2009 at 4:52 PM, Anthony LaForgelafo...@google.com
 wrote:
  Ok, I know when to stop pushing, that's reasonable and appreciated
  feedback.
     So shifting gears, it seems like everyone would be comfortable with
  using
  RELEASE_NOTES tag in SVN comments.  Any thoughts from the group on best
  practices for using that the tag gets used effectively?

 Who said everyone was comfortable?  I'm probably not going to bother
 writing RELEASE_NOTES pretty much ever.  (In exchange, I frequently edit our
 release notes to be more complete or accurate.)
 If the goal is pointing people at something that lists all changes, we can
 do it with a script.  If the goal is making the release notes for releases
 better, a ChangeLog wouldn't have helped you anyway.  I'm not sure there is
 much advantage in modifications to the current system -- even if
 RELEASE_NOTES get written sometimes, you're still going to need to parse all
 the rest of the changes and decide what to say.

 * When reverting, the log is reverted as well:
 Actually, I've never been too sure about reverting in WebKit: does one
 revert the ChangeLog file too or add another ChangeLog entry at the
 top describing the revert?

 Unless my memory is faulty, according to the Apple folks who have guided
 me through reverts (in particular, bdash), you add a new entry at top saying
 you're reverting; you never remove the old CL entry.

 But, the commit message should match the change message on the code
 review, so our reviewers can already critique it. So, this would
 appear to be a review issue rather than a technological issue.

 Yes, and if reviewers aren't complaining about poor descriptions here,
 they should be.
 PK

 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium

2009-07-22 Thread Scott Hess


BTW: if people aren't annotating their CL's with bugs, they SURELY
won't annotate them with release notes or update the change log.  Just
aiming for the path of least resistance, here.

-scott


On Wed, Jul 22, 2009 at 11:46 AM, Scott Hesssh...@chromium.org wrote:
 The stuff I'm implementing is important to _me_, but is it important
 enough to be in the release notes?

 Maybe we should have a tag for the issue-tracker which indicates that
 the issue is release-note-worthy, and we could use action on those
 bugs to help figure out which items are worthy of being in the release
 notes?  Then if someone complains that their change didn't make the
 release notes, we can tell them how to arrange for that in the future.
  From there, regular bug triage activities may suffice to work it down
 to a reasonable volume.

 -scott


 On Wed, Jul 22, 2009 at 11:33 AM, Anthony LaForgelafo...@google.com wrote:
 (Warning: TPM perspective) The main problem with the current system is that
 it's a very time consuming process to parse through ~1000 revisions each
 week.  Even with filter tools which parse the SVN logs and look for
 revisions with closed bugs, specific keywords in the logs, specific files,
 auto-discarding reverts, etc... that still brings us down to about 150
 entries that require manual review.  Of those, a good portion are
 not immediately clear from either the bug title or the SVN summary as to
 exactly what the fix was for, which requires extra detective work.  Once
 that's done we end up re-writing/ clarifying the text.  Even with all that
 effort I'm not 100% satisfied that we're coming up with what I'd call good
 results (we hit most things, but it's easy to miss lots of important stuff).
 Given the labor intensiveness and the so so yield, it seems like this
 process is an excellent candidate for applying some distributed labor and
 automation.  I understand the resistance to ChangeLogs, but it doesn't seem
 unreasonable to ask committers, who have the best sense of the nature of
 their work, to take an extra minute to put a single line descriptive comment
 along side their SVN commit (and for reviewers to check it).
 Kind Regards,

 Anthony Laforge
 Technical Program Manager
 Mountain View, CA
 External Phone: 1-650-214-4055


 On Wed, Jul 22, 2009 at 10:09 AM, Peter Kasting pkast...@google.com wrote:

 On Wed, Jul 22, 2009 at 10:03 AM, Adam Langley a...@chromium.org wrote:

 On Wed, Jul 22, 2009 at 4:52 PM, Anthony LaForgelafo...@google.com
 wrote:
  Ok, I know when to stop pushing, that's reasonable and appreciated
  feedback.
     So shifting gears, it seems like everyone would be comfortable with
  using
  RELEASE_NOTES tag in SVN comments.  Any thoughts from the group on best
  practices for using that the tag gets used effectively?

 Who said everyone was comfortable?  I'm probably not going to bother
 writing RELEASE_NOTES pretty much ever.  (In exchange, I frequently edit our
 release notes to be more complete or accurate.)
 If the goal is pointing people at something that lists all changes, we can
 do it with a script.  If the goal is making the release notes for releases
 better, a ChangeLog wouldn't have helped you anyway.  I'm not sure there is
 much advantage in modifications to the current system -- even if
 RELEASE_NOTES get written sometimes, you're still going to need to parse all
 the rest of the changes and decide what to say.

 * When reverting, the log is reverted as well:
 Actually, I've never been too sure about reverting in WebKit: does one
 revert the ChangeLog file too or add another ChangeLog entry at the
 top describing the revert?

 Unless my memory is faulty, according to the Apple folks who have guided
 me through reverts (in particular, bdash), you add a new entry at top saying
 you're reverting; you never remove the old CL entry.

 But, the commit message should match the change message on the code
 review, so our reviewers can already critique it. So, this would
 appear to be a review issue rather than a technological issue.

 Yes, and if reviewers aren't complaining about poor descriptions here,
 they should be.
 PK

 



--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] BookmarkHTMLWriterTest failing

2009-07-22 Thread Jonas Klink (Google)

I am trying to push http://codereview.chromium.org/155446 , but running into
issues with BookmarkHTMLWriterTest on Win tryserver:
http://build.chromium.org/buildbot/try-server/builders/win/builds/11093/steps/unit_tests/logs/stdio

Anyone have any experience with this test? I have tried to figure out why my
CL is breaking the test, but unsuccessful so far...

Thankful for any help,
Jonas

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] better commit descriptions WAS: Proposal for adding ChangeLog files to Chromium

On Wed, Jul 22, 2009 at 10:07 AM, Darin Fisher da...@chromium.org wrote:

 On Wed, Jul 22, 2009 at 10:03 AM, Adam Langley a...@chromium.org wrote:

 * By having the ChangeLog in the review, reviewers can critique it.


 Many of our commit messages are little brief. Some are far too brief.
 But, the commit message should match the change message on the code
 review, so our reviewers can already critique it. So, this would
 appear to be a review issue rather than a technological issue.


 I think we need to remember to review the CL description.  It is easy to
 overlook when reviewing an issue.


This is an understatement. We really do a poor job with commit descriptions.
There is a lot to be gained by having better commit descriptions. We can
learn from WebKit process here without adding the burden of ChangeLog files.
They have great change descriptions and it's frequently very useful.

To be a bit more concrete, gcl change could autopopulate your change
description with something like the following that has the list of modified
functions:
DETAILED DESCRIPTION HERE

BUG=required
TEST=required
RELEASE_NOTES=optional

Autogenerated list of modified methods here.


So here's what an example would look like (poached from AGL's recent webkit
commit):

Chromium Linux: Allow for setting the global font rendering preferences.
Added static functions for setting hinting, anti-alias and subpixel glyph
preferences.

BUG=12345
TEST=none
RELEASE_NOTES=none

platform/graphics/chromium/FontPlatformDataLinux.cpp:
  (WebCore::FontPlatformData::setHinting):
  (WebCore::FontPlatformData::setAntiAlias):
  (WebCore::FontPlatformData::setSubpixelGlyphs):
  (WebCore::FontPlatformData::setupPaint): Modified to do something super
special.
platform/graphics/chromium/FontPlatformDataLinux.h:

Ojan

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Reusing chromium code

2009-07-22 Thread Igor Gatis

Yep, base lots of threading APIs (thread, lock, atomic, etc).
It would be great if base was released as library by itself with all of this
cool stuff. I'd keep UI related in a separated library though.
On Mon, Jul 20, 2009 at 5:11 PM, Elliot Glaysher (Chromium) 
e...@chromium.org wrote:

 Google testing and logging libraries are already separate projects:

 http://code.google.com/p/googletest/
 http://code.google.com/p/googlemock/
 http://code.google.com/p/google-glog/

 A lot of the rest of stuff in base/ isn't, though.

 -- Elliot

 On Sun, Jul 19, 2009 at 6:46 AM, Igor Gatisigorga...@gmail.com wrote:
 
  Chromium has lots of interesting base APIs such as the ones found
  under base/ and testing/. Is there any chance these two could be
  available as a separate library? It would be great if I could use such
  library in my own projects.
 
  Thanks,
  -Gatis
 
   
 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Anyone know ScriptObjectQuarantine.cpp?

Mads and Dimitri do.  I wouldn't mind being part of such a discussion either
DOM Storage uses it but I don't really know how or why.  :-)
J

On Wed, Jul 22, 2009 at 11:24 AM, Adam Barth aba...@chromium.org wrote:


 If you know what WebCore/bindings/v8/ScriptObjectQuarantine.cpp is
 supposed to do, can you reply to me privately?  There's some code in
 there that doesn't make sense to me, and I'd like to understand what
 it's trying to accomplish.

 Thanks,
 Adam

 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: BookmarkHTMLWriterTest failing

Just flakiness. But I don't know why.

On Wed, Jul 22, 2009 at 18:53, Jonas Klink (Google) kl...@chromium.orgwrote:

 I am trying to push http://codereview.chromium.org/155446 , but running
 into issues with BookmarkHTMLWriterTest on Win tryserver:

 http://build.chromium.org/buildbot/try-server/builders/win/builds/11093/steps/unit_tests/logs/stdio

 Anyone have any experience with this test? I have tried to figure out why
 my CL is breaking the test, but unsuccessful so far...

 Thankful for any help,
 Jonas

 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: better commit descriptions WAS: Proposal for adding ChangeLog files to Chromium

On Wed, Jul 22, 2009 at 11:57 AM, Ojan Vafai o...@chromium.org wrote:

 On Wed, Jul 22, 2009 at 10:07 AM, Darin Fisher da...@chromium.org wrote:

 On Wed, Jul 22, 2009 at 10:03 AM, Adam Langley a...@chromium.org wrote:

 * By having the ChangeLog in the review, reviewers can critique it.


 Many of our commit messages are little brief. Some are far too brief.
 But, the commit message should match the change message on the code
 review, so our reviewers can already critique it. So, this would
 appear to be a review issue rather than a technological issue.


 I think we need to remember to review the CL description.  It is easy to
 overlook when reviewing an issue.


 This is an understatement. We really do a poor job with commit
 descriptions. There is a lot to be gained by having better commit
 descriptions. We can learn from WebKit process here without adding the
 burden of ChangeLog files. They have great change descriptions and it's
 frequently very useful.


TOTALLY agree.  We're too lax in reviewing CL descriptions in Chrome.
 WebKit reviewers scrutinizes them as much as the code itself, and that's a
good thing.


 To be a bit more concrete, gcl change could autopopulate your change
 description with something like the following that has the list of modified
 functions:
 DETAILED DESCRIPTION HERE

 BUG=required
 TEST=required
 RELEASE_NOTES=optional

 Autogenerated list of modified methods here.


 So here's what an example would look like (poached from AGL's recent webkit
 commit):

 Chromium Linux: Allow for setting the global font rendering preferences.
 Added static functions for setting hinting, anti-alias and subpixel glyph
 preferences.

 BUG=12345
 TEST=none
 RELEASE_NOTES=none


I feel like RELEASE_NOTES should only be there if it matters (i.e. isn't
'none').  Honestly, I'd say the same for TEST.

Maybe the default CL description when you first run 'gcl change' should add
BUG=\n TEST=\n RELEASE_NOTES= but then have the convention that we should
delete them if they don't apply to our change?


 platform/graphics/chromium/FontPlatformDataLinux.cpp:
   (WebCore::FontPlatformData::setHinting):
   (WebCore::FontPlatformData::setAntiAlias):
   (WebCore::FontPlatformData::setSubpixelGlyphs):
   (WebCore::FontPlatformData::setupPaint): Modified to do something super
 special.
 platform/graphics/chromium/FontPlatformDataLinux.h:


Is it worth putting this into the change list?  If so, maybe 'gcl commit'
can do it (since doing it any earlier risks it getting stale as the CL
changes).  I know a couple of WebKit developers find it helpful, but I'm not
sure it's worth the overhead.  Especially if people are used to it
currently.

Also note that when a function or file warrants a special note, there's
nothing stopping someone from making that note whether or not we have a
convention of always listing the files/functions modified.

J

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium

2009-07-22 Thread Jon

If you don't want to see this thread anymore you can use the 'm' shortcut to
mute it.
If you don't have a BUG in your commit comment then we probably won't even
see your CL and it won't make the release notes.

It would be enough, IMHO, to have the first line of your commit comment
describe the change in a way that makes it clear that it should be
highlighted in the release notes.

A tag would be even better, but I understand all that extra typing can be
tiresome.

Anthony was not looking for a CHANGE_LOG like WebKit which included each CL.
We already provide a link to all the CL
commentshttp://build.chromium.org/buildbot/perf/dashboard/ui/changelog.html?url=/trunk/srcrange=20903:21176mode=htmlfor
a release. He was looking for an entry to a file each time you have
something release note worthy. My experience is that we have about 5 items
that rise to this level with each release.

If you don't want to do any of these things then you should subscribe to
cr-rel-notify so you can see the proposed blog entry before it goes out.
Then you can let us know when we have missed something interesting.

Jon

On Wed, Jul 22, 2009 at 11:47 AM, Scott Hess sh...@chromium.org wrote:

BTW: if people aren't annotating their CL's with bugs, they SURELY
won't annotate them with release notes or update the change log. Just
aiming for the path of least resistance, here.

-scott

On Wed, Jul 22, 2009 at 11:46 AM, Scott Hesssh...@chromium.org wrote:
The stuff I'm implementing is important to _me_, but is it important
enough to be in the release notes?

Maybe we should have a tag for the issue-tracker which indicates that
the issue is release-note-worthy, and we could use action on those
bugs to help figure out which items are worthy of being in the release
notes? Then if someone complains that their change didn't make the
release notes, we can tell them how to arrange for that in the future.
From there, regular bug triage activities may suffice to work it down
to a reasonable volume.

-scott

On Wed, Jul 22, 2009 at 11:33 AM, Anthony LaForgelafo...@google.com
wrote:
(Warning: TPM perspective) The main problem with the current system is
that
it's a very time consuming process to parse through ~1000 revisions each
week. Even with filter tools which parse the SVN logs and look for
revisions with closed bugs, specific keywords in the logs, specific
files,
auto-discarding reverts, etc... that still brings us down to about 150
entries that require manual review. Of those, a good portion are
not immediately clear from either the bug title or the SVN summary as to
exactly what the fix was for, which requires extra detective work. Once
that's done we end up re-writing/ clarifying the text. Even with all
that
effort I'm not 100% satisfied that we're coming up with what I'd call
good
results (we hit most things, but it's easy to miss lots of important
stuff).
Given the labor intensiveness and the so so yield, it seems like this
process is an excellent candidate for applying some distributed labor
and
automation. I understand the resistance to ChangeLogs, but it doesn't
seem
unreasonable to ask committers, who have the best sense of the nature of
their work, to take an extra minute to put a single line descriptive
comment
along side their SVN commit (and for reviewers to check it).
Kind Regards,

Anthony Laforge
Technical Program Manager
Mountain View, CA
External Phone: 1-650-214-4055

On Wed, Jul 22, 2009 at 10:09 AM, Peter Kasting pkast...@google.com
wrote:

On Wed, Jul 22, 2009 at 10:03 AM, Adam Langley a...@chromium.org
wrote:

On Wed, Jul 22, 2009 at 4:52 PM, Anthony LaForgelafo...@google.com
wrote:
Ok, I know when to stop pushing, that's reasonable and appreciated
feedback.
So shifting gears, it seems like everyone would be comfortable
with
using
RELEASE_NOTES tag in SVN comments. Any thoughts from the group on
best
practices for using that the tag gets used effectively?

Who said everyone was comfortable? I'm probably not going to bother
writing RELEASE_NOTES pretty much ever. (In exchange, I frequently
edit our
release notes to be more complete or accurate.)
If the goal is pointing people at something that lists all changes, we
can
do it with a script. If the goal is making the release notes for
releases
better, a ChangeLog wouldn't have helped you anyway. I'm not sure
there is
much advantage in modifications to the current system -- even if
RELEASE_NOTES get written sometimes, you're still going to need to
parse all
the rest of the changes and decide what to say.

* When reverting, the log is reverted as well:
Actually, I've never been too sure about reverting in WebKit: does one
revert the ChangeLog file too or add another ChangeLog entry at the
top describing the revert?

Unless my memory is faulty, according to the Apple folks who have
guided
me

[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium

2009-07-22 Thread Dirk Pranke


-1000 to manual changelog updates

+1 to a changelog populated by a commit trigger. Having a
local/offline copy of the change history can be useful, in the absence
of git.

-100 to reverts deleting stuff from changelogs. changelogs should be
(except in exceptional circumstances) append only, just like version
control.

Seems to me that any substantive change or feature addition should be
tracked by a bug, and that bug should have a 'feature' or
'release_note' flag associated with it. Then writing a script to pull
all the relevant notes would be pretty easy.

-- Dirk


On Wed, Jul 22, 2009 at 10:13 AM, Darin Fisherda...@chromium.org wrote:
 On Wed, Jul 22, 2009 at 10:09 AM, Peter Kasting pkast...@google.com wrote:

 ...
 Actually, I've never been too sure about reverting in WebKit: does one
 revert the ChangeLog file too or add another ChangeLog entry at the
 top describing the revert?

 Unless my memory is faulty, according to the Apple folks who have guided
 me through reverts (in particular, bdash), you add a new entry at top saying
 you're reverting; you never remove the old CL entry.

 Oh, good to know!
 -Darin
 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] FF's search engine keyword

2009-07-22 Thread Igor Gatis

(please forgive me if this not the right list)
Firefox has what they call search engine aliases, or keywords. In order to
select a specific search, one just types keyword query on the URL bar
which causes the query to be issued against a particular search engine.

I have 5+ search engines setup within FF and I just love them. They work as
shortcuts for websites I use heavily; for instance, I have a keyword for
each of my favorite dictionary websites. Here they are:

keyword, site
g,google.com
dc,  dictionary.com
ud,  urbandictionary.com
de,  dict.tu-chemnitz.de
wp,  wikipedia.org
tt,  my company's intranet search engine 1
rr,   my company's intranet search engine 2

So when I want to google something, I just type g something, when I want
to lookup the meaning of a certain word, I just type dc word and so on.

Will something like that be supported by chromium?

Thanks,
-Gatis

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium

It sounds like better CL descriptions will make most of the problems go
away. Ojan started a new thread about this.
If people don't put BUG='s in their CL descriptions or won't use the
RELEASE_NOTES annotation, there's no hope for them using a ChangeLog.

Is this dead horse sufficiently beaten? :-)

On Wed, Jul 22, 2009 at 12:32 PM, Jon j...@chromium.org wrote:

If you don't want to see this thread anymore you can use the 'm' shortcut
to mute it.
If you don't have a BUG in your commit comment then we probably won't even
see your CL and it won't make the release notes.

It would be enough, IMHO, to have the first line of your commit comment
describe the change in a way that makes it clear that it should be
highlighted in the release notes.

A tag would be even better, but I understand all that extra typing can be
tiresome.

Anthony was not looking for a CHANGE_LOG like WebKit which included each
CL. We already provide a link to all the CL
commentshttp://build.chromium.org/buildbot/perf/dashboard/ui/changelog.html?url=/trunk/srcrange=20903:21176mode=htmlfor
a release. He was looking for an entry to a file each time you have
something release note worthy. My experience is that we have about 5 items
that rise to this level with each release.

Jon

On Wed, Jul 22, 2009 at 11:47 AM, Scott Hess sh...@chromium.org wrote:

BTW: if people aren't annotating their CL's with bugs, they SURELY
won't annotate them with release notes or update the change log. Just
aiming for the path of least resistance, here.

-scott

On Wed, Jul 22, 2009 at 11:46 AM, Scott Hesssh...@chromium.org wrote:
The stuff I'm implementing is important to _me_, but is it important
enough to be in the release notes?

-scott

On Wed, Jul 22, 2009 at 11:33 AM, Anthony LaForgelafo...@google.com
wrote:
(Warning: TPM perspective) The main problem with the current system is
that
it's a very time consuming process to parse through ~1000 revisions
each
week. Even with filter tools which parse the SVN logs and look for
revisions with closed bugs, specific keywords in the logs, specific
files,
auto-discarding reverts, etc... that still brings us down to about 150
entries that require manual review. Of those, a good portion are
not immediately clear from either the bug title or the SVN summary as
to
exactly what the fix was for, which requires extra detective work.
Once
that's done we end up re-writing/ clarifying the text. Even with all
that
effort I'm not 100% satisfied that we're coming up with what I'd call
good
results (we hit most things, but it's easy to miss lots of important
stuff).
Given the labor intensiveness and the so so yield, it seems like this
process is an excellent candidate for applying some distributed labor
and
automation. I understand the resistance to ChangeLogs, but it doesn't
seem
unreasonable to ask committers, who have the best sense of the nature
of
their work, to take an extra minute to put a single line descriptive
comment
along side their SVN commit (and for reviewers to check it).
Kind Regards,

Anthony Laforge
Technical Program Manager
Mountain View, CA
External Phone: 1-650-214-4055

On Wed, Jul 22, 2009 at 10:09 AM, Peter Kasting pkast...@google.com
wrote:

On Wed, Jul 22, 2009 at 10:03 AM, Adam Langley a...@chromium.org
wrote:

[chromium-dev] Re: FF's search engine keyword

On Wed, Jul 22, 2009 at 12:46 PM, Igor Gatis igorga...@gmail.com wrote:

 (please forgive me if this not the right list)


It's not.  chromium-discuss@ is the right list, or the Help Center.

So when I want to google something, I just type g something, when I want
 to lookup the meaning of a certain word, I just type dc word and so on.

 Will something like that be supported by chromium?


It already is, and furthermore if you imported all your settings from
Firefox during install, you have those same keywords set up for you.

PK

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: FYI: Upcoming O3D integration changes.

2009-07-22 Thread Nicolas Sylvain

On Wed, Jul 22, 2009 at 11:47 AM, Greg Spencer gspen...@google.com wrote:



 On Wed, Jul 22, 2009 at 11:27 AM, Nicolas Sylvain 
 nsylv...@chromium.orgwrote:

   src/third_party/nixysa/files:

 why in a subdir called files?


 A leftover from converting from p4/scons -- I'll remove it.

   # NACL has to be in this weird directory because it looks for
   # googleclient two levels above it.
   src/third_party/native_client/googleclient/native_client:

 Looks like they should change their code to make it work without assuming
 all these directories.

 and this code is already fetched in src/native_client, we don't want it
 twice.


 Yes, that just happened recently -- I'll try to switch to using their new
 GYP build.

 For those who are curious :

  $ du -h --max-depth=1 .
 4.1M./gflags
 34M ./native_client
 1.3M./nixysa
 251K./npapi
 2.1M./ply-3.1
 24M ./vectormath
 64M .



 And the additional native_client will disappear, so more like 30M.  (and
 these numbers include all the .svn dirs, so the real code is half that).
 The docs in the vectormath library are 17M, so we could probably delete
 those from the repo if size is an issue, and make it 13M total.

That would be great!

Thanks

Nicolas



 -Greg.


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Question about V8 bindings

2009-07-22 Thread Drew Wilson

I think this may not be true, as I got a compilation error in the generated
bindings when I removed the type enum for the base class.
Note that the code generated for my derived class contains an explicit
reference to the base class:
static v8::Persistentv8::FunctionTemplate
ConfigureV8DedicatedWorkerContextTemplate(v8::Persistentv8::FunctionTemplate
desc) {

   ...initialization of attributes...

  desc-Inherit(V8DOMWrapper::getTemplate(*V8ClassIndex::WORKERCONTEXT*));
  desc-SetClassName(v8::String::New(DedicatedWorkerContext));
  return desc;
}

So it appears that we *do* need to define the base type in this case, and in
general we need to be able to generate a template for every item in the
class hierarchy, even if that class should not be directly instantiable.

Is this correct, or am I missing something?

-atw

On Tue, Jul 21, 2009 at 10:42 PM, Mads Sig Ager a...@chromium.org wrote:

 If you don't need the base 'type' in the binding layer code, you don't
 have to specify it in the V8Index file.  Prototype chains and
 instanceof operations are all handled by V8 based on the code
 generated from the IDL files and it is independent of the 'type'
 declarations in the V8Index file.

 Cheers,-- Mads

 On Tue, Jul 21, 2009 at 6:13 PM, Drew Wilsonatwil...@chromium.org wrote:
  The other unanswered question is whether it's useful to define the base
  type in V8Index.h.
  If a wrapper of the base type (WRAPPERCONTEXT) is never instantiated, do
 I
  still need to define it for the purposes of things like instanceof and
  prototype chains? Or is it *only* used to specify the type of wrapper
  instances?
  -atw
 
  On Tue, Jul 21, 2009 at 10:58 AM, Adam Barth aba...@chromium.org
 wrote:
 
  I think the way this works in general is that you create the wrapper
  for the derived class.  You can see all the switch statements in
  V8DOMWrapper.cpp that try to do this for Nodes, etc.
 
  Adam
 
 
  On Tue, Jul 21, 2009 at 10:32 AM, Jeremy Orlowjor...@chromium.org
 wrote:
   On Tue, Jul 21, 2009 at 10:19 AM, Drew Wilson atwil...@google.com
   wrote:
  
   It seems like that would have some undesirable side-effects, aside
 from
   the fact that WebKit frowns on using virtual functions unnecessarily.
   So, let's imagine that I have two derived classes,
 SharedWorkerContext
   and
   DedicatedWorkerContext. DedicatedWorkerContext wants to expose
   postMessage()
   as a public callable function, but SharedWorkerContext would not.
   If we only have a single V8 class for both of these (WORKERCONTEXT)
   then
   that implies:
   1) I have to define postMessage() as a virtual function on the base
   WebCore class (WorkerContext). In fact, WorkerContext ends up
   containing the
   union of all exposed APIs for every future derived class, which seems
   ugly.
   2) From javascript, if I have a SharedWorkerContext, and I do this
   typeof
   postMessage, it should return undefined (since SharedWorkerContext
   does
   not define this attribute) - however, since SharedWorkerContext is
   actually
   just a vanilla WORKERCONTEXT behind the scenes, it would return
   function,
   which violates the spec.
   It seems like the right way to do this is to actually have separate
 V8
   items. The alternative is to have just a single WORKERCONTEXT, but
   instead
   of using polymorphism have custom getters/setters for every attribute
   that
   check the type of the impl class and do the appropriate thing. But it
   seems
   like the whole point of having the V8ClassIndex enum is to avoid this
   kind
   of manual polymorphism.
  
   Good points.
   Are there other use cases for building polymorphism into V8?  Is there
   any
   notion of polymorphism in the IDL files?  Maybe the best answer is to
   just
   make them two completely different classes.  It kind of seems like
 doing
   this elegantly is going to cost us performance wise one way or
 another.
   J
  
   On Mon, Jul 20, 2009 at 8:22 PM, Jeremy Orlow jor...@chromium.org
   wrote:
  
   In other words, make all workers appear the same to V8 (i.e. as a
   WORKERCONTEXT) and then implement polymorphism in the
 implementations
   being
   wrapped by V8.
   On Mon, Jul 20, 2009 at 8:19 PM, Jeremy Orlow jor...@chromium.org
   wrote:
  
   Sorry if this is a dumb question, but why woudn't you simply have a
   WORKERCONTEXT and let virtual dispatch do its job for the rest?
Shared
   methods can be implemented on the base class and the rest can be
   purely
   virtual with implementations in the sub classes.
   J
  
   On Mon, Jul 20, 2009 at 3:21 PM, Drew Wilson 
 atwil...@chromium.org
   wrote:
  
   Following up on this. Let's imagine that I don't define a
   V8ClassIndex
   enum for the common base class (so, in my case, I get rid of
   WORKERCONTEXT,
   and have only DEDICATEDWORKERCONTEXT and SHAREDWORKERCONTEXT (the
   derived
   classes).
   Now, let's say I'm defining an ACCESSOR_GETTER on the base class -
   the
   first thing I want to do is get a pointer to

[chromium-dev] Re: Knowing when a context menu is closed

2009-07-22 Thread Tommi

for Windows:http://msdn.microsoft.com/en-us/library/ms647599(VS.85).aspx
The *WM_EXITMENULOOP* message informs an application's main window
procedure that a menu modal loop has been exited.

On Wed, Jul 22, 2009 at 2:13 PM, Albert J. Wong (王重傑)
ajw...@chromium.orgwrote:

 I need to find a way to know when a context menu is closed, either via a
 menu item selection, or via hitting escape, opening a new menu, unfocusing
 the window, etc.
 Ideally, there'd be some sort of menu closed function or event that is
 called when the menu stops being displayed.  On the gtk port, I see
 a RenderViewContextMenuGtk::StoppedShowing(), but nothing similar for
 Windows and Mac.

 Can anyone give me a pointer on how to do something like this for mac, and
 windows?

 Thanks,
 Albert

 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium

2009-07-22 Thread Mohamed Mansour

I like Scott's idea, if you think your patch is ChangeLog worthy, add some
sort of release-note-worthy key on the bottom of the commit description.
And as Peter stated, make sure the first line of the commit message is very
descriptive that explains what this release note worthy message is really
about.

I believe those two approaches will make it easier for the developers and
the managers to produce release notes. A simple script (python since you all
like python) could read the log since the last release and correctly parse
out release-note-worthy

Maybe modify bugdroid to parse out release-note-worthy and send an email
to the people responsible everytime that is there.

-- Mohamed Mansour

On Wed, Jul 22, 2009 at 3:48 PM, Jeremy Orlow jor...@chromium.org wrote:

Is this dead horse sufficiently beaten? :-)

On Wed, Jul 22, 2009 at 12:32 PM, Jon j...@chromium.org wrote:

If you don't want to see this thread anymore you can use the 'm' shortcut
to mute it.
If you don't have a BUG in your commit comment then we probably won't even
see your CL and it won't make the release notes.

It would be enough, IMHO, to have the first line of your commit comment
describe the change in a way that makes it clear that it should be
highlighted in the release notes.

A tag would be even better, but I understand all that extra typing can be
tiresome.

Anthony was not looking for a CHANGE_LOG like WebKit which included each
CL. We already provide a link to all the CL
commentshttp://build.chromium.org/buildbot/perf/dashboard/ui/changelog.html?url=/trunk/srcrange=20903:21176mode=htmlfor
a release. He was looking for an entry to a file each time you have
something release note worthy. My experience is that we have about 5 items
that rise to this level with each release.

Jon

On Wed, Jul 22, 2009 at 11:47 AM, Scott Hess sh...@chromium.org wrote:

BTW: if people aren't annotating their CL's with bugs, they SURELY
won't annotate them with release notes or update the change log. Just
aiming for the path of least resistance, here.

-scott

On Wed, Jul 22, 2009 at 11:46 AM, Scott Hesssh...@chromium.org wrote:
The stuff I'm implementing is important to _me_, but is it important
enough to be in the release notes?

-scott

On Wed, Jul 22, 2009 at 11:33 AM, Anthony LaForgelafo...@google.com
wrote:
(Warning: TPM perspective) The main problem with the current system is
that
it's a very time consuming process to parse through ~1000 revisions
each
week. Even with filter tools which parse the SVN logs and look for
revisions with closed bugs, specific keywords in the logs, specific
files,
auto-discarding reverts, etc... that still brings us down to about 150
entries that require manual review. Of those, a good portion are
not immediately clear from either the bug title or the SVN summary as
to
exactly what the fix was for, which requires extra detective work.
Once
that's done we end up re-writing/ clarifying the text. Even with all
that
effort I'm not 100% satisfied that we're coming up with what I'd call
good
results (we hit most things, but it's easy to miss lots of important
stuff).
Given the labor intensiveness and the so so yield, it seems like this
process is an excellent candidate for applying some distributed labor
and
automation. I understand the resistance to ChangeLogs, but it doesn't
seem
unreasonable to ask committers, who have the best sense of the nature
of
their work, to take an extra minute to put a single line descriptive
comment
along side their SVN commit (and for reviewers to check it).
Kind Regards,

Anthony Laforge
Technical Program Manager
Mountain View, CA
External Phone: 1-650-214-4055

On Wed, Jul 22, 2009 at 10:09 AM, Peter Kasting pkast...@google.com
wrote:

On Wed, Jul 22, 2009 at 10:03 AM, Adam Langley a...@chromium.org
wrote:

On Wed, Jul 22, 2009 at 4:52 PM, Anthony LaForgelafo...@google.com

wrote:
Ok, I know when to stop pushing, that's reasonable and

[chromium-dev] Re: Question about V8 bindings

2009-07-22 Thread Drew Wilson

Digging further through the errors, it seems that the generated code for the
base class itself is littered with references to the V8ClassIndex::type
value. For example:
  static v8::Handlev8::Value locationAttrGetter(v8::Localv8::String
name, const v8::AccessorInfo info) {
INC_STATS(DOM.WorkerContext.location._get);
v8::Handlev8::Object holder = info.Holder();
WorkerContext* imp = V8DOMWrapper::convertToNativeObjectWorkerContext(
*V8ClassIndex::WORKERCONTEXT*, holder);

I'd note that V8DOMWrapper::convertToNativeObject() is basically just a
wrapper around convertDOMWrapperToNative() which itself just pulls a pointer
value out of kDOMWrapperObjectIndex (the passed-in type is essentially
ignored except for some runtime debugging) so we could probably just
generate calls to convertDOMWrapperToNative() instead.

-atw



On Wed, Jul 22, 2009 at 12:59 PM, Drew Wilson atwil...@chromium.org wrote:

 I think this may not be true, as I got a compilation error in the generated
 bindings when I removed the type enum for the base class.
 Note that the code generated for my derived class contains an explicit
 reference to the base class:
 static v8::Persistentv8::FunctionTemplate
 ConfigureV8DedicatedWorkerContextTemplate(v8::Persistentv8::FunctionTemplate
 desc) {

...initialization of attributes...

   desc-Inherit(V8DOMWrapper::getTemplate(*V8ClassIndex::WORKERCONTEXT*));
   desc-SetClassName(v8::String::New(DedicatedWorkerContext));
   return desc;
 }

 So it appears that we *do* need to define the base type in this case, and
 in general we need to be able to generate a template for every item in the
 class hierarchy, even if that class should not be directly instantiable.

 Is this correct, or am I missing something?

 -atw

 On Tue, Jul 21, 2009 at 10:42 PM, Mads Sig Ager a...@chromium.org wrote:

 If you don't need the base 'type' in the binding layer code, you don't
 have to specify it in the V8Index file.  Prototype chains and
 instanceof operations are all handled by V8 based on the code
 generated from the IDL files and it is independent of the 'type'
 declarations in the V8Index file.

 Cheers,-- Mads

 On Tue, Jul 21, 2009 at 6:13 PM, Drew Wilsonatwil...@chromium.org
 wrote:
  The other unanswered question is whether it's useful to define the base
  type in V8Index.h.
  If a wrapper of the base type (WRAPPERCONTEXT) is never instantiated, do
 I
  still need to define it for the purposes of things like instanceof and
  prototype chains? Or is it *only* used to specify the type of wrapper
  instances?
  -atw
 
  On Tue, Jul 21, 2009 at 10:58 AM, Adam Barth aba...@chromium.org
 wrote:
 
  I think the way this works in general is that you create the wrapper
  for the derived class.  You can see all the switch statements in
  V8DOMWrapper.cpp that try to do this for Nodes, etc.
 
  Adam
 
 
  On Tue, Jul 21, 2009 at 10:32 AM, Jeremy Orlowjor...@chromium.org
 wrote:
   On Tue, Jul 21, 2009 at 10:19 AM, Drew Wilson atwil...@google.com
   wrote:
  
   It seems like that would have some undesirable side-effects, aside
 from
   the fact that WebKit frowns on using virtual functions
 unnecessarily.
   So, let's imagine that I have two derived classes,
 SharedWorkerContext
   and
   DedicatedWorkerContext. DedicatedWorkerContext wants to expose
   postMessage()
   as a public callable function, but SharedWorkerContext would not.
   If we only have a single V8 class for both of these
 (WORKERCONTEXT)
   then
   that implies:
   1) I have to define postMessage() as a virtual function on the base
   WebCore class (WorkerContext). In fact, WorkerContext ends up
   containing the
   union of all exposed APIs for every future derived class, which
 seems
   ugly.
   2) From javascript, if I have a SharedWorkerContext, and I do this
   typeof
   postMessage, it should return undefined (since
 SharedWorkerContext
   does
   not define this attribute) - however, since SharedWorkerContext is
   actually
   just a vanilla WORKERCONTEXT behind the scenes, it would return
   function,
   which violates the spec.
   It seems like the right way to do this is to actually have separate
 V8
   items. The alternative is to have just a single WORKERCONTEXT, but
   instead
   of using polymorphism have custom getters/setters for every
 attribute
   that
   check the type of the impl class and do the appropriate thing. But
 it
   seems
   like the whole point of having the V8ClassIndex enum is to avoid
 this
   kind
   of manual polymorphism.
  
   Good points.
   Are there other use cases for building polymorphism into V8?  Is
 there
   any
   notion of polymorphism in the IDL files?  Maybe the best answer is to
   just
   make them two completely different classes.  It kind of seems like
 doing
   this elegantly is going to cost us performance wise one way or
 another.
   J
  
   On Mon, Jul 20, 2009 at 8:22 PM, Jeremy Orlow jor...@chromium.org
   wrote:
  
   In other words, make all workers appear the same to V8

[chromium-dev] Re: better commit descriptions WAS: Proposal for adding ChangeLog files to Chromium

On Wed, Jul 22, 2009 at 12:26 PM, Jeremy Orlow jor...@chromium.org wrote:

On Wed, Jul 22, 2009 at 11:57 AM, Ojan Vafai o...@chromium.org wrote:

This is an understatement. We really do a poor job with commit
descriptions. There is a lot to be gained by having better commit
descriptions. We can learn from WebKit process here without adding the
burden of ChangeLog files. They have great change descriptions and it's
frequently very useful.

TOTALLY agree. We're too lax in reviewing CL descriptions in Chrome.
WebKit reviewers scrutinizes them as much as the code itself, and that's a
good thing.

Forgot to say, if someone felt really motivated to make this scrutinization
happen, a change to reitveld to allow commenting on the change description
and making it part of the list of things to review would work great for
this.

platform/graphics/chromium/FontPlatformDataLinux.cpp:

(WebCore::FontPlatformData::setHinting):
(WebCore::FontPlatformData::setAntiAlias):
(WebCore::FontPlatformData::setSubpixelGlyphs):
(WebCore::FontPlatformData::setupPaint): Modified to do something super
special.
platform/graphics/chromium/FontPlatformDataLinux.h:

Is it worth putting this into the change list? If so, maybe 'gcl commit'
can do it (since doing it any earlier risks it getting stale as the CL
changes).

The benefit of this is that you can give more detailed comments inline. You
see some WebKit commits do this (e.g. Darin Adler's) and it makes it much
more clear from reading the change description what happened. So, if we're
going to do it, it's not useful to do at commit time. It would be great if
people got in the habit of writing detailed descriptions like this.

Here's an example of a Darin Adler commit where this leads to a nice clear
and detailed description.

WebCore:

2009-07-15 Darin Adler da...@apple.com da...@apple.com

Reviewed by John Sullivan.

After double-clicking a word, using Shift-arrow to select behaves
unpredictably

https://bugs.webkit.org/show_bug.cgi?id=27177https://bugs.webkit.org/show_bug.cgi?id=27177
rdar://problem/7034324 rdar://problem/7034324

Test: editing/selection/extend-selection-after-double-click.html

The bug was due to the m_lastChangeWasHorizontalExtension flag, which was
not
being cleared in many cases where it should have been.

- editing/SelectionController.cpp:
(WebCore::SelectionController::setSelection): Set
m_lastChangeWasHorizontalExtension to false. This catches all sorts of cases
that don't flow through the modify function. Before, the flag would reflect
the last call to the modify function, which was not necessarily the last
selection change. (WebCore::SelectionController::willBeModified): Rearrange
function for clarity. Remove code that sets
m_lastChangeWasHorizontalExtension; that is now handled elsewhere.
(WebCore::SelectionController::modify): Call
setLastChangeWasHorizontalExtension after setSelection when setting up a
trial selection controller, since setSelection now clears that flag. Also
changed both trial selection controller cases to set the flag, although it's
not strictly necessary in both cases. Added code to set
m_lastChangeWasHorizontalExtension when extending the selection, which used
to be handled in willBeModified. Now we need to do it after the selection
change.

LayoutTests:

2009-07-15 Darin Adler da...@apple.com da...@apple.com

Reviewed by John Sullivan.

After double-clicking a word, using Shift-arrow to select behaves
unpredictably

https://bugs.webkit.org/show_bug.cgi?id=27177https://bugs.webkit.org/show_bug.cgi?id=27177
rdar://problem/7034324 rdar://problem/7034324

- editing/selection/extend-selection-after-double-click-expected.txt:
Added.
- editing/selection/extend-selection-after-double-click.html: Copied from
LayoutTests/editing/selection/word-granularity.html. Then turned it into a
new test.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Knowing when a context menu is closed

2009-07-22 Thread Nico Weber


On mac, you can probably set the NSMenu's delegate to an object of
your choice and have it implement menuDidClose: if you  want to
implement this yourself.

On Wed, Jul 22, 2009 at 1:07 PM, Tommito...@chromium.org wrote:
 for Windows:
 http://msdn.microsoft.com/en-us/library/ms647599(VS.85).aspx
 The WM_EXITMENULOOP message informs an application's main window procedure
 that a menu modal loop has been exited.
 On Wed, Jul 22, 2009 at 2:13 PM, Albert J. Wong (王重傑) ajw...@chromium.org
 wrote:

 I need to find a way to know when a context menu is closed, either via a
 menu item selection, or via hitting escape, opening a new menu, unfocusing
 the window, etc.
 Ideally, there'd be some sort of menu closed function or event that is
 called when the menu stops being displayed.  On the gtk port, I see
 a RenderViewContextMenuGtk::StoppedShowing(), but nothing similar for
 Windows and Mac.
 Can anyone give me a pointer on how to do something like this for mac, and
 windows?
 Thanks,
 Albert



 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: better commit descriptions WAS: Proposal for adding ChangeLog files to Chromium

On Wed, Jul 22, 2009 at 1:17 PM, Ojan Vafai o...@chromium.org wrote:

platform/graphics/chromium/FontPlatformDataLinux.cpp:

Is it worth putting this into the change list? If so, maybe 'gcl commit'
can do it (since doing it any earlier risks it getting stale as the CL
changes).

I really, really hate this style.

I have never encountered a case where a combination of comments-in-code and
good-change-description are not both sufficient, and far more readable than
the above style.

Here's an example of a Darin Adler commit where this leads to a nice clear
and detailed description.

WebCore:

2009-07-15 Darin Adler da...@apple.com da...@apple.com

Reviewed by John Sullivan.

After double-clicking a word, using Shift-arrow to select behaves
unpredictably

https://bugs.webkit.org/show_bug.cgi?id=27177https://bugs.webkit.org/show_bug.cgi?id=27177
rdar://problem/7034324

Test: editing/selection/extend-selection-after-double-click.html

The bug was due to the m_lastChangeWasHorizontalExtension flag, which was
not
being cleared in many cases where it should have been.

This kind of thing should be a comment in the code, and the fact that
WebKit does not generally comment code is much to their detriment.

- editing/selection/extend-selection-after-double-click.html: Copied
from LayoutTests/editing/selection/word-granularity.html. Then turned it
into a new test.

This kind of thing, if really important, should be a comment in the change
description.

[chromium-dev] Re: better commit descriptions WAS: Proposal for adding ChangeLog files to Chromium

2009-07-22 Thread Evan Martin


 platform/graphics/chromium/FontPlatformDataLinux.cpp:

   (WebCore::FontPlatformData::setHinting):
   (WebCore::FontPlatformData::setAntiAlias):
   (WebCore::FontPlatformData::setSubpixelGlyphs):
   (WebCore::FontPlatformData::setupPaint): Modified to do something super
 special.
 platform/graphics/chromium/FontPlatformDataLinux.h:

 Is it worth putting this into the change list?  If so, maybe 'gcl commit'
 can do it (since doing it any earlier risks it getting stale as the CL
 changes).

 The benefit of this is that you can give more detailed comments inline. You
 see some WebKit commits do this (e.g. Darin Adler's) and it makes it much
 more clear from reading the change description what happened. So, if we're
 going to do it, it's not useful to do at commit time. It would be great if
 people got in the habit of writing detailed descriptions like this.

I am against ... oh, PK already responded and said exactly what I was gonna say.
If there are notes that are relevant to some bit of code, they belong
as comments beside the code.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Knowing when a context menu is closed

On Wed, Jul 22, 2009 at 1:19 PM, Nico Weber tha...@chromium.org wrote:

 On mac, you can probably set the NSMenu's delegate to an object of
 your choice and have it implement menuDidClose: if you  want to
 implement this yourself.


Cool, I'll look into that once I get the windows side settled.


 On Wed, Jul 22, 2009 at 1:07 PM, Tommito...@chromium.org wrote:
  for Windows:
  http://msdn.microsoft.com/en-us/library/ms647599(VS.85).aspx
  The WM_EXITMENULOOP message informs an application's main window
 procedure
  that a menu modal loop has been exited.


I also see WM_UNINITMENUPOPUP.  The description of that is:

  The *WM_UNINITMENUPOPUP* message is sent when a drop-down menu or submenu
has been destroyed.

Is that less appropriate to use that WM_EXITMENULOOP?

Thanks,
Albert



  On Wed, Jul 22, 2009 at 2:13 PM, Albert J. Wong (王重傑) 
 ajw...@chromium.org
  wrote:
 
  I need to find a way to know when a context menu is closed, either via
 a
  menu item selection, or via hitting escape, opening a new menu,
 unfocusing
  the window, etc.
  Ideally, there'd be some sort of menu closed function or event that is
  called when the menu stops being displayed.  On the gtk port, I see
  a RenderViewContextMenuGtk::StoppedShowing(), but nothing similar for
  Windows and Mac.
  Can anyone give me a pointer on how to do something like this for mac,
 and
  windows?
  Thanks,
  Albert
 
 
 
   
 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: better commit descriptions WAS: Proposal for adding ChangeLog files to Chromium

On Wed, Jul 22, 2009 at 1:22 PM, Peter Kasting pkast...@google.com wrote:

On Wed, Jul 22, 2009 at 1:17 PM, Ojan Vafai o...@chromium.org wrote:

platform/graphics/chromium/FontPlatformDataLinux.cpp:

(WebCore::FontPlatformData::setHinting):
(WebCore::FontPlatformData::setAntiAlias):
(WebCore::FontPlatformData::setSubpixelGlyphs):
(WebCore::FontPlatformData::setupPaint): Modified to do something
super special.
platform/graphics/chromium/FontPlatformDataLinux.h:

Is it worth putting this into the change list? If so, maybe 'gcl commit'
can do it (since doing it any earlier risks it getting stale as the CL
changes).

The benefit of this is that you can give more detailed comments inline.
You see some WebKit commits do this (e.g. Darin Adler's) and it makes it
much more clear from reading the change description what happened. So, if
we're going to do it, it's not useful to do at commit time. It would be
great if people got in the habit of writing detailed descriptions like this.

I really, really hate this style.

I have never encountered a case where a combination of comments-in-code and
good-change-description are not both sufficient, and far more readable than
the above style.

Here's an example of a Darin Adler commit where this leads to a nice clear
and detailed description.

WebCore:

2009-07-15 Darin Adler da...@apple.com da...@apple.com

Reviewed by John Sullivan.

After double-clicking a word, using Shift-arrow to select behaves
unpredictably

https://bugs.webkit.org/show_bug.cgi?id=27177https://bugs.webkit.org/show_bug.cgi?id=27177
rdar://problem/7034324

Test: editing/selection/extend-selection-after-double-click.html

The bug was due to the m_lastChangeWasHorizontalExtension flag, which was
not
being cleared in many cases where it should have been.

This kind of thing should be a comment in the code, and the fact that
WebKit does not generally comment code is much to their detriment.

Yes. For some reason, WebKit likes to replace comments in the code with
comments in the ChangeLog which seems insane to me. If you need comments
this detailed in the ChangeLog then something is wrong with the code IMHO.

I think there are very few cases where you need down to the function level
of detail. In most case, you should be putting comments in the code or
splitting your CL into multiple that each address one specific issue.

- editing/selection/extend-selection-after-double-click.html: Copied
from LayoutTests/editing/selection/word-granularity.html. Then turned it
into a new test.

This kind of thing, if really important, should be a comment in the change
description.

[chromium-dev] valgrind updated


If you don't run valgrind, you can probably ignore this.

tools/valgrind/build-valgrind-for-chromium.sh has been updated.

Used to be, if you had gold as your system linker, it would
generate a valgrind that couldn't even valgrind /bin/true.
It's now a bit smarter, and won't build or install a broken valgrind.

It also adds a patch to properly terminate log files on exec
(which gets rid of an annoying delay when running
tools/valgrind/chrome_tests.sh on some tests).

Separately, http://wiki.corp.google.com/Main/ChromeBuildbotLinux
was also updated, and a new valgrind and gold were pushed to
the main valgrind bots, codf15[678].
They were missing the long suppressions patch before,
so the update should prevent recurrence of one
of the intermittent valgrind warnings seen today.
(It already had a suppression, but because the suppresson
had a line longer than 200 chars, it was ignored.)

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: better commit descriptions WAS: Proposal for adding ChangeLog files to Chromium

I'm OK with not having the function list. I can see the advantages of the
webkit approach as it means that comments in the code don't get outdated.
But, then it forces you to look at the changelog history of every line of
code.
Anyways, how about we prepopulate gcl/git-cl change with this text:
DETAILED_DESCRIPTION_HERE

BUG=http://bugs.chromium.org/BUG_NUMBER_HERE
TEST=required
RELEASE_NOTES=optional

On Wed, Jul 22, 2009 at 1:28 PM, Jeremy Orlow jor...@chromium.org wrote:

On Wed, Jul 22, 2009 at 1:22 PM, Peter Kasting pkast...@google.comwrote:

On Wed, Jul 22, 2009 at 1:17 PM, Ojan Vafai o...@chromium.org wrote:

platform/graphics/chromium/FontPlatformDataLinux.cpp:

(WebCore::FontPlatformData::setHinting):
(WebCore::FontPlatformData::setAntiAlias):
(WebCore::FontPlatformData::setSubpixelGlyphs):
(WebCore::FontPlatformData::setupPaint): Modified to do something
super special.
platform/graphics/chromium/FontPlatformDataLinux.h:

Is it worth putting this into the change list? If so, maybe 'gcl
commit' can do it (since doing it any earlier risks it getting stale as the
CL changes).

The benefit of this is that you can give more detailed comments inline.
You see some WebKit commits do this (e.g. Darin Adler's) and it makes it
much more clear from reading the change description what happened. So, if
we're going to do it, it's not useful to do at commit time. It would be
great if people got in the habit of writing detailed descriptions like this.

I really, really hate this style.

I have never encountered a case where a combination of comments-in-code
and good-change-description are not both sufficient, and far more readable
than the above style.

Here's an example of a Darin Adler commit where this leads to a nice clear
and detailed description.

WebCore:

2009-07-15 Darin Adler da...@apple.com da...@apple.com

Reviewed by John Sullivan.

After double-clicking a word, using Shift-arrow to select behaves
unpredictably

https://bugs.webkit.org/show_bug.cgi?id=27177https://bugs.webkit.org/show_bug.cgi?id=27177
rdar://problem/7034324

Test: editing/selection/extend-selection-after-double-click.html

The bug was due to the m_lastChangeWasHorizontalExtension flag, which was
not
being cleared in many cases where it should have been.

This kind of thing should be a comment in the code, and the fact that
WebKit does not generally comment code is much to their detriment.

- editing/selection/extend-selection-after-double-click.html: Copied
from LayoutTests/editing/selection/word-granularity.html. Then turned it
into a new test.

This kind of thing, if really important, should be a comment in the
change description.

[chromium-dev] Re: better commit descriptions WAS: Proposal for adding ChangeLog files to Chromium

Here comes the bike shedding...but what about this:

BUG=
TEST=
RELEASE_NOTES=

I don't think any ALL CAPS TEXT at the top is going to make people put in
better descriptions. If you want bug to be a url, it should use
crbug.cominstead of the full string, but the convention so far has
been a bar bug
number which I think is fine.

I don't really see why TEST is required...it's none much more often than
BUG. I think simply populating it by default will get people to annotate it
if they have anything to say. Otherwise they should just delete it.

And I don't like the idea of needing to delete instructions on how to use
the change descriptions every time I make a CL. I think what I'm proposing
makes it obvious enough for newcomers while optimizing for people who submit
a lot of CLs.

On Wed, Jul 22, 2009 at 1:43 PM, Ojan Vafai o...@chromium.org wrote:

BUG=http://bugs.chromium.org/BUG_NUMBER_HERE
TEST=required
RELEASE_NOTES=optional

On Wed, Jul 22, 2009 at 1:28 PM, Jeremy Orlow jor...@chromium.org wrote:

On Wed, Jul 22, 2009 at 1:22 PM, Peter Kasting pkast...@google.comwrote:

On Wed, Jul 22, 2009 at 1:17 PM, Ojan Vafai o...@chromium.org wrote:

platform/graphics/chromium/FontPlatformDataLinux.cpp:

(WebCore::FontPlatformData::setHinting):
(WebCore::FontPlatformData::setAntiAlias):
(WebCore::FontPlatformData::setSubpixelGlyphs):
(WebCore::FontPlatformData::setupPaint): Modified to do something
super special.
platform/graphics/chromium/FontPlatformDataLinux.h:

Is it worth putting this into the change list? If so, maybe 'gcl
commit' can do it (since doing it any earlier risks it getting stale as
the
CL changes).

The benefit of this is that you can give more detailed comments inline.
You see some WebKit commits do this (e.g. Darin Adler's) and it makes it
much more clear from reading the change description what happened. So, if
we're going to do it, it's not useful to do at commit time. It would be
great if people got in the habit of writing detailed descriptions like
this.

I really, really hate this style.

I have never encountered a case where a combination of comments-in-code
and good-change-description are not both sufficient, and far more readable
than the above style.

Here's an example of a Darin Adler commit where this leads to a nice
clear and detailed description.

WebCore:

2009-07-15 Darin Adler da...@apple.com da...@apple.com

Reviewed by John Sullivan.

After double-clicking a word, using Shift-arrow to select behaves
unpredictably

https://bugs.webkit.org/show_bug.cgi?id=27177https://bugs.webkit.org/show_bug.cgi?id=27177
rdar://problem/7034324

Test: editing/selection/extend-selection-after-double-click.html

The bug was due to the m_lastChangeWasHorizontalExtension flag, which
was not
being cleared in many cases where it should have been.

This kind of thing should be a comment in the code, and the fact that
WebKit does not generally comment code is much to their detriment.

- editing/selection/extend-selection-after-double-click.html: Copied
from LayoutTests/editing/selection/word-granularity.html. Then turned it
into a new test.

This kind of thing, if really important, should be a comment in the
change description.

[chromium-dev] Re: valgrind updated

Seems like a good news, but why should I use this script instead of
regular valgrind? I don't know the difference.

On Wed, Jul 22, 2009 at 20:39, Dan Kegel d...@kegel.com wrote:


 If you don't run valgrind, you can probably ignore this.

 tools/valgrind/build-valgrind-for-chromium.sh has been updated.

 Used to be, if you had gold as your system linker, it would
 generate a valgrind that couldn't even valgrind /bin/true.
 It's now a bit smarter, and won't build or install a broken valgrind.

 It also adds a patch to properly terminate log files on exec
 (which gets rid of an annoying delay when running
 tools/valgrind/chrome_tests.sh on some tests).

 Separately, http://wiki.corp.google.com/Main/ChromeBuildbotLinux
 was also updated, and a new valgrind and gold were pushed to
 the main valgrind bots, codf15[678].
 They were missing the long suppressions patch before,
 so the update should prevent recurrence of one
 of the intermittent valgrind warnings seen today.
 (It already had a suppression, but because the suppresson
 had a line longer than 200 chars, it was ignored.)

 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: better commit descriptions WAS: Proposal for adding ChangeLog files to Chromium

On Wed, Jul 22, 2009 at 1:49 PM, Jeremy Orlow jor...@chromium.org wrote:

 Here comes the bike shedding


Yes, Evan already concluded that was where we were.

RELEASE_NOTES=


I thought the conclusion was that people should just write better commit
messages?  Maybe I'm wrong.

I'd almost prefer:

Replace this with one-line summary of your change

Replace this with more details as needed

BUG=
TEST=

...although I also agree with you that deleting instruction can be really
annoying.

PK

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: better commit descriptions WAS: Proposal for adding ChangeLog files to Chromium

Bug filed: http://code.google.com/p/chromium/issues/detail?id=17471

On Wed, Jul 22, 2009 at 1:49 PM, Jeremy Orlow jor...@chromium.org wrote:

Here comes the bike shedding...but what about this:

BUG=
TEST=
RELEASE_NOTES=

On Wed, Jul 22, 2009 at 1:43 PM, Ojan Vafai o...@chromium.org wrote:

BUG=http://bugs.chromium.org/BUG_NUMBER_HERE
TEST=required
RELEASE_NOTES=optional

On Wed, Jul 22, 2009 at 1:28 PM, Jeremy Orlow jor...@chromium.orgwrote:

On Wed, Jul 22, 2009 at 1:22 PM, Peter Kasting pkast...@google.comwrote:

On Wed, Jul 22, 2009 at 1:17 PM, Ojan Vafai o...@chromium.org wrote:

platform/graphics/chromium/FontPlatformDataLinux.cpp:

(WebCore::FontPlatformData::setHinting):
(WebCore::FontPlatformData::setAntiAlias):
(WebCore::FontPlatformData::setSubpixelGlyphs):
(WebCore::FontPlatformData::setupPaint): Modified to do something
super special.
platform/graphics/chromium/FontPlatformDataLinux.h:

Is it worth putting this into the change list? If so, maybe 'gcl
commit' can do it (since doing it any earlier risks it getting stale as
the
CL changes).

The benefit of this is that you can give more detailed comments inline.
You see some WebKit commits do this (e.g. Darin Adler's) and it makes it
much more clear from reading the change description what happened. So, if
we're going to do it, it's not useful to do at commit time. It would be
great if people got in the habit of writing detailed descriptions like
this.

I really, really hate this style.

I have never encountered a case where a combination of comments-in-code
and good-change-description are not both sufficient, and far more readable
than the above style.

Here's an example of a Darin Adler commit where this leads to a nice
clear and detailed description.

WebCore:

2009-07-15 Darin Adler da...@apple.com da...@apple.com

Reviewed by John Sullivan.

After double-clicking a word, using Shift-arrow to select behaves
unpredictably

https://bugs.webkit.org/show_bug.cgi?id=27177https://bugs.webkit.org/show_bug.cgi?id=27177
rdar://problem/7034324

Test: editing/selection/extend-selection-after-double-click.html

The bug was due to the m_lastChangeWasHorizontalExtension flag, which
was not
being cleared in many cases where it should have been.

This kind of thing should be a comment in the code, and the fact that
WebKit does not generally comment code is much to their detriment.

I think there are very few cases where you need down to the function
level of detail. In most case, you should be putting comments in the code
or splitting your CL into multiple that each address one specific issue.

- editing/selection/extend-selection-after-double-click.html:
Copied from LayoutTests/editing/selection/word-granularity.html. Then
turned
it into a new test.

This kind of thing, if really important, should be a comment in the
change description.

[chromium-dev] Re: valgrind updated

2009-07-22 Thread Evan Stade


it's just a helpful wrapper, doing stuff like --malloc-fill=41 and
pointing at the suppression file.

-- Evan Stade



On Wed, Jul 22, 2009 at 8:53 PM, Paweł Hajdan
Jr.phajdan...@chromium.org wrote:
 Seems like a good news, but why should I use this script instead of
 regular valgrind? I don't know the difference.

 On Wed, Jul 22, 2009 at 20:39, Dan Kegel d...@kegel.com wrote:

 If you don't run valgrind, you can probably ignore this.

 tools/valgrind/build-valgrind-for-chromium.sh has been updated.

 Used to be, if you had gold as your system linker, it would
 generate a valgrind that couldn't even valgrind /bin/true.
 It's now a bit smarter, and won't build or install a broken valgrind.

 It also adds a patch to properly terminate log files on exec
 (which gets rid of an annoying delay when running
 tools/valgrind/chrome_tests.sh on some tests).

 Separately, http://wiki.corp.google.com/Main/ChromeBuildbotLinux
 was also updated, and a new valgrind and gold were pushed to
 the main valgrind bots, codf15[678].
 They were missing the long suppressions patch before,
 so the update should prevent recurrence of one
 of the intermittent valgrind warnings seen today.
 (It already had a suppression, but because the suppresson
 had a line longer than 200 chars, it was ignored.)




 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: valgrind updated

2009-07-22 Thread James Hawkins


I believe Pawel is referring to build-valgrind-for-chromium.sh, as in
why use this script to build valgrind instead of the system-supplied
valgrind.  There are a few bugs that aren't in upstream releases that
we patch to workaround.

https://bugs.kde.org/show_bug.cgi?id=162848
https://bugs.kde.org/show_bug.cgi?id=186796

James

On Wed, Jul 22, 2009 at 2:23 PM, Evan Stadeest...@chromium.org wrote:

 it's just a helpful wrapper, doing stuff like --malloc-fill=41 and
 pointing at the suppression file.

 -- Evan Stade



 On Wed, Jul 22, 2009 at 8:53 PM, Paweł Hajdan
 Jr.phajdan...@chromium.org wrote:
 Seems like a good news, but why should I use this script instead of
 regular valgrind? I don't know the difference.

 On Wed, Jul 22, 2009 at 20:39, Dan Kegel d...@kegel.com wrote:

 If you don't run valgrind, you can probably ignore this.

 tools/valgrind/build-valgrind-for-chromium.sh has been updated.

 Used to be, if you had gold as your system linker, it would
 generate a valgrind that couldn't even valgrind /bin/true.
 It's now a bit smarter, and won't build or install a broken valgrind.

 It also adds a patch to properly terminate log files on exec
 (which gets rid of an annoying delay when running
 tools/valgrind/chrome_tests.sh on some tests).

 Separately, http://wiki.corp.google.com/Main/ChromeBuildbotLinux
 was also updated, and a new valgrind and gold were pushed to
 the main valgrind bots, codf15[678].
 They were missing the long suppressions patch before,
 so the update should prevent recurrence of one
 of the intermittent valgrind warnings seen today.
 (It already had a suppression, but because the suppresson
 had a line longer than 200 chars, it was ignored.)




 


 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: valgrind updated

Yes, that's what I was asking about. Thanks.

On Wed, Jul 22, 2009 at 21:28, James Hawkins jhawk...@chromium.org wrote:

 I believe Pawel is referring to build-valgrind-for-chromium.sh, as in
 why use this script to build valgrind instead of the system-supplied
 valgrind.  There are a few bugs that aren't in upstream releases that
 we patch to workaround.

 https://bugs.kde.org/show_bug.cgi?id=162848
 https://bugs.kde.org/show_bug.cgi?id=186796

 James

 On Wed, Jul 22, 2009 at 2:23 PM, Evan Stadeest...@chromium.org wrote:
 
  it's just a helpful wrapper, doing stuff like --malloc-fill=41 and
  pointing at the suppression file.
 
  -- Evan Stade
 
 
 
  On Wed, Jul 22, 2009 at 8:53 PM, Paweł Hajdan
  Jr.phajdan...@chromium.org wrote:
  Seems like a good news, but why should I use this script instead of
  regular valgrind? I don't know the difference.
 
  On Wed, Jul 22, 2009 at 20:39, Dan Kegel d...@kegel.com wrote:
 
  If you don't run valgrind, you can probably ignore this.
 
  tools/valgrind/build-valgrind-for-chromium.sh has been updated.
 
  Used to be, if you had gold as your system linker, it would
  generate a valgrind that couldn't even valgrind /bin/true.
  It's now a bit smarter, and won't build or install a broken valgrind.
 
  It also adds a patch to properly terminate log files on exec
  (which gets rid of an annoying delay when running
  tools/valgrind/chrome_tests.sh on some tests).
 
  Separately, http://wiki.corp.google.com/Main/ChromeBuildbotLinux
  was also updated, and a new valgrind and gold were pushed to
  the main valgrind bots, codf15[678].
  They were missing the long suppressions patch before,
  so the update should prevent recurrence of one
  of the intermittent valgrind warnings seen today.
  (It already had a suppression, but because the suppresson
  had a line longer than 200 chars, it was ignored.)
 
 
 
 
  
 
 
   
 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: valgrind updated


That's right.  You can get a lot of good work out of plain
old valgrind-1.4, but it suffers from the bugs James linked to,
i.e. it match suppressions with long symbols,
and it will produce garbled output after fork().
build-valgrind-for-chromium.sh installs a valgrind that
handles those situations better.

On Wed, Jul 22, 2009 at 9:28 PM, James Hawkinsjhawk...@chromium.org wrote:
 I believe Pawel is referring to build-valgrind-for-chromium.sh, as in
 why use this script to build valgrind instead of the system-supplied
 valgrind.  There are a few bugs that aren't in upstream releases that
 we patch to workaround.

 https://bugs.kde.org/show_bug.cgi?id=162848
 https://bugs.kde.org/show_bug.cgi?id=186796

 James

 On Wed, Jul 22, 2009 at 2:23 PM, Evan Stadeest...@chromium.org wrote:

 it's just a helpful wrapper, doing stuff like --malloc-fill=41 and
 pointing at the suppression file.

 -- Evan Stade



 On Wed, Jul 22, 2009 at 8:53 PM, Paweł Hajdan
 Jr.phajdan...@chromium.org wrote:
 Seems like a good news, but why should I use this script instead of
 regular valgrind? I don't know the difference.

 On Wed, Jul 22, 2009 at 20:39, Dan Kegel d...@kegel.com wrote:

 If you don't run valgrind, you can probably ignore this.

 tools/valgrind/build-valgrind-for-chromium.sh has been updated.

 Used to be, if you had gold as your system linker, it would
 generate a valgrind that couldn't even valgrind /bin/true.
 It's now a bit smarter, and won't build or install a broken valgrind.

 It also adds a patch to properly terminate log files on exec
 (which gets rid of an annoying delay when running
 tools/valgrind/chrome_tests.sh on some tests).

 Separately, http://wiki.corp.google.com/Main/ChromeBuildbotLinux
 was also updated, and a new valgrind and gold were pushed to
 the main valgrind bots, codf15[678].
 They were missing the long suppressions patch before,
 so the update should prevent recurrence of one
 of the intermittent valgrind warnings seen today.
 (It already had a suppression, but because the suppresson
 had a line longer than 200 chars, it was ignored.)




 


 



--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] [linux] Using system libraries for Chromium

2009-07-22 Thread Adam Langley


Context: both fta (Ubuntu) and Tom (Fedora) patch Chromium to use the
system versions of libpng, libz etc. This seems perfectly reasonable,
it saves memory, startup times etc. We should support this without
patching the code.

I have a prototype CL for libpng: http://codereview.chromium.org/159229

I'm requesting comments on the style.

At first I thought about creating a 'shadow includes' directory which
would look like

build/
  linux/
shadow/
  third_party/
libpng/
  png.h - #include png.h

If this directory was first on the include path list, it would
override the normal path. However, it is a little spooky and it
depends on a GYP change ('early_include_paths' or some such) to set
the ordering. (I couldn't find a good way to do it with the existing
make and SCons builds.)

The above CL uses a macro include:

#include INCLUDE_LIBPNG_PNG_H

In order to support build tools which do header chasing, I also kept
the old include in an #if 0 block.

This is a little more ugly in the source code, but it doesn't hide the
fact that something odd is happening. Here's the current Fedora patch
showing that not too many locations need patching like this:

http://spot.fedorapeople.org/chromium/patches/chromium-20090715-codechanges-system-bz2-xml2-xslt-zlib-minizip-libevent-jpeg-png-nss-nspr-v8.patch

If the above technique is acceptable, I'll do the rest of the common
libraries in the coming weeks. libevent is one exception since we have
local bug fixes there which need to be upstream first. (I sent them
upstream ages ago, but to no reply.)


AGL

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: better commit descriptions WAS: Proposal for adding ChangeLog files to Chromium

On Wed, Jul 22, 2009 at 2:52 PM, Darin Fisher da...@chromium.org wrote:

 On Wed, Jul 22, 2009 at 2:02 PM, Peter Kasting pkast...@google.comwrote:

 On Wed, Jul 22, 2009 at 1:49 PM, Jeremy Orlow jor...@chromium.orgwrote:

 Here comes the bike shedding


 Yes, Evan already concluded that was where we were.

 RELEASE_NOTES=


 I thought the conclusion was that people should just write better commit
 messages?  Maybe I'm wrong.

 I'd almost prefer:

 Replace this with one-line summary of your change

 Replace this with more details as needed

  BUG=
 TEST=

 ...although I also agree with you that deleting instruction can be really
 annoying.

 PK



 I like the suggestion of a short (one line) summary followed by a
 paragraph.  I also like the BUG=, TEST= fields.  What about R=/TBR=?


Is this something people typically grep for?  If not, then I think the
codereview.chromium.org link is enough.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [linux] Using system libraries for Chromium

2009-07-22 Thread Matt Perry

Rather than changing the code, can you do some tricks so that #include
third_party/libpng/png.h
that includes a forwarding file that includes png.h?  I'm thinking, in the
case that we want to build with system libpng:- ensure forwarding_includes
is first in the include order
- add file forwarding_includes/third_party/libpng/png.h that does #include
png.h

Or maybe just
- change the code to #include forwarding_includes/libpng/png.h
- add forwarding_includes/libpng/png.h that includes either png.h or
third_party/png.h, depending on the build flags.

On Wed, Jul 22, 2009 at 2:43 PM, Adam Langley a...@chromium.org wrote:


 Context: both fta (Ubuntu) and Tom (Fedora) patch Chromium to use the
 system versions of libpng, libz etc. This seems perfectly reasonable,
 it saves memory, startup times etc. We should support this without
 patching the code.

 I have a prototype CL for libpng: http://codereview.chromium.org/159229

 I'm requesting comments on the style.

 At first I thought about creating a 'shadow includes' directory which
 would look like

 build/
  linux/
shadow/
  third_party/
libpng/
  png.h - #include png.h

 If this directory was first on the include path list, it would
 override the normal path. However, it is a little spooky and it
 depends on a GYP change ('early_include_paths' or some such) to set
 the ordering. (I couldn't find a good way to do it with the existing
 make and SCons builds.)

 The above CL uses a macro include:

 #include INCLUDE_LIBPNG_PNG_H

 In order to support build tools which do header chasing, I also kept
 the old include in an #if 0 block.

 This is a little more ugly in the source code, but it doesn't hide the
 fact that something odd is happening. Here's the current Fedora patch
 showing that not too many locations need patching like this:


 http://spot.fedorapeople.org/chromium/patches/chromium-20090715-codechanges-system-bz2-xml2-xslt-zlib-minizip-libevent-jpeg-png-nss-nspr-v8.patch

 If the above technique is acceptable, I'll do the rest of the common
 libraries in the coming weeks. libevent is one exception since we have
 local bug fixes there which need to be upstream first. (I sent them
 upstream ages ago, but to no reply.)


 AGL

 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: better commit descriptions WAS: Proposal for adding ChangeLog files to Chromium

2009-07-22 Thread Mark Larson (Google)

On Wed, Jul 22, 2009 at 14:02, Peter Kasting pkast...@google.com wrote:

 On Wed, Jul 22, 2009 at 1:49 PM, Jeremy Orlow jor...@chromium.org wrote:

 Here comes the bike shedding


 Yes, Evan already concluded that was where we were.

 RELEASE_NOTES=


 I thought the conclusion was that people should just write better commit
 messages?


I still want a RELEASE_NOTES flag, but not a NOTES=I'm repeating what I
just wrote up above.

Writing concise summaries as the first line of a description is good form
that we should encourage for all changes, not just noteworthy changes. Given
a token that says hey, this is noteworthy or a user visible change, we can
write scripts to pull out the first line of the description for inclusion in
the release notes.

I'll look for a place to document writing good log messages on
dev.chromium.org.

--Mark

+1 for painting the bikeshed blue


 Maybe I'm wrong.

 I'd almost prefer:

 Replace this with one-line summary of your change

 Replace this with more details as needed

 BUG=
 TEST=

 ...although I also agree with you that deleting instruction can be really
 annoying.

 PK

 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [linux] Using system libraries for Chromium

2009-07-22 Thread Adam Langley


On Wed, Jul 22, 2009 at 9:50 PM, Darin Fisherda...@google.com wrote:
 Personally, I much prefer the #include png.h approach.  Is it a problem to
 wait for the GYP change that makes this possible?

Well, I could make it #include png.h everywhere and then add an
include directory in the case that we aren't using the system libpng.
If folks are happy with that (it goes against our usual policy of
avoid -I flags), then that's cool.


AGL

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: better commit descriptions WAS: Proposal for adding ChangeLog files to Chromium

2009-07-22 Thread Darin Fisher

On Wed, Jul 22, 2009 at 2:02 PM, Peter Kasting pkast...@google.com wrote:

 On Wed, Jul 22, 2009 at 1:49 PM, Jeremy Orlow jor...@chromium.org wrote:

 Here comes the bike shedding


 Yes, Evan already concluded that was where we were.

 RELEASE_NOTES=


 I thought the conclusion was that people should just write better commit
 messages?  Maybe I'm wrong.

 I'd almost prefer:

 Replace this with one-line summary of your change

 Replace this with more details as needed

 BUG=
 TEST=

 ...although I also agree with you that deleting instruction can be really
 annoying.

 PK



I like the suggestion of a short (one line) summary followed by a paragraph.
 I also like the BUG=, TEST= fields.  What about R=/TBR=?
-Darin

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: better commit descriptions WAS: Proposal for adding ChangeLog files to Chromium

2009-07-22 Thread Andrew Scherkus

Even though git-cl doesn't have presubmit checks per se, I do like how it
forces your first line to = 100 characters (rietveld limitation, I
believe).

gcl gets around this issue by truncating your description and adding an
ellipsis.

On Wed, Jul 22, 2009 at 2:52 PM, Darin Fisher da...@chromium.org wrote:

 On Wed, Jul 22, 2009 at 2:02 PM, Peter Kasting pkast...@google.comwrote:

 On Wed, Jul 22, 2009 at 1:49 PM, Jeremy Orlow jor...@chromium.orgwrote:

 Here comes the bike shedding


 Yes, Evan already concluded that was where we were.

 RELEASE_NOTES=


 I thought the conclusion was that people should just write better commit
 messages?  Maybe I'm wrong.

 I'd almost prefer:

 Replace this with one-line summary of your change

 Replace this with more details as needed

  BUG=
 TEST=

 ...although I also agree with you that deleting instruction can be really
 annoying.

 PK



 I like the suggestion of a short (one line) summary followed by a
 paragraph.  I also like the BUG=, TEST= fields.  What about R=/TBR=?
 -Darin



 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Purify help office hours

2009-07-22 Thread Erik Kay

If you were looking into any of the new Purify Fixit bugs in ui_tests,
please hold off.  It appears that a number of the bugs are bogus.  If you're
interested in the gory details, feel free to mail me.
Erik


On Mon, Jul 20, 2009 at 9:16 AM, Erik Kay erik...@chromium.org wrote:

 To echo Dan's valgrind office hours, I'll be available to help with Purify
 issues for this week's fixit as well.  See
 http://code.google.com/p/chromium/wiki/StabilityFixitWeek for more details
 (thanks to dank for setting up this page).

 I'll be on IRC from 9-3:30PST, and should respond to email questions as
 well.

 You may still be able to help review bugs even if you don't have Purify
 installed (Purify isn't a free tool).  It's likely that a number of the bugs
 will be findable simply by inspection.

 thanks,
 Erik




--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Purify help office hours

2009-07-22 Thread Erik Kay

I've marked all of the suspect bugs as Invalid.
For now, I've left the memory leak bugs filed as part of this fixit.  Let me
know if you think that any of these look bogus.

Erik


On Wed, Jul 22, 2009 at 3:14 PM, Erik Kay erik...@chromium.org wrote:

 If you were looking into any of the new Purify Fixit bugs in ui_tests,
 please hold off.  It appears that a number of the bugs are bogus.  If you're
 interested in the gory details, feel free to mail me.
 Erik


 On Mon, Jul 20, 2009 at 9:16 AM, Erik Kay erik...@chromium.org wrote:

 To echo Dan's valgrind office hours, I'll be available to help with Purify
 issues for this week's fixit as well.  See
 http://code.google.com/p/chromium/wiki/StabilityFixitWeek for more
 details (thanks to dank for setting up this page).

 I'll be on IRC from 9-3:30PST, and should respond to email questions as
 well.

 You may still be able to help review bugs even if you don't have Purify
 installed (Purify isn't a free tool).  It's likely that a number of the bugs
 will be findable simply by inspection.

 thanks,
 Erik





--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: [linux] Using system libraries for Chromium

2009-07-22 Thread Brett Wilson


On Wed, Jul 22, 2009 at 2:58 PM, Adam Langleya...@chromium.org wrote:

 On Wed, Jul 22, 2009 at 9:50 PM, Darin Fisherda...@google.com wrote:
 Personally, I much prefer the #include png.h approach.  Is it a problem to
 wait for the GYP change that makes this possible?

 Well, I could make it #include png.h everywhere and then add an
 include directory in the case that we aren't using the system libpng.
 If folks are happy with that (it goes against our usual policy of
 avoid -I flags), then that's cool.

Looks like you made this change in the patch, although I don't see the
include rule update for chrome.gyp.

I guess some obvious ones like png.h and bzlib.h are fine. Some of
them give me pause, like event.h, which we also have in views and
may also have in other parts of the system, and this will cause
compilation problems on Windows (I think). event.h just isn't very
clear to me either.

You could also have a define USE_SYSTEM_LIBRARIES and you write:

#ifdef USE_SYSTEM_LIBRARIES
#include png.h
#else
#include third_party/libpng/png.h
#endif

Which I find much more readable than your magic define for the png filename.

Brett

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] 3.0.195.1 Released to Dev Channel

2009-07-22 Thread Jon

See http://googlechromereleases.blogspot.com/ for more information.
Jon

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: 3.0.195.1 Released to Dev Channel

2009-07-22 Thread Julie Parent

What is the best way to figure out which WebKit revision this corresponds
to?  Some of the older release notes were including that information in the
notes, but I don't see it in the last few releases.

On Wed, Jul 22, 2009 at 5:28 PM, Jon j...@chromium.org wrote:

 See http://googlechromereleases.blogspot.com/ for more information.
 Jon

 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: 3.0.195.1 Released to Dev Channel

2009-07-22 Thread Nico Weber


http://src.chromium.org/viewvc/chrome/branches/195/src/DEPS?view=log

On Wed, Jul 22, 2009 at 5:49 PM, Julie Parentjpar...@chromium.org wrote:
 What is the best way to figure out which WebKit revision this corresponds
 to?  Some of the older release notes were including that information in the
 notes, but I don't see it in the last few releases.

 On Wed, Jul 22, 2009 at 5:28 PM, Jon j...@chromium.org wrote:

 See http://googlechromereleases.blogspot.com/ for more information.
 Jon



 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] avoiding compile failures on buildbot

One thing that would help us keep the tree more green is avoiding compile
failures. A compile failure is very bad, because without binaries the tests
can't run, and then we have to wait for all of them to run, which may reveal
additional failures etc.
I'm actually surprised by some failures on buildbot, but at least one thing
was not surprising for me: Windows Release compile failures when the Debug
compiles fine (because we don't have Release trybot).

What do you think? Do you have any ideas how we could avoid more compile
failures, even if they are not possible to apply now due to lack of
resources? (for example adding trybots, which seems to not happen soon).

I was also thinking about allowing simple check-ins when the tree is
waiting for cycle state (when the sheriff wants to verify that bots cycle
green after a lot of redness). The status would say (Tree closed, waiting
for cycle; ask sheriff to commit a simple change), or maybe some
abbreviation for that. It would help people getting code in, and the sheriff
could require really a lot from that change (like full green trybot pass
etc). What do you think about that (especially sheriffs)?

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Knowing when a context menu is closed

On Wed, Jul 22, 2009 at 1:26 PM, Albert J. Wong (王重傑)
ajw...@chromium.orgwrote:

 On Wed, Jul 22, 2009 at 1:19 PM, Nico Weber tha...@chromium.org wrote:

 On mac, you can probably set the NSMenu's delegate to an object of
 your choice and have it implement menuDidClose: if you  want to
 implement this yourself.


 Cool, I'll look into that once I get the windows side settled.


  On Wed, Jul 22, 2009 at 1:07 PM, Tommito...@chromium.org wrote:
  for Windows:
  http://msdn.microsoft.com/en-us/library/ms647599(VS.85).aspx
  The WM_EXITMENULOOP message informs an application's main window
 procedure
  that a menu modal loop has been exited.


 I also see WM_UNINITMENUPOPUP.  The description of that is:

   The *WM_UNINITMENUPOPUP* message is sent when a drop-down menu or
 submenu has been destroyed.

 Is that less appropriate to use that WM_EXITMENULOOP?


I tried this, but it doesn't quite do what I want.  The messages that are
received by the context menu window after a left-click are:

  0x215 - WM_CAPTURECHANGED
  0x125 - WM_UNINITMENUPOPUP
  0x11f - WM_MENUSELECT
  0x212 - WM_EXITMENULOOP
  0x126 - WM_MENUCOMMAND

This is a problem because WM_EXITMENULOOP occurs before WM_MENUCOMMAND.

The problem currently is that, for certain context menu items on a HTML5
media element, I need to keep a reference inside the renderer to the actual
HTML5 DOM node so that if an action is selected I can call commands on this
DOM node.

If the context menu is dismissed, I need to send message to the render to
the drop the reference in order to not leak a resource.

If an action is selected on the context menu, I need to send the selected
action to the renderer before I instruct the renderer to drop the reference.

Unforutnately, the message ordering for the window doesn't allow for me to
do this.

Currently, I'm down to really cheesy solutions like posting a delayed task
for 500ms later to drop the reference on a WM_EXITMENULOOP in hopes that
the WM_MENUCOMMAND can beat it in the race and send the selected action to
the renderer before the reference drop.

Is there any windows magic that I'm missing to be able to get a guaranteed
windows message that will show up after WM_MENUCOMMAND if a selection is
made?

Thanks,
Albert

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Knowing when a context menu is closed

On Wed, Jul 22, 2009 at 6:05 PM, Albert J. Wong (王重傑)
ajw...@chromium.orgwrote:

 The problem currently is that, for certain context menu items on a HTML5
 media element, I need to keep a reference inside the renderer to the actual
 HTML5 DOM node so that if an action is selected I can call commands on this
 DOM node.


Can you keep a weak reference, and if the node is no longer available at
MENUCOMMAND time, just do nothing?

PK

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: avoiding compile failures on buildbot

On Wed, Jul 22, 2009 at 5:59 PM, Paweł Hajdan Jr.
phajdan...@chromium.orgwrote:

 One thing that would help us keep the tree more green is avoiding compile
 failures. A compile failure is very bad, because without binaries the tests
 can't run, and then we have to wait for all of them to run, which may reveal
 additional failures etc.
 I'm actually surprised by some failures on buildbot, but at least one thing
 was not surprising for me: Windows Release compile failures when the Debug
 compiles fine (because we don't have Release trybot).


How often does something run in Windows when compiled with the release
configuration but not the debug?  I've definitely seen it, but I'm not sure
it's terribly common.  My guess is that there are other causes of the build
breaking that should be addressed first.  Are there any stats on this?

My gut feeling is that many of the build breaks are for things that never
passed on a try bot.  For example, WebKit gardening patches almost never
work on the try bots so we just ignore them.  I think working on stuff like
this will bear more fruit.

Not to mention that each bot costs a lot in terms of the machine,
power, maintenance time, etc.


 What do you think? Do you have any ideas how we could avoid more compile
 failures, even if they are not possible to apply now due to lack of
 resources? (for example adding trybots, which seems to not happen soon).

 I was also thinking about allowing simple check-ins when the tree is
 waiting for cycle state (when the sheriff wants to verify that bots cycle
 green after a lot of redness). The status would say (Tree closed, waiting
 for cycle; ask sheriff to commit a simple change), or maybe some
 abbreviation for that. It would help people getting code in, and the sheriff
 could require really a lot from that change (like full green trybot pass
 etc). What do you think about that (especially sheriffs)?


I think you can always ask the sheriffs if you can put something small in.
 I don't see the point of making any such message policy or a convention.
 That said, unless it doesn't compile or is REALLY obviously OK, I don't
think it's a good idea.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Knowing when a context menu is closed

On Wed, Jul 22, 2009 at 6:11 PM, Peter Kasting pkast...@google.com wrote:

 On Wed, Jul 22, 2009 at 6:05 PM, Albert J. Wong (王重傑) ajw...@chromium.org
  wrote:

 The problem currently is that, for certain context menu items on a HTML5
 media element, I need to keep a reference inside the renderer to the actual
 HTML5 DOM node so that if an action is selected I can call commands on this
 DOM node.


 Can you keep a weak reference, and if the node is no longer available at
 MENUCOMMAND time, just do nothing?


That would work. Does WebKit have weak references?  I don't see anything
that looks obviosuly like one in JavaScriptCore/wtf.

I also got another suggestion that on the action, I should just redo the hit
test to retrieve the media node, which nicely handles cases where the movie
node is getting changed out via javascript from undernearth the context
menu.

-Albert

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Knowing when a context menu is closed

2009-07-22 Thread Adam Barth


On Wed, Jul 22, 2009 at 6:23 PM, Albert J. Wong
(王重傑)ajw...@chromium.org wrote:
 I also got another suggestion that on the action, I should just redo the hit
 test to retrieve the media node, which nicely handles cases where the movie
 node is getting changed out via javascript from undernearth the context
 menu.

This is the approach we usually use, e.g., when saving an image by
right clicking.

Adam

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: avoiding compile failures on buildbot

2009-07-22 Thread Andrew Scherkus

On a related note, Frank (cc'd) ran into an issue where the mac try bots
have a less-strict compiler warning error than the build bots, which led to
a broken build once he checked in: http://codereview.chromium.org/155834

Probably a simple config tweak somewhere, but interesting nonetheless.

Andrew

On Wed, Jul 22, 2009 at 6:19 PM, Jeremy Orlow jor...@chromium.org wrote:

 On Wed, Jul 22, 2009 at 5:59 PM, Paweł Hajdan Jr. phajdan...@chromium.org
  wrote:

 One thing that would help us keep the tree more green is avoiding compile
 failures. A compile failure is very bad, because without binaries the tests
 can't run, and then we have to wait for all of them to run, which may reveal
 additional failures etc.
 I'm actually surprised by some failures on buildbot, but at least one
 thing was not surprising for me: Windows Release compile failures when the
 Debug compiles fine (because we don't have Release trybot).


 How often does something run in Windows when compiled with the release
 configuration but not the debug?  I've definitely seen it, but I'm not sure
 it's terribly common.  My guess is that there are other causes of the build
 breaking that should be addressed first.  Are there any stats on this?

 My gut feeling is that many of the build breaks are for things that never
 passed on a try bot.  For example, WebKit gardening patches almost never
 work on the try bots so we just ignore them.  I think working on stuff like
 this will bear more fruit.

 Not to mention that each bot costs a lot in terms of the machine,
 power, maintenance time, etc.


  What do you think? Do you have any ideas how we could avoid more compile
 failures, even if they are not possible to apply now due to lack of
 resources? (for example adding trybots, which seems to not happen soon).

 I was also thinking about allowing simple check-ins when the tree is
 waiting for cycle state (when the sheriff wants to verify that bots cycle
 green after a lot of redness). The status would say (Tree closed, waiting
 for cycle; ask sheriff to commit a simple change), or maybe some
 abbreviation for that. It would help people getting code in, and the sheriff
 could require really a lot from that change (like full green trybot pass
 etc). What do you think about that (especially sheriffs)?


 I think you can always ask the sheriffs if you can put something small in.
  I don't see the point of making any such message policy or a convention.
  That said, unless it doesn't compile or is REALLY obviously OK, I don't
 think it's a good idea.

 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: avoiding compile failures on buildbot


That's consistent with trybots doing debug builds.
Uninitialized var warnings only show up in optimized builds,
nothing we can do there but turn on optimizations.

On Thu, Jul 23, 2009 at 2:00 AM, Andrew Scherkusscher...@chromium.org wrote:
 On a related note, Frank (cc'd) ran into an issue where the mac try bots
 have a less-strict compiler warning error than the build bots, which led to
 a broken build once he checked in: http://codereview.chromium.org/155834
 Probably a simple config tweak somewhere, but interesting nonetheless.
 Andrew
 On Wed, Jul 22, 2009 at 6:19 PM, Jeremy Orlow jor...@chromium.org wrote:

 On Wed, Jul 22, 2009 at 5:59 PM, Paweł Hajdan Jr.
 phajdan...@chromium.org wrote:

 One thing that would help us keep the tree more green is avoiding compile
 failures. A compile failure is very bad, because without binaries the tests
 can't run, and then we have to wait for all of them to run, which may reveal
 additional failures etc.
 I'm actually surprised by some failures on buildbot, but at least one
 thing was not surprising for me: Windows Release compile failures when the
 Debug compiles fine (because we don't have Release trybot).

 How often does something run in Windows when compiled with the release
 configuration but not the debug?  I've definitely seen it, but I'm not sure
 it's terribly common.  My guess is that there are other causes of the build
 breaking that should be addressed first.  Are there any stats on this?
 My gut feeling is that many of the build breaks are for things that never
 passed on a try bot.  For example, WebKit gardening patches almost never
 work on the try bots so we just ignore them.  I think working on stuff like
 this will bear more fruit.
 Not to mention that each bot costs a lot in terms of the machine,
 power, maintenance time, etc.


 What do you think? Do you have any ideas how we could avoid more compile
 failures, even if they are not possible to apply now due to lack of
 resources? (for example adding trybots, which seems to not happen soon).
 I was also thinking about allowing simple check-ins when the tree is
 waiting for cycle state (when the sheriff wants to verify that bots cycle
 green after a lot of redness). The status would say (Tree closed, waiting
 for cycle; ask sheriff to commit a simple change), or maybe some
 abbreviation for that. It would help people getting code in, and the sheriff
 could require really a lot from that change (like full green trybot pass
 etc). What do you think about that (especially sheriffs)?

 I think you can always ask the sheriffs if you can put something small in.
  I don't see the point of making any such message policy or a convention.
  That said, unless it doesn't compile or is REALLY obviously OK, I don't
 think it's a good idea.



 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: avoiding compile failures on buildbot

2009-07-22 Thread Andrew Scherkus

On Wed, Jul 22, 2009 at 7:07 PM, Dan Kegel d...@kegel.com wrote:

 That's consistent with trybots doing debug builds.
 Uninitialized var warnings only show up in optimized builds,
 nothing we can do there but turn on optimizations.


Gotcha -- thanks for the explanation!

Andrew




 On Thu, Jul 23, 2009 at 2:00 AM, Andrew Scherkusscher...@chromium.org
 wrote:
  On a related note, Frank (cc'd) ran into an issue where the mac try bots
  have a less-strict compiler warning error than the build bots, which led
 to
  a broken build once he checked in: http://codereview.chromium.org/155834
  Probably a simple config tweak somewhere, but interesting nonetheless.
  Andrew
  On Wed, Jul 22, 2009 at 6:19 PM, Jeremy Orlow jor...@chromium.org
 wrote:
 
  On Wed, Jul 22, 2009 at 5:59 PM, Paweł Hajdan Jr.
  phajdan...@chromium.org wrote:
 
  One thing that would help us keep the tree more green is avoiding
 compile
  failures. A compile failure is very bad, because without binaries the
 tests
  can't run, and then we have to wait for all of them to run, which may
 reveal
  additional failures etc.
  I'm actually surprised by some failures on buildbot, but at least one
  thing was not surprising for me: Windows Release compile failures when
 the
  Debug compiles fine (because we don't have Release trybot).
 
  How often does something run in Windows when compiled with the release
  configuration but not the debug?  I've definitely seen it, but I'm not
 sure
  it's terribly common.  My guess is that there are other causes of the
 build
  breaking that should be addressed first.  Are there any stats on this?
  My gut feeling is that many of the build breaks are for things that
 never
  passed on a try bot.  For example, WebKit gardening patches almost never
  work on the try bots so we just ignore them.  I think working on stuff
 like
  this will bear more fruit.
  Not to mention that each bot costs a lot in terms of the machine,
  power, maintenance time, etc.
 
 
  What do you think? Do you have any ideas how we could avoid more
 compile
  failures, even if they are not possible to apply now due to lack of
  resources? (for example adding trybots, which seems to not happen
 soon).
  I was also thinking about allowing simple check-ins when the tree is
  waiting for cycle state (when the sheriff wants to verify that bots
 cycle
  green after a lot of redness). The status would say (Tree closed,
 waiting
  for cycle; ask sheriff to commit a simple change), or maybe some
  abbreviation for that. It would help people getting code in, and the
 sheriff
  could require really a lot from that change (like full green trybot
 pass
  etc). What do you think about that (especially sheriffs)?
 
  I think you can always ask the sheriffs if you can put something small
 in.
   I don't see the point of making any such message policy or a
 convention.
   That said, unless it doesn't compile or is REALLY obviously OK, I don't
  think it's a good idea.
 
 
 
   
 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Generating files in source tree considered harmful


Stop me if you've heard this one before.

Today, a new directory was added to the source tree, and shortly
thereafter was reverted.
Should have been no problem, but... because the new directory
contained a gyp file, a file was generated in that directory,
and svn couldn't delete the directory when the revert landed.
This caused a build breakage, and I gather from nsylvain's
comments that this wasn't the first time this has happened.

At some point soon, it'd be good to teach gyp not to generate
files in the source tree.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Generating files in source tree considered harmful

2009-07-22 Thread Mark Larson (Google)

On Wed, Jul 22, 2009 at 20:27, Dan Kegel d...@kegel.com wrote:


 Stop me if you've heard this one before.

 Today, a new directory was added to the source tree, and shortly
 thereafter was reverted.
 Should have been no problem, but... because the new directory
 contained a gyp file, a file was generated in that directory,
 and svn couldn't delete the directory when the revert landed.
 This caused a build breakage, and I gather from nsylvain's
 comments that this wasn't the first time this has happened.

 At some point soon, it'd be good to teach gyp not to generate
 files in the source tree.


Or maybe teach gclient how to deal forcefully with directories with no files
under version control. Generating files in the source tree is kinda the
point of gyp.




 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Generating files in source tree considered harmful

2009-07-22 Thread Dirk Pranke


Being the person who perpetrated this crime, if someone could even
tell me how to fix it, that would be an improvement. It seems like
nsylvain is the only one with the appropriate mojo (at least in the
evenings...)

-- Dirk

On Wed, Jul 22, 2009 at 8:27 PM, Dan Kegeld...@kegel.com wrote:

 Stop me if you've heard this one before.

 Today, a new directory was added to the source tree, and shortly
 thereafter was reverted.
 Should have been no problem, but... because the new directory
 contained a gyp file, a file was generated in that directory,
 and svn couldn't delete the directory when the revert landed.
 This caused a build breakage, and I gather from nsylvain's
 comments that this wasn't the first time this has happened.

 At some point soon, it'd be good to teach gyp not to generate
 files in the source tree.

 


--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Generating files in source tree considered harmful