date:20091210

http://code.google.com/p/gyp has some wiki pages.

On Thu, Dec 10, 2009 at 10:49 AM, Igor Gatis igorga...@gmail.com wrote:
 Thanks Mark.

 BTW, do you guys know of lists or wiki I could get more information
 regarding GYP tool?

 On Wed, Dec 9, 2009 at 5:40 PM, Mark Mentovai m...@chromium.org wrote:

 There's better info in gclient.py, as a comment.  Maybe we can just
 rip this off and stick it in a web page somewhere on the developer
 site.

 Hooks
  .gclient and DEPS files may optionally contain a list named hooks to
  allow custom actions to be performed based on files that have changed in
 the
  working copy as a result of a sync/update or revert operation.
  This
  could be prevented by using --nohooks (hooks run by default). Hooks can
 also
  be forced to run with the runhooks operation.  If sync is run with
  --force, all known hooks will run regardless of the state of the working
  copy.

  Each item in a hooks list is a dict, containing these two keys:
    pattern  The associated value is a string containing a regular
               expression.  When a file whose pathname matches the
 expression
               is checked out, updated, or reverted, the hook's action
 will
               run.
    action   A list describing a command to run along with its arguments,
 if
               any.  An action command will run at most one time per
 gclient
               invocation, regardless of how many files matched the
 pattern.
               The action is executed in the same directory as the .gclient
               file.  If the first item in the list is the string python,
               the current Python interpreter (sys.executable) will be used
               to run the command. If the list contains string
 $matching_files
               it will be removed from the list and the list will be
 extended
               by the list of matching files.

  Example:
    hooks = [
      { pattern: \\.(gif|jpe?g|pr0n|png)$,
        action:  [python, image_indexer.py, --all]},
    ]

 Marc-Antoine Ruel wrote:
  Humm, that's a good question. Right now the only doc is gclient help
  runhooks which is .. uh .. not really useful.
 
  M-A
 
  On Wed, Dec 9, 2009 at 3:28 PM, Igor Gatis igorga...@gmail.com wrote:
  Is there documentation somewhere regarding gclient? I'd like to know
  more
  about how hooks and other gclient features work.
 
 
  On Tue, Dec 8, 2009 at 6:27 PM, Mark Mentovai mmento...@google.com
  wrote:
 
  Igor Gatis wrote:
   When I change a .gyp, do I need to call gyp or the build process
   does
   that
   for me?
 
  When you change it yourself, in your own working copy, you run
  gclient runhooks to get new files generated.
 
  When a .gyp change is checked in, you don't need to do this: gclient
  will automatically run GYP as needed when you run gclient sync.
 
  Mark
 
  --
  Chromium Developers mailing list: chromium-dev@googlegroups.com
  View archives, change email options, or unsubscribe:
  http://groups.google.com/group/chromium-dev
 



-- 
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] Modifying .gyp files

2009-12-10 Thread Mikhail Naganov

http://code.google.com/p/gyp/w/list

On Thu, Dec 10, 2009 at 18:49, Igor Gatis igorga...@gmail.com wrote:
 Thanks Mark.

 BTW, do you guys know of lists or wiki I could get more information
 regarding GYP tool?

 On Wed, Dec 9, 2009 at 5:40 PM, Mark Mentovai m...@chromium.org wrote:

 There's better info in gclient.py, as a comment.  Maybe we can just
 rip this off and stick it in a web page somewhere on the developer
 site.

 Hooks
  .gclient and DEPS files may optionally contain a list named hooks to
  allow custom actions to be performed based on files that have changed in
 the
  working copy as a result of a sync/update or revert operation.
  This
  could be prevented by using --nohooks (hooks run by default). Hooks can
 also
  be forced to run with the runhooks operation.  If sync is run with
  --force, all known hooks will run regardless of the state of the working
  copy.

  Each item in a hooks list is a dict, containing these two keys:
    pattern  The associated value is a string containing a regular
               expression.  When a file whose pathname matches the
 expression
               is checked out, updated, or reverted, the hook's action
 will
               run.
    action   A list describing a command to run along with its arguments,
 if
               any.  An action command will run at most one time per
 gclient
               invocation, regardless of how many files matched the
 pattern.
               The action is executed in the same directory as the .gclient
               file.  If the first item in the list is the string python,
               the current Python interpreter (sys.executable) will be used
               to run the command. If the list contains string
 $matching_files
               it will be removed from the list and the list will be
 extended
               by the list of matching files.

  Example:
    hooks = [
      { pattern: \\.(gif|jpe?g|pr0n|png)$,
        action:  [python, image_indexer.py, --all]},
    ]

 Marc-Antoine Ruel wrote:
  Humm, that's a good question. Right now the only doc is gclient help
  runhooks which is .. uh .. not really useful.
 
  M-A
 
  On Wed, Dec 9, 2009 at 3:28 PM, Igor Gatis igorga...@gmail.com wrote:
  Is there documentation somewhere regarding gclient? I'd like to know
  more
  about how hooks and other gclient features work.
 
 
  On Tue, Dec 8, 2009 at 6:27 PM, Mark Mentovai mmento...@google.com
  wrote:
 
  Igor Gatis wrote:
   When I change a .gyp, do I need to call gyp or the build process
   does
   that
   for me?
 
  When you change it yourself, in your own working copy, you run
  gclient runhooks to get new files generated.
 
  When a .gyp change is checked in, you don't need to do this: gclient
  will automatically run GYP as needed when you run gclient sync.
 
  Mark
 
  --
  Chromium Developers mailing list: chromium-dev@googlegroups.com
  View archives, change email options, or unsubscribe:
  http://groups.google.com/group/chromium-dev
 

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

-- 
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] Reflecting SSL state in a world with SharedWorkers and cross-window sharing/x-domain messaging

2009-12-10 Thread Adam Barth

On Thu, Dec 10, 2009 at 2:44 AM, Ian Hickson i...@google.com wrote:
 I'd recommend switching to a mixed content lock whenever any
 interaction occurs with any insecure content (unencrypted or imperfect
 cert), whether that be posting to an http:// window with
 postMessage(), receiving a message (and actually having an event
 handler run) from such a page, any worker in the whole chain of
 workers from the page doing anything with insecure content (including
 before the page existed), basically being the most hard-core tainting
 possible. Ideally, we'd send explanations to the console explaining
 what it is that made it mixed content, too, so that authors would have
 no difficulty working it out.

 We might also want to consider tainting whenever there's a message
 received from a page that is secure content but from a different
 origin. (Do we do this today with script? It seems that we should
 consider a script on https://example.com/ invoking a .js file from
 https://twitter.com/ to flag the page as mixed content, for instance,
 since that's an XSS vector right there, if anyone ever goes evil at
 twitter, say.)

We don't do this for script today.  The mixed content indicator is
about whether the current page has protected itself from active
network attackers.  When HTTPS origin A includes a script from HTTPS
origin B, origin A hasn't opened itself up to a network attack.
Consider the case of www.paypal.com, which includes script from
paypalobjects.com over HTTPS.  There's nothing nefarious going on.
PayPalObjects is just the name of their CDN.  If we broke the lock
icon in this case, hardly any sites would keep their lock, which
doesn't seem to be in the best interest of the user.

Adam

-- 
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] Windows build problem: base_nacl_win64.lib LNK1112: module machine type 'x64' conflicts with target machine type 'X86'

2009-12-10 Thread Gregory Dardyk

John,
I build this target daily on Vista64, so I believe the problem is not caused
by building on Vista alone. Also, disabling nacl won't help in this case -
the flag does not disable the 64-bit targets. However, Chrome does not
depend on the 64-bit targets at this stage, they are only built as part of
'all'. Therefore, you should be able to build Chrome successfully even if
the 64-bit targets fail.
Please let me know if you have any problems building the 64-bit Windows
targets.
Greg

On Dec 9, 2009 10:28 PM, John Grabowski j...@chromium.org wrote:

I saw this on Vista64 today as well.  We don't have a Vista64 bot so it
wouldn't have made the tree red.

To fix, GYP_DEFINES='disable_nacl=1' gclient runhooks (in cygwin), then
build.

The right parties have been notified.

jrg

On Wed, Dec 9, 2009 at 2:00 PM, Steve VanDeBogart vand...@chromium.org
wrote:   My windows bui...

-- 
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] [Linux] New build deps (jpeg, xslt)

2009-12-10 Thread Michael Moss

This is back in. XSLT is no longer required (though it doesn't hurt to
have it), and it seems some machines are also missing bzip2 headers,
so for Hardy, the new command to install the deps is:

sudo apt-get install -y libbz2-dev libjpeg62-dev

After you update your packages and sync your sources, you may also
need to clobber your build in order to switch to the system headers.

Michael

On Wed, Dec 9, 2009 at 5:33 PM, Michael Nordman micha...@google.com wrote:
 There were several crashing layout tests on linux when loading .xml files
 shortly after this (and a little later, a webkit roll) was landed. We've
 reverted both this change and the webkit roll, but i'm thinking the xslt
 changes may have more to do with the crashes then the webkit roll? The try
 servers were happy with the roll, things just went awry once it got landed
 on the trunk.
 On Wed, Dec 9, 2009 at 3:57 PM, Michael Moss mm...@chromium.org wrote:

 A recent change to use more system libs
 (http://src.chromium.org/viewvc/chrome?view=revrevision=34195) might
 break Linux builds. If you see messages about missing jpeg or xslt
 headers, please install the relevant -dev packages. For instance, on
 Hardy you would run:

 sudo apt-get install -y libxslt1-dev libjpeg62-dev

 Michael

 PS - Due to other issues, libxslt might change back to being a static
 lib, but it shouldn't hurt to install the -dev package either way.

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



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

[chromium-dev] buildbot failure in Chromium on Webkit Linux (valgrind), revision 34256

Automatically closing tree for compile on Webkit Linux (valgrind)

http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Linux%20%28valgrind%29/builds/7663

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20Linux%20%28valgrind%29

--=  Automatically closing tree for compile on Webkit Linux (valgrind)  
=--

Revision: 34255, 34256
Blame list: dglaz...@chromium.org,mm...@google.com

Buildbot waterfall: http://build.chromium.org/

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

[chromium-dev] buildbot failure in Chromium on Linux Perf, revision 34260

Automatically closing tree for compile on Linux Perf

http://build.chromium.org/buildbot/waterfall/builders/Linux%20Perf/builds/4401

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Perf

--=  Automatically closing tree for compile on Linux Perf  =--

Revision: 34252, 34253, 34254, 34255, 34256, 34257, 34258, 34259, 34260
Blame list: 
dglaz...@chromium.org,mbel...@google.com,mm...@google.com,o...@chromium.org,si...@chromium.org,s...@chromium.org,thoma...@chromium.org,xiy...@chromium.org

Buildbot waterfall: http://build.chromium.org/

-- 
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] Embedding Chromium

http://code.google.com/p/chromiumembedded/.

Marshall would probably appreciate to have some help.

On Thu, Dec 10, 2009 at 12:43 PM, hap 497 hap...@gmail.com wrote:

 Hi,

 Is it possible to embed a chromium in my c/c++ application? (just like
 someone embed a Webkit rendering engine in his application). I
 understand  chromium uses Webkit rendering engine too. But I would
 like to take advantage Chromium's v8 javascript engine and it 1
 process/tab architecture.

 Thank you.

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


-- 
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] Embedding Chromium

2009-12-10 Thread Marshall Greenblatt

On Thu, Dec 10, 2009 at 1:24 PM, Marc-Antoine Ruel mar...@chromium.orgwrote:

 http://code.google.com/p/chromiumembedded/.

 Marshall would probably appreciate to have some help.


More help is always welcome :-)



 On Thu, Dec 10, 2009 at 12:43 PM, hap 497 hap...@gmail.com wrote:

 Hi,

 Is it possible to embed a chromium in my c/c++ application? (just like
 someone embed a Webkit rendering engine in his application). I
 understand  chromium uses Webkit rendering engine too. But I would
 like to take advantage Chromium's v8 javascript engine and it 1
 process/tab architecture.


CEF is an embedded version of Chromium designed specifically for use in
C/C++ applications.  The CEF architecture is currently single-process.



 Thank you.


Regards,
Marshall



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




-- 
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?

2009-12-10 Thread Jonathan Dixon

2009/12/10 Brett Wilson bre...@chromium.org

 On Wed, Dec 9, 2009 at 4:24 PM, John Abd-El-Malek j...@chromium.org
 wrote:
  btw I searched the code, almost all the instances are in code from
 different
  repositories, like v8, gtest, gmock.  I counted only 17 instances in
  Chrome's code.


 Most of the Chrome NOLINTs look like the're around ifdefs, where the
 ifdef code sometimes mean that a comma or a semicolon goes on the line
 after the ifdef. We should be working to remove these anyway since the
 ifdefs are super ugly, and I'm not sure the NOLINT comment actually
 makes them worse. Some of these may not be practical or desirable to
 remove, though.


This is exactly the case I came across recently (which maybe what inspired
John to start this thread.)

In essence:

return DoWork(foo)
#if defined(OS_POSIX)
 DoWork(posix_specific)
#endif
;  // -- Lint complains about this guy

We converged on NOLINT as the solution, but I admit my ingrained instinct is
to pull out the #if altogether, and try to make both calls to DoWork() be
acceptable to call on all platforms, or at the very least replace the second
with a wrapper its body with a null implementation on !OS_POSIX.

Do we have agreed guidelines on when to use #if for portability, or which
patterns to prefer to it?

-- 
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 10:45 AM, Jonathan Dixon j...@chromium.org 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.

PK

-- 
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 10:45 AM, Jonathan Dixon j...@chromium.org wrote:



 2009/12/10 Brett Wilson bre...@chromium.org

 On Wed, Dec 9, 2009 at 4:24 PM, John Abd-El-Malek j...@chromium.org
 wrote:
  btw I searched the code, almost all the instances are in code from
 different
  repositories, like v8, gtest, gmock.  I counted only 17 instances in
  Chrome's code.


 Most of the Chrome NOLINTs look like the're around ifdefs, where the
 ifdef code sometimes mean that a comma or a semicolon goes on the line
 after the ifdef. We should be working to remove these anyway since the
 ifdefs are super ugly, and I'm not sure the NOLINT comment actually
 makes them worse. Some of these may not be practical or desirable to
 remove, though.


 This is exactly the case I came across recently (which maybe what inspired
 John to start this thread.)

 In essence:

 return DoWork(foo)
 #if defined(OS_POSIX)
  DoWork(posix_specific)
 #endif
 ;  // -- Lint complains about this guy

 We converged on NOLINT as the solution, but I admit my ingrained instinct
 is to pull out the #if altogether, and try to make both calls to DoWork() be
 acceptable to call on all platforms, or at the very least replace the second
 with a wrapper its body with a null implementation on !OS_POSIX.

 Do we have agreed guidelines on when to use #if for portability, or which
 patterns to prefer to it?


From the code I've seen, the preference is if only one platform needs a
function to be called, then we only call it using an ifdef instead of
defining that empty function in all other platforms.  Things like
PlatformInit, PlatformDestroy are an exeception since it makes sense that
you want to give each platform the capability for that.  But if you look at
places like PluginService or PluginProcessHost, there are things that only
make sense to call on one platform.

-- 
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] Windows build problem: base_nacl_win64.lib LNK1112: module machine type 'x64' conflicts with target machine type 'X86'

2009-12-10 Thread John Grabowski

Why then do you think vandebo and I hit this error?  Or is this an error
from a subbuild whose result is ignored so the build otherwise works?

jrg

On Thu, Dec 10, 2009 at 9:31 AM, Gregory Dardyk grego...@google.com wrote:

 John,
 I build this target daily on Vista64, so I believe the problem is not
 caused by building on Vista alone. Also, disabling nacl won't help in this
 case - the flag does not disable the 64-bit targets. However, Chrome does
 not depend on the 64-bit targets at this stage, they are only built as part
 of 'all'. Therefore, you should be able to build Chrome successfully even if
 the 64-bit targets fail.
 Please let me know if you have any problems building the 64-bit Windows
 targets.
 Greg

 On Dec 9, 2009 10:28 PM, John Grabowski j...@chromium.org wrote:

 I saw this on Vista64 today as well.  We don't have a Vista64 bot so it
 wouldn't have made the tree red.

 To fix, GYP_DEFINES='disable_nacl=1' gclient runhooks (in cygwin), then
 build.

 The right parties have been notified.

 jrg

 On Wed, Dec 9, 2009 at 2:00 PM, Steve VanDeBogart vand...@chromium.org
 wrote:   My windows bui...



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

[chromium-dev] sheriff swap Dec 18/21?

2009-12-10 Thread Mike Pinkerton

Hey everyone, I noticed I'm on the hook for sheriff duty on Dec 18/21
(Friday/Monday) but I was hoping to be taking vacation during that
time. Does someone want to swap with me?

Thanks in advance!

-- 
Mike Pinkerton
Mac Weenie
pinker...@google.com

-- 
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?

2009-12-10 Thread Scott Hess

On Thu, Dec 10, 2009 at 10:58 AM, Peter Kasting pkast...@google.com wrote:
 On Thu, Dec 10, 2009 at 10:45 AM, Jonathan Dixon j...@chromium.org 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.

-scott

-- 
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?

2009-12-10 Thread Jacob Mandelson

On Thu, Dec 10, 2009 at 11:14:32AM -0800, Scott Hess wrote:
 On Thu, Dec 10, 2009 at 10:58 AM, Peter Kasting pkast...@google.com wrote:
  On Thu, Dec 10, 2009 at 10:45 AM, Jonathan Dixon j...@chromium.org 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] Thoughts on // NOLINT?

On Thu, Dec 10, 2009 at 11:20 AM, Jacob Mandelson ja...@mandelson.orgwrote:

 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.


The Google C++ Style Guide says to avoid macros when there is a non-macro
way to do the same thing.

PK

-- 
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 2:24 PM, Peter Kasting pkast...@google.com wrote:

 On Thu, Dec 10, 2009 at 11:20 AM, Jacob Mandelson ja...@mandelson.org
  wrote:

 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.


 The Google C++ Style Guide says to avoid macros when there is a non-macro
 way to do the same thing.


Sanity says that too.

Scott's technique is the best. If you can't figure out what's happening by
glancing at the code, it's not code, it's assembly.

M-A

(grr)

-- 
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?

2009-12-10 Thread Mark Mentovai

There are cases where you'll want to flout the linter, but this isn't
one of them.  Scott and Peter have both posted viable workarounds that
don't hamper readability (and in fact improve it relative to the
snippet Jonathan is asking about.)  Personally, I prefer Scott's, but
Peter's is good too.

Don't do what Jacob proposed in this case: it's a net a readability
loss because the pattern is unfamiliar.  (Sorry, Jacob!)

Mark

Scott Hess wrote:
 On Thu, Dec 10, 2009 at 10:58 AM, Peter Kasting pkast...@google.com wrote:
 On Thu, Dec 10, 2009 at 10:45 AM, Jonathan Dixon j...@chromium.org 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.

 -scott

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


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

[chromium-dev] buildbot failure in Chromium on Chromium Builder, revision 34267

Automatically closing tree for compile on Chromium Builder

http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder/builds/20216

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Builder

--=  Automatically closing tree for compile on Chromium Builder  =--

Revision: 34267
Blame list: bradnel...@google.com

Buildbot waterfall: http://build.chromium.org/

-- 
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 3:02 PM, Shall be Unnamed @google.com wrote:

 On Thu, Dec 10, 2009 at 2:29 PM, Marc-Antoine Ruel mar...@chromium.orgwrote:

 On Thu, Dec 10, 2009 at 2:24 PM, Peter Kasting pkast...@google.com
  wrote:

  On Thu, Dec 10, 2009 at 11:20 AM, Jacob Mandelson ja...@mandelson.org
  wrote:

 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.


 The Google C++ Style Guide says to avoid macros when there is a non-macro
 way to do the same thing.


 Sanity says that too.

 Scott's technique is the best. If you can't figure out what's happening by
 glancing at the code, it's not code, it's assembly.


 I'd say:

 If you can't figure out what's happening by glancing at the code, it's not
 code, it's template metaprogramming.

 Assembly is easy!

  [Makes a face in the general direction of Herb Sutter.]


LOL

Were you looking at src/base/singleton.h lately?

M-A

-- 
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] Splitting off some pieces of chrome.gyp...

2009-12-10 Thread Brett Wilson

On Mon, Dec 7, 2009 at 1:43 PM, Bradley Nelson bradnel...@google.com wrote:
 Hello All,
 Last week I re-landed a change to split off parts of chrome.gyp into .gypi's
 in the same directory.
 I had done something similar a couple weeks back, but took it out because
 concern was raised about merge conflicts in m4.
 I put it back in because I got the all clear on m4.
 The goal is to reduce contention on chrome.gyp which has gotten quite large
 - 7000+ lines.

I just tried to add a file to chrome.gyp and I couldn't find where it
should go. It took me a minute to remember this thread.

I'm concerned our build system is getting out of control. I can not
explain in simple sentences where anything should go. Even if I'm
using my visual tool and find the right project, the only real way to
find where a file should go is to grep for files nearby. .gyp files
already had this property where you can't find where things should go
in them and you needed to search. Now it seems like we've added an
additional layer of you don't know which file its in, either.

How much does this solve contention? It seems like actual conflicts
for changes will be the same as before. What contention cases are
there that splitting everything out helps a lot?

Thanks
Brett

PS Thanks for working on the build system, I don't mean to be non-appreciative.

-- 
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] Splitting off some pieces of chrome.gyp...

2009-12-10 Thread oshima

I have similar concern about our build, in a way we handle different
configurations.
There are several ways to specify a set of files for different
configurations, such as suffic (_gtk/_mac),
source!, exclude/include, concat file lists, and I'm worrying that
it's getting out of control.
I'm working on linux_views/chromeos, and it's getting harder to
understand what files are really
used for particular configuration (and i'm afraid that I may be contributing
to make it even more complicated by
adding linux_view/chromeos builds). I don't have any particular good
solution in my mind, though.

PS: If you need search over gyp, try code search http://cs/, which has
index for gyp files as well.

- oshima

On Thu, Dec 10, 2009 at 12:25 PM, Brett Wilson bre...@chromium.org wrote:

 On Mon, Dec 7, 2009 at 1:43 PM, Bradley Nelson bradnel...@google.com
 wrote:
  Hello All,
  Last week I re-landed a change to split off parts of chrome.gyp into
 .gypi's
  in the same directory.
  I had done something similar a couple weeks back, but took it out because
  concern was raised about merge conflicts in m4.
  I put it back in because I got the all clear on m4.
  The goal is to reduce contention on chrome.gyp which has gotten quite
 large
  - 7000+ lines.

 I just tried to add a file to chrome.gyp and I couldn't find where it
 should go. It took me a minute to remember this thread.

 I'm concerned our build system is getting out of control. I can not
 explain in simple sentences where anything should go. Even if I'm
 using my visual tool and find the right project, the only real way to
 find where a file should go is to grep for files nearby. .gyp files
 already had this property where you can't find where things should go
 in them and you needed to search. Now it seems like we've added an
 additional layer of you don't know which file its in, either.

 How much does this solve contention? It seems like actual conflicts
 for changes will be the same as before. What contention cases are
 there that splitting everything out helps a lot?

 Thanks
 Brett

 PS Thanks for working on the build system, I don't mean to be
 non-appreciative.

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


-- 
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?

2009-12-10 Thread Evan Stade

On Thu, Dec 10, 2009 at 10:58 AM, Peter Kasting pkast...@google.com wrote:

 On Thu, Dec 10, 2009 at 10:45 AM, Jonathan Dixon j...@chromium.orgwrote:

 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.


disagree. It's harder to read because it's not immediately obvious that some
of the code overlaps. Scott's solution seems best to me.



 PK


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

[chromium-dev] buildbot failure in Chromium on Linux Builder (ChromiumOS), revision 34285

Automatically closing tree for compile on Linux Builder (ChromiumOS)

http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28ChromiumOS%29/builds/1213

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28ChromiumOS%29

--=  Automatically closing tree for compile on Linux Builder (ChromiumOS)  
=--

Revision: 34285
Blame list: est...@chromium.org

Buildbot waterfall: http://build.chromium.org/

-- 
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] Splitting off some pieces of chrome.gyp...

2009-12-10 Thread Evan Martin

On Thu, Dec 10, 2009 at 1:02 PM, oshima osh...@chromium.org wrote:
 I have similar concern about our build, in a way we handle different
 configurations.
 There are several ways to specify a set of files for different
 configurations, such as suffic (_gtk/_mac),
 source!, exclude/include, concat file lists, and I'm worrying that
 it's getting out of control.

I made some changes here recently to help more cleanup.  The suffix
rules are now all in build/common.gypi, so the per-project lists only
need tweaking when the suffix rules are wrong.  (In particular when
ChromeOS uses / doesn't use a _gtk file is never clear to me, but that
seems to be just because it's a work in progress.)

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

[chromium-dev] buildbot failure in Chromium on Chromium Builder (dbg), revision 34293

Automatically closing tree for compile on Chromium Builder (dbg)

http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/14559

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Builder%20%28dbg%29

--=  Automatically closing tree for compile on Chromium Builder (dbg)  =--

Revision: 34291, 34292, 34293
Blame list: est...@chromium.org,t...@chromium.org

Buildbot waterfall: http://build.chromium.org/

-- 
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 1:22 PM, Evan Stade est...@chromium.org wrote:

 On Thu, Dec 10, 2009 at 10:58 AM, Peter Kasting pkast...@google.comwrote:

 On Thu, Dec 10, 2009 at 10:45 AM, Jonathan Dixon j...@chromium.orgwrote:

 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.


 disagree. It's harder to read because it's not immediately obvious that
 some of the code overlaps. Scott's solution seems best to me.


+1 Scott's solution seems best for me.  The problem with the above solution
is that it contains code duplication.  For DoWork(foo), that might seem
small, but as parameters get added, functions get renamed, etc, it's more
work (and error prone) to update two locations instead of one.




 PK




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

[chromium-dev] Re: Building chromium for arm--erroring out

2009-12-10 Thread Joel Stanley

On Fri, Dec 11, 2009 at 04:08, Sofia Tahseen sofia.tahs...@gmail.com wrote:
 You are so right, Joel... I corrected my .so and now I could build the
 chrome browser ...finally!!

 I copied the whole /src/out/Release directory

While it's not important, that is unnecessary.  This directory
contains all of the object code, you only need the final binary.
Copying the following list of files should be sufficient, and save you
some time:

 chrome
 chrome.pak
 libffmpegsumo.so
 resources/
 locales/
 chrome-wrapper

 to my jaunty on the BeagleBoard(256MB RAM). I try to launch chrome through:
 ./chrome
 It starts up chrome, and then immediately kills chrome. I get an Illegal
 Instruction.

Jaunty targets the ARMv5 ISA, and you are building Chromium for ARMv7
(by including the armv7=1 flag).  I suspect you need to do one of the
following (not both):

 - run Karmic, which is built for ARMv7, on your BeagleBoard
 - omit the armv7=1 flag when building Chromium

As a data point: I regularly build and run Chromium targeting thumb2
(armv7=1 arm_thumb=1) on my BeagleBoard (RevB, 128MB RAM) running
Ubuntu Karmic.  It starts and can browse in multiple tabs.

Joel

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

[chromium-dev] speed or flakiness

2009-12-10 Thread Ojan Vafai

Summary:
We're increasing sharding for running webkit tests and it's increasing test
flakiness a bit.

1. Is the tradeoff of (hopefully) temporary increased flakiness worth the
speed gains? We retry these failures, so they rarely actually turn the bots
red,
2. The flakiness is temporary only if we fix it. Currently, as far as I
know, only Julie and I are fixing flaky webkit tests. There's a lot of
low-hanging fruit here. Tests with obvious race conditions. Anyone else
willing to help fixing these?

Details:
As we increase parallelism in the webkit tests, we greatly reduce cycle
times, but we also increase flakiness. I'm fairly convinced that, with the
exception of the http tests on Windows, nearly all of the flakiness results
from race conditions in the test itself and occasionally bugs in
Chrome/WebKit.

We currently shard webkit tests by directory in order to minimize flakiness.
The theory is that we run them in roughly the same order as upstream webkit
does that way. In order to minimize pain and flakiness we are gradually
sharding into smaller chunks. Initially, we sharded just the directories
under LayoutTests. Now we also shard the directories under fast, svg and (on
the Mac) http.

For example, sharding LayoutTests/fast made the webkit tests on the debug-2
bots 2x faster (~10 mins!). But it also exposed flakiness in ~10 tests. You
can see this by looking at
http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/flakiness_dashboard.html#builder=Webkit%20Linux%20(dbg)(2),
which used to have 2 flaky tests.

Ultimately, I think on machines with 8 hyperthreaded cores we are close to
getting the tests to run in 2 minutes.

Ojan

--
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] speed or flakiness

2009-12-10 Thread Eric Seidel

I expect that WebKit folks would be willing to help flight WebKit test
flakyness once we move more of our testing infrastructure into the
svn.webkit.org repository.

You might make a similar plea for help on webkit-dev, although I doubt
you'll get a super-positive response until webkit folks can help just
from their webkit.org checkout.

-eric

On Thu, Dec 10, 2009 at 3:52 PM, Ojan Vafai o...@chromium.org wrote:
Summary:
We're increasing sharding for running webkit tests and it's increasing test
flakiness a bit.
1. Is the tradeoff of (hopefully) temporary increased flakiness worth the
speed gains? We retry these failures, so they rarely actually turn the bots
red,
2. The flakiness is temporary only if we fix it. Currently, as far as I
know, only Julie and I are fixing flaky webkit tests. There's a lot of
low-hanging fruit here. Tests with obvious race conditions. Anyone else
willing to help fixing these?
Details:
As we increase parallelism in the webkit tests, we greatly reduce cycle
times, but we also increase flakiness. I'm fairly convinced that, with the
exception of the http tests on Windows, nearly all of the flakiness results
from race conditions in the test itself and occasionally bugs in
Chrome/WebKit.
We currently shard webkit tests by directory in order to minimize flakiness.
The theory is that we run them in roughly the same order as upstream webkit
does that way. In order to minimize pain and flakiness we are gradually
sharding into smaller chunks. Initially, we sharded just the directories
under LayoutTests. Now we also shard the directories under fast, svg and (on
the Mac) http.
For example, sharding LayoutTests/fast made the webkit tests on the debug-2
bots 2x faster (~10 mins!). But it also exposed flakiness in ~10 tests. You
can see this by looking
at http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/flakiness_dashboard.html#builder=Webkit%20Linux%20(dbg)(2),
which used to have 2 flaky tests.
Ultimately, I think on machines with 8 hyperthreaded cores we are close to
getting the tests to run in 2 minutes.
Ojan

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

[chromium-dev] Extensions and the Mac

Andy sent me a CL for review about an extension crashing (
http://crbug.com/29584). Turns out the cause was a failure to load a Windows
.dll on the Mac.

Huh? Then I went to look at the docs (
http://code.google.com/chrome/extensions/npapi.html):

{
  name: My extension,
  ...
  *plugins: [
{ path: content_plugin.dll, public: true },
{ path: extension_plugin.dll }

  ]*,
  ...
}

Are you kidding me? How can we get away with not specifying what platform
the extension will run on? (Hint: we can't.)

If we had something like:

plugins: {
  mac: ...
  win: ...
  linux: ...
}

then at least we could warn on the extensions website that a given extension
is only compatible with a certain platform. On a load attempt we could know
that the extension requires a certain native library and fail to load it
with a real user-friendly warning.

And developers could *make* extensions that are cross-platform compatible.

Today?
- We can't tell in advance what platforms an extensions runs on, so we can't
warn the user (either on the extensions site or in the app)
- The developer has no way of creating a cross-platform extension.

This is a *really* bad situation we've created. We need to get a new syntax
out for extensions to fix this, and soon, before world-breaking becomes
prohibitively expensive.

Avi

-- 
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: Extensions and the Mac

Filed http://code.google.com/p/chromium/issues/detail?id=30052 .

Avi

On Thu, Dec 10, 2009 at 7:03 PM, Avi Drissman a...@chromium.org wrote:

 Andy sent me a CL for review about an extension crashing (
 http://crbug.com/29584). Turns out the cause was a failure to load a
 Windows .dll on the Mac.

 Huh? Then I went to look at the docs (
 http://code.google.com/chrome/extensions/npapi.html):

 {
   name: My extension,
   ...
   *plugins: [
 { path: content_plugin.dll, public: true },
 { path: extension_plugin.dll }


   ]*,
   ...
 }

 Are you kidding me? How can we get away with not specifying what platform
 the extension will run on? (Hint: we can't.)

 If we had something like:

 plugins: {
   mac: ...
   win: ...
   linux: ...
 }

 then at least we could warn on the extensions website that a given
 extension is only compatible with a certain platform. On a load attempt we
 could know that the extension requires a certain native library and fail to
 load it with a real user-friendly warning.

 And developers could *make* extensions that are cross-platform compatible.

 Today?
 - We can't tell in advance what platforms an extensions runs on, so we
 can't warn the user (either on the extensions site or in the app)
 - The developer has no way of creating a cross-platform extension.

 This is a *really* bad situation we've created. We need to get a new
 syntax out for extensions to fix this, and soon, before world-breaking
 becomes prohibitively expensive.

 Avi


-- 
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] Extensions and the Mac

http://codereview.chromium.org/492012

So the design is for every platform to try to load all plugins. We don't
even want to have a hint that allows the website to say this is
Windows-only?

How about from the browser perspective? Is failure to load a library a fatal
error? (Sorry, we can't load this extension because it is damaged) Or is
it expected, since we're just likely hitting a library for a different
platform?

Avi

On Thu, Dec 10, 2009 at 7:12 PM, Aaron Boodman a...@google.com wrote:

 On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman a...@chromium.org wrote:
  Andy sent me a CL for review about an extension crashing
  (http://crbug.com/29584). Turns out the cause was a failure to load a
  Windows .dll on the Mac.

 We have had threads on this before. The consensus was that it was
 possible to simply fail to load incompatible plugins, without
 crashing. That is, that it should be possible for each platform to try
 and load all plugins, but they will only succeed in loading those that
 are meant for them.

 Can you point me to the CL?

 - a


-- 
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] Extensions and the Mac

2009-12-10 Thread Matt Perry

Yeah, that's very bad. I knew the NPAPI syntax sucked, but we punted on it
because we didn't like any of the alternatives. (Even if we do have a
manifest syntax for it, the extension package becomes bloated with plugin
binaries for other platforms.) But I didn't realize that it could cause a
crash. I'll definitely have to figure something out soon.

On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman a...@chromium.org wrote:

 Andy sent me a CL for review about an extension crashing (
 http://crbug.com/29584). Turns out the cause was a failure to load a
 Windows .dll on the Mac.

 Huh? Then I went to look at the docs (
 http://code.google.com/chrome/extensions/npapi.html):

 {
   name: My extension,
   ...
   *plugins: [
 { path: content_plugin.dll, public: true },
 { path: extension_plugin.dll }


   ]*,
   ...
 }

 Are you kidding me? How can we get away with not specifying what platform
 the extension will run on? (Hint: we can't.)

 If we had something like:

 plugins: {
   mac: ...
   win: ...
   linux: ...
 }

 then at least we could warn on the extensions website that a given
 extension is only compatible with a certain platform. On a load attempt we
 could know that the extension requires a certain native library and fail to
 load it with a real user-friendly warning.

 And developers could *make* extensions that are cross-platform compatible.

 Today?
 - We can't tell in advance what platforms an extensions runs on, so we
 can't warn the user (either on the extensions site or in the app)
 - The developer has no way of creating a cross-platform extension.

 This is a *really* bad situation we've created. We need to get a new
 syntax out for extensions to fix this, and soon, before world-breaking
 becomes prohibitively expensive.

 Avi

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

-- 
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] Extensions and the Mac

2009-12-10 Thread Mohamed Mansour

Can we at least deny installing the extension in Chromium if it contains
plugins that cannot be used in that operating system for now until a better
design for cross-platform manifest?

- Mohamed Mansour


On Thu, Dec 10, 2009 at 7:15 PM, Matt Perry mpcompl...@chromium.org wrote:

 Yeah, that's very bad. I knew the NPAPI syntax sucked, but we punted on it
 because we didn't like any of the alternatives. (Even if we do have a
 manifest syntax for it, the extension package becomes bloated with plugin
 binaries for other platforms.) But I didn't realize that it could cause a
 crash. I'll definitely have to figure something out soon.

 On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman a...@chromium.org wrote:

 Andy sent me a CL for review about an extension crashing (
 http://crbug.com/29584). Turns out the cause was a failure to load a
 Windows .dll on the Mac.

 Huh? Then I went to look at the docs (
 http://code.google.com/chrome/extensions/npapi.html):

 {
   name: My extension,
   ...
   *plugins: [
 { path: content_plugin.dll, public: true },
 { path: extension_plugin.dll }




   ]*,
   ...
 }

 Are you kidding me? How can we get away with not specifying what platform
 the extension will run on? (Hint: we can't.)

 If we had something like:

 plugins: {
   mac: ...
   win: ...
   linux: ...
 }

 then at least we could warn on the extensions website that a given
 extension is only compatible with a certain platform. On a load attempt we
 could know that the extension requires a certain native library and fail to
 load it with a real user-friendly warning.

 And developers could *make* extensions that are cross-platform
 compatible.

 Today?
 - We can't tell in advance what platforms an extensions runs on, so we
 can't warn the user (either on the extensions site or in the app)
 - The developer has no way of creating a cross-platform extension.

 This is a *really* bad situation we've created. We need to get a new
 syntax out for extensions to fix this, and soon, before world-breaking
 becomes prohibitively expensive.

 Avi

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


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


-- 
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] Extensions and the Mac

The crash is fixed. But the fact that we're now expecting random dll loads
to fail prevents us from giving good UI to users, and not labelling what
platforms it'll work on prevents us from warning in advance.

Imagine a million angry Mac and Linux users filing bugs because their
favorite extension fails to fully load because it relies on an NPAPI plugin
not available on their platform.

Avi

On Thu, Dec 10, 2009 at 7:15 PM, Matt Perry mpcompl...@chromium.org wrote:

 Yeah, that's very bad. I knew the NPAPI syntax sucked, but we punted on it
 because we didn't like any of the alternatives. (Even if we do have a
 manifest syntax for it, the extension package becomes bloated with plugin
 binaries for other platforms.) But I didn't realize that it could cause a
 crash. I'll definitely have to figure something out soon.

 On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman a...@chromium.org wrote:

  Andy sent me a CL for review about an extension crashing (
 http://crbug.com/29584). Turns out the cause was a failure to load a
 Windows .dll on the Mac.

 Huh? Then I went to look at the docs (
 http://code.google.com/chrome/extensions/npapi.html):

 {
   name: My extension,
   ...
   *plugins: [
 { path: content_plugin.dll, public: true },
 { path: extension_plugin.dll }




   ]*,
   ...
 }

 Are you kidding me? How can we get away with not specifying what platform
 the extension will run on? (Hint: we can't.)

 If we had something like:

 plugins: {
   mac: ...
   win: ...
   linux: ...
 }

 then at least we could warn on the extensions website that a given
 extension is only compatible with a certain platform. On a load attempt we
 could know that the extension requires a certain native library and fail to
 load it with a real user-friendly warning.

 And developers could *make* extensions that are cross-platform
 compatible.

 Today?
 - We can't tell in advance what platforms an extensions runs on, so we
 can't warn the user (either on the extensions site or in the app)
 - The developer has no way of creating a cross-platform extension.

 This is a *really* bad situation we've created. We need to get a new
 syntax out for extensions to fix this, and soon, before world-breaking
 becomes prohibitively expensive.

 Avi

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




-- 
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] Extensions and the Mac

Can we have the syntax say platform x loads x.dll, platform y loads y.so,
etc?

If a dll required by a platform fails to load, we need to alert the user
that their extension is busted. The prospect of having failure to load
binaries be an expected thing scares me.

Avi

On Thu, Dec 10, 2009 at 7:25 PM, Aaron Boodman a...@google.com wrote:

 It is good that we can avoid the crash. We do need to get some kind of
 syntax in the manifest.

 - a

 On Thu, Dec 10, 2009 at 4:18 PM, Avi Drissman a...@google.com wrote:
  The crash is fixed. But the fact that we're now expecting random dll
 loads
  to fail prevents us from giving good UI to users, and not labelling what
  platforms it'll work on prevents us from warning in advance.
 
  Imagine a million angry Mac and Linux users filing bugs because their
  favorite extension fails to fully load because it relies on an NPAPI
 plugin
  not available on their platform.
 
  Avi
 
  On Thu, Dec 10, 2009 at 7:15 PM, Matt Perry mpcompl...@chromium.org
 wrote:
 
  Yeah, that's very bad. I knew the NPAPI syntax sucked, but we punted on
 it
  because we didn't like any of the alternatives. (Even if we do have a
  manifest syntax for it, the extension package becomes bloated with
 plugin
  binaries for other platforms.) But I didn't realize that it could cause
 a
  crash. I'll definitely have to figure something out soon.
 
  On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman a...@chromium.org wrote:
 
  Andy sent me a CL for review about an extension crashing
  (http://crbug.com/29584). Turns out the cause was a failure to load a
  Windows .dll on the Mac.
 
  Huh? Then I went to look at the docs
  (http://code.google.com/chrome/extensions/npapi.html):
 
  {
name: My extension,
...
plugins: [
  { path: content_plugin.dll, public: true },
  { path: extension_plugin.dll }
 
 
 
 
 
],
...
  }
 
  Are you kidding me? How can we get away with not specifying what
 platform
  the extension will run on? (Hint: we can't.)
 
  If we had something like:
 
  plugins: {
mac: ...
win: ...
linux: ...
  }
 
  then at least we could warn on the extensions website that a given
  extension is only compatible with a certain platform. On a load attempt
 we
  could know that the extension requires a certain native library and
 fail to
  load it with a real user-friendly warning.
 
  And developers could make extensions that are cross-platform
 compatible.
 
  Today?
  - We can't tell in advance what platforms an extensions runs on, so we
  can't warn the user (either on the extensions site or in the app)
  - The developer has no way of creating a cross-platform extension.
 
  This is a really bad situation we've created. We need to get a new
 syntax
  out for extensions to fix this, and soon, before world-breaking becomes
  prohibitively expensive.
 
  Avi
 
  --
  Chromium Developers mailing list: chromium-dev@googlegroups.com
  View archives, change email options, or unsubscribe:
  http://groups.google.com/group/chromium-dev
 
  --
  Chromium Developers mailing list: chromium-dev@googlegroups.com
  View archives, change email options, or unsubscribe:
  http://groups.google.com/group/chromium-dev


-- 
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] Extensions and the Mac

On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman a...@chromium.org wrote:
 Andy sent me a CL for review about an extension crashing
 (http://crbug.com/29584). Turns out the cause was a failure to load a
 Windows .dll on the Mac.

We have had threads on this before. The consensus was that it was
possible to simply fail to load incompatible plugins, without
crashing. That is, that it should be possible for each platform to try
and load all plugins, but they will only succeed in loading those that
are meant for them.

Can you point me to the CL?

- a

-- 
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] Extensions and the Mac

On Thu, Dec 10, 2009 at 4:27 PM, Avi Drissman a...@google.com wrote:
 Can we have the syntax say platform x loads x.dll, platform y loads y.so,
 etc?

Yes that is the idea.

 If a dll required by a platform fails to load, we need to alert the user
 that their extension is busted. The prospect of having failure to load
 binaries be an expected thing scares me.

Agree.

- a

-- 
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] Extensions and the Mac

It is good that we can avoid the crash. We do need to get some kind of
syntax in the manifest.

- a

On Thu, Dec 10, 2009 at 4:18 PM, Avi Drissman a...@google.com wrote:
 The crash is fixed. But the fact that we're now expecting random dll loads
 to fail prevents us from giving good UI to users, and not labelling what
 platforms it'll work on prevents us from warning in advance.

 Imagine a million angry Mac and Linux users filing bugs because their
 favorite extension fails to fully load because it relies on an NPAPI plugin
 not available on their platform.

 Avi

 On Thu, Dec 10, 2009 at 7:15 PM, Matt Perry mpcompl...@chromium.org wrote:

 Yeah, that's very bad. I knew the NPAPI syntax sucked, but we punted on it
 because we didn't like any of the alternatives. (Even if we do have a
 manifest syntax for it, the extension package becomes bloated with plugin
 binaries for other platforms.) But I didn't realize that it could cause a
 crash. I'll definitely have to figure something out soon.

 On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman a...@chromium.org wrote:

 Andy sent me a CL for review about an extension crashing
 (http://crbug.com/29584). Turns out the cause was a failure to load a
 Windows .dll on the Mac.

 Huh? Then I went to look at the docs
 (http://code.google.com/chrome/extensions/npapi.html):

 {
   name: My extension,
   ...
   plugins: [
 { path: content_plugin.dll, public: true },
 { path: extension_plugin.dll }





   ],
   ...
 }

 Are you kidding me? How can we get away with not specifying what platform
 the extension will run on? (Hint: we can't.)

 If we had something like:

 plugins: {
   mac: ...
   win: ...
   linux: ...
 }

 then at least we could warn on the extensions website that a given
 extension is only compatible with a certain platform. On a load attempt we
 could know that the extension requires a certain native library and fail to
 load it with a real user-friendly warning.

 And developers could make extensions that are cross-platform compatible.

 Today?
 - We can't tell in advance what platforms an extensions runs on, so we
 can't warn the user (either on the extensions site or in the app)
 - The developer has no way of creating a cross-platform extension.

 This is a really bad situation we've created. We need to get a new syntax
 out for extensions to fix this, and soon, before world-breaking becomes
 prohibitively expensive.

 Avi

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

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

-- 
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] Extensions and the Mac

2009-12-10 Thread Evan Martin

On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman a...@chromium.org wrote:
 If we had something like:

 plugins: {
   mac: ...
   win: ...
   linux: ...
 }

FWIW, one reason to avoid this sort of thing is that there is really
no single thing called linux to target.  For example, because our
builds of Chrome off the buildbot are built against the Debian-derived
libnss so they will run on Debian and derivatives (Ubuntu, Mint) but
not any others (Fedora/SUSE/Gentoo/Arch/etc.) without hacks.  (I guess
you could have the manifest say you target LSB 3.2 or something.)
Distributing binaries on Linux = sadness, as the Flash guys will tell
you.

I imagine there are similar (though smaller scale) incompatibilities
between major revs of OS X and Windows.  Like say a plugin depends on
DirectX 17 which is only available on Windows 7.

In summary, all I offer you is more problems and the plea that we
should really really deter people from doing this kind of thing.  I
imagine a dystopian future where we have a per-extension appsupport
matrix on the install page (Works on x86-based ChromeOS but not
arm-based ChromeOS or whatever).

-- 
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] Extensions and the Mac

Is there a timetable? http://crbug.com/14936 has been Mstone-Xed since June.

Avi

On Thu, Dec 10, 2009 at 7:30 PM, Aaron Boodman a...@google.com wrote:

 On Thu, Dec 10, 2009 at 4:27 PM, Avi Drissman a...@google.com wrote:
  Can we have the syntax say platform x loads x.dll, platform y loads
 y.so,
  etc?

 Yes that is the idea.

  If a dll required by a platform fails to load, we need to alert the user
  that their extension is busted. The prospect of having failure to load
  binaries be an expected thing scares me.

 Agree.

 - a


-- 
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] Extensions and the Mac

On Thu, Dec 10, 2009 at 7:36 PM, Evan Martin ev...@google.com wrote:

 Distributing binaries on Linux = sadness, as the Flash guys will tell
 you.
 [...]
 In summary, all I offer you is more problems and the plea that we
 should really really deter people from doing this kind of thing.  I
 imagine a dystopian future where we have a per-extension appsupport
 matrix on the install page (Works on x86-based ChromeOS but not
 arm-based ChromeOS or whatever).


As much as I agree with everything you've said, I think the ship has already
sailed on this. We're already allowing binaries in extensions. Now we have
to figure out how to mitigate the pain.

Avi

-- 
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: Extensions and the Mac

2009-12-10 Thread Jo

Don't forget x64 user... ;)

On Dec 10, 7:03 pm, Avi Drissman a...@chromium.org wrote:
 plugins: {
   mac: ...
   win: ...
   linux: ...
 }

-- 
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] Extensions and the Mac

2009-12-10 Thread Ojan Vafai

On Thu, Dec 10, 2009 at 4:38 PM, Avi Drissman a...@google.com wrote:

 On Thu, Dec 10, 2009 at 7:36 PM, Evan Martin ev...@google.com wrote:

  Distributing binaries on Linux = sadness, as the Flash guys will tell
 you.
 [...]

 In summary, all I offer you is more problems and the plea that we
 should really really deter people from doing this kind of thing.  I
 imagine a dystopian future where we have a per-extension appsupport
 matrix on the install page (Works on x86-based ChromeOS but not
 arm-based ChromeOS or whatever).


 As much as I agree with everything you've said, I think the ship has
 already sailed on this. We're already allowing binaries in extensions. Now
 we have to figure out how to mitigate the pain.


I think we can wait to see what percentage of extensions actually include
binaries before devoting too much time to this. Our expectation is that this
will be a very small percentage, right?

Ojan



 Avi

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


-- 
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] Extensions and the Mac

On Thu, Dec 10, 2009 at 7:55 PM, Ojan Vafai o...@google.com wrote:

 I think we can wait to see what percentage of extensions actually include
 binaries before devoting too much time to this. Our expectation is that this
 will be a very small percentage, right?


Quick, look at
https://chrome.google.com/extensions/detail/pfhifmnkpieijjfdlmijncagohajdfmp.

Q: Can I install this on my Mac?
A: Sure, but it won't work, as it has an NPAPI dll.

Q: Can't we have the extensions gallery warn that it won't work?
A: Sorry, we can't do that in an automated fashion. The extensions author
should mention it. Too bad they don't.

Q: Can't we have the Chromium app warn that it won't work when it loads it?
A: Sorry, we can't do that in an automated fashion. The only notice that the
user will get when they have an extension that won't work on their platform
is that the extension malfunctions.

Avi

-- 
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] Extensions and the Mac

2009-12-10 Thread James Robinson

On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman a...@chromium.org wrote:

 Andy sent me a CL for review about an extension crashing (
 http://crbug.com/29584). Turns out the cause was a failure to load a
 Windows .dll on the Mac.

 Huh? Then I went to look at the docs (
 http://code.google.com/chrome/extensions/npapi.html):

 {
   name: My extension,
   ...
   *plugins: [
 { path: content_plugin.dll, public: true },
 { path: extension_plugin.dll }


   ]*,
   ...
 }

 Are you kidding me? How can we get away with not specifying what platform
 the extension will run on? (Hint: we can't.)


I believe the extension author can make this work - the .dll is not loaded
until the embed tag is processed, so a properly written extension could
sniff the host OS and then dynamically add an embed tag pointing at the
correct binary.  Simply specifying the .dll in the manifest is not
sufficient to trigger a load attempt.

In general extensions should _not_ use NPAPI and we should be discouraging
it as actively as possible but some things are impossible to do without
them, unfortunately.

- James


 If we had something like:

 plugins: {
   mac: ...
   win: ...
   linux: ...
 }

 then at least we could warn on the extensions website that a given
 extension is only compatible with a certain platform. On a load attempt we
 could know that the extension requires a certain native library and fail to
 load it with a real user-friendly warning.

 And developers could *make* extensions that are cross-platform compatible.

 Today?
 - We can't tell in advance what platforms an extensions runs on, so we
 can't warn the user (either on the extensions site or in the app)
 - The developer has no way of creating a cross-platform extension.

 This is a *really* bad situation we've created. We need to get a new
 syntax out for extensions to fix this, and soon, before world-breaking
 becomes prohibitively expensive.

 Avi

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

-- 
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] Extensions and the Mac

On Thu, Dec 10, 2009 at 8:00 PM, Ojan Vafai o...@chromium.org wrote:

 I think we can wait to see what percentage of extensions actually include
 binaries before devoting too much time to this. Our expectation is that this
 will be a very small percentage, right?


If we give people the capabilities, people will use them. I see that we
would *like* for this to be a very small percentage, but I don't see why
that would cause it to be so.

Avi

-- 
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] Extensions and the Mac

On Thu, Dec 10, 2009 at 5:02 PM, Avi Drissman a...@google.com wrote:

 Q: Can't we have the extensions gallery warn that it won't work?
 A: Sorry, we can't do that in an automated fashion. The extensions author
 should mention it. Too bad they don't.


But we explicitly review patches with binary components.  I can't see how it
could be impossible for us to also mark them as Win-only.

PK

-- 
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] Extensions and the Mac

2009-12-10 Thread James Robinson

On Thu, Dec 10, 2009 at 5:05 PM, Avi Drissman a...@google.com wrote:

 On Thu, Dec 10, 2009 at 8:00 PM, Ojan Vafai o...@chromium.org wrote:

 I think we can wait to see what percentage of extensions actually include
 binaries before devoting too much time to this. Our expectation is that this
 will be a very small percentage, right?


 If we give people the capabilities, people will use them. I see that we
 would *like* for this to be a very small percentage, but I don't see why
 that would cause it to be so.


NPAPI is a _massive_ pain to deal with especially compared to the ease of
use of building a webby extension.  Authors will probably tend towards using
NPAPI for extensions only when they really really have to, so if we can
ensure that the APIs for extensions are powerful enough for what extensions
want to be able to do the problem should mostly take care of itself.

- James



 Avi

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


-- 
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] Extensions and the Mac

We do? I didn't know that. Then we should enforce some kind of labeling.

Avi

On Thu, Dec 10, 2009 at 8:12 PM, Peter Kasting pkast...@google.com wrote:

 On Thu, Dec 10, 2009 at 5:02 PM, Avi Drissman a...@google.com wrote:

 Q: Can't we have the extensions gallery warn that it won't work?
 A: Sorry, we can't do that in an automated fashion. The extensions author
 should mention it. Too bad they don't.


 But we explicitly review patches with binary components.  I can't see how
 it could be impossible for us to also mark them as Win-only.

 PK


-- 
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] Extensions and the Mac

Or reject extensions that could be written without a NPAPI component.
 *ducks*

On Thu, Dec 10, 2009 at 5:12 PM, Peter Kasting pkast...@google.com wrote:

 On Thu, Dec 10, 2009 at 5:02 PM, Avi Drissman a...@google.com wrote:

 Q: Can't we have the extensions gallery warn that it won't work?
 A: Sorry, we can't do that in an automated fashion. The extensions author
 should mention it. Too bad they don't.


 But we explicitly review patches with binary components.  I can't see how
 it could be impossible for us to also mark them as Win-only.

 PK

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


-- 
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] Extensions and the Mac

Much of what can't be done on the web platform also can't be done inside the
NaCl sandbox.

On Thu, Dec 10, 2009 at 5:49 PM, John Abd-El-Malek
jabdelma...@google.comwrote:

 NaCl is the answer to all these problems...

 On Thu, Dec 10, 2009 at 5:15 PM, Jeremy Orlow jor...@google.com wrote:

 Or reject extensions that could be written without a NPAPI component.
  *ducks*

 On Thu, Dec 10, 2009 at 5:12 PM, Peter Kasting pkast...@google.comwrote:

 On Thu, Dec 10, 2009 at 5:02 PM, Avi Drissman a...@google.com wrote:

 Q: Can't we have the extensions gallery warn that it won't work?
 A: Sorry, we can't do that in an automated fashion. The extensions
 author should mention it. Too bad they don't.


 But we explicitly review patches with binary components.  I can't see how
 it could be impossible for us to also mark them as Win-only.

 PK

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


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




-- 
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] Extensions and the Mac

NaCl is the answer to all these problems...

On Thu, Dec 10, 2009 at 5:15 PM, Jeremy Orlow jor...@google.com wrote:

 Or reject extensions that could be written without a NPAPI component.
  *ducks*

 On Thu, Dec 10, 2009 at 5:12 PM, Peter Kasting pkast...@google.comwrote:

 On Thu, Dec 10, 2009 at 5:02 PM, Avi Drissman a...@google.com wrote:

 Q: Can't we have the extensions gallery warn that it won't work?
 A: Sorry, we can't do that in an automated fashion. The extensions author
 should mention it. Too bad they don't.


 But we explicitly review patches with binary components.  I can't see how
 it could be impossible for us to also mark them as Win-only.

 PK

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


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


-- 
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] Extensions and the Mac

The goal is to expose all this through Pepper.

On Thu, Dec 10, 2009 at 5:50 PM, Jeremy Orlow jor...@chromium.org wrote:

 Much of what can't be done on the web platform also can't be done inside
 the NaCl sandbox.


 On Thu, Dec 10, 2009 at 5:49 PM, John Abd-El-Malek jabdelma...@google.com
  wrote:

 NaCl is the answer to all these problems...

 On Thu, Dec 10, 2009 at 5:15 PM, Jeremy Orlow jor...@google.com wrote:

 Or reject extensions that could be written without a NPAPI component.
  *ducks*

 On Thu, Dec 10, 2009 at 5:12 PM, Peter Kasting pkast...@google.comwrote:

 On Thu, Dec 10, 2009 at 5:02 PM, Avi Drissman a...@google.com wrote:

 Q: Can't we have the extensions gallery warn that it won't work?
 A: Sorry, we can't do that in an automated fashion. The extensions
 author should mention it. Too bad they don't.


 But we explicitly review patches with binary components.  I can't see
 how it could be impossible for us to also mark them as Win-only.

 PK

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


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





-- 
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] Extensions and the Mac

Yes, extensions that include NPAPI are a very small minority. Last
time I checked there were something like 5. It is a way out for people
who already have binary code that they would like to reuse, or who
need to talk to the platform.

I don't see what the big deal is about a few extensions only
supporting a particular platform. As long as it is clear to users
(you're right, we need to do this), I think this is ok.

- 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] revised output for run_webkit_tests

2009-12-10 Thread Dirk Pranke

Hi all,

If you never run the webkit layout tests, you can stop reading.

Otherwise, earlier today I checked in a patch that should make the
output much less verbose in the normal case. From the CL:

First, a number of log messages have had their levels changed (mostly to
make them quieter).

Second, the script outputs a meter that shows progress through the
test run, which is a one line summary of where it's at current
(e.g. parsing expectations, gathering files. During the actual test
execution, the meter displays %d tests completed as expected, %d didn't,
%d remain. The meter uses carriage returns but no linefeeds, so the output
is overwritten as it progresses. The meter is disabled if --verbose is
specified, to avoid unnecessary confusion.

Third, I removed the --find-baselines option. I think I was the only one
using it, and --sources is good enough (but added the baseline for
the checksum as well as the .png when using --sources).

Fourth, there is a new --log option that can be used to provide finer
granularity of logging. It accepts a comma-separated list of options, like:
--log 'actual,expected,timing':

  actual: the actual test results (# of failures by type and timeline)
  config: the test settings (results dir, platform, etc.)
  expected: the results we expected by type and timeline
  timing: test timing results (slow files, total execution, etc.)

All of this information is logged at the logging.info level (if the
appropriate option is enabled).

Using the --verbose switch will cause all of options to be logged, as well
as the normal verbose output.  In addition, the verbose output will disable
the meter (as mentioned above). Note that the actual results will be logged
to stdout, not stderr, for compatibility with the buildbot log parser.

Finally, the list of unexpected results (if any) will be logged to stdout,
along with a one-line summary of the test run.

The net result is that when run with no command line options (and when no
tests fail), only one line of output will be produced.

Feedback / problems / questions to me.

Pam, sorry for making all of your examples in your tech talk
immediately out of date :)

-- Dirk

-- 
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] revised output for run_webkit_tests

2009-12-10 Thread David Levin

Have you considered making the output closer to that of WebKit's
run-webkit-tests?

It seems that would ease the hopeful transition to this version upstream.

dave

On Thu, Dec 10, 2009 at 7:23 PM, Dirk Pranke dpra...@chromium.org wrote:

 Hi all,

 If you never run the webkit layout tests, you can stop reading.

 Otherwise, earlier today I checked in a patch that should make the
 output much less verbose in the normal case. From the CL:

 First, a number of log messages have had their levels changed (mostly to
 make them quieter).

 Second, the script outputs a meter that shows progress through the
 test run, which is a one line summary of where it's at current
 (e.g. parsing expectations, gathering files. During the actual test
 execution, the meter displays %d tests completed as expected, %d didn't,
 %d remain. The meter uses carriage returns but no linefeeds, so the output
 is overwritten as it progresses. The meter is disabled if --verbose is
 specified, to avoid unnecessary confusion.

 Third, I removed the --find-baselines option. I think I was the only one
 using it, and --sources is good enough (but added the baseline for
 the checksum as well as the .png when using --sources).

 Fourth, there is a new --log option that can be used to provide finer
 granularity of logging. It accepts a comma-separated list of options, like:
 --log 'actual,expected,timing':

  actual: the actual test results (# of failures by type and timeline)
  config: the test settings (results dir, platform, etc.)
  expected: the results we expected by type and timeline
  timing: test timing results (slow files, total execution, etc.)

 All of this information is logged at the logging.info level (if the
 appropriate option is enabled).

 Using the --verbose switch will cause all of options to be logged, as well
 as the normal verbose output.  In addition, the verbose output will disable
 the meter (as mentioned above). Note that the actual results will be
 logged
 to stdout, not stderr, for compatibility with the buildbot log parser.

 Finally, the list of unexpected results (if any) will be logged to stdout,
 along with a one-line summary of the test run.

 The net result is that when run with no command line options (and when no
 tests fail), only one line of output will be produced.

 Feedback / problems / questions to me.

 Pam, sorry for making all of your examples in your tech talk
 immediately out of date :)

 -- Dirk

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


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

[chromium-dev] [WebGL] Recommending --no-sandbox

2009-12-10 Thread Darin Fisher

After reading the WebGL blog post today, and following the link to the wiki,
it struck me as fairly *bad* that we are telling people to disable the
sandbox.  A good number of folks are going to disable the sandbox and forget
that they had ever done so.

Once we can support WebGL in the sandbox, what will we do?  It would be nice
if we could somehow restore the sandbox automatically.  But renaming
--no-sandbox doesn't seem like a great choice, and it isn't a scalable
solution for other things like this that come up in the future.

Perhaps --enable-webgl should instead implicitly disable the sandbox today
so that tomorrow, when WebGL just works, folks won't have to change any
command line options to restore sandbox functionality.  I can see a counter
argument that people should have to explicitly opt-in to disabling the
sandbox, but I'm not sure that out-weighs the cost of having a good number
of dev channel users running *permanently* without the sandbox.

Was this idea considered?  Any other ideas?

-Darin

-- 
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] [WebGL] Recommending --no-sandbox

On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher da...@chromium.org wrote:

 Perhaps --enable-webgl should instead implicitly disable the sandbox today


I think this is better than having users manually disable it.  They'll be
running without a sandbox either way, but this (a) makes the enabling
process less error-prone and (b) makes it more likely the sandbox will get
turned back on eventually.

PK

-- 
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] [WebGL] Recommending --no-sandbox

On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher da...@chromium.org wrote:

 After reading the WebGL blog post today, and following the link to the
 wiki, it struck me as fairly *bad* that we are telling people to disable the
 sandbox.  A good number of folks are going to disable the sandbox and forget
 that they had ever done so.

 Once we can support WebGL in the sandbox, what will we do?  It would be
 nice if we could somehow restore the sandbox automatically.  But renaming
 --no-sandbox doesn't seem like a great choice, and it isn't a scalable
 solution for other things like this that come up in the future.

 Perhaps --enable-webgl should instead implicitly disable the sandbox today
 so that tomorrow, when WebGL just works, folks won't have to change any
 command line options to restore sandbox functionality.  I can see a counter
 argument that people should have to explicitly opt-in to disabling the
 sandbox, but I'm not sure that out-weighs the cost of having a good number
 of dev channel users running *permanently* without the sandbox.

 Was this idea considered?  Any other ideas?


From a past thread on the subject:

On Thu, Oct 8, 2009 at 9:58 AM, Jeremy Orlow jor...@google.com wrote:

 For the record, I'm very against publicly telling people to turn off the
 sandbox if you want to check out this really cool feature.

 Somewhat related: Maybe we need to do something really scary looking when
 the Sanbox is disabled to impress upon users running that way that they're
 in a very dangerous state.  It could actually be useful to developers too;
 I've run without sandbox before and been very confused why things were
 working when they shouldn't be.


I still think this is the right solution.

-- 
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] [WebGL] Recommending --no-sandbox

On Thu, Dec 10, 2009 at 9:29 PM, Jeremy Orlow jor...@google.com wrote:

 On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher da...@chromium.org wrote:

 After reading the WebGL blog post today, and following the link to the
 wiki, it struck me as fairly *bad* that we are telling people to disable the
 sandbox.  A good number of folks are going to disable the sandbox and forget
 that they had ever done so.

 Once we can support WebGL in the sandbox, what will we do?  It would be
 nice if we could somehow restore the sandbox automatically.  But renaming
 --no-sandbox doesn't seem like a great choice, and it isn't a scalable
 solution for other things like this that come up in the future.

 Perhaps --enable-webgl should instead implicitly disable the sandbox today
 so that tomorrow, when WebGL just works, folks won't have to change any
 command line options to restore sandbox functionality.  I can see a counter
 argument that people should have to explicitly opt-in to disabling the
 sandbox, but I'm not sure that out-weighs the cost of having a good number
 of dev channel users running *permanently* without the sandbox.

 Was this idea considered?  Any other ideas?


 From a past thread on the subject:

 On Thu, Oct 8, 2009 at 9:58 AM, Jeremy Orlow jor...@google.com wrote:

 For the record, I'm very against publicly telling people to turn off the
 sandbox if you want to check out this really cool feature.

 Somewhat related: Maybe we need to do something really scary looking when
 the Sanbox is disabled to impress upon users running that way that they're
 in a very dangerous state.  It could actually be useful to developers too;
 I've run without sandbox before and been very confused why things were
 working when they shouldn't be.


 I still think this is the right solution.


Oh, and I filed this:
http://code.google.com/p/chromium/issues/detail?id=24411

To be clear, I think this is the right solution because 1) some people might
have already disabled the sandbox and forgotten about it  and 2) in
that interterm period, some people will just leave the flag on and they'll
be insecure.

I do agree that your suggestion is better than the status quo tho.  And it's
something we could do immediately.  Of course, by the time the next dev
channel build is out there (and thus we can change the instructions) it
seems as though most of the damage will have already been done.

J

-- 
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] [WebGL] Recommending --no-sandbox

We disable --single-process and --in-process-plugins on release Google
Chrome builds to avoid the support headache that it causes.  I think we
should do the same for --no-sandbox.

On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher da...@chromium.org wrote:

 After reading the WebGL blog post today, and following the link to the
 wiki, it struck me as fairly *bad* that we are telling people to disable the
 sandbox.  A good number of folks are going to disable the sandbox and forget
 that they had ever done so.

 Once we can support WebGL in the sandbox, what will we do?  It would be
 nice if we could somehow restore the sandbox automatically.  But renaming
 --no-sandbox doesn't seem like a great choice, and it isn't a scalable
 solution for other things like this that come up in the future.

 Perhaps --enable-webgl should instead implicitly disable the sandbox today
 so that tomorrow, when WebGL just works, folks won't have to change any
 command line options to restore sandbox functionality.  I can see a counter
 argument that people should have to explicitly opt-in to disabling the
 sandbox, but I'm not sure that out-weighs the cost of having a good number
 of dev channel users running *permanently* without the sandbox.

 Was this idea considered?  Any other ideas?

 -Darin

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

-- 
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] [WebGL] Recommending --no-sandbox

2009-12-10 Thread Finnur Thorarinsson

I wonder... should we show an infobar on startup when the sandbox is
disabled?

On Thu, Dec 10, 2009 at 21:38, John Abd-El-Malek j...@chromium.org wrote:

 We disable --single-process and --in-process-plugins on release Google
 Chrome builds to avoid the support headache that it causes.  I think we
 should do the same for --no-sandbox.

 On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher da...@chromium.org wrote:

 After reading the WebGL blog post today, and following the link to the
 wiki, it struck me as fairly *bad* that we are telling people to disable the
 sandbox.  A good number of folks are going to disable the sandbox and forget
 that they had ever done so.

 Once we can support WebGL in the sandbox, what will we do?  It would be
 nice if we could somehow restore the sandbox automatically.  But renaming
 --no-sandbox doesn't seem like a great choice, and it isn't a scalable
 solution for other things like this that come up in the future.

 Perhaps --enable-webgl should instead implicitly disable the sandbox today
 so that tomorrow, when WebGL just works, folks won't have to change any
 command line options to restore sandbox functionality.  I can see a counter
 argument that people should have to explicitly opt-in to disabling the
 sandbox, but I'm not sure that out-weighs the cost of having a good number
 of dev channel users running *permanently* without the sandbox.

 Was this idea considered?  Any other ideas?

 -Darin

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


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


-- 
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] [WebGL] Recommending --no-sandbox

2009-12-10 Thread Mohamed Mansour

That would be nice to have. Everyone agrees that is a critical option to
turn on, so a light red tone info bar would be great for that.

-Mohamed Mansour


On Fri, Dec 11, 2009 at 12:49 AM, Finnur Thorarinsson
fin...@chromium.orgwrote:

 I wonder... should we show an infobar on startup when the sandbox is
 disabled?


 On Thu, Dec 10, 2009 at 21:38, John Abd-El-Malek j...@chromium.org wrote:

 We disable --single-process and --in-process-plugins on release Google
 Chrome builds to avoid the support headache that it causes.  I think we
 should do the same for --no-sandbox.

 On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher da...@chromium.org wrote:

 After reading the WebGL blog post today, and following the link to the
 wiki, it struck me as fairly *bad* that we are telling people to disable the
 sandbox.  A good number of folks are going to disable the sandbox and forget
 that they had ever done so.

 Once we can support WebGL in the sandbox, what will we do?  It would be
 nice if we could somehow restore the sandbox automatically.  But renaming
 --no-sandbox doesn't seem like a great choice, and it isn't a scalable
 solution for other things like this that come up in the future.

 Perhaps --enable-webgl should instead implicitly disable the sandbox
 today so that tomorrow, when WebGL just works, folks won't have to change
 any command line options to restore sandbox functionality.  I can see a
 counter argument that people should have to explicitly opt-in to disabling
 the sandbox, but I'm not sure that out-weighs the cost of having a good
 number of dev channel users running *permanently* without the sandbox.

 Was this idea considered?  Any other ideas?

 -Darin

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


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


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


-- 
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] revised output for run_webkit_tests

2009-12-10 Thread Dirk Pranke

Yes, I did consider that. The fatal flaw in that plan is that the
webkit test script is single-threaded and runs through the tests in
order. Ours doesn't, and so we can't easily guarantee the same sort of
output they have. Eric and I will probably work through this as we
upstream the code. I'm actually hoping to get them to adopt my output,
but we'll see.

-- Dirk

On Thu, Dec 10, 2009 at 7:45 PM, David Levin le...@chromium.org wrote:
 Have you considered making the output closer to that of WebKit's
 run-webkit-tests?
 It seems that would ease the hopeful transition to this version upstream.
 dave
 On Thu, Dec 10, 2009 at 7:23 PM, Dirk Pranke dpra...@chromium.org wrote:

 Hi all,

 If you never run the webkit layout tests, you can stop reading.

 Otherwise, earlier today I checked in a patch that should make the
 output much less verbose in the normal case. From the CL:

 First, a number of log messages have had their levels changed (mostly to
 make them quieter).

 Second, the script outputs a meter that shows progress through the
 test run, which is a one line summary of where it's at current
 (e.g. parsing expectations, gathering files. During the actual test
 execution, the meter displays %d tests completed as expected, %d didn't,
 %d remain. The meter uses carriage returns but no linefeeds, so the
 output
 is overwritten as it progresses. The meter is disabled if --verbose is
 specified, to avoid unnecessary confusion.

 Third, I removed the --find-baselines option. I think I was the only one
 using it, and --sources is good enough (but added the baseline for
 the checksum as well as the .png when using --sources).

 Fourth, there is a new --log option that can be used to provide finer
 granularity of logging. It accepts a comma-separated list of options,
 like:
 --log 'actual,expected,timing':

  actual: the actual test results (# of failures by type and timeline)
  config: the test settings (results dir, platform, etc.)
  expected: the results we expected by type and timeline
  timing: test timing results (slow files, total execution, etc.)

 All of this information is logged at the logging.info level (if the
 appropriate option is enabled).

 Using the --verbose switch will cause all of options to be logged, as well
 as the normal verbose output.  In addition, the verbose output will
 disable
 the meter (as mentioned above). Note that the actual results will be
 logged
 to stdout, not stderr, for compatibility with the buildbot log parser.

 Finally, the list of unexpected results (if any) will be logged to stdout,
 along with a one-line summary of the test run.

 The net result is that when run with no command line options (and when no
 tests fail), only one line of output will be produced.

 Feedback / problems / questions to me.

 Pam, sorry for making all of your examples in your tech talk
 immediately out of date :)

 -- Dirk

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



-- 
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] [WebGL] Recommending --no-sandbox

On Thu, Dec 10, 2009 at 9:38 PM, John Abd-El-Malek j...@chromium.org wrote:

 We disable --single-process and --in-process-plugins on release Google
 Chrome builds to avoid the support headache that it causes.  I think we
 should do the same for --no-sandbox.


There are legit reasons we have asked users to try temporarily disabling the
sandbox, more frequently than for those other flags.  I'd prefer to just
make the UI turn ugly a la Jeremy's bug.

PK

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

[chromium-dev] buildbot failure in Chromium on Webkit Linux (valgrind), revision 34333

Automatically closing tree for compile on Webkit Linux (valgrind)

http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Linux%20%28valgrind%29/builds/7715

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20Linux%20%28valgrind%29

--=  Automatically closing tree for compile on Webkit Linux (valgrind)  
=--

Revision: 34333
Blame list: yu...@chromium.org

Buildbot waterfall: http://build.chromium.org/

-- 
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] [WebGL] Recommending --no-sandbox

On Thu, Dec 10, 2009 at 10:57 PM, Jeremy Orlow jor...@chromium.org wrote:

 On Thu, Dec 10, 2009 at 10:25 PM, Peter Kasting pkast...@google.comwrote:

 On Thu, Dec 10, 2009 at 9:38 PM, John Abd-El-Malek j...@chromium.orgwrote:

 We disable --single-process and --in-process-plugins on release Google
 Chrome builds to avoid the support headache that it causes.  I think we
 should do the same for --no-sandbox.


 There are legit reasons we have asked users to try temporarily disabling
 the sandbox, more frequently than for those other flags.  I'd prefer to just
 make the UI turn ugly a la Jeremy's bug.


 It might even make sense to re-enable --single-process and use the same UI
 technique to discourage it.


--single-process is buggy and not well tested, and can cause deadlocks in
some scenarios.

I think only developers should run without the sandbox, as those are the
ones who'd be able to understand the risks in doing so, and are the only
ones who need to test out features like webgl that aren't ready yet.  So I
still think we should disable --no-sandbox in shipping Google Chrome builds,
and if someone needs it, they can use Chromium builds.

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

[chromium-dev] buildbot failure in Chromium on Webkit Mac10.5 (dbg)(3), revision 34335