[chromium-dev] Re: Try out --enable-omnibox2!
I know this is only for complaints ;) but I like the present look. The clues as to where each omnibox suggestion comes from are great, clear and useful! - Itai On May 14, 3:22 pm, Ben Goodger (Google) b...@chromium.org wrote: I have adjusted the transparency slightly, and disabled it altogether when Glass isn't active. Let me know how annoying it is now. (I have a knob, and can adjust the annoyingness). -Ben On Fri, May 8, 2009 at 2:20 PM, Mike Belshe mbel...@google.com wrote: On Thu, May 7, 2009 at 4:27 PM, Mohamed Mansour m0.interact...@gmail.com wrote: Great! adds a new fresh look. +1 One question though, is the transparency really needed? It distracts me for some reason from the actual results. I suggest lowering down the transparency a little, but that's just me. +1 - I don't like the transparency either. I'd prefer opaque. Mike On Thu, May 7, 2009 at 1:53 PM, Ben Goodger (Google) b...@chromium.org wrote: Please try out the --enable-omnibox2 command line switch in Chrome and file bugs against me in the issue tracker. I'd like to get a better sense of what needs to be done with it so we can turn it on by default. The differences thus far are aesthetic, and in the popup. -Ben --~--~-~--~~~---~--~~ 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: [chromium-reviews] Re: Add in boost_tuple into third-party for use by googlemock in windows.
[-chromium-reviews, +chromium-dev] (take 2) From their website, «To use Google Mock, you will need the TR1http://en.wikipedia.org/wiki/Technical_Report_1 tuple C++ library installed.» and not directly boost. Up to now, chromium source tree assumed defined(_MSC_VER) == No TR1, which is not exactly true. This is particularly not true on VS2008 + SP1 + Feature Packhttp://www.microsoft.com/downloads/details.aspx?FamilyId=D466226B-8DAB-445F-A7B4-448B326C48E7 . Since it's included in VS2008 as an addon and there's only VS2005 that truly lacks it, it *could *be a compelling reason to drop support for VS2005. We'd be at odds with WebKit but 'eh' is all I have to say. :) It'd be a bit awkward with a potentially eminent move to VS2010 within a year or so. So to summarize my mind; If TR1 is available natively on MSVC, I want its stl tr1 library to be used with conditional include magic. I'm fine to include boost only as a supplicant to continue supporting MSVC8 and MSVC9 without FP. Is that fine? M-A 2009/5/15 John Grabowski j...@chromium.org I did a quick test. The minimal set of files needed to get only boost's tuple is 390 (down from ~1200 in the zip), and size drops from 9M to 1.3M. Windows may differ a tad that OSX (e.g. uses platform/win32.hpp instead of platform/macos.hpp) but it'll be in the same ballpark. Is an extra 1.3M in the source tree acceptable for the benefit of getting gmock? I think yes. maruel brettw? jrg On Fri, May 15, 2009 at 9:48 AM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: On Fri, May 15, 2009 at 9:14 AM, Steven Knight s...@google.com wrote: Guys, it would be a major win to get gmock landed. I'd like to keep trying here, even if not trivially small. Re: boost size. If necessary we could probably checkin only the few files actually needed (e.g. tuple.hpp, boost/config.hpp, boost/static_assert.hpp, and perhaps 10 more). maruel, is that something you'd be happier with? That seems much more acceptable to me. Especially if it doing it also sidesteps the svn:external issue. Unfortunately, it does not sidestep svn:external. What about just adding --ignore-externals to all our svn commands in gclient? I don't think anyone else uses externals, and give people's reactions, I don't think they should be. As for reducing boost to something sane, this is supposedly the reduced subset... -Albert (Seriously, svn:external really only works for such a narrow use case, and introduces so many other problems down the road when things need to change (branching+merging, local mods, etc.) that I'd really try to wave off upstream gmock from using it.) --SK On Fri, May 15, 2009 at 7:40 AM, nsylv...@chromium.org wrote: LGTM with my comment and sgk's comments. As for maruel's comment : It made me sad too. gmock seems to be a lot of troubles (svn:external, then ugly dependencies). Have we at least considered using something else? Or not using it at all? http://codereview.chromium.org/115398/diff/1/2 File third_party/boost/README.chromium (right): http://codereview.chromium.org/115398/diff/1/2#newcode3 Line 3: http://googlemock.googlecode.com/files/boost_tr1_tuple_1_36_0.zip Can you add a line that says what the license is. http://codereview.chromium.org/115398 --~--~-~--~~~---~--~~ 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: [chromium-reviews] Re: Add in boost_tuple into third-party for use by googlemock in windows.
One other idea to explore...what about reimplementing tr1::tuple using base::Tuple? It'd be a pretty naughty hack (adding something to the tr1:: namespace), but for the limited use-case of gmock, it could be good enough? -Albert On Fri, May 15, 2009 at 11:11 AM, Marc-Antoine Ruel mar...@chromium.orgwrote: [-chromium-reviews, +chromium-dev] (take 2) From their website, «To use Google Mock, you will need the TR1http://en.wikipedia.org/wiki/Technical_Report_1 tuple C++ library installed.» and not directly boost. Up to now, chromium source tree assumed defined(_MSC_VER) == No TR1, which is not exactly true. This is particularly not true on VS2008 + SP1 + Feature Packhttp://www.microsoft.com/downloads/details.aspx?FamilyId=D466226B-8DAB-445F-A7B4-448B326C48E7 . Since it's included in VS2008 as an addon and there's only VS2005 that truly lacks it, it *could *be a compelling reason to drop support for VS2005. We'd be at odds with WebKit but 'eh' is all I have to say. :) It'd be a bit awkward with a potentially eminent move to VS2010 within a year or so. So to summarize my mind; If TR1 is available natively on MSVC, I want its stl tr1 library to be used with conditional include magic. I'm fine to include boost only as a supplicant to continue supporting MSVC8 and MSVC9 without FP. Is that fine? M-A 2009/5/15 John Grabowski j...@chromium.org I did a quick test. The minimal set of files needed to get only boost's tuple is 390 (down from ~1200 in the zip), and size drops from 9M to 1.3M. Windows may differ a tad that OSX (e.g. uses platform/win32.hpp instead of platform/macos.hpp) but it'll be in the same ballpark. Is an extra 1.3M in the source tree acceptable for the benefit of getting gmock? I think yes. maruel brettw? jrg On Fri, May 15, 2009 at 9:48 AM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: On Fri, May 15, 2009 at 9:14 AM, Steven Knight s...@google.com wrote: Guys, it would be a major win to get gmock landed. I'd like to keep trying here, even if not trivially small. Re: boost size. If necessary we could probably checkin only the few files actually needed (e.g. tuple.hpp, boost/config.hpp, boost/static_assert.hpp, and perhaps 10 more). maruel, is that something you'd be happier with? That seems much more acceptable to me. Especially if it doing it also sidesteps the svn:external issue. Unfortunately, it does not sidestep svn:external. What about just adding --ignore-externals to all our svn commands in gclient? I don't think anyone else uses externals, and give people's reactions, I don't think they should be. As for reducing boost to something sane, this is supposedly the reduced subset... -Albert (Seriously, svn:external really only works for such a narrow use case, and introduces so many other problems down the road when things need to change (branching+merging, local mods, etc.) that I'd really try to wave off upstream gmock from using it.) --SK On Fri, May 15, 2009 at 7:40 AM, nsylv...@chromium.org wrote: LGTM with my comment and sgk's comments. As for maruel's comment : It made me sad too. gmock seems to be a lot of troubles (svn:external, then ugly dependencies). Have we at least considered using something else? Or not using it at all? http://codereview.chromium.org/115398/diff/1/2 File third_party/boost/README.chromium (right): http://codereview.chromium.org/115398/diff/1/2#newcode3 Line 3: http://googlemock.googlecode.com/files/boost_tr1_tuple_1_36_0.zip Can you add a line that says what the license is. http://codereview.chromium.org/115398 --~--~-~--~~~---~--~~ 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: [chromium-reviews] Re: Add in boost_tuple into third-party for use by googlemock in windows.
And to correct an error I made, the feature pack is included in the SP1 so there's no reason to download an additional 320 megs :) And since we require the service pack 1 on VS2008 anyway, we can assume(_MSCVER = 1500) means TR1 is available. So I guess it's fine to not hack out a tr1::tuple out of base::Tuple. I don't mind as long as it is a fix for VS2005 only. M-A On Fri, May 15, 2009 at 2:11 PM, Marc-Antoine Ruel mar...@chromium.orgwrote: [-chromium-reviews, +chromium-dev] (take 2) From their website, «To use Google Mock, you will need the TR1http://en.wikipedia.org/wiki/Technical_Report_1 tuple C++ library installed.» and not directly boost. Up to now, chromium source tree assumed defined(_MSC_VER) == No TR1, which is not exactly true. This is particularly not true on VS2008 + SP1 + Feature Packhttp://www.microsoft.com/downloads/details.aspx?FamilyId=D466226B-8DAB-445F-A7B4-448B326C48E7 . Since it's included in VS2008 as an addon and there's only VS2005 that truly lacks it, it *could *be a compelling reason to drop support for VS2005. We'd be at odds with WebKit but 'eh' is all I have to say. :) It'd be a bit awkward with a potentially eminent move to VS2010 within a year or so. So to summarize my mind; If TR1 is available natively on MSVC, I want its stl tr1 library to be used with conditional include magic. I'm fine to include boost only as a supplicant to continue supporting MSVC8 and MSVC9 without FP. Is that fine? M-A 2009/5/15 John Grabowski j...@chromium.org I did a quick test. The minimal set of files needed to get only boost's tuple is 390 (down from ~1200 in the zip), and size drops from 9M to 1.3M. Windows may differ a tad that OSX (e.g. uses platform/win32.hpp instead of platform/macos.hpp) but it'll be in the same ballpark. Is an extra 1.3M in the source tree acceptable for the benefit of getting gmock? I think yes. maruel brettw? jrg On Fri, May 15, 2009 at 9:48 AM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: On Fri, May 15, 2009 at 9:14 AM, Steven Knight s...@google.com wrote: Guys, it would be a major win to get gmock landed. I'd like to keep trying here, even if not trivially small. Re: boost size. If necessary we could probably checkin only the few files actually needed (e.g. tuple.hpp, boost/config.hpp, boost/static_assert.hpp, and perhaps 10 more). maruel, is that something you'd be happier with? That seems much more acceptable to me. Especially if it doing it also sidesteps the svn:external issue. Unfortunately, it does not sidestep svn:external. What about just adding --ignore-externals to all our svn commands in gclient? I don't think anyone else uses externals, and give people's reactions, I don't think they should be. As for reducing boost to something sane, this is supposedly the reduced subset... -Albert (Seriously, svn:external really only works for such a narrow use case, and introduces so many other problems down the road when things need to change (branching+merging, local mods, etc.) that I'd really try to wave off upstream gmock from using it.) --SK On Fri, May 15, 2009 at 7:40 AM, nsylv...@chromium.org wrote: LGTM with my comment and sgk's comments. As for maruel's comment : It made me sad too. gmock seems to be a lot of troubles (svn:external, then ugly dependencies). Have we at least considered using something else? Or not using it at all? http://codereview.chromium.org/115398/diff/1/2 File third_party/boost/README.chromium (right): http://codereview.chromium.org/115398/diff/1/2#newcode3 Line 3: http://googlemock.googlecode.com/files/boost_tr1_tuple_1_36_0.zip Can you add a line that says what the license is. http://codereview.chromium.org/115398 --~--~-~--~~~---~--~~ 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: [chromium-reviews] Re: Add in boost_tuple into third-party for use by googlemock in windows.
If this is the only reason gmock needs boost, it seems like a better idea would be to push a copy of tuple.h into gmock and submit a patch to make it more self-contained in the first place. -scott On Fri, May 15, 2009 at 11:17 AM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: One other idea to explore...what about reimplementing tr1::tuple using base::Tuple? It'd be a pretty naughty hack (adding something to the tr1:: namespace), but for the limited use-case of gmock, it could be good enough? -Albert On Fri, May 15, 2009 at 11:11 AM, Marc-Antoine Ruel mar...@chromium.org wrote: [-chromium-reviews, +chromium-dev] (take 2) From their website, To use Google Mock, you will need the TR1 tuple C++ library installed. and not directly boost. Up to now, chromium source tree assumed defined(_MSC_VER) == No TR1, which is not exactly true. This is particularly not true on VS2008 + SP1 + Feature Pack. Since it's included in VS2008 as an addon and there's only VS2005 that truly lacks it, it could be a compelling reason to drop support for VS2005. We'd be at odds with WebKit but 'eh' is all I have to say. :) It'd be a bit awkward with a potentially eminent move to VS2010 within a year or so. So to summarize my mind; If TR1 is available natively on MSVC, I want its stl tr1 library to be used with conditional include magic. I'm fine to include boost only as a supplicant to continue supporting MSVC8 and MSVC9 without FP. Is that fine? M-A 2009/5/15 John Grabowski j...@chromium.org I did a quick test. The minimal set of files needed to get only boost's tuple is 390 (down from ~1200 in the zip), and size drops from 9M to 1.3M. Windows may differ a tad that OSX (e.g. uses platform/win32.hpp instead of platform/macos.hpp) but it'll be in the same ballpark. Is an extra 1.3M in the source tree acceptable for the benefit of getting gmock? I think yes. maruel brettw? jrg On Fri, May 15, 2009 at 9:48 AM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: On Fri, May 15, 2009 at 9:14 AM, Steven Knight s...@google.com wrote: Guys, it would be a major win to get gmock landed. I'd like to keep trying here, even if not trivially small. Re: boost size. If necessary we could probably checkin only the few files actually needed (e.g. tuple.hpp, boost/config.hpp, boost/static_assert.hpp, and perhaps 10 more). maruel, is that something you'd be happier with? That seems much more acceptable to me. Especially if it doing it also sidesteps the svn:external issue. Unfortunately, it does not sidestep svn:external. What about just adding --ignore-externals to all our svn commands in gclient? I don't think anyone else uses externals, and give people's reactions, I don't think they should be. As for reducing boost to something sane, this is supposedly the reduced subset... -Albert (Seriously, svn:external really only works for such a narrow use case, and introduces so many other problems down the road when things need to change (branching+merging, local mods, etc.) that I'd really try to wave off upstream gmock from using it.) --SK On Fri, May 15, 2009 at 7:40 AM, nsylv...@chromium.org wrote: LGTM with my comment and sgk's comments. As for maruel's comment : It made me sad too. gmock seems to be a lot of troubles (svn:external, then ugly dependencies). Have we at least considered using something else? Or not using it at all? http://codereview.chromium.org/115398/diff/1/2 File third_party/boost/README.chromium (right): http://codereview.chromium.org/115398/diff/1/2#newcode3 Line 3: http://googlemock.googlecode.com/files/boost_tr1_tuple_1_36_0.zip Can you add a line that says what the license is. http://codereview.chromium.org/115398 --~--~-~--~~~---~--~~ 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: Try out --enable-omnibox2!
Am I alone to have the down arrow in See XX recent pages in your history containing YY make me think that if I hover on it, the menu will drop down with more results? I guess it's an MS office side-effect but that would be an expectation from a lot of people. Also, the drop down text is occasionally rendered wrong here on r16158. M-A On Thu, May 7, 2009 at 1:53 PM, Ben Goodger (Google) b...@chromium.orgwrote: Please try out the --enable-omnibox2 command line switch in Chrome and file bugs against me in the issue tracker. I'd like to get a better sense of what needs to be done with it so we can turn it on by default. The differences thus far are aesthetic, and in the popup. -Ben --~--~-~--~~~---~--~~ 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: Try out --enable-omnibox2!
With snapshot. Look the for It's on vista with classic theme. On Fri, May 15, 2009 at 2:48 PM, Marc-Antoine Ruel mar...@chromium.orgwrote: Am I alone to have the down arrow in See XX recent pages in your history containing YY make me think that if I hover on it, the menu will drop down with more results? I guess it's an MS office side-effect but that would be an expectation from a lot of people. Also, the drop down text is occasionally rendered wrong here on r16158. M-A On Thu, May 7, 2009 at 1:53 PM, Ben Goodger (Google) b...@chromium.orgwrote: Please try out the --enable-omnibox2 command line switch in Chrome and file bugs against me in the issue tracker. I'd like to get a better sense of what needs to be done with it so we can turn it on by default. The differences thus far are aesthetic, and in the popup. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~--- attachment: omnibox2_text_rendering.png
[chromium-dev] Re: [chromium-reviews] Re: Add in boost_tuple into third-party for use by googlemock in windows.
[ +zhanyong ] I chatted with Zhanyong about both swapping out tr1::tuple, and about removing the svn:external reference in the repository. The gmock actions use tr1:tuple as part of the public interface for defining new actions. Thus, changing the tuple implementation would basically mean that any other googlemock client using tr1::tuple in their code would have clashing tuple implementations. This will only get worse as tr1 is adopted more widely. As for getting our own version of gtest instead of retrieving it through svn:external, the implementation of gmock and gtest are pretty tightly coupled. Thus, versioning gtest separately might be a bad idea. The suggestion is to consider gmock a super-set of gtest and drop the original dependency. Zhanyong, please correct me if I got something wrong here. Regarding the svn:external reference to google test, currently, the best solution seems to be either a) having 2 copies of gtest in the tree (a bit dangerous due to possible shadowing issues) b) passing --ignore-externals to svn in gclient (an incomplete solution because not every svn access goes through gclient) How bad is it if we don't explicitly version gtest ourselves? -Albert 2009/5/15 Scott Hess sh...@chromium.org If this is the only reason gmock needs boost, it seems like a better idea would be to push a copy of tuple.h into gmock and submit a patch to make it more self-contained in the first place. -scott On Fri, May 15, 2009 at 11:17 AM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: One other idea to explore...what about reimplementing tr1::tuple using base::Tuple? It'd be a pretty naughty hack (adding something to the tr1:: namespace), but for the limited use-case of gmock, it could be good enough? -Albert On Fri, May 15, 2009 at 11:11 AM, Marc-Antoine Ruel mar...@chromium.org wrote: [-chromium-reviews, +chromium-dev] (take 2) From their website, To use Google Mock, you will need the TR1 tuple C++ library installed. and not directly boost. Up to now, chromium source tree assumed defined(_MSC_VER) == No TR1, which is not exactly true. This is particularly not true on VS2008 + SP1 + Feature Pack. Since it's included in VS2008 as an addon and there's only VS2005 that truly lacks it, it could be a compelling reason to drop support for VS2005. We'd be at odds with WebKit but 'eh' is all I have to say. :) It'd be a bit awkward with a potentially eminent move to VS2010 within a year or so. So to summarize my mind; If TR1 is available natively on MSVC, I want its stl tr1 library to be used with conditional include magic. I'm fine to include boost only as a supplicant to continue supporting MSVC8 and MSVC9 without FP. Is that fine? M-A 2009/5/15 John Grabowski j...@chromium.org I did a quick test. The minimal set of files needed to get only boost's tuple is 390 (down from ~1200 in the zip), and size drops from 9M to 1.3M. Windows may differ a tad that OSX (e.g. uses platform/win32.hpp instead of platform/macos.hpp) but it'll be in the same ballpark. Is an extra 1.3M in the source tree acceptable for the benefit of getting gmock? I think yes. maruel brettw? jrg On Fri, May 15, 2009 at 9:48 AM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: On Fri, May 15, 2009 at 9:14 AM, Steven Knight s...@google.com wrote: Guys, it would be a major win to get gmock landed. I'd like to keep trying here, even if not trivially small. Re: boost size. If necessary we could probably checkin only the few files actually needed (e.g. tuple.hpp, boost/config.hpp, boost/static_assert.hpp, and perhaps 10 more). maruel, is that something you'd be happier with? That seems much more acceptable to me. Especially if it doing it also sidesteps the svn:external issue. Unfortunately, it does not sidestep svn:external. What about just adding --ignore-externals to all our svn commands in gclient? I don't think anyone else uses externals, and give people's reactions, I don't think they should be. As for reducing boost to something sane, this is supposedly the reduced subset... -Albert (Seriously, svn:external really only works for such a narrow use case, and introduces so many other problems down the road when things need to change (branching+merging, local mods, etc.) that I'd really try to wave off upstream gmock from using it.) --SK On Fri, May 15, 2009 at 7:40 AM, nsylv...@chromium.org wrote: LGTM with my comment and sgk's comments. As for maruel's comment : It made me sad too. gmock seems to be a lot of troubles (svn:external, then ugly dependencies). Have we at least considered using something else? Or not using it at all? http://codereview.chromium.org/115398/diff/1/2 File third_party/boost/README.chromium (right): http://codereview.chromium.org/115398/diff/1/2#newcode3 Line 3:
[chromium-dev] Re: [chromium-reviews] Re: Add in boost_tuple into third-party for use by googlemock in windows.
On Fri, May 15, 2009 at 12:15 PM, Albert J. Wong (王重傑) ajw...@chromium.orgwrote: [ +zhanyong ] I chatted with Zhanyong about both swapping out tr1::tuple, and about removing the svn:external reference in the repository. The gmock actions use tr1:tuple as part of the public interface for defining new actions. Thus, changing the tuple implementation would basically mean that any other googlemock client using tr1::tuple in their code would have clashing tuple implementations. This will only get worse as tr1 is adopted more widely. As for getting our own version of gtest instead of retrieving it through svn:external, the implementation of gmock and gtest are pretty tightly coupled. Thus, versioning gtest separately might be a bad idea. The suggestion is to consider gmock a super-set of gtest and drop the original dependency. Zhanyong, please correct me if I got something wrong here. Regarding the svn:external reference to google test, currently, the best solution seems to be either a) having 2 copies of gtest in the tree (a bit dangerous due to possible shadowing issues) b) passing --ignore-externals to svn in gclient (an incomplete solution because not every svn access goes through gclient) How bad is it if we don't explicitly version gtest ourselves? Very. googlemock is at version 238 right now. But we are using version 243, which is , afaik, the first revision that is stable and has support for the new sharding feature. If we start using the one in googlemock, the buildbots are going to break. We need to be able to control which version we pull, and we need to be able to change it fast if we realize there is a bug. (rollback to a previous version, or go to a newer version with a fix). Nicolas -Albert 2009/5/15 Scott Hess sh...@chromium.org If this is the only reason gmock needs boost, it seems like a better idea would be to push a copy of tuple.h into gmock and submit a patch to make it more self-contained in the first place. -scott On Fri, May 15, 2009 at 11:17 AM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: One other idea to explore...what about reimplementing tr1::tuple using base::Tuple? It'd be a pretty naughty hack (adding something to the tr1:: namespace), but for the limited use-case of gmock, it could be good enough? -Albert On Fri, May 15, 2009 at 11:11 AM, Marc-Antoine Ruel mar...@chromium.org wrote: [-chromium-reviews, +chromium-dev] (take 2) From their website, To use Google Mock, you will need the TR1 tuple C++ library installed. and not directly boost. Up to now, chromium source tree assumed defined(_MSC_VER) == No TR1, which is not exactly true. This is particularly not true on VS2008 + SP1 + Feature Pack. Since it's included in VS2008 as an addon and there's only VS2005 that truly lacks it, it could be a compelling reason to drop support for VS2005. We'd be at odds with WebKit but 'eh' is all I have to say. :) It'd be a bit awkward with a potentially eminent move to VS2010 within a year or so. So to summarize my mind; If TR1 is available natively on MSVC, I want its stl tr1 library to be used with conditional include magic. I'm fine to include boost only as a supplicant to continue supporting MSVC8 and MSVC9 without FP. Is that fine? M-A 2009/5/15 John Grabowski j...@chromium.org I did a quick test. The minimal set of files needed to get only boost's tuple is 390 (down from ~1200 in the zip), and size drops from 9M to 1.3M. Windows may differ a tad that OSX (e.g. uses platform/win32.hpp instead of platform/macos.hpp) but it'll be in the same ballpark. Is an extra 1.3M in the source tree acceptable for the benefit of getting gmock? I think yes. maruel brettw? jrg On Fri, May 15, 2009 at 9:48 AM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: On Fri, May 15, 2009 at 9:14 AM, Steven Knight s...@google.com wrote: Guys, it would be a major win to get gmock landed. I'd like to keep trying here, even if not trivially small. Re: boost size. If necessary we could probably checkin only the few files actually needed (e.g. tuple.hpp, boost/config.hpp, boost/static_assert.hpp, and perhaps 10 more). maruel, is that something you'd be happier with? That seems much more acceptable to me. Especially if it doing it also sidesteps the svn:external issue. Unfortunately, it does not sidestep svn:external. What about just adding --ignore-externals to all our svn commands in gclient? I don't think anyone else uses externals, and give people's reactions, I don't think they should be. As for reducing boost to something sane, this is supposedly the reduced subset... -Albert (Seriously, svn:external really only works for such a narrow use case, and introduces so many other problems down the road when things need to change (branching+merging, local mods, etc.) that I'd really try to wave off
[chromium-dev] Re: [chromium-reviews] Re: Add in boost_tuple into third-party for use by googlemock in windows.
2009/5/15 Nicolas Sylvain nsylv...@chromium.org On Fri, May 15, 2009 at 12:15 PM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: [ +zhanyong ] I chatted with Zhanyong about both swapping out tr1::tuple, and about removing the svn:external reference in the repository. The gmock actions use tr1:tuple as part of the public interface for defining new actions. Thus, changing the tuple implementation would basically mean that any other googlemock client using tr1::tuple in their code would have clashing tuple implementations. This will only get worse as tr1 is adopted more widely. As for getting our own version of gtest instead of retrieving it through svn:external, the implementation of gmock and gtest are pretty tightly coupled. Thus, versioning gtest separately might be a bad idea. The suggestion is to consider gmock a super-set of gtest and drop the original dependency. Zhanyong, please correct me if I got something wrong here. Regarding the svn:external reference to google test, currently, the best solution seems to be either a) having 2 copies of gtest in the tree (a bit dangerous due to possible shadowing issues) b) passing --ignore-externals to svn in gclient (an incomplete solution because not every svn access goes through gclient) How bad is it if we don't explicitly version gtest ourselves? Very. googlemock is at version 238 right now. But we are using version 243, which is , afaik, the first revision that is stable and has support for the new sharding feature. If we start using the one in googlemock, the buildbots are going to break. To be clear: googlemock is at version 238 should have been: trunk of googlemock is fetching gtest at version 238. Nicolas We need to be able to control which version we pull, and we need to be able to change it fast if we realize there is a bug. (rollback to a previous version, or go to a newer version with a fix). Nicolas -Albert 2009/5/15 Scott Hess sh...@chromium.org If this is the only reason gmock needs boost, it seems like a better idea would be to push a copy of tuple.h into gmock and submit a patch to make it more self-contained in the first place. -scott On Fri, May 15, 2009 at 11:17 AM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: One other idea to explore...what about reimplementing tr1::tuple using base::Tuple? It'd be a pretty naughty hack (adding something to the tr1:: namespace), but for the limited use-case of gmock, it could be good enough? -Albert On Fri, May 15, 2009 at 11:11 AM, Marc-Antoine Ruel mar...@chromium.org wrote: [-chromium-reviews, +chromium-dev] (take 2) From their website, To use Google Mock, you will need the TR1 tuple C++ library installed. and not directly boost. Up to now, chromium source tree assumed defined(_MSC_VER) == No TR1, which is not exactly true. This is particularly not true on VS2008 + SP1 + Feature Pack. Since it's included in VS2008 as an addon and there's only VS2005 that truly lacks it, it could be a compelling reason to drop support for VS2005. We'd be at odds with WebKit but 'eh' is all I have to say. :) It'd be a bit awkward with a potentially eminent move to VS2010 within a year or so. So to summarize my mind; If TR1 is available natively on MSVC, I want its stl tr1 library to be used with conditional include magic. I'm fine to include boost only as a supplicant to continue supporting MSVC8 and MSVC9 without FP. Is that fine? M-A 2009/5/15 John Grabowski j...@chromium.org I did a quick test. The minimal set of files needed to get only boost's tuple is 390 (down from ~1200 in the zip), and size drops from 9M to 1.3M. Windows may differ a tad that OSX (e.g. uses platform/win32.hpp instead of platform/macos.hpp) but it'll be in the same ballpark. Is an extra 1.3M in the source tree acceptable for the benefit of getting gmock? I think yes. maruel brettw? jrg On Fri, May 15, 2009 at 9:48 AM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: On Fri, May 15, 2009 at 9:14 AM, Steven Knight s...@google.com wrote: Guys, it would be a major win to get gmock landed. I'd like to keep trying here, even if not trivially small. Re: boost size. If necessary we could probably checkin only the few files actually needed (e.g. tuple.hpp, boost/config.hpp, boost/static_assert.hpp, and perhaps 10 more). maruel, is that something you'd be happier with? That seems much more acceptable to me. Especially if it doing it also sidesteps the svn:external issue. Unfortunately, it does not sidestep svn:external. What about just adding --ignore-externals to all our svn commands in gclient? I don't think anyone else uses externals, and give people's reactions, I don't think they should be. As for reducing boost to something sane, this is supposedly the reduced subset... -Albert (Seriously, svn:external really only
[chromium-dev] Bookmark system not reliable enough for user preferences
I have spent some time playing around the new release of Chrome, especially building user preference system using the bookmarking and script/extension communication aspects. I have to say it is not reliable enough yet to build a real system. Generally there are several concerns as mentioned below. Sorry I don't have too much time to do a thorough bug test, and the following is just general description, not a formal bug report. If you want to know more details, just directly contact w/ me. 1) Bookmarking: bookmarking system only works well for directly loaded extension page (i.e., type or copy chrome-extension://*/*.html and enter). If the extension page is loaded by hyperlink from other pages, or by communication event (within onMessage), bookmarking is quite unreliable. e.g., if the extension page contains some javascript creating a bookmark item in onload(), by merely refreshing the page I got different results randomly (sometime w/ the item created, sometime in a different folder, sometime nothing at all). 2) chrome.bookmarks.search will not find any folder 3) Open the communication channel between the script and extension makes the whole Chrome much more vulnerable to crashing. 4) Transfer large amount of data (say 2K bytes) via postMessage is extremely slow (multiple sec.) 5) Is the hidden_pages in json still working, or not yet, or not any longer? Hidden page is good for the communication w/o exposing any UI as toolstrip does, but it didn't work for me so far. I will continue exploring it and update (if any) progress. Your comments are welcome. -Jack --~--~-~--~~~---~--~~ 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: Bookmark system not reliable enough for user preferences
Hi Jack, On Fri, May 15, 2009 at 2:05 PM, jack js2...@gmail.com wrote: I have spent some time playing around the new release of Chrome, especially building user preference system using the bookmarking and script/extension communication aspects. I have to say it is not reliable enough yet to build a real system. Using the bookmark system for storage was just an idea for a quick hack, but I'm still interested in the bugs you found. 1) Bookmarking: bookmarking system only works well for directly loaded extension page (i.e., type or copy chrome-extension://*/*.html and enter). If the extension page is loaded by hyperlink from other pages, or by communication event (within onMessage), bookmarking is quite unreliable. e.g., if the extension page contains some javascript creating a bookmark item in onload(), by merely refreshing the page I got different results randomly (sometime w/ the item created, sometime in a different folder, sometime nothing at all). 2) chrome.bookmarks.search will not find any folder I'll try and make some test cases for these two bugs and replicate them. Thanks. 3) Open the communication channel between the script and extension makes the whole Chrome much more vulnerable to crashing. Hm, if you can come up with a test case for this, I'd appreciate it. Otherwise, we'll just keep an eye out for crashes related to the communication channel. 4) Transfer large amount of data (say 2K bytes) via postMessage is extremely slow (multiple sec.) I'll try and create a test case for this, too. 5) Is the hidden_pages in json still working, or not yet, or not any longer? Hidden page is good for the communication w/o exposing any UI as toolstrip does, but it didn't work for me so far. It's not fully baked yet, but it will be background_page. Thanks for the feedback, - a --~--~-~--~~~---~--~~ 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: Bookmark system not reliable enough for user preferences
*Not so much in the extensions and bookmarks area here, but, have you noticed that weird behavior where clicking on a toolstrip button makes Chrome focus on an arbitrary tab all of a sudden?* * *☆PhistucK On Sat, May 16, 2009 at 00:18, Aaron Boodman a...@chromium.org wrote: Hi Jack, On Fri, May 15, 2009 at 2:05 PM, jack js2...@gmail.com wrote: I have spent some time playing around the new release of Chrome, especially building user preference system using the bookmarking and script/extension communication aspects. I have to say it is not reliable enough yet to build a real system. Using the bookmark system for storage was just an idea for a quick hack, but I'm still interested in the bugs you found. 1) Bookmarking: bookmarking system only works well for directly loaded extension page (i.e., type or copy chrome-extension://*/*.html and enter). If the extension page is loaded by hyperlink from other pages, or by communication event (within onMessage), bookmarking is quite unreliable. e.g., if the extension page contains some javascript creating a bookmark item in onload(), by merely refreshing the page I got different results randomly (sometime w/ the item created, sometime in a different folder, sometime nothing at all). 2) chrome.bookmarks.search will not find any folder I'll try and make some test cases for these two bugs and replicate them. Thanks. 3) Open the communication channel between the script and extension makes the whole Chrome much more vulnerable to crashing. Hm, if you can come up with a test case for this, I'd appreciate it. Otherwise, we'll just keep an eye out for crashes related to the communication channel. 4) Transfer large amount of data (say 2K bytes) via postMessage is extremely slow (multiple sec.) I'll try and create a test case for this, too. 5) Is the hidden_pages in json still working, or not yet, or not any longer? Hidden page is good for the communication w/o exposing any UI as toolstrip does, but it didn't work for me so far. It's not fully baked yet, but it will be background_page. Thanks for the feedback, - a --~--~-~--~~~---~--~~ 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: Bookmark system not reliable enough for user preferences
Yeah I have noticed that. There is a bug open for it: http://code.google.com/p/chromium/issues/detail?id=11901 I agree it is weird :). - a 2009/5/15 PhistucK phist...@gmail.com: Not so much in the extensions and bookmarks area here, but, have you noticed that weird behavior where clicking on a toolstrip button makes Chrome focus on an arbitrary tab all of a sudden? ☆PhistucK On Sat, May 16, 2009 at 00:18, Aaron Boodman a...@chromium.org wrote: Hi Jack, On Fri, May 15, 2009 at 2:05 PM, jack js2...@gmail.com wrote: I have spent some time playing around the new release of Chrome, especially building user preference system using the bookmarking and script/extension communication aspects. I have to say it is not reliable enough yet to build a real system. Using the bookmark system for storage was just an idea for a quick hack, but I'm still interested in the bugs you found. 1) Bookmarking: bookmarking system only works well for directly loaded extension page (i.e., type or copy chrome-extension://*/*.html and enter). If the extension page is loaded by hyperlink from other pages, or by communication event (within onMessage), bookmarking is quite unreliable. e.g., if the extension page contains some javascript creating a bookmark item in onload(), by merely refreshing the page I got different results randomly (sometime w/ the item created, sometime in a different folder, sometime nothing at all). 2) chrome.bookmarks.search will not find any folder I'll try and make some test cases for these two bugs and replicate them. Thanks. 3) Open the communication channel between the script and extension makes the whole Chrome much more vulnerable to crashing. Hm, if you can come up with a test case for this, I'd appreciate it. Otherwise, we'll just keep an eye out for crashes related to the communication channel. 4) Transfer large amount of data (say 2K bytes) via postMessage is extremely slow (multiple sec.) I'll try and create a test case for this, too. 5) Is the hidden_pages in json still working, or not yet, or not any longer? Hidden page is good for the communication w/o exposing any UI as toolstrip does, but it didn't work for me so far. It's not fully baked yet, but it will be background_page. Thanks for the feedback, - a --~--~-~--~~~---~--~~ 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: [chromium-reviews] Re: Add in boost_tuple into third-party for use by googlemock in windows.
2009/5/15 Zhanyong Wan (λx.x x) w...@google.com 2009/5/15 Nicolas Sylvain nsylv...@chromium.org: 2009/5/15 Nicolas Sylvain nsylv...@chromium.org On Fri, May 15, 2009 at 12:15 PM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: [ +zhanyong ] I chatted with Zhanyong about both swapping out tr1::tuple, and about removing the svn:external reference in the repository. The gmock actions use tr1:tuple as part of the public interface for defining new actions. Thus, changing the tuple implementation would basically mean that any other googlemock client using tr1::tuple in their code would have clashing tuple implementations. This will only get worse as tr1 is adopted more widely. As for getting our own version of gtest instead of retrieving it through svn:external, the implementation of gmock and gtest are pretty tightly coupled. Thus, versioning gtest separately might be a bad idea. The suggestion is to consider gmock a super-set of gtest and drop the original dependency. Zhanyong, please correct me if I got something wrong here. Regarding the svn:external reference to google test, currently, the best solution seems to be either a) having 2 copies of gtest in the tree (a bit dangerous due to possible shadowing issues) b) passing --ignore-externals to svn in gclient (an incomplete solution because not every svn access goes through gclient) How bad is it if we don't explicitly version gtest ourselves? Very. googlemock is at version 238 right now. But we are using version 243, which is , afaik, the first revision that is stable and has support for the new sharding feature. If we start using the one in googlemock, the buildbots are going to break. To be clear: googlemock is at version 238 should have been: trunk of googlemock is fetching gtest at version 238. I can make googlemock pull in gtest r243 or a later revision. Nicolas We need to be able to control which version we pull, and we need to be able to change it fast if we realize there is a bug. (rollback to a previous version, or go to a newer version with a fix). I understand. The issue is that gtest and gmock are meant to version in lock steps (almost), as the latest revision of gmock often needs features from a newer revision of gtest. In general, you cannot freely combine two revisions of gtest and gmock. I view gtest as part of gmock. We release gtest separately for people not interested in mocking or not using a compiler gmock requires. However if you want gmock, it's recommended to let gmock decide which version of gtest is compatible. In the end, I guess it depends on how fine-grained you want to control your dependency on gtest/gmock. Dealing with them separately gives you more flexibility (at least in theory), but also incurs more maintenance overhead. You need to decide whether it's worth it. My hunch, is that it's not. That's not changing the fact that we don't want code to be pulled auto-magically. svn:external is clearly one of the biggest scm user-unfriendly feature that I know of and it's why we have gclient. I agree that this is a difficult choice, there are no obvious good solutions. I don't think we like to pull in third party dependencies that are not self contained. This is far from being a great solution, but I would personally just paste a copy of gmock in our repo (without fetching it with deps), like we do for the majority of our third_party. And make this version of gmock self contained with the version of gtest it needs, while the rest of chrome continues to use our version of gtest. Not making it clash might be a challenge though. Nicolas Nicolas -Albert 2009/5/15 Scott Hess sh...@chromium.org If this is the only reason gmock needs boost, it seems like a better idea would be to push a copy of tuple.h into gmock and submit a patch to make it more self-contained in the first place. -scott On Fri, May 15, 2009 at 11:17 AM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: One other idea to explore...what about reimplementing tr1::tuple using base::Tuple? It'd be a pretty naughty hack (adding something to the tr1:: namespace), but for the limited use-case of gmock, it could be good enough? -Albert On Fri, May 15, 2009 at 11:11 AM, Marc-Antoine Ruel mar...@chromium.org wrote: [-chromium-reviews, +chromium-dev] (take 2) From their website, To use Google Mock, you will need the TR1 tuple C++ library installed. and not directly boost. Up to now, chromium source tree assumed defined(_MSC_VER) == No TR1, which is not exactly true. This is particularly not true on VS2008 + SP1 + Feature Pack. Since it's included in VS2008 as an addon and there's only VS2005 that truly lacks it, it could be a compelling reason to drop support for VS2005. We'd be at odds with WebKit but 'eh' is all I have to
[chromium-dev] Re: [chromium-reviews] Re: Add in boost_tuple into third-party for use by googlemock in windows.
2009/5/15 Zhanyong Wan (λx.x x) w...@google.com 2009/5/15 Nicolas Sylvain nsylv...@chromium.org: 2009/5/15 Zhanyong Wan (λx.x x) w...@google.com 2009/5/15 Nicolas Sylvain nsylv...@chromium.org: 2009/5/15 Nicolas Sylvain nsylv...@chromium.org On Fri, May 15, 2009 at 12:15 PM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: [ +zhanyong ] I chatted with Zhanyong about both swapping out tr1::tuple, and about removing the svn:external reference in the repository. The gmock actions use tr1:tuple as part of the public interface for defining new actions. Thus, changing the tuple implementation would basically mean that any other googlemock client using tr1::tuple in their code would have clashing tuple implementations. This will only get worse as tr1 is adopted more widely. As for getting our own version of gtest instead of retrieving it through svn:external, the implementation of gmock and gtest are pretty tightly coupled. Thus, versioning gtest separately might be a bad idea. The suggestion is to consider gmock a super-set of gtest and drop the original dependency. Zhanyong, please correct me if I got something wrong here. Regarding the svn:external reference to google test, currently, the best solution seems to be either a) having 2 copies of gtest in the tree (a bit dangerous due to possible shadowing issues) b) passing --ignore-externals to svn in gclient (an incomplete solution because not every svn access goes through gclient) How bad is it if we don't explicitly version gtest ourselves? Very. googlemock is at version 238 right now. But we are using version 243, which is , afaik, the first revision that is stable and has support for the new sharding feature. If we start using the one in googlemock, the buildbots are going to break. To be clear: googlemock is at version 238 should have been: trunk of googlemock is fetching gtest at version 238. I can make googlemock pull in gtest r243 or a later revision. Nicolas We need to be able to control which version we pull, and we need to be able to change it fast if we realize there is a bug. (rollback to a previous version, or go to a newer version with a fix). I understand. The issue is that gtest and gmock are meant to version in lock steps (almost), as the latest revision of gmock often needs features from a newer revision of gtest. In general, you cannot freely combine two revisions of gtest and gmock. I view gtest as part of gmock. We release gtest separately for people not interested in mocking or not using a compiler gmock requires. However if you want gmock, it's recommended to let gmock decide which version of gtest is compatible. In the end, I guess it depends on how fine-grained you want to control your dependency on gtest/gmock. Dealing with them separately gives you more flexibility (at least in theory), but also incurs more maintenance overhead. You need to decide whether it's worth it. My hunch, is that it's not. That's not changing the fact that we don't want code to be pulled auto-magically. svn:external is clearly one of the biggest scm user-unfriendly feature that I know of and it's why we have gclient. Sorry I was late to the discussion - could you explain what you mean by code being pulled auto-magically? svn:externals lets you specify the revision number you want to pull in. If you set that, you'll always get the same code whenever you sync, until the next time you update the svn:externals property. I mean: http://googlemock.googlecode.com/svn/trunk/ : I'm browsing the code, and I have no indication that something is going to be pulled, and at what version. same here : http://code.google.com/p/googlemock/source/browse/#svn/trunk I'm familiar with svn, and it still took me a while to be able to query the right property and be able to know what version it was pulling. I don't think our code review tool supports review for svn properties either. Feel free to get a second opinion though. But personally I think it would be a big set back if chrome was to depend on svn:externals to be able to build. Nicolas I agree that this is a difficult choice, there are no obvious good solutions. I don't think we like to pull in third party dependencies that are not self contained. This is far from being a great solution, but I would personally just paste a copy of gmock in our repo (without fetching it with deps), like we do for the majority of our third_party. And make this version of gmock self contained with the version of gtest it needs, while the rest of chrome continues to use our version of gtest. Not making it clash might be a challenge though. Unless you can guarantee that code using gmock will never be linked with code in the rest of chrome (which uses a
[chromium-dev] Re: [chromium-reviews] Re: Add in boost_tuple into third-party for use by googlemock in windows.
2009/5/15 Nicolas Sylvain nsylv...@chromium.org: 2009/5/15 Zhanyong Wan (λx.x x) w...@google.com 2009/5/15 Nicolas Sylvain nsylv...@chromium.org: 2009/5/15 Zhanyong Wan (λx.x x) w...@google.com 2009/5/15 Nicolas Sylvain nsylv...@chromium.org: 2009/5/15 Nicolas Sylvain nsylv...@chromium.org On Fri, May 15, 2009 at 12:15 PM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: [ +zhanyong ] I chatted with Zhanyong about both swapping out tr1::tuple, and about removing the svn:external reference in the repository. The gmock actions use tr1:tuple as part of the public interface for defining new actions. Thus, changing the tuple implementation would basically mean that any other googlemock client using tr1::tuple in their code would have clashing tuple implementations. This will only get worse as tr1 is adopted more widely. As for getting our own version of gtest instead of retrieving it through svn:external, the implementation of gmock and gtest are pretty tightly coupled. Thus, versioning gtest separately might be a bad idea. The suggestion is to consider gmock a super-set of gtest and drop the original dependency. Zhanyong, please correct me if I got something wrong here. Regarding the svn:external reference to google test, currently, the best solution seems to be either a) having 2 copies of gtest in the tree (a bit dangerous due to possible shadowing issues) b) passing --ignore-externals to svn in gclient (an incomplete solution because not every svn access goes through gclient) How bad is it if we don't explicitly version gtest ourselves? Very. googlemock is at version 238 right now. But we are using version 243, which is , afaik, the first revision that is stable and has support for the new sharding feature. If we start using the one in googlemock, the buildbots are going to break. To be clear: googlemock is at version 238 should have been: trunk of googlemock is fetching gtest at version 238. I can make googlemock pull in gtest r243 or a later revision. Nicolas We need to be able to control which version we pull, and we need to be able to change it fast if we realize there is a bug. (rollback to a previous version, or go to a newer version with a fix). I understand. The issue is that gtest and gmock are meant to version in lock steps (almost), as the latest revision of gmock often needs features from a newer revision of gtest. In general, you cannot freely combine two revisions of gtest and gmock. I view gtest as part of gmock. We release gtest separately for people not interested in mocking or not using a compiler gmock requires. However if you want gmock, it's recommended to let gmock decide which version of gtest is compatible. In the end, I guess it depends on how fine-grained you want to control your dependency on gtest/gmock. Dealing with them separately gives you more flexibility (at least in theory), but also incurs more maintenance overhead. You need to decide whether it's worth it. My hunch, is that it's not. That's not changing the fact that we don't want code to be pulled auto-magically. svn:external is clearly one of the biggest scm user-unfriendly feature that I know of and it's why we have gclient. Sorry I was late to the discussion - could you explain what you mean by code being pulled auto-magically? svn:externals lets you specify the revision number you want to pull in. If you set that, you'll always get the same code whenever you sync, until the next time you update the svn:externals property. I mean: http://googlemock.googlecode.com/svn/trunk/ : I'm browsing the code, and I have no indication that something is going to be pulled, and at what version. same here : http://code.google.com/p/googlemock/source/browse/#svn/trunk I'm familiar with svn, and it still took me a while to be able to query the right property and be able to know what version it was pulling. I don't think our code review tool supports review for svn properties either. Feel free to get a second opinion though. But personally I think it would be a big set back if chrome was to depend on svn:externals to be able to build. Nicolas FYI, as a data point. For historical reasons (compatibility with our perforce layout), o3d pulls both gmock an gtest with DEPS. So it means that technically we pull 2 versions of gtest, but we use only one. We make sure that gmock uses the same version of gtest as we do, by adding the correct include path (and making babies cry, yeah, I know). Ideally we'd love to have only one copy of gtest, and a single way to do deps, but in the mean time, it can work. Antoine I agree that this is a difficult choice, there are no obvious good solutions. I don't think we like to pull in third party dependencies
[chromium-dev] Destruction of C++ objects attached to V8 objects
Hi All,
I'm seeking a way to trigger destruction (or reference decrement) of a C++
object attached to a V8 object when the V8 object is destroyed. For
instance, consider the following code where I create and return a new V8
object in a function template callback:
static v8::Handlev8::Value MyCallback(const v8::Arguments args) {
// Create a new V8 object template with one internal field.
v8::Handlev8::ObjectTemplate my_templ = v8::ObjectTemplate::New();
my_templ-SetInternalFieldCount(1);
// Create a new MyClass instance.
MyClass* my_class = ...;
// Create a new V8 object.
v8::Localv8::Object obj = my_templ-NewInstance();
// Attach the MyClass instance to the V8 object.
obj-SetInternalField(0, v8::External::New(my_class));
return obj;
}
How can I clean up the MyClass instance when the associated V8 object
destroyed? Is there some way that I can assign a destructor callback for
the V8 object?
Thanks,
Marshall
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
