Re: [chromium-dev] Link error with chromium on ubuntu 9.10
On Sat, Dec 19, 2009 at 05:03:57PM -0800, n179911 wrote:
> Hi,
>
> I get the chromium on ubuntu 9.10. The compilation is okay, but when I get
> link, it fails:
>
> $ make -j5 chrome
> LINK(target) out/Debug/chrome
> collect2: ld terminated with signal 9 [Killed]
> make: *** [out/Debug/chrome] Error 1
>
> I think I have 'gold linker' installed:
> Building dependency tree
> Reading state information... Done
> binutils-gold is already the newest version.
> 0 upgraded, 0 newly installed, 0 to remove and 33 not upgraded.
>
> And i have checked I have enough disk space.
>
> Can you please tell me why?
Probably the OOM killer. Chrome takes a very large amount of memory to link.
You can add some swap, or trade a lot of link-time memory for a little startup
delay by building shared. You can do that by putting this in your
~/.gyp/include.gypi:
{'variables': {
'library': 'shared_library',
}}
Good luck, -- Jacob
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Thoughts on "// NOLINT"?
On Thu, Dec 10, 2009 at 11:14:32AM -0800, Scott Hess wrote: > On Thu, Dec 10, 2009 at 10:58 AM, Peter Kasting wrote: > > On Thu, Dec 10, 2009 at 10:45 AM, Jonathan Dixon wrote: > >> In essence: > >> return DoWork(&foo) > >> #if defined(OS_POSIX) > >> && DoWork(&posix_specific) > >> #endif > >> ; // <-- Lint complains about this guy > > > > I'd prefer this: > > #if defined(OS_POSIX) > > return DoWork(&foo) && DoWork(&posix_specific); > > #else > > return DoWork(&foo); > > #endif > > The same number of lines, but much easier to read. > > > Or: > bool ret = DoWork(&foo); > #if defined(OS_POSIX) > ret = ret && DoWork(&posix_specific); > #endif > return ret; > > Breaking a single statement up with a macro is icky. If something extra in an expression is a common case, I've sometimes seen it done like: return DoWork(&foo) POSIX_ONLY(&& DoWork(&posix_specific)); where POSIX_ONLY will expand to nothing or its argument. It's ugly, but compact. -- Jacob -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] class has virtual method but non-virtual destructor
On Fri, Nov 20, 2009 at 03:06:21PM -0800, James Robinson wrote: > On Fri, Nov 20, 2009 at 3:01 PM, Jacob Mandelson wrote: > > > On Fri, Nov 20, 2009 at 02:55:17PM -0800, Peter Kasting wrote: > > > On Fri, Nov 20, 2009 at 2:53 PM, Jacob Mandelson > >wrote: > > > > > > > http://codereview.chromium.org/201100/show > > > > > > > > > > Yes, that caused a large subsequent discussion at which it seemed like it > > > was determined that this was fine. I was surprised to hear this issue > > come > > > up again because I'd assumed you'd already checked in your fixes. > > > > I had the impression that at the end of the discussion you were still > > against. Can you LG 201100 and 200106 ? > > > > They have whitespace errors which need resolving. I'd also favor just going > with virtual d'tors rather than protected non-virtual ones. Protected > virtual if you want to enforce that the object is never deleted via a ptr to > the base class. Yes, I'll fix the whitespace to style. I don't feel strongly about which way the dtors go, protected or virtual, but chose to prefer protected because the intent was that the class not be derived-destructed and that expressed that intent. -- Jacob -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] class has virtual method but non-virtual destructor
On Fri, Nov 20, 2009 at 02:55:17PM -0800, Peter Kasting wrote: > On Fri, Nov 20, 2009 at 2:53 PM, Jacob Mandelson wrote: > > > http://codereview.chromium.org/201100/show > > > > Yes, that caused a large subsequent discussion at which it seemed like it > was determined that this was fine. I was surprised to hear this issue come > up again because I'd assumed you'd already checked in your fixes. I had the impression that at the end of the discussion you were still against. Can you LG 201100 and 200106 ? -- Jacob -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] class has virtual method but non-virtual destructor
On Fri, Nov 20, 2009 at 02:47:56PM -0800, Peter Kasting wrote: > On Fri, Nov 20, 2009 at 1:31 PM, James Robinson wrote: > > What's the benefit of omitting the virtual destructor? > > > > I'm not trying to say it has massive benefits. I'm trying to make concrete > the rather abstract statement that we have patterns right now where objects > don't specify destructors. > > If you want me to argue for it, then I would probably say that it's a little > simpler and clearer without a destructor, and for someone used to reading > our code it's a tipoff that this is an instance of the "interface" class > pattern. If I were to add a destructor, I'd declare one in private as > opposed to adding a virtual one, again just to emphasize that this is an > interface as opposed to a parent of more specialized children. Not a very > important set of reasons. > > If you feel violently, write the patch. I won't stop you. Ahem? http://codereview.chromium.org/201100/show -- Jacob -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] class has virtual method but non-virtual destructor
On Fri, Nov 20, 2009 at 12:05:55PM -0800, Evan Martin wrote: > On Fri, Nov 20, 2009 at 4:23 AM, rahul wrote: > > I was trying to compile chromium today on Linux and I got this error. > > This error occurred because of -Werror CFLAG set in the Makefile. I > > remedied by writing a one-liner to delete all occurrences of -Werror > > from CFLAGS in all Makefiles. > > > > However, this error intrigued me. I saw through the code and the > > classes in question have declared virtual methods but haven't declared > > a destructor. In that case, the compiler generates the destructor. > > > > > > Base *b = new Sub(); > > delete b; > > > > To the best of my knowledge, if Base is the class which defines > > virtual methods but non-virtual destructor, delete can cause a memory > > leak if Sub happens to be taking more memory than Base. I think that > > the destructor for a class with virtual methods has either to be > > "public virtual" or "protected non-virtual" for the proper freeing of > > memory. > > > > > > Would someone help me clarify this? > > > > I know there might be some scenarios where this can be done > > intentionally but looks like there are more arguments for adding a > > virtual destructor than not adding one. I see that this is done for > > the Delegates. Also, if this is one of the intended special cases, can > > someone explain how to compile chromium then? Deleting -Werror from > > CFLAGS is an ugly hack at best. > > Your analysis is correct. However, a virtual destructor is not needed > in the case where you never delete through the Base*. It turns out > for our codebase that is very common (due to lots of "observer"-like > patterns), so we decided to not rely on this compiler warning. It's > only caused horrible bugs once or twice! :) > > The correct fix would be to disable this particular warning in > build/common.gypi. > However, I'm puzzled why nobody else has encountered the problem > you're mentioning. > Can you provide some details about your compiler, system configuration, etc.? I encountered this, by turning on -Wextra which included -Wnon-virtual-dtor, and submitted some patches to clean it up, which were rejected. (So, add on -Wno-non-virtual-dtor to get a build.) -- Jacob -- 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: chrome build problem on Ubuntu
On Tue, Oct 20, 2009 at 05:47:08PM -0700, webinfinite wrote: > I am building Chromium on my Ubuntu box but have the following errors: > > > /usr/bin/ld: skipping incompatible /home/yezhang/chrome/chromium_zhang/ > src/sconsbuild/Debug/lib/libnpGoogleNaClPluginChrome.a when searching > for -lnpGoogleNaClPluginChrome > /usr/bin/ld: cannot find -lnpGoogleNaClPluginChrome > collect2: ld returned 1 exit status > scons: *** [/home/yezhang/chrome/chromium_zhang/src/sconsbuild/Debug/ > chrome] Error 1 > scons: building terminated because of errors. You're on x86_64, right? There's a build bug on that arch where chrome proper and nacl pick different build architectures or something like that. You can work around it by setting the envvar GYP_DEFINES to target_arch=ia32 or target_arch=x64 so they don't try to pick an arch themselves. You'll have to run gclient runhooks to rebuild the scons files from gyp. -- Jacob --~--~-~--~~~---~--~~ 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: Scalability
On Tue, Oct 13, 2009 at 08:26:38AM +0200, Craig Schlenter wrote: > Hi > > The patch below should fix it (there are arguably other perhaps better > ways to tackle the debugger dependency etc.). > > With that patch, the linux shared make build compiles and links all > targets for me. Thanks, that patch works for me! I can vouch at its review. -- Jacob --~--~-~--~~~---~--~~ 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: Scalability
On Mon, Oct 12, 2009 at 06:29:02PM -0700, Lei Zhang wrote: > Maybe you need to clobber? The shared build bot on the FYI waterfall > is working: > http://build.chromium.org/buildbot/waterfall.fyi/builders/Chromium%20Linux%20Builder%20(dbg-shlib)/builds/1069 > gclient runhooks regenerated a bunch of .mk's, but I'm still getting the same link error. -- Jacob --~--~-~--~~~---~--~~ 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: Scalability
On Wed, Oct 07, 2009 at 06:48:15PM +0200, Craig Schlenter wrote: > On Wed, Oct 7, 2009 at 10:00 AM, Craig Schlenter > wrote: [big snip] > > This problem only seems to happen with the scons shared build. The > > make build does not have this problem so there seems to be something > > different about how the dependencies are being generated with the make > > versus scons gyp backends. I'm now getting build failures for linux_page_load_uitest with the shared object build, under both scons and make: /mnt/sda4/chromium/src/out/Debug/obj/chrome/libbrowser.so: undefined reference to `DevToolsManager::ActivateWindow(RenderViewHost*)' ... and a bunch of other DevToolsManager:: undefined references. (32-bit, Debug. Giving 32-bit Release a spin now.) -- Jacob --~--~-~--~~~---~--~~ 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: Scalability
On Tue, Oct 06, 2009 at 09:19:49PM +0200, Craig Schlenter wrote:
> On Tue, Oct 6, 2009 at 8:14 PM, Craig Schlenter
> wrote:
> > On Tue, Oct 6, 2009 at 7:51 PM, Jacob Mandelson wrote:
> >> On Tue, Oct 06, 2009 at 07:39:14PM +0200, Craig Schlenter wrote:
> >>> On Tue, Oct 6, 2009 at 6:58 PM, Evan Martin wrote:
> >>> >
> >>> > On Tue, Oct 6, 2009 at 9:21 AM, Jacob Mandelson
> >>> > wrote:
> >>> >> I tried this, and it does indeed link far, far faster!
> >>> >> However, I got errors about RegisterInternalNaClPlugin():
> >>> >> /mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/lib/librenderer.so:
> >>> >> undefined reference to `RegisterInternalNaClPlugin(bool (*)(int,
> >>> >> int*))'
> >>> >> (Also one for libbrowser.so)
> >>> >
> >>> > In general, the shared link breaks frequently. Whenever I work from a
> >>> > cafe or wherever from my laptop, I usually will do a TBR commit or two
> >>> > to fix the shared link.
> >>>
> >>> The shared build is working perfectly for me FWIW but that is on 32 bit.
> >>>
> >>> Are you on 64 bit or do you have any special gyp variables etc. set?
> >>
> >> I'm on 32-bit. Only gyp changes from stock I have are:
> >> {'variables': {
> >> 'library': 'shared_library',
> >> 'remove_webcore_debug_symbols': 1,
> >> }}
> >
> > Ah, you're doing a debug build then? I have only tested release recently.
> >
> > I'll poke at a debug build tomorrow and try to sort it out ...
>
> Hm ... debug build is also fine for me and I'm building with the
> same gyp variables as you (except that I also have gcc_version=44).
>
> If you stick your build into verbose mode can you see if it is linking
> librenderer.so with libnpGoogleNaClPluginChrome.a? Maybe clobbering,
> regyping etc. will encourage it to do that.
>
> PS. I'm on r28124
I switched to --mode=Release, got strict-aliasing warnings^Werrors, stuck
on -Wno-strict-aliasing, and it landed back in
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/lib/librenderer.so:
undefined reference to `RegisterInternalNaClPlugin(bool (*)(int, int*))'
Running gclient runhooks had no effect here.
Building with --verbose shows the very long link line attached, which
has [nN][aA][cC][lL] only in -lnacl.
gclient revinfo begins with
src: http://src.chromium.org/svn/trunk/s...@28154;
(Simpler way to get this?)
-- Jacob
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
flock
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/linker.lock
g++ -o
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/lib/librenderer.so
-L/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/lib
-Wl,-rpath=/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/lib
-pthread -m32 -shared -pthread -m32
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/automation/dom_automation_controller.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/extensions/bindings_utils.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/extensions/event_bindings.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/extensions/extension_process_bindings.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/extensions/js_only_v8_extensions.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/extensions/renderer_extension_bindings.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/loadtimes_extension_bindings.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/media/audio_renderer_impl.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/net/render_dns_master.os
/mn
[chromium-dev] Re: Scalability
On Tue, Oct 06, 2009 at 07:39:14PM +0200, Craig Schlenter wrote:
> On Tue, Oct 6, 2009 at 6:58 PM, Evan Martin wrote:
> >
> > On Tue, Oct 6, 2009 at 9:21 AM, Jacob Mandelson wrote:
> >> I tried this, and it does indeed link far, far faster!
> >> However, I got errors about RegisterInternalNaClPlugin():
> >> /mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/lib/librenderer.so:
> >> undefined reference to `RegisterInternalNaClPlugin(bool (*)(int, int*))'
> >> (Also one for libbrowser.so)
> >
> > In general, the shared link breaks frequently. Whenever I work from a
> > cafe or wherever from my laptop, I usually will do a TBR commit or two
> > to fix the shared link.
>
> The shared build is working perfectly for me FWIW but that is on 32 bit.
>
> Are you on 64 bit or do you have any special gyp variables etc. set?
I'm on 32-bit. Only gyp changes from stock I have are:
{'variables': {
'library': 'shared_library',
'remove_webcore_debug_symbols': 1,
}}
-- Jacob
--~--~-~--~~~---~--~~
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: Scalability
On Mon, Oct 05, 2009 at 10:20:47AM -0700, Steven Knight wrote: > The variable name is actually just 'library'. The default is set in > build/common.gypi. You can either change the default variable right in > build/common.gypi or set the environment variable > GYP_DEFINES=library=shared_library to get a shared library build. > (I have it modified locally in one of my checked-out Linux trees for > periodic sanity checks that Linux at least nominally builds with shared > libraries. IIRC, a lot of the Linux folks use shared library builds > regularly, for the much faster link times.) I tried this, and it does indeed link far, far faster! However, I got errors about RegisterInternalNaClPlugin(): /mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/lib/librenderer.so: undefined reference to `RegisterInternalNaClPlugin(bool (*)(int, int*))' (Also one for libbrowser.so) I see these are protected by #ifndef DISABLE_NACL and if (command_line.HasSwitch(switches::kInternalNaCl)), but why would that affect things? DISABLE_NACL should be defined or not the same for shared or static build, and the HasSwitch is a run-time check. If I comment them out, then chrome links. But the call is in RenderProcess::RenderProcess(), surely not dead code that the static link would be removing. Any idea what's going on here? -- Jacob --~--~-~--~~~---~--~~ 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] How did I just fix the build?
On Sat, Oct 03, 2009 at 04:25:08PM -0700, Peter Kasting wrote: > On Sat, Oct 3, 2009 at 11:59 AM, Antoine Labour wrote: > > On Sat, Oct 3, 2009 at 11:09 AM, Dan Kegel wrote: > >> On Sat, Oct 3, 2009 at 11:07 AM, Dan Kegel wrote: > >> >> "undefined reference to > >> >> BlockedPopupContainer::kImpossibleNumberOfPopups" > >> > >> Aha. It's a bug in our code. chrome/browser/blocked_popup_container.cc > >> needs to follow through and actually declare storage for that variable. > >> > > > > MSVC and GCC differ regarding the C++ spec for when you define a static > > const in a class. > > The spec says you need to provide storage for it. > > > > You're missing the point. The pre-existing code already had the existing > declarations and usage for this variable. I didn't touch that at all. I > added a DCHECK that referred to it in a function that already referred to > it, and things broke. I commented out the DCHECK and left all the other > references and things worked again. This puzzles me. The other references are all in arithmetic expressions, so I presume they get the variable access converted to using its immediate value, and don't reference the variable anymore by link time. But DCHECK_NE expands to CheckNEImpl, which takes its arguments by reference, so now the variable has to actually exist (have storage). (I guess CheckNEImpl's inline isn't kicking in, or if it is, the compiler isn't following the reference-dereference to see it can just use the immediate value.) -- Jacob --~--~-~--~~~---~--~~ 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: Why SOCK_SEQPACKET?
On Fri, Oct 02, 2009 at 03:48:02PM -0700, Adam Langley wrote: > On Fri, Oct 2, 2009 at 3:44 PM, Jacob Mandelson wrote: > > The Linux send(2) man page explicitly says the message is all-or-nothing, > > I don't think so. It says: > > "If the message is too long to pass atomically through the underlying > protocol, the error EMSGSIZE is returned, and the message is not > transmitted." > > I think the confusion is that the "underlying protocol" for > SOCK_STREAM isn't atomic. The description of the error is clearer: > > "EMSGSIZE: The socket type requires that message be sent atomically, > and the size of the message to be sent made this impossible." It also says: When the message does not fit into the send buffer of the socket, send() normally blocks, unless the socket has been placed in non-block‐ ing I/O mode. In non-blocking mode it would return EAGAIN in this case. Which reads like "all or nothing" to me, though I could imagine a (perverse?) implementation with each writer having a send buffer lower layer pulling data from multiple writers' send buffers in an interleaved manner. (But maybe there's something else which restricts sockets to a single send buffer.) -- Jacob --~--~-~--~~~---~--~~ 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: Why SOCK_SEQPACKET?
On Fri, Oct 02, 2009 at 02:45:21PM -0700, Ben Laurie wrote: > On Fri, Oct 2, 2009 at 2:40 PM, Adam Langley wrote: > > On Fri, Oct 2, 2009 at 2:37 PM, Ben Laurie wrote: > >> Why will it certainly not work? From what (little) I understand, > >> SOCK_SEQPACKET adds record boundaries to SOCK_STREAM ... presumably > >> one could simulate that over SOCK_STREAM? > > > > There are multiple, concurrent writers to the socket. If you make > > assumptions about the kernel's behaviour, you might be able to come up > > with a workable framing protocol, but it's much better to use the > > correct socket type. > > Ah, I see. Hmmm. The Linux send(2) man page explicitly says the message is all-or-nothing, and the SUS entry seems to indicate the same thing, though not as clearly, so that framing protocol can probably just be []* Still more complicated than having the socket layer do it though. -- Jacob --~--~-~--~~~---~--~~ 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: gclient sync failing with 405 Method Not Allowed
On Wed, Sep 30, 2009 at 11:39:24AM -0700, Yaar Schnitman wrote: > This is probably related to: > http://groups.google.com/group/chromium-dev/browse_thread/thread/64a19a5f78db8fba > Ahh yes, that fixed it, thanks. -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] gclient sync failing with 405 Method Not Allowed
Recent attempts to run gclient sync have been failing with: running 'svn update /usr/local/google/home/jlm/chrome/home/chrome-svn/tarball/chromium/src/third_party/WebKit --revision 27313' in '/usr/local/google/home/jlm/chrome/home/chrome-svn/tarball/chromium' svn: Server sent unexpected return value (405 Method Not Allowed) in response to PROPFIND request for '/repository/webkit/trunk/WebKit/chromium' Error: failed to run command: svn update /usr/local/google/home/jlm/chrome/home/chrome-svn/tarball/chromium/src/third_party/WebKit --revision 27313 --~--~-~--~~~---~--~~ 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: Kiosk Mode for Chrome
On Tue, Sep 29, 2009 at 04:37:46PM -0700, Jeremy Orlow wrote: > On Tue, Sep 29, 2009 at 4:20 PM, Brett Wilson wrote: > > On Tue, Sep 29, 2009 at 4:15 PM, Jeremy Orlow wrote: > > > I'm guessing different people/companies will have different needs for a > > > kiosk mode. > > > Maybe all of these should be separate flags rather than one "kiosk" flag? > > > We could then offer recommendations in a "Chromium for kiosks" Wiki > > page? > > > > I think the reasoning for allowing this feature is that some minority > > would find it helpful and it wouldn't hurt much. I'm concerned that it > > is getting much too complicated. I think we shouldn't do it if it is > > going to be this complicated. > > > > Would multiple command line flags rather than one really complicate the > design? Mohamed's original patch was just a bunch of if statements keying > off of one flag. Seems like the same amount of work to have each if > statement key off of a different one. Or am I missing something? If nothing else, it grows the configuration space. Supporting a kiosk mode seems like a good idea. Supporting 2^N different flavors of kiosk mode sounds dicier. -- Jacob --~--~-~--~~~---~--~~ 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: Add "Jank" to appropriate bugs
On Tue, Sep 15, 2009 at 04:28:41PM -0700, Peter Kasting wrote: > Tomorrow afternoon a couple of us will be triaging all bugs with the "Jank" > label. Jankiness is sluggishness in the UI, so things like slow startup or > shutdown, tabs taking a while to paint or to close, keyboard accelerators > and button clicks being unresponsive, and other similar "Chrome doesn't do > what I tell it to, when I tell it to" bugs are all "Jank". > In preparation for this triage, please add this label to applicable bugs > you've filed or are following. If you know bugs that should have this added > but don't have the ability to change them yourself, send me an email with > the bug numbers and I'll take a look. This will ensure we don't miss any > issues in our triage. When I find web pages which demonstrate an exceptional amount of chrome jank, is there a particular bug I should add them to? Or should we wait for the general jank-tagged issues to get resolved? -- Jacob --~--~-~--~~~---~--~~ 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: Chrome Keyboard Access, opinions?
On Sat, Sep 26, 2009 at 11:40:07AM -0400, Mohamed Mansour wrote: > Hi all, (need UI team feedback and other keyboard guru's) > We need a more coherent story for accessing various toolbars. The current > toolbars that exist right now are: > >- Toolbar >- Bookmark bar >- Extension bar >- More in the future > > Currently ALT + SHIFT + T brings your focus to the toolbar, but there is no > way to get to the others. This blocks keyboard users accessing the other > bars which is kind of annoying if your a keyboard user. According to Jonas > Klink (Accessibility guru) he said that shortcut was only a temporary > solution and would like to get rid of it and replace it with something more > generic. So we need to think of a uniform access solution to all these > toolbars. [...] Maybe we could treat them akin to menus, and have Alt-SomeLetter go move the active focus to the bar? Alt-T and Alt-B seem unbound, but Alt-E (and not Alt-D) opens the Document menu. Alt-F opens the Wrench menu. -- Jacob --~--~-~--~~~---~--~~ 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] user feedback one month in
On Mon, Sep 21, 2009 at 01:49:26PM -0700, Evan Stade wrote: > On Sun, Sep 20, 2009 at 7:43 PM, Evan Martin wrote: > > - He's bookmarking by pasting urls into "add page" dialog found via > > the bookmark manager(!). Maybe he doesn't realize the star is the add > > bookmark button? > > My response: I'm no UI designer, but I wonder if it'd help to put the > > bookmark button star in some of the dialogs related to bookmarking? > > If you don't hover the star you'll never learn what it does; on the > > other hand, there are only seven buttons on the toolbar and I kind of > > don't have much pity for people who haven't looked at them. > > there are about 10,000 ways to bookmark a page: > - drag web page link to bookmark bar > - drag omnibox contents to bookmark bar > - drag star button to bookmark bar > - press star button > - right click on bookmark bar, add page > - go to bookmark manager, right click, add page > - go to bookmark manager, organize menu, add page You left off my favorite of typing ^D, but then I seem fonder of keyboard shotcuts than the typical user. :) The bookmark bar is hidden by default, so the reviewer might well be completely unaware of it. -- Jacob --~--~-~--~~~---~--~~ 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 core principles and multiplatform development?
On Fri, Sep 11, 2009 at 01:15:22PM -0700, Scott Hess wrote: > On Fri, Sep 11, 2009 at 1:03 PM, Jacob Mandelson wrote: > > ... And then we got in a long discussion about whether the policy that > > external contributors need to have built their patches against all three > > platforms was adequately disclosed or not. > > > > I must admit I'm suffering cognitive dissonance now that after that you're > > telling me all long it wasn't the policy. > > Hmm, well my impression is that submitting without running against the > trybots is a no-no, and there are Windows, Mac, and Linux trybots. If > you've successfully passed the trybots, you have built your patch > against all three platforms. > > Of course, sometimes something slips through. But if people are > giving you grief for something which looks good, and which passed the > trybots, then I'm sad. The trybot is restricted access to committers only. I'm not a committer, and as such I don't have access. -- Jacob --~--~-~--~~~---~--~~ 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 core principles and multiplatform development?
On Fri, Sep 11, 2009 at 12:49:22PM -0700, Dan Kegel wrote: > On Fri, Sep 11, 2009 at 12:38 PM, Jacob Mandelson wrote: > >> I don't think we should require contributors to have access to all > >> platforms, but they do need to be aware of and responsible for them all. > > > > There is internal dispute about this then. Evan Stade and Dan Kegel > > considered me to be violating policy by not doing local Visual Studio > > builds myself. > > Not really. I suggested you get a windows machine because you're > a googler, and it's easy for you. I don't think contributors > in general are required to have all three platforms locally. ... And then we got in a long discussion about whether the policy that external contributors need to have built their patches against all three platforms was adequately disclosed or not. I must admit I'm suffering cognitive dissonance now that after that you're telling me all long it wasn't the policy. -- Jacob --~--~-~--~~~---~--~~ 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 core principles and multiplatform development?
On Fri, Sep 11, 2009 at 12:04:47PM -0700, Pam Greene wrote: > On Fri, Sep 11, 2009 at 11:50 AM, Dan Kegel wrote: > > On Thu, Sep 10, 2009 at 10:19 AM, Paweł Hajdan Jr. > > wrote: > > >> In this case, the code may have been submitted by a committer > > >> without using the trybots (tsk, tsk). We don't currently mention > > >> the trybots on dev.chromium.org. Is it time to? > > > > > > Submitting without trybots and breaking the compile? Doesn't look good to > > > me. I think we should mention that all committers should use the trybots > > > (they have access to them). > > > > I see we do talk about the trybots on dev.chromium.org, so I changed > > http://sites.google.com/a/chromium.org/dev/developers/contributing-code > > as follows: > > > > Added new line: > > # If you can commit, run your changes through the try server before > > committing to reduce the chances your change will break the build on > > some other platform. > > (where try server is a link to > > http://dev.chromium.org/developers/try-server-usage) > > > > Added *new text* in old line: > > # If you can't commit, ask the reviewer to commit your fix for you. > > They will patch their working copy with your changelist, *run it > > through the try server,* and commit it for you. > > > > Added *new text* in old line: > > # Once you've checked something in, you're on the hook for making sure > > the BuildBot waterfall stays healthy, so stick around and watch them > > until everything cycles green. If you break something, you have to fix > > it, *even if it's on a different platform*. > > > > Perhaps append something like "People more familiar with other platforms > will be glad to help, but your patch will be rolled back in the meantime." > > I don't think we should require contributors to have access to all > platforms, but they do need to be aware of and responsible for them all. There is internal dispute about this then. Evan Stade and Dan Kegel considered me to be violating policy by not doing local Visual Studio builds myself. I'd be very happy with what you're proposing, instead. -- Jacob --~--~-~--~~~---~--~~ 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 core principles and multiplatform development?
On Thu, Sep 10, 2009 at 10:03:00AM -0700, Dan Kegel wrote: > An external contributor was recently surprised that a change tested > on linux was reverted because it broke the build on windows. > (His mental model was that linux developers don't have to > worry about other platforms, that's what windows developers are for.) > He said that none of the doc at dev.chromium.org covered this, so I had a > look. > It was more surprised that I was expected to have built chrome at home under multiple platforms. I think most coders out there don't have set ups that let them build on all of the three. Requiring that substantially restricts your contributor pool. It's not an unreasonable policy, but it is an atypical one, so I think it should be spelled out in the "contributing" pages. It's not that in other cross-platform projects Mac or Linux developers don't have to "worry" about Windows, it's that they aren't expected to have Visual Studio and people that do have it will cooperate with them on problems. Plus there's all the Windows developers that don't happen to have Macintoshes with XCode around... -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
