Re: [webkit-dev] If you like writing memory smashers, you'll love this

2014-12-16 Thread Mark Rowe

 On Dec 16, 2014, at 10:47, Geoffrey Garen gga...@apple.com wrote:
 
 As of r177317, FastMalloc can be disabled at runtime. This means that you 
 can use system memory analysis tools like GuardMalloc, MallocScribble, 
 Instruments allocation tracking, leaks, and heap to debug memory issues in 
 WebKit nightly builds, spade builds, and release builds.
 
 Is this in reference to bmalloc?
 
 Yes.
 
 Instruments allocation tracking, leaks, and heap were supported with 
 TCMalloc-based FastMalloc for quite some time.
 
 I think you’re remembering that TCMalloc supported malloc zone introspection? 
 Yes, it did — and bmalloc doesn’t.
 
 But zone introspection isn’t enough to get malloc/free backtraces, which is 
 what you need in order to to do leaks analysis and allocation tracking. (And, 
 of course, TCMalloc didn’t support scribbling, guard edges, guard malloc, and 
 so on.)

http://trac.webkit.org/changeset/153767 
http://trac.webkit.org/changeset/153767. It’s somewhat academic though since 
bmalloc is what is in use on tip of tree.

Do we intend to move the remaining ports over to bmalloc so we can remove 
TCMalloc from the tree?

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] If you like writing memory smashers, you'll love this

2014-12-15 Thread Mark Rowe

 On Dec 15, 2014, at 17:31, Geoffrey Garen gga...@apple.com wrote:
 
 As of r177317, FastMalloc can be disabled at runtime. This means that you can 
 use system memory analysis tools like GuardMalloc, MallocScribble, 
 Instruments allocation tracking, leaks, and heap to debug memory issues in 
 WebKit nightly builds, spade builds, and release builds.

Is this in reference to bmalloc? Instruments allocation tracking, leaks, and 
heap were supported with TCMalloc-based FastMalloc for quite some time.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Downtime for Bugzilla upgrade on Thursday, October 16 from 8-10 AM PDT

2014-10-17 Thread Mark Rowe

 On Oct 17, 2014, at 03:52, Osztrogonác Csaba o...@inf.u-szeged.hu wrote:
 
 Hi,
 
 On 2014-10-17 12:42, Sergio Villar Senin wrote:
 Could the format of bz emails be changed? The new one with those huge
 tables on top and tiny fonts for the bug comments are pretty difficult
 to process.
 
 You can change the Preferred email format to text only here:
 https://bugs.webkit.org/userprefs.cgi?tab=settings
 
 I already did it. ;)

I went looking for such a setting yesterday but didn’t find it since I expected 
that it’d live on the “Email Preferences” page of settings. Thanks for pointing 
out where it is!

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Mac WK1 EWS bots having issues

2014-08-15 Thread Mark Rowe

 On Aug 15, 2014, at 02:10, Osztrogonác Csaba o...@inf.u-szeged.hu wrote:
 
 Hi,
 
 it seems the Apple Mac WK1 EWS bots have problems:
 http://webkit-queues.appspot.com/queue-status/mac-ews
 
 Last Pass: 11 hours, 57 minutes ago by webkit-ews-01
 Unable to pass tests without patch (tree is red?)
 
 Regressions: Unexpected text-only failures (30)
  compositing/plugins/composited-plugin.html [ Failure ]
  compositing/plugins/no-backing-store.html [ Failure ]
  compositing/plugins/small-to-large-composited-plugin.html [ Failure ]
  fast/frames/sandboxed-iframe-about-blank.html [ Failure ]
  fast/frames/sandboxed-iframe-navigation-allowed.html [ Failure ]
  fast/frames/sandboxed-iframe-plugins.html [ Failure ]
  fast/replaced/invalid-object-with-fallback.html [ Failure ]
  fullscreen/full-screen-plugin.html [ Failure ]
  http/tests/plugins/create-v8-script-objects.html [ Failure ]
  http/tests/plugins/cross-frame-object-access.html [ Failure ]
  http/tests/plugins/get-url-beforeunload-destroys-plugin.html [ Failure
  platform/mac/plugins/convert-point.html [ Failure ]
  platform/mac/plugins/supports-carbon-event-model.html [ Failure ]
  platform/mac/plugins/testplugin-onnew-onpaint.html [ Failure ]
  plugins/destroy-during-npp-new.html [ Failure ]
  plugins/destroy-plugin-from-callback.html [ Failure ]
  plugins/npruntime/browser-object-identity.html [ Failure ]
  plugins/npruntime/construct.html [ Failure ]
  plugins/npruntime/delete-plugin-within-invoke.html [ Failure ]
  plugins/npruntime/embed-property-equality.html [ Failure ]
  plugins/npruntime/embed-property-iframe-equality.html [ Failure ]
  plugins/npruntime/embed-property.html [ Failure ]
  plugins/npruntime/enumerate.html [ Failure ]
  plugins/npruntime/evaluate.html [ Failure ]
  plugins/npruntime/get-int-identifier-special-values.html [ Failure ]
  plugins/npruntime/get-property-return-value.html [ Failure ]
  plugins/npruntime/identifier-conversion.html [ Failure ]
  plugins/npruntime/invoke-browserfuncs.html [ Failure ]
  plugins/npruntime/invoke-default.html [ Failure ]
  plugins/npruntime/invoke.html [ Failure ]
 
 It's so strange, because all (8) of the Mac WK1 EWS suffer
 from this issue, but there isn't any failure on the buildbots.
 How is it possible? I thought the buildbots and EWS bots
 have exactly the same configuration.
 
 Maybe https://trac.webkit.org/changeset/172608 is the culprit,
 because there weren't any other relevant patch that time.

The plug-in failures are due to http://trac.webkit.org/changeset/172595 
http://trac.webkit.org/changeset/172595. I’m working on a fix now. The 
reason the EWS is seeing it while the buildbots aren’t is due to the EWS 
performing clean builds every so often while the buildbots don’t.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Mac WK1 EWS bots having issues

2014-08-15 Thread Mark Rowe

 On Aug 15, 2014, at 09:22, Mark Rowe mr...@apple.com wrote:
 
 
 On Aug 15, 2014, at 02:10, Osztrogonác Csaba o...@inf.u-szeged.hu 
 mailto:o...@inf.u-szeged.hu wrote:
 
 Hi,
 
 it seems the Apple Mac WK1 EWS bots have problems:
 http://webkit-queues.appspot.com/queue-status/mac-ews 
 http://webkit-queues.appspot.com/queue-status/mac-ews
 
 Last Pass: 11 hours, 57 minutes ago by webkit-ews-01
 Unable to pass tests without patch (tree is red?)
 
 Regressions: Unexpected text-only failures (30)
  compositing/plugins/composited-plugin.html [ Failure ]
  compositing/plugins/no-backing-store.html [ Failure ]
  compositing/plugins/small-to-large-composited-plugin.html [ Failure ]
  fast/frames/sandboxed-iframe-about-blank.html [ Failure ]
  fast/frames/sandboxed-iframe-navigation-allowed.html [ Failure ]
  fast/frames/sandboxed-iframe-plugins.html [ Failure ]
  fast/replaced/invalid-object-with-fallback.html [ Failure ]
  fullscreen/full-screen-plugin.html [ Failure ]
  http/tests/plugins/create-v8-script-objects.html [ Failure ]
  http/tests/plugins/cross-frame-object-access.html [ Failure ]
  http/tests/plugins/get-url-beforeunload-destroys-plugin.html [ Failure
  platform/mac/plugins/convert-point.html [ Failure ]
  platform/mac/plugins/supports-carbon-event-model.html [ Failure ]
  platform/mac/plugins/testplugin-onnew-onpaint.html [ Failure ]
  plugins/destroy-during-npp-new.html [ Failure ]
  plugins/destroy-plugin-from-callback.html [ Failure ]
  plugins/npruntime/browser-object-identity.html [ Failure ]
  plugins/npruntime/construct.html [ Failure ]
  plugins/npruntime/delete-plugin-within-invoke.html [ Failure ]
  plugins/npruntime/embed-property-equality.html [ Failure ]
  plugins/npruntime/embed-property-iframe-equality.html [ Failure ]
  plugins/npruntime/embed-property.html [ Failure ]
  plugins/npruntime/enumerate.html [ Failure ]
  plugins/npruntime/evaluate.html [ Failure ]
  plugins/npruntime/get-int-identifier-special-values.html [ Failure ]
  plugins/npruntime/get-property-return-value.html [ Failure ]
  plugins/npruntime/identifier-conversion.html [ Failure ]
  plugins/npruntime/invoke-browserfuncs.html [ Failure ]
  plugins/npruntime/invoke-default.html [ Failure ]
  plugins/npruntime/invoke.html [ Failure ]
 
 It's so strange, because all (8) of the Mac WK1 EWS suffer
 from this issue, but there isn't any failure on the buildbots.
 How is it possible? I thought the buildbots and EWS bots
 have exactly the same configuration.
 
 Maybe https://trac.webkit.org/changeset/172608 is the culprit,
 because there weren't any other relevant patch that time.
 
 The plug-in failures are due to http://trac.webkit.org/changeset/172595 
 http://trac.webkit.org/changeset/172595. I’m working on a fix now. The 
 reason the EWS is seeing it while the buildbots aren’t is due to the EWS 
 performing clean builds every so often while the buildbots don’t.

There’s a fix up for review at https://bugs.webkit.org/show_bug.cgi?id=135979 
https://bugs.webkit.org/show_bug.cgi?id=135979.

- Mark


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] FeatureDefines.h and .xcconfig

2014-08-07 Thread Mark Rowe

 On Aug 7, 2014, at 09:36, Maciej Stachowiak m...@apple.com wrote:
 
 
 On Aug 6, 2014, at 2:22 PM, Dean Jackson d...@apple.com wrote:
 
 Hi floks,
 
 Things are a bit confusing in the OS X and iOS build configurations because 
 we have both a FeatureDefines.h and a set of .xcconfig files, often defining 
 the same thing, and sometimes inconsistently (or at least I've made the 
 mistake of turning a feature off in one place when the other place turned it 
 back on).
 
 Obviously it would be good to have only one location for feature enabling.
 
 While FeatureDefines.h says Use this file to list _all_ ENABLE() macros it 
 also says The feature defaults in this file are only taken into account if 
 the (port specific) build system has not enabled or disabled a particular 
 feature, which is not true.
 
 My proposal is to stop using FeatureDefines.h for the Apple ports (*) and 
 move completely to .xcconfig files. 
 
 Notes:
 
 - Some scripts launched by Xcode might use the ENABLE_WHATEVER environment 
 variables (which FeatureDefines.h can't provide)
 
 - The xcconfig files will probably have to be of the form ENABLE_WHATEVER=0 
 to disable a feature, rather than just leaving it blank.
 
 - We'd have to change from #ifdef to #if in places.
 
 - You'd always have to edit 4 files to toggle a feature :(
 
 - Generating the FeatureDefines.xcconfig from FeatureDefines.h might be 
 cool, but we have a fair amount of release-specific logic in there (e.g. 
 only enabled on 10.9).
 
 Is this a terrible idea? Please suggest a better one!
 
 I’d like to propose the opposite: do all feature configuration in header 
 files, and none in port-specific build system files. .xconfig files have a 
 bunch of disadvantages. They are harder to find, harder to edit (since there 
 are multiple), harder to do conditionals in. It also makes it much harder to 
 figure out the feature flag settings for all ports, and to share common 
 defaults.
 
 If there are scripts depending on ENABLE flags, we should probably fix that. 
 If the scripts generate source, they could create source files with #ifdefs 
 in them instead of testing the flags themselves. Having scripts produce 
 different sources based on build-time settings is more likely to lead to bad 
 builds and broken dependencies, and should be avoided. I would like to know 
 which scripts actually depend on ENABLE_WHATEVER.

At a quick glance:

Source/WebCore/DerivedSources.make contains numerous tests of ENABLE flags 
which I’d guess could be eliminated as you suggest.

Source/WebCore/bindings/scripts/CodeGeneratorObjC.pm appears to have at least 
one test of ENABLE flags, which is an interesting case since we can’t generate 
these #ifs in to the Objective-C DOM API headers.

The various CMake files used by other ports also contain a large number of 
tests of ENABLE flags to add search paths or link against different libraries 
when particular features are enabled. I’m not sure this can be avoided.

The JavaScriptCore Xcode project has script phases that do different work 
depending on whether or not ENABLE_FTL_JIT is set. It’s not sure this can be 
avoided.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Style proposal for branch style for macros

2014-04-20 Thread Mark Rowe

On Apr 19, 2014, at 13:09, Filip Pizlo fpi...@apple.com wrote:

 Hey everyone,
 
 When guarding code with macros that are always defined, such as 
 ASSERT_DISABLED (it's always either 0 or 1), we have a choice between:
 
   if (!ASSERT_DISABLED) {
   // do things
   }
 
 and:
 
 #if !ASSERT_DISABLED
   // do things
 #endif
 
 I'd like to propose that anytime the normal if would be semantically 
 equivalent to the preprocessor #if, the normal if should be used.
 
 We don't lose any compiler optimization, since even at -O0, the compiler will 
 constant fold the normal if.  We do gain a lot of clarity, since the control 
 flow of normal if statements is subject to proper indentation.
 
 The semantically equivalent requirement still allows for #if to be used for 
 thinngs like:
 
 - Guarding the placement of fields in a class.
 - Guarding the definitions of other macros (in the case of ASSERT_DISABLED, 
 we define ASSERT in different ways guarded by #if's)
 - Guarding the definition/declaration/inclusion of entire functions, classes, 
 and other top-level constructs.
 
 Thoughts?

It’d be one thing if we could adopt this approach everywhere, but as you note 
there are numerous situations in which it won’t compile. What’s worse is that 
there are situations in which it’ll silently give unintended behavior. It’s not 
clear to me what benefit you see this proposal bringing, and why it’d be worth 
the complexity that it adds. Given the lack of a compelling argument in favor 
of this change I’m firmly against it.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Style proposal for branch style for macros

2014-04-20 Thread Mark Rowe

On Apr 20, 2014, at 13:08, Filip Pizlo fpi...@apple.com wrote:

 
 
 On Apr 20, 2014, at 12:56 PM, Mark Rowe mr...@apple.com wrote:
 
 
 On Apr 19, 2014, at 13:09, Filip Pizlo fpi...@apple.com wrote:
 
 Hey everyone,
 
 When guarding code with macros that are always defined, such as 
 ASSERT_DISABLED (it's always either 0 or 1), we have a choice between:
 
 if (!ASSERT_DISABLED) {
 // do things
 }
 
 and:
 
 #if !ASSERT_DISABLED
 // do things
 #endif
 
 I'd like to propose that anytime the normal if would be semantically 
 equivalent to the preprocessor #if, the normal if should be used.
 
 We don't lose any compiler optimization, since even at -O0, the compiler 
 will constant fold the normal if.  We do gain a lot of clarity, since the 
 control flow of normal if statements is subject to proper indentation.
 
 The semantically equivalent requirement still allows for #if to be used 
 for thinngs like:
 
 - Guarding the placement of fields in a class.
 - Guarding the definitions of other macros (in the case of ASSERT_DISABLED, 
 we define ASSERT in different ways guarded by #if's)
 - Guarding the definition/declaration/inclusion of entire functions, 
 classes, and other top-level constructs.
 
 Thoughts?
 
 It’d be one thing if we could adopt this approach everywhere, but as you 
 note there are numerous situations in which it won’t compile. What’s worse 
 is that there are situations in which it’ll silently give unintended 
 behavior.
 
 Can you give an example of this?

Won’t compile:

if (!MAYBE_DEFINED) {
…
}

if (SOMETHING) {
void doSomething() { }
}

if (SOMETHING) {
#include “Something.h
}


Will result in unintended behavior:

if (!FOO) {
…
#define BAR
…
}


 It’s not clear to me what benefit you see this proposal bringing, and why 
 it’d be worth the complexity that it adds. Given the lack of a compelling 
 argument in favor of this change I’m firmly against it.
 
 I would be firmly against changing any of the existing if 
 (!ASSERT_DISABLED) into #if's as this would make already-gnarly JIT code 
 even harder to follow. 

So you’re only interested in the wider community’s opinion on this style 
proposal if they agree with you, and if not you’ll just ignore them and keep 
doing your own thing?

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Style proposal for branch style for macros

2014-04-20 Thread Mark Rowe

On Apr 19, 2014, at 13:36, Filip Pizlo fpi...@apple.com wrote:

 Here are some examples.
 
 Guarding a loop that does assertions:
 
 if (!ASSERT_DISABLED) {
 for (unsigned index = 0; index  m_generationInfo.size(); ++index) {
 GenerationInfo info = m_generationInfo[index];
 RELEASE_ASSERT(!info.alive());
 }
 }
 
 The one above comes from DFGSpeculativeJIT.cpp, and it is in a non-trivial 
 method.  Using an #if here would obfuscate the control flow and make the 
 method harder to maintain.  Arguably, a ASSERT would have been fine because 
 the compiler should be smart enough to kill the loop if the ASSERT is a 
 no-op.  I'm not sure all compilers would be smart enough, though - 
 particularly if m_generationInfo is any kind of interesting collection class.

How does using an #if obfuscate the control follow and make the method harder 
to maintain?

 Guarding code in the JIT that emits an assertion:
 
 if (!ASSERT_DISABLED) {
 JITCompiler::Jump ok = m_jit.branch32(
 JITCompiler::GreaterThanOrEqual, allocatorGPR, TrustedImm32(0));
 m_jit.breakpoint();
 ok.link(m_jit);
 }
 
 The one above also comes from the DFG JIT.  We have lots of code like this.  
 The assertions are very useful but obviously we don't want them in a release 
 build.  Using an #if would make the code harder to maintain.

How would using an #if make the code harder to maintain?

 Counterexample where we using an #if to guard an assertion in the JIT:
 
 #if !ASSERT_DISABLED
 SpeculateCellOperand op1(this, node-child1());
 JITCompiler::Jump isOK = m_jit.branchStructurePtr(
 JITCompiler::Equal, 
 JITCompiler::Address(op1.gpr(), JSCell::structureIDOffset()), 
 node-structure());
 m_jit.breakpoint();
 isOK.link(m_jit);
 #else
 speculateCell(node-child1());
 #endif
 
 Code like this is harder to understand, especially if the code being guarded 
 is longer than a page.  I don't think we should encourage this style, when it 
 would have been clearer to do:
 
 if (!ASSERT_DISABLED) {
 SpeculateCellOperand op1(this, node-child1());
 JITCompiler::Jump isOK = m_jit.branchStructurePtr(
 JITCompiler::Equal, 
 JITCompiler::Address(op1.gpr(), JSCell::structureIDOffset()), 
 node-structure());
 m_jit.breakpoint();
 isOK.link(m_jit);
 } else
 speculateCell(node-child1());

I disagree with your assertion that the latter is clearer. It’s certainly 
different, but how is it an improvement?

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Style proposal for branch style for macros

2014-04-20 Thread Mark Rowe

On Apr 20, 2014, at 13:19, Mark Rowe mr...@apple.com wrote:

 
 On Apr 20, 2014, at 13:08, Filip Pizlo fpi...@apple.com wrote:
 
 
 
 On Apr 20, 2014, at 12:56 PM, Mark Rowe mr...@apple.com wrote:
 
 
 On Apr 19, 2014, at 13:09, Filip Pizlo fpi...@apple.com wrote:
 
 Hey everyone,
 
 When guarding code with macros that are always defined, such as 
 ASSERT_DISABLED (it's always either 0 or 1), we have a choice between:
 
if (!ASSERT_DISABLED) {
// do things
}
 
 and:
 
 #if !ASSERT_DISABLED
// do things
 #endif
 
 I'd like to propose that anytime the normal if would be semantically 
 equivalent to the preprocessor #if, the normal if should be used.
 
 We don't lose any compiler optimization, since even at -O0, the compiler 
 will constant fold the normal if.  We do gain a lot of clarity, since the 
 control flow of normal if statements is subject to proper indentation.
 
 The semantically equivalent requirement still allows for #if to be used 
 for thinngs like:
 
 - Guarding the placement of fields in a class.
 - Guarding the definitions of other macros (in the case of 
 ASSERT_DISABLED, we define ASSERT in different ways guarded by #if's)
 - Guarding the definition/declaration/inclusion of entire functions, 
 classes, and other top-level constructs.
 
 Thoughts?
 
 It’d be one thing if we could adopt this approach everywhere, but as you 
 note there are numerous situations in which it won’t compile. What’s worse 
 is that there are situations in which it’ll silently give unintended 
 behavior. 
 
 Can you give an example of this?
 
 Won’t compile:
 
 if (!MAYBE_DEFINED) {
 …
 }
 
 if (SOMETHING) {
 void doSomething() { }
 }
 
 if (SOMETHING) {
 #include “Something.h
 }

It’s also not possible to determine from context alone whether #if or if should 
be used. When #if is used to remove members or functions you’re then forced to 
use #if, rather than if, around all uses of those members or functions since 
the alternative won’t compile.

An example lifted from Vector.h:

#if !ASSERT_DISABLED
templatetypename T struct ValueCheckVectorT {
typedef VectorT TraitType;
static void checkConsistency(const VectorT v)
{
v.checkConsistency();
}
};
#endif

templatetypename T, size_t inlineCapacity, typename OverflowHandler
inline void VectorT, inlineCapacity, OverflowHandler::checkConsistency()
{
if (!ASSERT_DISABLED) {
for (size_t i = 0; i  size(); ++i)
ValueCheckT::checkConsistency(at(i));
}
}


This won’t compile with assertions disabled because 
ValueCheck::checkConsistency doesn’t exist.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Style proposal for branch style for macros

2014-04-20 Thread Mark Rowe

On Apr 20, 2014, at 14:02, Filip Pizlo fpi...@apple.com wrote:

 The #if means that the code being guarded isn't indented. I believe that 
 indenting control flow is a good idea. 
 
 Also, using normal if's whenever it would compile and be semantically 
 equivalent means that the code being protected would benefit from 
 syntax/type/semantic checking even in a release build.

We use preprocessor defines to distinguish between many things besides debug 
and release builds, and in many cases it’s impossible to tell ahead of time 
whether the alternate paths will compile on all platforms. This is particularly 
true for code guarded by defines related to the compiler, target platform, or 
OS version, but is also a concern with feature defines where symbols have been 
#if’d out.

 I think of this as being analogous to our preference for static assertions: 
 we use them whenever we can but resort to dynamic assertions when we can't. 

I don’t think this is a great analogy. It’s usually clear from the context 
whether what you’re asserting is a compile-time or run-time concept, and thus 
whether a compile-time or run-time assertion is appropriate. It’s far from 
obvious whether all branches of an if will compile.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Style proposal for branch style for macros

2014-04-20 Thread Mark Rowe

On Apr 20, 2014, at 14:50, Filip Pizlo fpi...@apple.com wrote:

 
 
 On Apr 20, 2014, at 2:43 PM, Mark Rowe mr...@apple.com wrote:
 
 
 On Apr 20, 2014, at 14:02, Filip Pizlo fpi...@apple.com wrote:
 
 The #if means that the code being guarded isn't indented. I believe that 
 indenting control flow is a good idea. 
 
 Also, using normal if's whenever it would compile and be semantically 
 equivalent means that the code being protected would benefit from 
 syntax/type/semantic checking even in a release build.
 
 We use preprocessor defines to distinguish between many things besides debug 
 and release builds, and in many cases it’s impossible to tell ahead of time 
 whether the alternate paths will compile on all platforms. This is 
 particularly true for code guarded by defines related to the compiler, 
 target platform, or OS version, but is also a concern with feature defines 
 where symbols have been #if’d out.
 
 I think of this as being analogous to our preference for static assertions: 
 we use them whenever we can but resort to dynamic assertions when we can't.
 
 I don’t think this is a great analogy. It’s usually clear from the context 
 whether what you’re asserting is a compile-time or run-time concept, and 
 thus whether a compile-time or run-time assertion is appropriate. It’s far 
 from obvious whether all branches of an if will compile.
 
 In the cases that I'm concerned with, I don't care if the code guarded by 
 ASSERT_DISABLED will compile, only whether it will run. This is mostly, but 
 not entirely, different from CPU guards - even those may be dynamic like in 
 the case of tests for exotic SSE capabilities.

I’m not sure what you’re trying to say here. Surely you care that the code 
compiles without warnings, since otherwise you’d break the build. Can you 
elaborate on the difference you see between ASSERT_DISABLED checks and 
platform-related checks (OS, OS version, CPU architecture, etc), and what 
impact that difference has on your proposal?

 I don't think you can make a hard and fast rule based on the compile versus 
 run distinction. You can make one based on semantic equivalence (if it's 
 equivalent then avoid the preprocessor). So, I think that if the only goal 
 here was to make an enforceable rule then my proposal is somewhat better. 

I’m not sure exactly what you mean by semantic equivalence here. #if vs if 
inherently have different semantics.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Support for 10.8.5

2014-04-06 Thread Mark Rowe

On Apr 6, 2014, at 4:07, Rüdiger Cordes r...@opelgt.org wrote:

 Hello list,
  
 with Webkit r164187 the support of 10.8.5 is dropped.
  
 What is the reason for incompatibility?

If you’re seeing a problem with building or running on OS X 10.8.5, please file 
a bug report and provide details about the nature of the problem you’re seeing.

For what it’s worth, the Mountain Lion build bots (e.g., 
http://build.webkit.org/builders/Apple%20MountainLion%20Debug%20%28Build%29) 
appear to be building successfully.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] *.webkit.org downtime Tuesday, 3/11

2014-03-12 Thread Mark Rowe
I’ve just fixed both trac.webkit.org and git.webkit.org. Please let us know if 
you notice any further issues.

Thanks,

- Mark

On Mar 11, 2014, at 23:53, Osztrogonác Csaba o...@inf.u-szeged.hu wrote:

 Additionally git.webkit.org is stucked too on r165452.
 
 Osztrogonác Csaba írta:
 Hi,
 something is still wrong with trac.webkit.org, because it thinks
 that the newest commit is http://trac.webkit.org/changeset/165452 ,
 but the newest is r165460.
 Could you check what happened? Thanks.
 Ossy
 Lucas Forschler írta:
 Hello Webkit developers,
 
 Apple will be upgrading our network infrastructure starting Tuesday morning 
 at 8am.
 The webkit.org services will be affected for approximately 4 hours.
 
 This includes all *.webkit.org domains.  We expect them to be back online 
 before 12.
 
 Thanks,
 Lucas
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] How did Apple build libicucore.dylib?

2014-01-20 Thread Mark Rowe
Moving webkit-dev to BCC since this is off-topic for the list.

On Jan 10, 2014, at 13:45, Eric Wing ewmail...@gmail.com wrote:

 (I tried webkit-help but didn't get any responses, so I thought maybe
 this list might be more appropriate for this question. Sorry for the
 duplicate if otherwise.)
 
 I am attempting to build JavaScriptCore for my own embedded
 application use. I noticed that Mac and iOS JavaScriptCore have a
 dependency on a library called libicucore.
 
 When I build ICU myself from the , I get a handful of different icu
 libraries, but nothing named core.
 
 While I can get a working JavaScriptCore built against my ICU
 libraries (I need icuuc, icui18n, and icudata), my final binary size
 is huge due to the ICU libraries I link in. I tried statically linking
 my icu libraries, but the smallest my binary gets is about 30MB per
 architecture. When I dynamically link ICU, I can tell that the major
 contribution of the bloat is due to the ICU libraries.
 
 Looking at Apple's icucore binary, it is about 6.5MB for 3
 architectures which is tiny compared to my 3 icu libraries. I'm
 speculating that Apple ripped out all the stuff they don't need and
 merged in all the parts they do need into the single libicucore.
 
 Can somebody confirm this is what Apple did, and can somebody tell me
 how I can reproduce that? (I did try downloading Apple's 10.9 source
 for ICU from MacOSForge, but it built the normal ICU stuff and not
 libicucore, nor did I notice any special build options.)

Disclaimer: I know very little about ICU, this is just what I found from 
spending a few minutes looking at their source.

If you look at the http://www.opensource.apple.com/source/ICU/ICU-511.25/ you 
can see the Makefile used when building ICU. It functions as a wrapper around 
ICU’s regular build process. I think the key option to shrink the library size 
is --with-data-packaging=archive. This puts the ICU data tables in a standalone 
file (/usr/share/icu/icudt51l.dat) rather than embedding them in the library. 
You'll also find the logic for packaging things up in to a library named 
libicucore.dylib here.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Minimum supported Xcode version is changing

2013-09-20 Thread Mark Rowe

On 2013-09-20, at 12:59 PM, Bem Jones-Bey bjone...@adobe.com wrote:

 Did you fix it so that the build works on Mountain Lion when running Xcode 5? 
 As of yesterday, the tree didn't build on Mountain Lion with Xcode 5, with 
 the following linker error:
 
 Undefined symbols for architecture x86_64:
  __kCFURLCachePartitionKey, referenced from:
  _WKCachePartitionKey in 
 libWebKitSystemInterfaceMountainLion.a(WebKitSystemInterface.o)
  __CFHostIsDomainTopLevel, referenced from:
  _WKIsPublicSuffix in 
 libWebKitSystemInterfaceMountainLion.a(WebKitSystemInterface.o)

I’ve never been able to reproduce this error myself. The WebKit nightly builds 
have been built with Xcode 5 for the last week or two now without problems. If 
you can email me your entire output of build-webkit off-list I’ll see if I can 
spot what’s going awry.

- Mark


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Minimum supported Xcode version is changing

2013-09-20 Thread Mark Rowe
Hi all,

Just a friendly heads-up that the minimum supported Xcode version will be 
increasing to Xcode 4.6 later today. We’re doing this to ensure that WebKit is 
building with a compiler toolchain that supports all of the modern C++ features 
we care about. Xcode 4.6 has been available for several months so most people 
are already using it. If you're not, please take a few minutes to upgrade to 
the latest available Xcode version that is supported on your OS. For Lion 
users, this will mean visiting https://developer.apple.com/downloads/ to 
download Xcode 4.6.3. Mountain Lion users should upgrade directly to Xcode 5 
via the App Store.

Please let me know if you have any questions or concerns.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Minimum supported Xcode version is changing

2013-09-20 Thread Mark Rowe

On 2013-09-20, at 1:01 PM, Mark Rowe mr...@apple.com wrote:

 
 On 2013-09-20, at 12:59 PM, Bem Jones-Bey bjone...@adobe.com wrote:
 
 Did you fix it so that the build works on Mountain Lion when running Xcode 
 5? As of yesterday, the tree didn't build on Mountain Lion with Xcode 5, 
 with the following linker error:
 
 Undefined symbols for architecture x86_64:
 __kCFURLCachePartitionKey, referenced from:
 _WKCachePartitionKey in 
 libWebKitSystemInterfaceMountainLion.a(WebKitSystemInterface.o)
 __CFHostIsDomainTopLevel, referenced from:
 _WKIsPublicSuffix in 
 libWebKitSystemInterfaceMountainLion.a(WebKitSystemInterface.o)
 
 I’ve never been able to reproduce this error myself. The WebKit nightly 
 builds have been built with Xcode 5 for the last week or two now without 
 problems. If you can email me your entire output of build-webkit off-list 
 I’ll see if I can spot what’s going awry.

This should be fixed with r156218.

- Mark


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] ChangeLog format

2013-08-22 Thread Mark Rowe

On 2013-08-21, at 11:11 PM, Carlos Garcia Campos carlo...@webkit.org wrote:

 I see, I thought ChangeLog parser was used everywhere. So, I guess the
 solution would be to find a format most people like and adapt all
 scripts to it. I personally think it's not worth it, though. The oneline
 git log format is ok with the old commit message format IMO. If the only
 problem is that the bug number is not in the first line we can probably
 add it without adding the URL in angle brackets, something like:
 
 Bug 119872 - REGRESSION: Crash under JITCompiler::link while loading Gmail
 https://bugs.webkit.org/show_bug.cgi?id=119872

What benefit does duplicating the bug number in the first line provide? It’s 
just yet another thing to have to add when writing the ChangeLog entry.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] ChangeLog format

2013-08-22 Thread Mark Rowe

On 2013-08-22, at 12:46 AM, Carlos Garcia Campos carlo...@webkit.org wrote:

 El jue, 22-08-2013 a las 00:41 -0700, Mark Rowe escribió:
 On 2013-08-21, at 11:11 PM, Carlos Garcia Campos carlo...@webkit.org wrote:
 
 I see, I thought ChangeLog parser was used everywhere. So, I guess the
 solution would be to find a format most people like and adapt all
 scripts to it. I personally think it's not worth it, though. The oneline
 git log format is ok with the old commit message format IMO. If the only
 problem is that the bug number is not in the first line we can probably
 add it without adding the URL in angle brackets, something like:
 
 Bug 119872 - REGRESSION: Crash under JITCompiler::link while loading Gmail
 https://bugs.webkit.org/show_bug.cgi?id=119872
 
 What benefit does duplicating the bug number in the first line provide? It’s 
 just yet another thing to have to add when writing the ChangeLog entry.
 
 The benefit is that you see the bug number when using git log oneline
 format, I'm guessing that seeing the bug number in the first line was
 the motivation of the new ChangeLog format.

I’m ok with moving it in to the first line, but I’m against duplicating it.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Upcoming changes to WebKit's logging functionality

2013-08-05 Thread Mark Rowe

On 2013-08-02, at 4:39 PM, Mark Rowe mr...@apple.com wrote:

 As part of improving WebKit's logging subsystem on OS X 
 (https://webkit.org/b/119031) I'm refactoring the code in WebCore, WebKit 
 and WebKit2 that initializes logging channels. I'm doing this to reduce the 
 need to touch several different pieces of code in order to add a new logging 
 channel, and so that more of the initialization code can be shared across 
 platforms. The result of this is that all ports will now share a common 
 syntax for the string specifying which logging channels to enable.
 
 Logging channels may now be enabled by providing a comma-separated list of 
 channel names, with the special all name enabling all channels. Channel 
 names prefixed with a leading - will result in the named channel being 
 disabled. For instance, specifying all,-history,-loading will result in all 
 logging channels except for history and loading being enabled.
 
 For OS X developers, this will also change the name of the user defaults used 
 to enable logging. This is done to allow the old user defaults to remain set 
 for those people that need to switch between version of WebKit before and 
 after this change. Where the old user default keys were WebCoreLogLevel, 
 WebKitLogLevel and WebKit2LogLevel, the new user default keys are 
 WebCoreLogging, WebKitLogging and WebKit2Logging.
 
 For developers of other ports, the syntax used to enable logging channels may 
 change for you. Some ports had been using a space-separated list of channel 
 names rather than a comma-separated list. Please let me know if you feel that 
 this change will cause you pain. I've made a best-effort attempt to keep 
 other ports compiling, but since my brain only supports a subset of C++11 
 it's likely that I've introduced some build breakages. The EWS appears to 
 build with logging disabled so I've not been able to use it for testing this 
 change. I'd appreciate it if maintainers of other ports could take a few 
 minutes to check whether the most recent patch attached to 
 https://webkit.org/b/119031 builds on their platform and let me know if it 
 works or what needs to be fixed.
 
 I'll be holding off on landing these changes for a few days to gives folks an 
 opportunity to provide feedback. I’ll also be keeping an eye on the bots 
 after I land the change in case I do happen to break any builds.

I landed this change in r153736, with Windows build fixes in subsequent 
revisions. I’ll continue to keep an eye on the other build bots in case it 
causes problems for any other ports.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Mavericks Nightly

2013-06-19 Thread Mark Rowe

On 2013-06-19, at 10:12 AM, Mark Gilbert web...@gallery.co.uk wrote:

 Hi Folks.
 
 Any news on when we can get a nightly build to run on Mavericks ?

After it is released.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Enabling new features in WebKit + prefixing

2013-05-12 Thread Mark Rowe

On 2013-05-04, at 15:32, Dean Jackson d...@apple.com wrote:

 This is a brief summary of yesterday's discussion at the contributors' 
 meeting. If there is no strong disagreement here then I'll add this to the 
 wiki.
 
 New Features
 
 
 - The rule of sending an email to webkit-dev when you're about to start work 
 on a new feature remains in place. The idea here is that the community can 
 support or object to the feature even being in the tree.
 
 - Once the implementation of the feature is ready for use, send another email 
 to webkit-dev announcing your intentions to enable the feature in nightly 
 builds. How do you know when something is ready for use”?

By “nightly builds” do we mean “all ports in tip of tree”? If so, can we please 
say that instead? “Nightly builds” refer to a specific subset of builds 
produced from tip of tree and unless the intent is to enable the features for 
that subset alone, and no other builds, it’s confusing to phrase things in this 
way.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Intent to Enable CSS Exclusions in Nightlies

2013-05-09 Thread Mark Rowe

On 2013-05-09, at 17:21, Bear Travis betra...@adobe.com wrote:

 Hi WebKit,
 
 The CSS Exclusions  Shapes [1] feature is currently behind a runtime flag 
 that I would like to enable by default in the WebKit nightlies.

Can you clarify what it means to enable something by default in the WebKit 
nightlies”? Do you mean enabling it by default on tip of tree?

- Mark


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Intent to Enable CSS Exclusions in Nightlies

2013-05-09 Thread Mark Rowe
The only platform for which nightly builds are produced is OS X. Do you intend 
to enable it for all platforms on tip of tree, or just for those from which 
nightly builds are built?

What I'm getting at is that I'm confused as to why you mentioned nightly builds 
at all in your initial email if you're enabling it for all platforms.

- Mark

 On May 9, 2013, at 17:49, Bear Travis betra...@adobe.com wrote:
 
 Hi Mark,
 
 Yes, my understanding of the policy [1] was that this was done at tip of tree.
 
 -Bear
 
 [1] https://lists.webkit.org/pipermail/webkit-dev/2013-May/024850.html
 
 From: Mark Rowe mr...@apple.com
 Date: Thursday, May 9, 2013 5:25 PM
 To: Adobe betra...@adobe.com
 Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] Intent to Enable CSS Exclusions in Nightlies
 
 
 On 2013-05-09, at 17:21, Bear Travis betra...@adobe.com wrote:
 
 Hi WebKit,
 
 The CSS Exclusions  Shapes [1] feature is currently behind a runtime flag 
 that I would like to enable by default in the WebKit nightlies.
 
 Can you clarify what it means to enable something by default in the WebKit 
 nightlies”? Do you mean enabling it by default on tip of tree?
 
 - Mark
 
 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Buildsystem cleanup

2013-04-08 Thread Mark Rowe

On 2013-04-08, at 15:44, Patrick Gansterer par...@paroga.com wrote:

 
 Am 08.04.2013 um 21:26 schrieb Roger Fong:
 
 Unfortunately this would cause a lot of complication in our internal build 
 setup that we currently don’t really have the resources to deal with right 
 now.
 
 Please don't get me wrong, but I only get a some internal problems answer 
 always. Can someone please give some more detailed answer on the internal 
 requirements. I'm willing to do the work for the Windows ports, but I need 
 more information. How is the Windows port built at Apple? Is it possible to 
 switch it to a CMake generated project? 

The biggest complicating factor is that when each project builds it only has 
access to its own source, and the built products from earlier projects. This 
was mentioned the last time you suggested switching to CMake for the Windows 
build: https://lists.webkit.org/pipermail/webkit-dev/2012-April/020291.html.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Buildsystem cleanup

2013-04-08 Thread Mark Rowe

On 2013-04-08, at 17:16, Patrick Gansterer par...@paroga.com wrote:

 
 Am 09.04.2013 um 00:58 schrieb Mark Rowe:
 
 
 On 2013-04-08, at 15:44, Patrick Gansterer par...@paroga.com wrote:
 
 
 Am 08.04.2013 um 21:26 schrieb Roger Fong:
 
 Unfortunately this would cause a lot of complication in our internal build 
 setup that we currently don’t really have the resources to deal with right 
 now.
 
 Please don't get me wrong, but I only get a some internal problems answer 
 always. Can someone please give some more detailed answer on the internal 
 requirements. I'm willing to do the work for the Windows ports, but I need 
 more information. How is the Windows port built at Apple? Is it possible to 
 switch it to a CMake generated project? 
 
 The biggest complicating factor is that when each project builds it only has 
 access to its own source, and the built products from earlier projects. This 
 was mentioned the last time you suggested switching to CMake for the Windows 
 build: 
 https://lists.webkit.org/pipermail/webkit-dev/2012-April/020291.html.
 
 I know the last thread, so please don't hurt me if I ask dumb questions, but 
 how does it work at the moment? ;-)
 What is the root directory of a checkout? E.g. if I checkout only 
 Source/JavaScriptCore how can I access the vsprops files from 
 WebKitLibraries/win?

WebKitLibraries/win/tools is treated as its own project. It is built first so 
that the other WebKit projects can use the files that it installs. You can see 
a Makefile at WebKitLibraries/win/tools/WinTools.make that does the 
installation.

 Is there a checkout of this global files for the individual targets too?

No.

 If there is a checkout of the whole tree for every target, how do you make 
 sure that the files from the previous build are use (and not from the 
 checkout)?

Only a subset of the tree is available. For instance, when preparing to build 
JavaScriptCore the relevant source is fetched using “svn export 
https://svn.webkit.org/repository/webkit/trunk/Source/JavaScriptCore”. The 
resulting directory is then provided to the build machine.

 Beside this, is there a general problem with CMake for the Windows port? For 
 the Mac port there is the problem, that CMake is not an executable provided 
 by the system (maybe i can some time...). Since many other tools are require 
 separate installation  on Windows anyway there should be no problem in 
 installing CMake too?

Making the CMake executable available shouldn’t be a problem.

Do the projects generated by CMake suffer from the same problem with absolute 
paths as CMake’s Xcode projects? I’m not sure whether that would be a problem 
for us on Windows, but it’s good to understand any limitations ahead of time.

- Mark
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Buildsystem cleanup

2013-04-08 Thread Mark Rowe

On 2013-04-08, at 17:45, Patrick Gansterer par...@paroga.com wrote:

 
 Am 09.04.2013 um 02:29 schrieb Mark Rowe:
 
 
 On 2013-04-08, at 17:16, Patrick Gansterer par...@paroga.com wrote:
 
 
 Am 09.04.2013 um 00:58 schrieb Mark Rowe:
 
 
 On 2013-04-08, at 15:44, Patrick Gansterer par...@paroga.com wrote:
 
 
 Am 08.04.2013 um 21:26 schrieb Roger Fong:
 
 Unfortunately this would cause a lot of complication in our internal 
 build setup that we currently don’t really have the resources to deal 
 with right now.
 
 Please don't get me wrong, but I only get a some internal problems 
 answer always. Can someone please give some more detailed answer on the 
 internal requirements. I'm willing to do the work for the Windows ports, 
 but I need more information. How is the Windows port built at Apple? Is 
 it possible to switch it to a CMake generated project? 
 
 The biggest complicating factor is that when each project builds it only 
 has access to its own source, and the built products from earlier 
 projects. This was mentioned the last time you suggested switching to 
 CMake for the Windows build: 
 https://lists.webkit.org/pipermail/webkit-dev/2012-April/020291.html.
 
 I know the last thread, so please don't hurt me if I ask dumb questions, 
 but how does it work at the moment? ;-)
 What is the root directory of a checkout? E.g. if I checkout only 
 Source/JavaScriptCore how can I access the vsprops files from 
 WebKitLibraries/win?
 
 WebKitLibraries/win/tools is treated as its own project. It is built first 
 so that the other WebKit projects can use the files that it installs. You 
 can see a Makefile at WebKitLibraries/win/tools/WinTools.make that does the 
 installation.
 
 So having an additional top level directory with all shares CMake files is 
 possible?

It should be, yes.

 How are the ENABLE_* feature defines handled? Are they part of this files too?

I think that’s what the WebKitLibraries/win/tools/vsprops/FeatureDefines* is 
about, yes.

 If there is a checkout of the whole tree for every target, how do you make 
 sure that the files from the previous build are use (and not from the 
 checkout)?
 
 Only a subset of the tree is available. For instance, when preparing to 
 build JavaScriptCore the relevant source is fetched using “svn export 
 https://svn.webkit.org/repository/webkit/trunk/Source/JavaScriptCore”. The 
 resulting directory is then provided to the build machine.
 
 Hmm, I'll try to set up an example for WTF + JavaScriptCore. Maybe you can 
 have a look at it then to check if I understand the concept correctly before 
 I move on to WebCore + WebKit?

Sounds good.

 
 Beside this, is there a general problem with CMake for the Windows port? 
 For the Mac port there is the problem, that CMake is not an executable 
 provided by the system (maybe i can some time...). Since many other tools 
 are require separate installation  on Windows anyway there should be no 
 problem in installing CMake too?
 
 Making the CMake executable available shouldn’t be a problem.
 
 Do the projects generated by CMake suffer from the same problem with 
 absolute paths as CMake’s Xcode projects? I’m not sure whether that would be 
 a problem for us on Windows, but it’s good to understand any limitations 
 ahead of time.
 
 What is the concrete problem with the absolute paths? It's true that you 
 can't copy a generated vcproj to an other location, but that shouldn't be 
 required when you have installed CMake on that machine. And since the CMake 
 executable is required by the generated build files (in the background for 
 platform abstraction) it makes not much sense in a CMake workflow anyway. You 
 usually just run cd build_dir  cmake path/to/source  cmake --build . 
 and get all your files built.

I mentioned it because it's an obvious point that’s different than how our 
existing build systems work and so it has the potential to cause unexpected 
problems. I’m not aware of any actual issues that it will cause (beyond 
offending my sensibilities).

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] How to report iOS UIWebView WebKit issues

2013-04-03 Thread Mark Rowe

On 2013-04-03, at 03:51, Mustafizur Rahaman mustaf.h...@gmail.com wrote:

 Hi All,
 
 I am developing an application using UIWebView on iPad  I am seeing couple 
 of WebCore (element style related) crashes. The crashes happens randomly (yet 
 to narrow it down to exact use case), but the call stack is the same in all 
 crashes.
 
 I want to know if bugs.webkit.org is the right place to log such issues? I 
 know I have to provide a test html (so that it is easier for anyone to 
 reproduce)along with other details, when I will log the issue.
 
 Could any one please confirm?

Please report them at http://bugreport.apple.com/

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Compiling WebKit up to 25% faster in Windows?

2013-03-26 Thread Mark Rowe

On 2013-03-26, at 11:37, Ryosuke Niwa rn...@webkit.org wrote:

 On Tue, Mar 26, 2013 at 11:21 AM, Daniel Bratell brat...@opera.com wrote:
 Is this something that has been talked about in the past, and would you be 
 interested in replacing the long list of directories to search for every 
 include with paths (relative some good base) directly in the include 
 directives?
 
 Using explicit paths to include files has been talked about in the past; e.g. 
 https://lists.webkit.org/pipermail/webkit-dev/2011-November/018632.html
 
 The most convincing counter argument I can remember is that it'll make 
 refactoring harder because you'll have to update all #include's when you move 
 headers. 
 
 It would be great if we can figure out if this also improves the build time 
 on Mac/Linux.

I’d be very interested on what effect, if any, this has on Mac too. My initial 
impression is that any improvement should be minimal since a header map is used 
to optimize for precisely this situation. If that mechanism isn’t helping then 
it would be useful to know.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] 32-bit WebKit Nighly build APPLICATION ?

2013-03-01 Thread Mark Rowe

On 2013-03-01, at 11:48, Mark Gilbert web...@gallery.co.uk wrote:

 Hi Folks.
 
 Does anyone know if the WebKit Nightly build app is / can be built as a 
 32-bit capable binary app ?
 
 I note that forcing WebKit to start up in 32-bit mode throws an error - 
 relating to a path in the /Applications/Safari directory.  Even tho Safari 
 itself is quite happy to launch in 32-bit mode, and I have compiled the 
 WebKit frameworks with build-webkit --32-bit and replaced the frameworks 
 inside the WebKit nightly app.

Safari on recent OS versions is a 64-bit-only application. I suspect that’s why 
what you’re trying to do isn’t working.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] build.webkit.org is down?

2013-02-16 Thread Mark Rowe

On 2013-02-16, at 00:12, Christophe Dumez - SISA ch.du...@sisa.samsung.com 
wrote:

 build.webkit.org appears to be down:
 http://www.downforeveryoneorjustme.com/build.webkit.org

I’ve fixed it.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-02-07 Thread Mark Rowe

On 2013-02-03, at 21:20, Maciej Stachowiak m...@apple.com wrote:

 I should mention that there's a lot of interest right now at Apple in the 
 possibility of switching to Gyp. 

I’ve filed https://bugs.webkit.org/show_bug.cgi?id=109248 to track initial 
work in getting gyp set up for the Mac build. I’m initially attempting to 
generate Xcode projects that closely match our existing projects in order to 
minimize unintentional changes in build behavior.

- Mark


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-02-04 Thread Mark Rowe

On 2013-02-04, at 10:57, Maciej Stachowiak m...@apple.com wrote:

 
 On Feb 4, 2013, at 10:46 AM, Mark Mentovai m...@chromium.org wrote:
 
 GYP was written in Python to address point (b). Python was already part of 
 the baseline requirements on all platforms, so we already had Python 
 available everywhere we needed it. There are no dependencies on external 
 binaries, and no compiled code needs to be checked in anywhere or maintained 
 as part of a base image.
 
 As for point (a), you can easily have a top-level Makefile not generated by 
 GYP that says “run GYP to produce the build files for whatever environment 
 you like and then pass control to that build system to do the rest of the 
 build. Developers who like it can use ninja for their own builds, and your 
 bots can use Xcode or make if that’s a requirement (or if ninja doesn’t meet 
 your requirements given point (b)).
 
 Checking in the generated Xcode projects is another alternative. The Makefile 
 might be better for the reasons you suggest, though.

It’s not immediately obvious to me that a Makefile that ran GYP would be 
suitable for our production builds. I think it would be materially the same as 
building with something other than Xcode, in that it would limit the 
integration with the rest of the Apple build infrastructure.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Mark Rowe

On 2013-01-30, at 17:14, Dirk Pranke dpra...@chromium.org wrote:

 On Wed, Jan 30, 2013 at 4:15 PM, Maciej Stachowiak m...@apple.com wrote:
 
 On Jan 30, 2013, at 3:24 PM, Dirk Pranke dpra...@chromium.org wrote:
 
 On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote:
 Thanks for sharing this.
 
 On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote:
 
 I wish we only had one build system (it were easy to add/remove/move 
 files).
 
 I believe changes like http://trac.webkit.org/changeset/74849 are an
 unhealthy sign for the project.  Adam is not the only person who has chosen
 to empty files instead of removing them.  The pain of updating 8 build
 system is so great, we jump through hoops to avoid it.  Which means it took
 us months to move JavaScriptCore/wtf to WTF, and will take us years to kill
 WebCore/platform.
 
 
 +1
 
 This is a hard problem.  It is a problem worth solving.
 
 Do you have more thoughts on this, particularly since you know quite well
 how both Xcode and gyp work?
 
 I suspect this is one of those things that it would be hard to achieve
 consensus on since there are so many stakeholders.  But it may be fruitful
 to have a what if discussion about what this might look like.
 
 
 I think we can solve this problem if we agree that we want to. I think
 we haven't in the past mostly because we couldn't reach a consensus
 that it was worth solving enough to really try.
 
 I would love to see this fixed and would be glad to work on it. I
 think we should at least pursue this far enough to fully understand
 what our options are and what the costs and tradeoffs might be; does
 anyone disagree, and is anyone else willing to help pitch in?
 
 I think there are several possible ways we could solve this. One would
 be to switch to a common meta-build system. My understanding is that
 Apple's internal production build processes impose certain constraints
 here that I don't fully understand, but I know we've discussed the
 possibility of checking in generated project files as a workaround.
 Maybe there are other options as well to those constraints? I would
 love to discuss this further w/ someone from Apple ...
 
 It's far simplest for us if:
 (a) There is an Xcode project (or a Makefile) that builds the Mac port 
 checked in to source control.
 (b) The generated project invokes only tools that are part of the default 
 Mac OS X install.
 
 It may not be completely impossible to violate these requirements but it 
 will require a lot of bureaucracy.
 
 (Also, just to get this out of the way, I don't think gyp needs to be
 the solution).
 
 Another alternative would be to write a script that did support at
 least the common use cases (add/move/delete files). There have been
 attempts in the past, but they have foundered on at least some
 perceived skepticism over how well this would work w/ XCode. That
 said, I don't think we've really pushed this to see. At some point
 this script might turn into a meta-meta-build system, which might be
 silly but also be the shortest path to the finish line.
 
 I suggest if there is interest in this we can start a new thread to
 discuss further ...
 
 My preference would be to use a common meta-build system with a comfortably 
 human-readable and human-editable syntax, and checked in generated project 
 files for those ports that need them.
 
 I think a key to making this work is to get Chromium and the Apple Mac port 
 onto a common build system, which will probably require both Google and 
 Apple ponying up at least one person to work on this project for a 
 reasonable period of time.
 
 I think the plausible meta-build-systems to use would be CMake and Gyp, but 
 in both cases it may be necessary to modify them to work well for everyone.
 
 
 Premake might also be an option, though I wouldn't necessarily vote
 for it. Gyp's syntax is ... awkward ... but apart from that might just
 work for checking in generated apple mac xcode projects. We should try
 it (shouldn't be too hard, since abarth had it working at one point).

I think Eric and/or Adam had JavaScriptCore building with gyp at one point. I’m 
not sure if they ever got to the other projects.

 I would consider changing or improving gyp's syntax to be on the table
 if it was needed to reach the goal.

For what it’s worth, I also find the gyp syntax to be unpleasant. It feels as 
though it was optimized for being processed by a machine rather than for being 
written and maintained by humans.

 CMake was originally considered a non-starter for chromium since the
 XCode and VS projects it produced didn't look or feel like native
 projects. However, we've since switched to ninja for most things so
 I'm less sure how important this is now. I've never been a huge fan of
 the CMake syntax but I haven't used it enough to really have an
 informed opinion.

Generating well-structured Xcode projects is still something that is important 
for any meta build system that we would consider 

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Mark Rowe

On 2013-01-31, at 00:48, Adam Barth aba...@webkit.org wrote:

 I would consider changing or improving gyp's syntax to be on the table
 if it was needed to reach the goal.
 
 For what it’s worth, I also find the gyp syntax to be unpleasant. It feels 
 as though it was optimized for being processed by a machine rather than for 
 being written and maintained by humans.
 
 Unlike xcodeproj files.  :)

Don’t get me wrong, Xcode projects suck for hand-editing too. However, they’re 
not intended to be edited by hand. Gyp files are, and so the expected level of 
human readability is much higher.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Mark Rowe

On 2013-01-31, at 00:59, Jochen Eisinger joc...@chromium.org wrote:

 
 
 On Thu, Jan 31, 2013 at 9:53 AM, Mark Rowe mr...@apple.com wrote:
 
 On 2013-01-31, at 00:48, Adam Barth aba...@webkit.org wrote:
 
  I would consider changing or improving gyp's syntax to be on the table
  if it was needed to reach the goal.
 
  For what it’s worth, I also find the gyp syntax to be unpleasant. It feels 
  as though it was optimized for being processed by a machine rather than 
  for being written and maintained by humans.
 
  Unlike xcodeproj files.  :)
 
 Don’t get me wrong, Xcode projects suck for hand-editing too. However, 
 they’re not intended to be edited by hand. Gyp files are, and so the expected 
 level of human readability is much higher.
 
 Many of us are actually editing the Xcode projects by hand, either because 
 they don't have Xcode or don't know how to use it. (Yes, that includes coming 
 up with a bunch of new UUIDs by hand)


I wasn’t trying to suggest that current situation is a good one, only that if 
it would be easier to get momentum on switching to something like gyp if the 
replacement’s syntax was friendlier. Particularly when the people that need to 
be convinced to switch, and who’ll have to adapt their workflow, are those that 
are editing the project files in a nice GUI.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

2013-01-31 Thread Mark Rowe

On 2013-01-31, at 01:07, Hajime Morrita morr...@chromium.org wrote:

 In my understanding, it doesn't matter whether Apple Mac port supports ninja 
 or not. We could use GNU make if some meta-build system is adopted because 
 Mac OS has it installed. The problem here is that the neither CMake and GYP 
 isn't easy to adopt for reasons discussed in this thread.

As I mentioned in an earlier email, we need to keep the Mac port building via 
Xcode for our production builds.

 My personal feeling is that we could build a simple meta build system which 
 specifically targetsMac WebKit and XCode.
 
 It could be just a little more than a templating system which generates the 
 list of files plus their UUIDs. The tool doesn't need to be so general like 
 CMake/GYP. Many tricky configuration things could be in the hard-coded 
 boilerplate. It could just focus on generating file list and UUIDs. It's 
 something like project.pbxproj.in and its preprocessor.
 
 It won't be a direct step toward the unified build system. But we'll figure 
 out the next step once the build is represented by a simple plain text.

I’ve experimented with this in the past and you’re right that it shouldn’t be 
particularly difficult to do. However, I suspect that the task would be similar 
in scope to defining an improved syntax for gyp. And if the syntax is the 
primary sticking point with gyp then it’d seem preferable to tackle initially.

I should also clarify that I don’t think gyp’s current syntax is a showstoppper 
for adoption. I’d just like to see it improved.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Rolling out a patch requires a justification beyond a test failure in downstream projects

2012-12-11 Thread Mark Rowe

On 2012-12-11, at 19:34, Ryosuke Niwa rn...@webkit.org wrote:

 On Tue, Dec 11, 2012 at 7:20 PM, Elliott Sprehn espr...@chromium.org wrote:
 Do you have an example of when this has occurred? It's good to have examples 
 if we want to prevent this in the future.
 
 Yes. I'd rather not publicly humiliate someone on webkit-dev so I'll send you 
 a bug URL in private.
 
 In this particular incident, a WebKit patch was rolled out due to a Chromium 
 UI test failure. The person who rolled out the patch didn't communicate any 
 information on the original bug from which the patch was landed. On the bug 
 where the rollout was made, the person left links to Chromium WebKit roll 
 patches but without any information regarding tests that failed. The only 
 reason I could follow his comments is because I used to work on Chromium. The 
 patch was subsequently rolled out in less than 20 minutes from the time the 
 person first provided any information about the test failure at all.
 
 To make it even worse, the roll out was speculative, and the patch was found 
 innocent of causing the failure. The person promised to re-land the patch by 
 Monday and never came back to the bug. (Now you know where my previous email 
 came from).

In my opinion, that sort of behavior is out of line with the behavior that we 
as a community expect from WebKit committers.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Behaviour of CapsLock in WebKit/Mac

2012-12-11 Thread Mark Rowe

On 2012-12-11, at 21:24, Wez w...@chromium.org wrote:

 Hi all,
 
 There's a bug reported against Chromium (crbug.com/144757) for the CapsLock 
 key generating only a keydown when first pressed and released, and a keyup 
 when next pressed and released, i.e. the keydown  keyup events correspond 
 with the caps lock-state being toggled, rather than with the key itself being 
 pressed or released.
 
 The same issue reproduces against Safari on Mac.  Is this a by-design 
 behaviour of WebKit?

It’s a known issue (https://bugs.webkit.org/show_bug.cgi?id=18792).

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] bugs.webkit.org and trac.webkit org down?

2012-08-21 Thread Mark Rowe

On 2012-08-21, at 02:25, Osztrogonac Csaba o...@inf.u-szeged.hu wrote:

 and again ...

I poked the server to work around the issue. I may have also tracked down the 
root cause of these issues too. I've sent Bill details of my theory, so 
hopefully we can come up with a permanent solution to it tomorrow!

- Mark

 
 Osztrogonac Csaba írta:
 Hi,
 ... and again and again ... Bill, Mark or Lucas, could you check
 it, please? Have you got any idea why does it happen regularly?
 br,
 Ossy
 Osztrogonac Csaba írta:
 bugs.webkit.org and trac.webkit.org is unavailable again. :(
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Proposal for coding guidelines: Do not use fall-through switch cases inside #ifdef's

2012-08-21 Thread Mark Rowe

On 2012-08-21, at 13:02, Bruno Abinader brunoabina...@gmail.com wrote:

 On Sat, Aug 18, 2012 at 10:20 PM, Tim Horton timothy_hor...@apple.com wrote:
 Without looking at the code, I vaguely think that 
 CSSPropertyWebkitTextDecorationLine comes from a generated file that might 
 not rebuild when it's supposed to. You should try a clean build and see -- 
 there've been a few problems with this recently (I ran into it when 
 switching flexbox and regions/exclusions on and off a lot a few months ago, 
 and a colleague ran into it again recently in a similar situation).
 
 Is there a way to force the EWS build bots to do a clean build? I'm
 frequently obtaining build failures on gtk, mac and win due to this
 refuse to rebuild these generated files (ie.
 https://bugs.webkit.org/show_bug.cgi?id=94094#c9 ). From the output
 you can see that both Source/WebCore/css/CSSValueKeywords.in and
 Source/WebCore/css/CSSPropertyNames.in were supposed to generate the
 new values, but aren't, causing the failures.

It'd be preferable to fix whatever problem exists with the dependencies so that 
these files are automatically regenerated when needed. Otherwise anyone 
building on these platforms, including buildbots, will just run in to the issue 
after you land the patch.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] bugs.webkit.org and trac.webkit org down?

2012-08-18 Thread Mark Rowe

On 2012-08-18, at 07:54, Osztrogonac Csaba o...@inf.u-szeged.hu wrote:

 Hi,
 
 ... and again and again ... Bill, Mark or Lucas, could you check
 it, please? Have you got any idea why does it happen regularly?

Bill is back from vacation next week and will look in to the underlying cause 
of the problem.

- Mark

 
 br,
 Ossy
 
 Osztrogonac Csaba írta:
 bugs.webkit.org and trac.webkit.org is unavailable again. :(

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] bugs.webkit.org and trac.webkit org down?

2012-08-09 Thread Mark Rowe
On 2012-08-09, at 02:41, Osztrogonac Csaba o...@inf.u-szeged.hu wrote:

 Hi,
 
 bugs.webkit.org and trac.webkit.org is unavailable again. :(
 Could you check it, please?

This is caused by a problem on a host that I don't have sufficient privileges 
on to be able to address the issue myself. I've pinged people that should be 
able to resolve the issue, but given that it's currently 3am in California it 
may be a few hours before they're awake and fixing it.

- Mark

 
 br,
 Ossy
 
 Osztrogonac Csaba írta:
 It seems bugs.webkit.org and trac.webkit.org is unavailable
 now. (at least from Hungary) Have you got any idea what happened?
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] bugs.webkit.org and trac.webkit org down?

2012-08-09 Thread Mark Rowe

On 2012-08-09, at 04:22, Peter Beverloo pe...@chromium.org wrote:

 On Thu, Aug 9, 2012 at 11:41 AM, Mark Rowe mr...@apple.com wrote:
 
 On 2012-08-09, at 03:14, Peter Beverloo pe...@chromium.org wrote:
 
 On Thu, Aug 9, 2012 at 11:09 AM, Mark Rowe mr...@apple.com wrote:
 On 2012-08-09, at 02:41, Osztrogonac Csaba o...@inf.u-szeged.hu wrote:
 
  Hi,
 
  bugs.webkit.org and trac.webkit.org is unavailable again. :(
  Could you check it, please?
 
 This is caused by a problem on a host that I don't have sufficient 
 privileges on to be able to address the issue myself. I've pinged people 
 that should be able to resolve the issue, but given that it's currently 3am 
 in California it may be a few hours before they're awake and fixing it.
 
 Thank you. Is there any way an on-call or monitoring system could be set up? 
 While it fortunately occurs much less frequently nowadays than it did 
 earlier in the year, it --please excuse my directness-- is unacceptable for 
 a project the size of WebKit to have critical infrastructure unavailable 
 like this for several hours. Even though it's 3am in California, there are 
 many contributors in Asia and Europe who are severely impacted by this.
 
 We have people online virtually 24x7 that are capable of investigating and 
 addressing issues with the webkit.org infrastructure. I'm one such person. 
 This particular case is an unfortunate combination of events: a configuration 
 error on a subset of the new hardware that webkit.org was recently migrated 
 to has unintentionally limited the number of people that can access the host 
 that is currently experiencing problems, and the person that such issues are 
 escalated to is currently on vacation. It's an unfortunate combination, but 
 also one that is unlikely to repeat.
 
 One thing we should look in to is improving the process for reporting issues 
 with webkit.org infrastructure. webkit-dev isn't an ideal way to report 
 issues that our monitoring system hasn't noticed as there's no separation 
 between the regular discussion and more urgent issues, so the emails can be 
 overlooked.
 
 I see. Thank you for the insight, and I hope the access issues get sorted 
 out. I presume this is something Bill or Lucas will be able to pick up? 
 Hopefully the remaining downtime won't be more than three or four hours, then.

Bill is the one that's on vacation, and Lucas is in the same boat that I am as 
far as access to the host in question.  I managed to track down someone else 
with sufficient access though, and they've fixed the issue that was impacting 
bugs.webkit.org and trac.webkit.org.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] bugs.webkit.org and trac.webkit org down?

2012-08-07 Thread Mark Rowe

On 2012-08-07, at 10:55, Sravan sra1sand...@gmail.com wrote:

 I am still seeing the problem(ofcourse, Sunnyvale, CA) ? any one, when this 
 will be up?

This should be fixed now. Part of the database infrastructure (pgpool) was 
timing out all new connections. This caused all of the services that depend on 
the database to stop working.

- Mark

 On Tue, Aug 7, 2012 at 9:20 AM, Osztrogonac Csaba o...@inf.u-szeged.hu 
 wrote:
 Hi,
 
 It seems bugs.webkit.org and trac.webkit.org is unavailable
 now. (at least from Hungary) Have you got any idea what happened?
 
 br,
 Ossy
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] build time - lion vs mountain lion - 200% slowdown

2012-07-27 Thread Mark Rowe

On 2012-07-27, at 13:33, Glenn Adams gl...@skynav.com wrote:

 Just upgraded from Lion to Mountain Lion (and XCode 4.4). Clean build time 
 went from 29mins to 1h 29mins on a new 2.6GHz 16GB MacBook Pro 15 Retina. 
 You might want to hold off on an upgrade unless you enjoy waiting for builds.

You didn't mention what port of WebKit you're building, but I'm going to assume 
you're building the Mac port. I suspect there's something isolated to your 
system that's caused this problem (low disk space? Spotlight indexing / Time 
Machine backup after the upgrade?) as I'm able to do a clean build on Mountain 
Lion on a MacBook Air in less time than what you're seeing. My Mac Pro's also 
show no obvious showdown in building relative to their days running Lion.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Building on Mountain Lion

2012-07-25 Thread Mark Rowe

On 2012-07-25, at 14:15, Jacob Goldstein jac...@adobe.com wrote:

 Has any tried to build WebKit on Mountain Lion?  
 
 I just attempted with a new install of Mountain Lion and Xcode 4.4 and the 
 build keeps failing while trying to compile AlternativeTextUIController.  If 
 anyone has thoughts as to why this could be, please let me know.

We've obviously been building on Mountain Lion for quite some time. The WebKit 
nightly builds have been building for 10.6 through 10.8 against the OS X 10.8 
SDK for the last few weeks. What problems are you running in to?

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Removing BUILDING_ON / TARGETING macros in favor of system availability macros

2012-07-11 Thread Mark Rowe

On 2012-07-10, at 16:24, Mark Rowe mr...@apple.com wrote:

 I'm open to feedback on this proposal, but I'd like to move forward with this 
 change in the next day or two if no one objects.

Given the lack of outcry I've posted patches on 
https://bugs.webkit.org/show_bug.cgi?id=91015 that make this change.

- Mark


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Removing BUILDING_ON / TARGETING macros in favor of system availability macros

2012-07-11 Thread Mark Rowe

On 2012-07-11, at 17:46, Mark Mentovai m...@chromium.org wrote:

 Tony brought me in to comment on what impact this might have on the Chromium 
 Mac build. It shouldn’t have any impact. Any use of the compiler-defined 
 macros is fine.

I agree. The only impact I expect this to have is if I've missed hand-fixing 
any cases that were using BUILDING_ON and meant it (vs the vast majority of 
cases where they really wanted TARGETING). There were around half a dozen 
instances of this that I noticed and fixed when building the Mac build against 
an SDK but it's possible some may exist in Chromium-specific code paths. These 
cases should cause build failures and be obvious to address.

 In Chrome code, we usually use MAC_OS_X_VERSION_MAX_ALLOWED and 
 MAC_OS_X_VERSION_MIN_REQUIRED from AvailabilityMacros.h, along with 
 symbolic macros like MAC_OS_X_VERSION_10_7 instead of 1070. This has an 
 annoying disadvantage that older SDKs (like the 10.6 SDK) don’t define 
 MAC_OS_X_VERSION_10_7, so we’re stuck testing things like 
 defined(MAC_OS_X_VERSION_10_7)  MAC_OS_X_VERSION_MAX_ALLOWED = 
 MAC_OS_X_VERSION_10_7. The same applies when using Availability.h, where 
 the symbolic names are of the form __MAC_10_7, but you seem to have chosen 
 not to use those, thus condensing the macro logic.
 
 We used AvailabilityMacros.h’s MAC_OS_X_VERSION_MAX_ALLOWED and 
 MAC_OS_X_VERSION_MIN_REQUIRED instead of Availability.h’s 
 __MAC_OS_X_VERSION_MAX_ALLOWED and __MAC_OS_X_VERSION_MIN_REQUIRED because 
 the latter header’s comments discuss how it’s appropriate for OS headers, 
 while the former documents its use for user (non-OS) code. TN2064 also 
 recommends AvailabilityMacros.h.

Availability.h has the following to say which addresses both of these points:

It is also possible to use the *_VERSION_MIN_REQUIRED in source code to 
make one
source base that can be compiled to target a range of OS versions.  It is 
best
to not use the _MAC_* and __IPHONE_* macros for comparisons, but rather 
their values.
That is because you might get compiled on an old OS that does not define a 
later
OS version macro, and in the C preprocessor undefined values evaluate to 
zero
in expresssions, which could cause the #if expression to evaluate in an 
unexpected
way.

TN2064 appears to have been last modified in 2003, so it predates the existence 
of Availability.h. Availability.h was introduced with the iOS SDK in order to 
support availability macros that are compatible with both OS X and iOS, where 
the older macros from AvailabilityMacros.h were specific to OS X.

 I never liked the WebKit-specific BUILDING_ON_*/TARGETING_* macros and am 
 happy to see them go.
 
 My one real gripe with the macros from both Availability.h and 
 AvailabilityMacros.h is that it’s not terribly obvious which one refers to 
 the SDK (it’s MAX_ALLOWED) and which refers to the deployment target (it’s 
 MIN_REQUIRED). Until you’re familiar with the macros, I think it’s unclear 
 that “allowed” refers to APIs allowed to be called because they’re present in 
 the SDK, and unclear that “required” refers to the runtime requirement. This 
 probably leads to more misuse and abuse than if they had SDK and DT in their 
 names. I guess BUILDING_ON_* and TARGETING_* were a little better in that 
 regard, but they were misused and abused too. SDKs and DTs are probably just 
 too confusing to begin with.

I agree that the terminology used is somewhat confusing. I don't think it's a 
huge concern though since the minimum required OS version is what the vast 
majority of the checks within WebKit care about, and that concept is quite easy 
to understand.

Thanks for taking the time to look this over!

- Mark

 
 
 On Tue, Jul 10, 2012 at 7:24 PM, Mark Rowe mr...@apple.com wrote:
 I would like to propose removing the BUILDING_ON and TARGETING family of 
 macros that are used to build code conditionally for different versions of OS 
 X. I propose this in order to address several problems:
 
 The checks are verbose, and getting worse.
 
 For instance, in order to write code targeting OS X 10.8 and newer I have to 
 enumerate all other supported OS versions:
 
 #if !defined(TARGETING_LEOPARD)  !defined(TARGETING_SNOW_LEOPARD)  
 !defined(TARGETING_LION)
 …
 #endif
 
 This problem has become worse over time as the number of supported OS X 
 versions in the WebKit code base has increased.
 
 The nature of the version checks are often not obvious at first glance.
 
 In order to understand the checks you have to first remember the marketing 
 names of the various OS X releases. You must then reason about the 
 conditional logic of the check itself, which will often contains multiple 
 negated clauses.
 
 Almost all current uses are incorrect in the context of SDKs.
 
 The vast majority of the checks in WebKit use the BUILDING_ON macros where 
 the TARGETING macros would be more appropriate. This hasn't cause many 
 problems to date since builds of WebKit

[webkit-dev] Removing BUILDING_ON / TARGETING macros in favor of system availability macros

2012-07-10 Thread Mark Rowe
I would like to propose removing the BUILDING_ON and TARGETING family of macros 
that are used to build code conditionally for different versions of OS X. I 
propose this in order to address several problems:

The checks are verbose, and getting worse.

For instance, in order to write code targeting OS X 10.8 and newer I have to 
enumerate all other supported OS versions:

#if !defined(TARGETING_LEOPARD)  !defined(TARGETING_SNOW_LEOPARD)  
!defined(TARGETING_LION)
…
#endif

This problem has become worse over time as the number of supported OS X 
versions in the WebKit code base has increased.

The nature of the version checks are often not obvious at first glance.

In order to understand the checks you have to first remember the marketing 
names of the various OS X releases. You must then reason about the conditional 
logic of the check itself, which will often contains multiple negated clauses.

Almost all current uses are incorrect in the context of SDKs.

The vast majority of the checks in WebKit use the BUILDING_ON macros where the 
TARGETING macros would be more appropriate. This hasn't cause many problems to 
date since builds of WebKit on OS X for the most part do not use SDKs. This 
means that they build with __MAC_OS_X_VERSION_MIN_REQUIRED == 
__MAC_OS_X_VERSION_MAX_ALLOWED, resulting in the BUILDING_ON and TARGETING 
macros being equivalent. However, when building with a deployment target of an 
older OS release than the SDK you're building against, the BUILDING_ON and 
TARGETING macros will have different behavior. The result is that WebKit fails 
to build against an SDK when targeting an older OS release.

My proposed solution to these problems is to remove the BUILDING_ON and 
TARGETING macros. The vast majority of the BUILDING_ON uses and all of the 
TARGETING uses would be replaced with tests against 
__MAC_OS_X_VERSION_MIN_REQUIRED. The small number of uses of BUILDING_ON that 
are being used correctly would be replaced with tests against 
__MAC_OS_X_VERSION_MAX_ALLOWED.

The example above of code targeting OS X 10.8 and newer would become:

#if __MAC_OS_X_VERSION_MIN_REQUIRED = 1080
…
#endif

Code that wishes to target only OS X 10.6 and older would become:

#if __MAC_OS_X_VERSION_MIN_REQUIRED = 1060
…
#endif

This is much more concise and understandable than the current approach.


I'm open to feedback on this proposal, but I'd like to move forward with this 
change in the next day or two if no one objects.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] build.webkit.org down?

2012-06-21 Thread Mark Rowe

On 2012-06-21, at 15:46, Lucas Forschler lforsch...@apple.com wrote:

 I'd like to see a 'test' buildbot up and running that we could use as a 
 staging area for trying out new changes before deploying to the production 
 server.  We could copy 
 /OpenSource/Tools/BuildSlaveSupport/build.webkit.org-config to 
 /OpenSource/Tools/BuildSlaveSupport/test.webkit.org-config, and have a test 
 build master that updates and outputs logs somewhere readable (public_html?). 
  Then, we could make sure any changes work on the test master before 
 committing them to production.

Having a test master seems like a good idea. Doing it by keeping a complete 
second copy of the configuration checked in to SVN seems less than ideal.

- Mark

 On Jun 21, 2012, at 1:15 PM, William Siegrist wrote:
 
 The server does not run the unittests, but it does normally run `buildbot 
 checkconfig`. However, we had to temporarily bypass the checkconfig test 
 during restart due to a bug in Buildbot:
 
 http://trac.buildbot.net/ticket/2279
 
 The best thing to do when working on the buildbot config is to have buildbot 
 installed on your local machine so you can test the config before 
 committing. That avoids the confusion of the reconfig not happening and 
 people thinking the automatic reconfig is just broken.
 
 -Bill
 
 
 On Jun 21, 2012, at 12:28 PM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote:
 
 Hi,
 
 In this case we could have avoided the breakage with running this unittest.
 Can we make the master somehow run this unittest before restarting itself?
 
 br,
 Ossy
 
 Eric Seidel írta:
 One can run:
 http://trac.webkit.org/browser/trunk/Tools/BuildSlaveSupport/build.webkit.org-config/mastercfg_unittest.py
 to test the master locally, but that's all I know of.
 On Thu, Jun 21, 2012 at 11:15 AM, Sergio Villar Senin
 svil...@igalia.com wrote:
 En 21/06/12 19:54, William Siegrist escribiu:
 On Jun 21, 2012, at 10:43 AM, Jon Lee jon...@apple.com wrote:
 
 Is something being upgraded right now?
 
 No, the config file has a problem in it which is unrelated to our 
 upgrade as far as I can tell. I'm trying to track down what happened.
 
 $ buildbot checkconfig
 Do we have any tool that allows to check locally changes in the slaves
 configuration?
 
 BR
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Debugging With Xcode

2012-04-23 Thread Mark Rowe

On 2012-04-23, at 18:02, Eric Seidel e...@webkit.org wrote:

 Does anyone still debug WebKit on Mac OS X with Xcode 4?
 
 
 1.  I don't know how to actually set up Xcode to point to WebKitBuild
 like it used to.
 http://www.webkit.org/building/debug.html
 Mentions a Legacy option which does not exist for me.

This page was updated recently to reflect the terminology used in the current 
version of Xcode. The diff may provide the information you need to get this 
working in earlier versions of Xcode.

 2.  Xcode tries to Re-index WebCore, seemingly every time I open
 WebCore.xcodeproj.  This is a hour+ process on my 12-core Mac Pro!
 
 The re-indexing takes a lot of processing power, and seems to render
 both my machine, and Xcode largely unusable.

That's interesting. If you're seeing that with the latest released version of 
Xcode then I'd strongly suggest filing a bug report at 
http://bugreport.apple.com/ so that the Xcode folks can address it.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] CMake for Apple's Windows port

2012-04-18 Thread Mark Rowe

On 2012-04-18, at 18:43, Patrick Gansterer par...@paroga.com wrote:

 
 Am 12.04.2012 um 20:06 schrieb Dirk Pranke:
 Patrick, have you documented what all you need to install on a Win box
 in order to be able to run CMake and do the build?
 
 You need to install CMake and the same tools listed at 
 http://trac.webkit.org/wiki/WinCE#Build and 
 http://www.webkit.org/building/tools.html (but without cygwin).
 
 
 Am 12.04.2012 um 23:47 schrieb Mark Rowe:
 On 2012-04-12, at 14:28, Dirk Pranke dpra...@chromium.org wrote:
 Interesting.  Can you comment further on why this is needed, instead of 
 just checking out the whole repo?
 
 
 The short answer is that doing so would violate internal policies that we 
 have about what sorts of files are acceptable in the source of production 
 builds (for example, precompiled libraries are not acceptable). We also 
 don't have any desire to shuffle multiple gigabytes of layout tests around 
 machines that are only used for building.
 
 Is it possible to get a (detailed) list of requirements? It's hard for people 
 don't knowing the internal Apple build process to work on it.

We don't have anything of this nature available for external consumption at 
this time.

 Why isn't it possible to checkout only the Source directory?
 Since the current system has more than 1 VS solution too, I don't think it 
 will be a problem to have more than one root CMakeLists.txt too.

That's the direction we're heading in for the Mac build system. If this can be 
made to work with CMake then that's wonderful.

 Is there a interest in getting rid of the Visual Studio files? Are there any 
 points agains CMake we know already? I don't want to put (much) work into the 
 CMake files for a simple No, thanks at the end. ;-)

I'll let someone else speak to these points.

- Mark


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] CMake for Apple's Windows port

2012-04-12 Thread Mark Rowe

On 2012-04-12, at 12:08, Adam Treat atr...@rim.com wrote:

 If my memory serves me the problem was that Apple couldn't figure out how to 
 get cmake installed on the Apple build system machine.

It has little to do with installing software and everything to do with the 
complexity involved in making a new build system work within the constraints of 
our production build process. In particular, each project needs to be able to 
build independently from the others. That is, the equivalent of svn co 
http://svn.webkit.org/repository/webkit/trunk/Source/WTF  make -C WTF needs 
to work. Based on what I can see of the existing structure of the CMake build 
system this isn't possible as parts of the build system live in the root of the 
repository or the Source directory.

- Mark

 
 From: webkit-dev-boun...@lists.webkit.org 
 [webkit-dev-boun...@lists.webkit.org] on behalf of Dirk Pranke 
 [dpra...@chromium.org]
 Sent: Thursday, April 12, 2012 2:06 PM
 To: Patrick Gansterer
 Cc: WebKit Development
 Subject: Re: [webkit-dev] CMake for Apple's Windows port
 
 I think this is great; I've been meaning to spend some time on the
 apple win port trying to fix the remaining bugs holding up the switch
 to NRWT, but the fact that the apple win port still uses VS2005 is
 definitely an impediment (yes, I can probably just pull the binaries
 down from a bot for my purposes, but I'd really like to be able to
 build it).
 
 Patrick, have you documented what all you need to install on a Win box
 in order to be able to run CMake and do the build?
 
 Can someone from Apple weigh in on whether switch to CMake would be feasible?
 
 -- Dirk
 
 On Thu, Apr 12, 2012 at 5:41 AM, Patrick Gansterer par...@paroga.com wrote:
 Hi,
 
 it's more than a year since the last discussion about the build system of 
 Apple's Windows port. In the meantime I merged most of the general changes 
 into the CMake files in the repository and have a working patch with a few 
 CMake files at [1] as written in [2]. I don't think that it is ready to 
 replace the existing vcproj files already, but I like to hear all points 
 needed to do that.
 Adding CMake files for the WinCairo port (which uses the vcproj files too) 
 will be very easy when the Apple version has been added.
 
 Here some benefits to the CMake version:
 1) Shared build system: The shared files are already used by the Blackberry, 
 EFL and WinCE port, so only the list of platform specific files needs to be 
 maintained.
 2) No dependency on cygwin [3]: The CMake build system searches for the 
 Win32 version of the required executables (bison, gperf, flex, perl and 
 python) like the WinCE port does already (see [4]).
 3) Less Solution targets: Some of he current vcproj files only used for 
 triggering Makefiles. The vcproj generates more native vcproj files, which 
 e.g. allows clicking on one of the IDL files to generate the corresponding 
 files.
 4) Easy creation of Visual Studio 2010 project files [5]: Using CMake allows 
 an easy transition to other (newer) Visual Studio versions, since every 
 developer can choose his preferred version.
 5) It's possibe to create Makefiles: The output of the windows buildbots 
 shows much unwanted messages. Using Makefiles on the bots can produce 
 cleaner logs and take advantage of all cores when used with JOM [7].
 
 Would be great if people who use the current VS Solution can give the CMake 
 version a try and provide some feedback about it.
 
 BTW: There is also a patch to switch Wx to CMake at [8], but it did not get 
 a positive response.
 
 [1] https://bugs.webkit.org/show_bug.cgi?id=72816
 [2] https://lists.webkit.org/pipermail/webkit-dev/2011-February/015831.html
 [3] https://bugs.webkit.org/show_bug.cgi?id=48166
 [4] http://trac.webkit.org/wiki/WinCE#Build
 [5] https://bugs.webkit.org/show_bug.cgi?id=53445
 [6] https://lists.webkit.org/pipermail/webkit-dev/2011-January/015815.html
 [7] http://qt-project.org/wiki/jom
 [8] https://bugs.webkit.org/show_bug.cgi?id=73100
 
 -- Patrick
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 -
 This transmission (including any attachments) may contain confidential 
 information, privileged material (including material protected by the 
 solicitor-client or other applicable privileges), or constitute non-public 
 information. Any use of this information by anyone other than the intended 
 recipient is prohibited. If you have received this transmission in error, 
 please immediately reply to the sender and delete this information from your 
 system. Use, dissemination, distribution, or reproduction of this 
 transmission by unintended 

Re: [webkit-dev] CMake for Apple's Windows port

2012-04-12 Thread Mark Rowe

On 2012-04-12, at 14:28, Dirk Pranke dpra...@chromium.org wrote:

 
 On Apr 12, 2012 1:17 PM, Mark Rowe mr...@apple.com wrote:
 
 
  On 2012-04-12, at 12:08, Adam Treat atr...@rim.com wrote:
 
   If my memory serves me the problem was that Apple couldn't figure out how 
   to get cmake installed on the Apple build system machine.
 
  It has little to do with installing software and everything to do with the 
  complexity involved in making a new build system work within the 
  constraints of our production build process. In particular, each project 
  needs to be able to build independently from the others. That is, the 
  equivalent of svn co 
  http://svn.webkit.org/repository/webkit/trunk/Source/WTF  make -C WTF 
  needs to work. Based on what I can see of the existing structure of the 
  CMake build system this isn't possible as parts of the build system live in 
  the root of the repository or the Source directory.
 
 
 Interesting.  Can you comment further on why this is needed, instead of just 
 checking out the whole repo?
 

The short answer is that doing so would violate internal policies that we have 
about what sorts of files are acceptable in the source of production builds 
(for example, precompiled libraries are not acceptable). We also don't have any 
desire to shuffle multiple gigabytes of layout tests around machines that are 
only used for building.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Mark Rowe

On 2012-03-09, at 10:23, Gustavo Noronha Silva g...@gnome.org wrote:

 On Thu, 2012-03-08 at 19:39 -0300, Alexis Menard wrote:
 To svn user :
 - Conflict resolving much easier and performant than svn (we have
 drivers for changelogs and the default one are much better than svn).
 - Local history/blaming/...
 - Proper diff coloration (though I'm sure you guys have some magic
 scripts using colordiff).
 - The staging area, upload what you want/need and keep some work local
 - Smaller checkouts
 
 - Bot maintainers :
 Power outage or network interruption in the middle of a svn
 checkout/up lock the repo sometimes and you need to manually svn
 cleanup the checkout (maybe someone have a tool or script to avoid
 that???). I had much more svn locked repos than git dead checkout
 because of interruptions.
 
 /me puts his bot maintainer hat on
 
 That does suck indeed. Been a while since I had to manually intervene,
 but even when it is fixed automatically, the new checkout takes ages
 (because the automatic fix is to rm -rf the whole source tree).

The solution for this would be to teach buildbot run 'svn cleanup' when 
necessary rather than just assuming the worst and nuking the working copy. This 
will become trivial to do in future versions of Buildbot as they're moving the 
logic for how version control operations to the server rather than the slaves, 
meaning it becomes much easier to update and customize.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Mark Rowe

On 2012-03-09, at 09:15, Kalle Vahlman kalle.vahl...@gmail.com wrote:

 2012/3/9 Ryosuke Niwa rn...@webkit.org:
 On Fri, Mar 9, 2012 at 7:14 AM, Ashod Nakashian ashodnakash...@yahoo.com
 wrote:
 I think if we address the main issues raised by the svn users, the current
 consensus (if representative) seems to point towards an overwhelming support
 (and demand?) for git over svn. On that point it's reasonable to say that
 we're heading towards option #1 or #2 of Maciej. As such, I'm humbly
 proposing the following (hopefully without getting ahead of myself):
 
 
 Frankly, I don't quite understand the benefit of this transition. Do we
 really need to move to git? If the only problem of keeping svn was about
 svn-apply being broken, I'm more than happy to fix that script.
 
 I think you missed the part where the impact on servers was discussed.
 If every time someone does svn log the server needs to not receive
 or deal out commits, it will show in response times. I'm sure people
 using svn do not check the log often, for obvious reasons, but it is
 still a factor to consider.

Making operations like 'log' not hit the server would obviously be nice, but 
the vast majority of the load on the Subversion server is from update or 
checkout operations.  Do you have a pointer to any concrete data about the 
relative load on a server for Git vs Subversion in terms of these operations?

Thanks,

- Mark


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Mark Rowe

On 2012-03-09, at 07:14, Ashod Nakashian ashodnakash...@yahoo.com wrote:

 
 From: David Barr davidb...@google.com
 To: Ryosuke Niwa rn...@webkit.org 
 Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org 
 Sent: Friday, March 9, 2012 2:37 AM
 Subject: Re: [webkit-dev] Moving to Git?
 
 
 I think we ought to streamline the git workflow before we start trying
 to proselytise Subversion users. :)
 
 
 
 Can you be more specific? What do you find wanting in the git workflow 
 besides the few cases raised by svn users (such as svn up that can be 
 supported in update-webkit)?
 
 I think if we address the main issues raised by the svn users, the current 
 consensus (if representative) seems to point towards an overwhelming support 
 (and demand?) for git over svn.

What you'll find is that the vast majority of SVN users are simply not 
participating in this email thread. You'll also find that many people that use 
git-svn are happy enough with the status quo since it gives those who chose to 
use it most of the benefits of a pure Git setup without forcing it on others.

In my opinion a substantial benefit needs to be demonstrated in order to 
convince the existing SVN users, many of which are substantial long-term 
contributors to the project, that it's worth it to them to relearn how to 
contribute to WebKit. And I do feel that SVN users need to want to switch to 
Git in order for it to be worth pursuing such a switch. As a heavy Git user 
myself I've not seen any arguments in this thread that would be convincing to 
someone not already familiar with Git.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Error while building on Mac SL 10.6.6

2012-03-02 Thread Mark Rowe

On 2012-03-02, at 15:45, Eric Seidel e...@webkit.org wrote:

 Building from snapshots is not supported.

Huh?

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Error while building on Mac SL 10.6.6

2012-03-02 Thread Mark Rowe

On 2012-03-02, at 15:53, Eric Seidel e...@webkit.org wrote:

 Am I wrong?  Feel encouraged to correct me.

Of course you're wrong.

 I don't validate the snapshots to make sure they build.  But perhaps you do.

The entire point of posting source snapshots along with the nightly build is so 
that people can build a revision that is known to compile (on at least a subset 
of platforms) from source.

- Mark

 On Fri, Mar 2, 2012 at 3:48 PM, Mark Rowe mr...@apple.com wrote:
 
 On 2012-03-02, at 15:45, Eric Seidel e...@webkit.org wrote:
 
 Building from snapshots is not supported.
 
 Huh?
 
 - Mark
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Error while building on Mac SL 10.6.6

2012-03-02 Thread Mark Rowe

On 2012-03-02, at 15:44, Vivek Galatage vivekgalat...@gmail.com wrote:

 Hi Webkit,
 
 I am trying to build nightly snapshot @rev r109209 on mac SL 10.6.6 with 
 xcode 3.2.6 installed. 
 
 But when I issue build-webkit from command line I am running into various 
 errors. I am attaching the log file containing the error messages.
 
 So any idea how to resolve this error and get the builds working?

webkit-dev isn't the best place to ask for help with building. I believe that 
webkit-help takes that role.

That said, it's not too surprising that you're running in to troubles when 
building with such an old version of Xcode. We typically recommend that people 
use Xcode 4.2.1 on SnowLeopard for WebKit development.  With older versions of 
Xcode we'll fall back to using older compilers (GCC 4.2 rather than Clang, for 
instance) and those older compilers aren't tested by our build bots or most 
developers.

- Mark


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] svn.webkit.org

2012-03-01 Thread Mark Rowe

On 2012-03-01, at 03:37, Osztrogonac Csaba o...@inf.u-szeged.hu wrote:

 Hi All,
 
 To avoid overloading svn.webkit.org again and again with zillion svn
 checkout after rm -rf-ed working copies on the bots, I stopped all
 of our clobbered buildbot.
 
 After unbanning our network, I'll copy a locally tar-ed WebKit-svn
 copy to all bots and then restart them one by one not to overload
 svn.webkit.org.

You can get a relatively up to date working copy from 
http://nightly.webkit.org/files/WebKit-SVN-source.tar.bz2.

 And I'm thinking about how can we make buildbots more robust in the future.
 My first idea is that we should setup git mirrors for all WebKit port, and
 then make buildbots use these mirrors instead of svn.webkit.org. To do it,
 we need to modify the master.cfg a little bit.

There are two different options that we're investigating to address this 
thundering herd problem that tends to kill SVN after buildbot downtime:
1) Teach build slaves to fetch and unpack 
http://nightly.webkit.org/files/WebKit-SVN-source.tar.bz2 rather than using 
svn checkout.
2) Add additional hardware and load-balance svn.webkit.org across several 
machines so that the spike in load is distributed.

I have a rough version of the former working locally on a test master I set up. 
I should be able to get it cleaned up enough to be usable later this week.  The 
latter is obviously a more involved solution but would also generally improve 
SVN performance.  I expect that we'll continue to pursue that solution 
regardless.

 -
 class Factory(factory.BuildFactory):
def __init__(self, platform, configuration, architectures, buildOnly, 
 features=None, **kwargs):
factory.BuildFactory.__init__(self)
self.addStep(ConfigureBuild, platform=platform, 
 configuration=configuration, architecture= .join(architectures), 
 buildOnly=buildOnly, features=features)
self.addStep(CheckOutSource)
self.addStep(KillOldProcesses)
 ...
 -
 
 To migrate the bots simple from svn to git isn't a good solution, because in 
 this case
 we'll loose the svn revision number on the waterfall. My idea is that replace 
 the
 self.addStep(CheckOutSource) to calling a shell/perl/python script which 
 updates
 the local copy from the Qt/GTK/Apple/Chromium/... git mirror with the 
 following way:
 - git fetch
 - git reset --hard `git svn find-rev 
 rsvn-revision-number-got-from-the-master`
 
 I'm going to implement this initial git updater script this week and try to 
 migrate our
 bots on build.webkit.sed.hu to use it. If we manage to make it stable, we can 
 make
 build.webkit.org slaves to use it too. How does it sound? Any better idea?

Pulling from git instead of SVN is certainly worth considering, but I wouldn't 
be surprised if this simply shifted the performance issue from svn.webkit.org 
to git.webkit.org.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] svn.webkit.org

2012-03-01 Thread Mark Rowe

On 2012-03-01, at 04:28, Osztrogonac Csaba o...@inf.u-szeged.hu wrote:

 Mark Rowe írta:
 On 2012-03-01, at 03:37, Osztrogonac Csaba o...@inf.u-szeged.hu wrote:
 After unbanning our network, I'll copy a locally tar-ed WebKit-svn
 copy to all bots and then restart them one by one not to overload
 svn.webkit.org.
 You can get a relatively up to date working copy from 
 http://nightly.webkit.org/files/WebKit-SVN-source.tar.bz2.
 
 We always have relatively up-to-date working copy. It is faster then 
 downloading
 from you. ;) (I tried to download this nightly and the ETA is ~3 hours ...)
 Additionally we use svn 1.7 (to make our bots faster, and less IO intensive)
 which has different working copy than svn 1.6 .

I'm surprised that it downloads so slowly for you. Do you have a rough idea how 
long a fresh svn checkout of WebKit trunk takes? I'd expect the tarball to 
download more quickly than svn can fetch.

 And I'm thinking about how can we make buildbots more robust in the future.
 My first idea is that we should setup git mirrors for all WebKit port, and
 then make buildbots use these mirrors instead of svn.webkit.org. To do it,
 we need to modify the master.cfg a little bit.
 There are two different options that we're investigating to address this 
 thundering herd problem that tends to kill SVN after buildbot downtime:
 1) Teach build slaves to fetch and unpack 
 http://nightly.webkit.org/files/WebKit-SVN-source.tar.bz2 rather than 
 using svn checkout.
 
 To do it, all slave must use same svn version.

They'd need to use the same version or newer. It's trivial to have the slave 
upgrade the working copy if necessary after unpacking it.

 2) Add additional hardware and load-balance svn.webkit.org across several 
 machines so that the spike in load is distributed.
 
 It is a good idea. ;)
 
 To migrate the bots simple from svn to git isn't a good solution, because 
 in this case
 we'll loose the svn revision number on the waterfall. My idea is that 
 replace the
 self.addStep(CheckOutSource) to calling a shell/perl/python script which 
 updates
 the local copy from the Qt/GTK/Apple/Chromium/... git mirror with the 
 following way:
 - git fetch
 - git reset --hard `git svn find-rev 
 rsvn-revision-number-got-from-the-master`
 
 I'm going to implement this initial git updater script this week and try to 
 migrate our
 bots on build.webkit.sed.hu to use it. If we manage to make it stable, we 
 can make
 build.webkit.org slaves to use it too. How does it sound? Any better idea?
 Pulling from git instead of SVN is certainly worth considering, but I 
 wouldn't be surprised if this simply shifted the performance issue from 
 svn.webkit.org to git.webkit.org.
 
 No, I don't want to shift the load from svn.webkit.org to git.webkit.org. But 
 make all port
 maintainer to use their own git mirror for the bots instead of the root 
 svn/git.webkit.org.
 Mirroring git.webkit.org locally is the simplest thing in the world. :)

I'd prefer to avoid forcing people to set up their own mirrors if at all 
possible.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] git.webkit.org problem

2012-02-29 Thread Mark Rowe

On 2012-02-29, at 17:05, Lucas Forschler lforsch...@apple.com wrote:

 build.webkit.org should be back online now with 0.8.5.
 
 Thanks for your patience!

For anyone following along at home, upgrading to Buildbot v0.8.5 alone actually 
made build.webkit.org substantially slower. After profiling it for a while we 
noticed that it was spending an exceptionally long time performing queries 
against its SQLite database. Some analysis on the queries that were being run 
showed that the database lacked appropriate indices for the queries, causing 
full table scans across rather large tables. Ouch. A few CREATE INDEX … 
statements later and now build.webkit.org is responding much more quickly than 
it has been in quite some time.

If anyone notices any bad behavior that they suspect may be related to this 
upgrade, please let us know.

- Mark.

 Lucas
 
 On Feb 29, 2012, at 3:44 PM, Lucas Forschler wrote:
 
 I'm currenlty upgrading build.webkit.org from 0.8.3 to 0.8.5.  It should be 
 back online shortly.  
 Lucas
 
 On Feb 29, 2012, at 12:38 PM, Ryosuke Niwa wrote:
 
 On Wed, Feb 29, 2012 at 11:32 AM, Lucas Forschler lforsch...@apple.com 
 wrote:
 I am looking into improving performance of build.webkit.org.  After doing 
 some initial research I feel that buildbot isn't the most efficient in 
 terms of processing a large number of requests.  I believe requests are 
 processed serially, and not in parallel.  The buildbot documentation 
 mentions a limit to the number of slaves that can be supported, but doesn't 
 give any specific numbers.  As webkit has grown, and the number of builds 
 and slaves we are supporting has increased, it seems the server is showing 
 signs of reaching this capacity.  We may have reached a limit on the number 
 of slaves we can handle with our current configuration.
 
 On Chromium side, buildbot appears to leak a great amount of memory. e.g. 
 we end up running out of memory at some point because buildbot keeps 
 leaking some memory over time :(  Do you see the same issue on your 
 buildbot?
 
 -Upgrades to hardware.  It's possible faster hardware could alleviate some 
 problems.  It is unclear if this is really the limiting factor, or how much 
 additional capacity this would provide.
 
 My understanding is that we use a really fast server but still experience a 
 similar problem.
  
 -Updating the way files are transferred
 (https://bugs.webkit.org/show_bug.cgi?id=73484)
 
 Would it make sense to have a separate apache server, etc... for receiving 
 these files? twistd doesn't appear to be a cut out for 
 uploading/downloading megabytes of data.
 
 -Upgrade the version of buildbot. (0.8.3 - 0.8.5).  
 Version 0.8.4 and higher supposedly has a threading improvement, but 
 it's unclear how much it would benefit us since it looks to be mostly 
 database related.
 
 I've been told that upgrading buildbot didn't improve the performance. But 
 upgrading it to 0.8.5 is probably a good nonetheless since it fixes various 
 bugs I've encountered while maintaining Chromium bots and also when I ran 
 buildbot locally.
 
 -Investigating some kind of apache caching layer on top of buildbot
 
 MUST DO THIS. This will greatly reduce the latency for most people.
 
 -Adding a second master to the buildbot system.
 buildbot supports multi-master mode.  We could potentially split out 
 build and test onto two separate masters.
 build.webkit.org and test.webkit.org ?
 
 build.chromium.org takes this approach. But then we won't be able to see 
 both build and test step at once though... Would it make more sense to 
 split per port? e.g. Apple Mac  Apple Win, Qt  Gtk, Chromium  misc or 
 something along that line?
 
 - Ryosuke
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] git.webkit.org problem

2012-02-29 Thread Mark Rowe

On 2012-02-29, at 18:20, Dirk Pranke dpra...@chromium.org wrote:

 On Wed, Feb 29, 2012 at 6:10 PM, Mark Rowe mr...@apple.com wrote:
 
 On 2012-02-29, at 17:05, Lucas Forschler lforsch...@apple.com wrote:
 
 build.webkit.org should be back online now with 0.8.5.
 
 Thanks for your patience!
 
 
 For anyone following along at home, upgrading to Buildbot v0.8.5 alone
 actually made build.webkit.org substantially slower. After profiling it for
 a while we noticed that it was spending an exceptionally long time
 performing queries against its SQLite database. Some analysis on the queries
 that were being run showed that the database lacked appropriate indices for
 the queries, causing full table scans across rather large tables. Ouch. A
 few CREATE INDEX … statements later and now build.webkit.org is responding
 much more quickly than it has been in quite some time.
 
 If anyone notices any bad behavior that they suspect may be related to this
 upgrade, please let us know.
 
 
 svn.webkit.org (and trac) appears to be very unhappy at the moment;
 seems like this is likely related?

It may be that svn.webkit.org is unhappy about the thundering herd of 
reconnecting build slaves after the downtime.  We'll look in to it. 

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving WTF out of JavaScriptCore

2012-02-28 Thread Mark Rowe

On 2012-02-28, at 07:38, Osztrogonac Csaba o...@inf.u-szeged.hu wrote:

 Hi,
 
 I uploaded the necessary buildfix for Qt to the bugzilla: 
 https://bugs.webkit.org/show_bug.cgi?id=79783 .
 
 Please be careful with moving JavaScriptCore/wtf to WTF, because we
 need zillion trivial fixes for case sensitive file systems. (~4000 files!!!)
 
 I made it locally to be able prepare the Qt buildfix and I had to replace all
 wtf to WTF includes everywhere. (*.cpp, *.h, *.y, *.py, *.pl, *.pm, ...)
 The patch is huge, ~2Mb and ~4000 files are affected.
 
 I suggest landing the following patches separately:
 - Moving Sources/JavaScriptCore/wtf -- Sources/WTF
 - s/wtf/WTF/g patch :)

I hadn't considered this issue of case before.  Having to replace all instances 
of #include wtf/Foo.h with #include WTF/Foo.h will make this much, much 
more likely to cause breakages than if we left the original case alone. It also 
seems somewhat tangential to the goal of moving WTF out of JavaScriptCore.

- Mark

 Eric Seidel írta:
 We've been talking about moving WTF out of JavaScriptCore for a long
 time.  We believe we're nearly there.
 https://bugs.webkit.org/show_bug.cgi?id=75673
 This will mean that WTF will be built as a separate static library on all 
 ports.
 The plan is to do this move all in one piece, after work hours PST,
 when the tree is least active.
 It won't be the most beautiful transition (as we're likely to break at
 least one port in the process), but we'll try not to make too much of
 a mess.
 We believe all the ports are ready for the move, except AppleWin:
 https://bugs.webkit.org/show_bug.cgi?id=75897
 Once AppleWin is ready we'll schedule a date for the transition and
 announce it one this thread.
 Thanks!
 -eric
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving WTF out of JavaScriptCore

2012-02-28 Thread Mark Rowe

On 2012-02-28, at 17:11, Eric Seidel e...@webkit.org wrote:

 I'm fine with Source/wtf.  Very easy to implement.

I think this has the potential to cause problems.  It would lead to adding the 
Source directory to the header search path for some build systems, which would 
cause all sorts of weird #include styles to work even though we don't want to 
support them.  I'd suggest sticking with Source/WTF and the code inside a wtf 
subdirectory, and we can consider further reorganisation down the line if 
necessary.

- Mark

 
 On Tue, Feb 28, 2012 at 4:59 PM, Geoffrey Garen gga...@apple.com wrote:
 My current plan is to have a WTF/wtf directory to avoid this exact issue. :)
 
 
 WTF/wtf makes the think, WTF? -- which is a fun mental onomatopoeia, but
 probably not a great design.
 
 Just plain Source/wtf looks better to me.
 
 And to avoid the annoyance of 131 files in the root WTF directory.
 
 
 I'd prefer to solve this problem -- if it is a problem -- orthogonally.
 
 Geoff

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving WTF out of JavaScriptCore

2012-02-27 Thread Mark Rowe
This will require some coordination to ensure that it doesn't break Apple's 
internal builds. It would be great if you could post a patch ahead of time so 
that we have some time to test and prepare for the changes on our side.

Thanks,

- Mark

On 2012-02-27, at 15:27, Eric Seidel e...@webkit.org wrote:

 Thank you, particularly to the Qt/Gtk folks who further readied their
 ports for this move over the last month.
 
 We're ready to go forward with this.
 
 
 We will be moving Source/JavaScriptCore/wtf to Source/WTF (and
 associated build files) this Wednesday, Feb 27th, 5PM PST.
 
 
 The move will likely break a couple bots, but I'll be watching the
 bots and will pick up any pieces.
 
 Let me know if you have issues with this specific timeframe, and
 thanks again for all your help.
 
 -eric
 
 On Tue, Jan 10, 2012 at 10:35 AM, Eric Seidel e...@webkit.org wrote:
 If a Qt person wants to make this move even less error-prone for Qt,
 adding a newwtf.a library which just builds WTF/Stub.cpp and links it
 into JavaScriptCore (similar to what Mac, Gtk, and Chromium do today),
 then there won't need to be any guess work on my part when moving
 wtf.a  I'll have newwtf.a as an example.
 
 If you look in Source/WTF/ you can see examples of how Gtk, Mac and
 Chromium build/link in newwtf.a today.
 
 On Tue, Jan 10, 2012 at 7:41 AM, Jarred Nicholls jar...@webkit.org wrote:
 On Tue, Jan 10, 2012 at 5:41 AM, Alexis Menard alexis.men...@openbossa.org
 wrote:
 
 On Tue, Jan 10, 2012 at 7:07 AM, Alexis Menard
 alexis.men...@openbossa.org wrote:
 On Mon, Jan 9, 2012 at 8:36 PM, Eric Seidel e...@webkit.org wrote:
 We've been talking about moving WTF out of JavaScriptCore for a long
 time.  We believe we're nearly there.
 https://bugs.webkit.org/show_bug.cgi?id=75673
 
 This will mean that WTF will be built as a separate static library on
 all ports.
 
 The plan is to do this move all in one piece, after work hours PST,
 when the tree is least active.
 
 It won't be the most beautiful transition (as we're likely to break at
 least one port in the process), but we'll try not to make too much of
 a mess.
 
 We believe all the ports are ready for the move, except AppleWin:
 https://bugs.webkit.org/show_bug.cgi?id=75897
 
 Once AppleWin is ready we'll schedule a date for the transition and
 announce it one this thread.
 
 Hi Eric,
 
 Is there a patch somewhere or you are still working on it? The bug
 link contains nothing.
 
 I would like to apply it here and test the Qt port so you'll get a bit
 more confidence before landing it. I believe other ports are
 interested too.
 
 Nevermind wtf is already a static lib for Qt :D.
 
 /me is going to hide himself for not opening wtf.pro for a while.
 
 
 To be clear, if we're talking about moving Source/JavaScriptCore/wtf =
 Source/WTF, there would still be project file changes necessary to support
 that move, so testing it wouldn't hurt :)
 
 -Jarred
 
 
 
 
 Thanks.
 
 
 Thanks!
 
 -eric
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 
 --
 Alexis Menard (darktears)
 Software Engineer
 INdT Recife Brazil
 
 
 
 --
 Alexis Menard (darktears)
 Software Engineer
 INdT Recife Brazil
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving WTF out of JavaScriptCore

2012-02-27 Thread Mark Rowe

On 2012-02-27, at 15:46, Eric Seidel e...@webkit.org wrote:

 The patch will be large (and thus likely un-reviewable/readable). But
 sure.  I'll make sure to have a Mac-only patch for you by EOD
 tomorrow.

Mac-only in what sense?  We'd like to ensure it doesn't break our Windows 
builds too!

 I'll email this list with a link to the patch.

Thanks!

- Mark

 On Mon, Feb 27, 2012 at 3:43 PM, Mark Rowe mr...@apple.com wrote:
 This will require some coordination to ensure that it doesn't break Apple's 
 internal builds. It would be great if you could post a patch ahead of time 
 so that we have some time to test and prepare for the changes on our side.
 
 Thanks,
 
 - Mark
 
 On 2012-02-27, at 15:27, Eric Seidel e...@webkit.org wrote:
 
 Thank you, particularly to the Qt/Gtk folks who further readied their
 ports for this move over the last month.
 
 We're ready to go forward with this.
 
 
 We will be moving Source/JavaScriptCore/wtf to Source/WTF (and
 associated build files) this Wednesday, Feb 27th, 5PM PST.
 
 
 The move will likely break a couple bots, but I'll be watching the
 bots and will pick up any pieces.
 
 Let me know if you have issues with this specific timeframe, and
 thanks again for all your help.
 
 -eric
 
 On Tue, Jan 10, 2012 at 10:35 AM, Eric Seidel e...@webkit.org wrote:
 If a Qt person wants to make this move even less error-prone for Qt,
 adding a newwtf.a library which just builds WTF/Stub.cpp and links it
 into JavaScriptCore (similar to what Mac, Gtk, and Chromium do today),
 then there won't need to be any guess work on my part when moving
 wtf.a  I'll have newwtf.a as an example.
 
 If you look in Source/WTF/ you can see examples of how Gtk, Mac and
 Chromium build/link in newwtf.a today.
 
 On Tue, Jan 10, 2012 at 7:41 AM, Jarred Nicholls jar...@webkit.org wrote:
 On Tue, Jan 10, 2012 at 5:41 AM, Alexis Menard 
 alexis.men...@openbossa.org
 wrote:
 
 On Tue, Jan 10, 2012 at 7:07 AM, Alexis Menard
 alexis.men...@openbossa.org wrote:
 On Mon, Jan 9, 2012 at 8:36 PM, Eric Seidel e...@webkit.org wrote:
 We've been talking about moving WTF out of JavaScriptCore for a long
 time.  We believe we're nearly there.
 https://bugs.webkit.org/show_bug.cgi?id=75673
 
 This will mean that WTF will be built as a separate static library on
 all ports.
 
 The plan is to do this move all in one piece, after work hours PST,
 when the tree is least active.
 
 It won't be the most beautiful transition (as we're likely to break at
 least one port in the process), but we'll try not to make too much of
 a mess.
 
 We believe all the ports are ready for the move, except AppleWin:
 https://bugs.webkit.org/show_bug.cgi?id=75897
 
 Once AppleWin is ready we'll schedule a date for the transition and
 announce it one this thread.
 
 Hi Eric,
 
 Is there a patch somewhere or you are still working on it? The bug
 link contains nothing.
 
 I would like to apply it here and test the Qt port so you'll get a bit
 more confidence before landing it. I believe other ports are
 interested too.
 
 Nevermind wtf is already a static lib for Qt :D.
 
 /me is going to hide himself for not opening wtf.pro for a while.
 
 
 To be clear, if we're talking about moving Source/JavaScriptCore/wtf =
 Source/WTF, there would still be project file changes necessary to support
 that move, so testing it wouldn't hurt :)
 
 -Jarred
 
 
 
 
 Thanks.
 
 
 Thanks!
 
 -eric
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 
 --
 Alexis Menard (darktears)
 Software Engineer
 INdT Recife Brazil
 
 
 
 --
 Alexis Menard (darktears)
 Software Engineer
 INdT Recife Brazil
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Hanging builds

2011-11-30 Thread Mark Rowe

On 2011-11-29, at 10:00, Adam Roben wrote:

 On Nov 28, 2011, at 6:35 PM, Adam Roben wrote:
 
 On Nov 26, 2011, at 3:34 AM, Nikolas Zimmermann wrote:
 
 Good morning WebKit folks,
 
 I'm looking at build.webkit.org/waterfall, and see several bots which are 
 idle, but still report building  1min pretending they would do something.
 Does any of our build.webkit.org masters know the cause of this? They all 
 seem to hang in the upload step. Can we detect these errors, and avoid 
 that?
 Maybe sth. like a 30min timeout timer for this step?
 
 Thanks in advance,
 Niko
 
 P.S. I'm aware that a master restart would fix this, but maybe we can try 
 better and avoid that completely.
 
 More and more of these seemed to be piling up, so I restarted the master. I 
 don't know what causes them, though I suspect it has something to do with 
 slaves restarting during a download/upload step.
 
 It looks like Buildbot doesn't have support for setting a timeout for file 
 transfers. We could write our own file transfer step that uses rsync or 
 similar, which would allow us to use the standard timeout mechanism.

We used rsync for this in the distant past. It's a hassle from the point of 
view of the build master as it introduces a host of new authentication and 
permission issues.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)

2011-11-04 Thread Mark Rowe

On 2011-11-04, at 10:57, Kevin Ollivier wrote:

 Hi Steve,
 
 On Nov 4, 2011, at 9:12 AM, Steve Falkenburg wrote:
 
 
 On Nov 4, 2011, at 8:48 AM, Kevin Ollivier wrote:
 
 Step (2) here involves coming up with a good solution for export control 
 in both the WTF and platform cases. Today we use an explicit .exp file for 
 JavaScriptCore and WebCore on Mac and I believe a .def file in the Apple 
 Windows WebKit port. So there might be a necessary first step of moving to 
 a different export approach. And I know someone has been working on that.
 
 If you guys want to go the route of finishing up the export macros work, 
 let me know and I'll see what I can do. I probably can't devote a lot of 
 time to it for the next week or two, but I'd like to see this fixed 
 regardless of if it's used to move forward the WTF split, obviously, so I 
 can put a higher priority on it if I know there are reviewers waiting to 
 land things. :) 
 
 FWIW, I did distinguish between JS and WTF symbol export macros in the work 
 I've been doing, so the macros approach will support the split as-is.
 
 If WTF is to be a static library, there's no need to change anything in the 
 .def file on Windows.
 .def files apply only to DLLs.
 
 Yes, I know, just saying I'd be willing to help if they wanted to go the DLL 
 route. Making it static would make life easier for me also by allowing us to 
 remove the need for WTF symbol exports entirely, of course, so either way is 
 a plus for me.

WTF being a static library doesn't change anything with respect to exports.  It 
will still only be linked by a single dynamic library, and that library will be 
expected to export the necessary symbols for other clients. Doing otherwise 
would cause problems due to multiple instances of WTF's data being created 
(e.g., separate FastMalloc heaps for each library that linked directly to WTF).

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)

2011-11-04 Thread Mark Rowe

On 2011-11-04, at 11:56, Adam Barth wrote:

 Mark,
 
 I've created a stub WTF library at
 http://trac.webkit.org/browser/trunk/Source/WTF
 
 Would you be willing to create an appropriate xcodeproj file that
 builds Stub.h and Stub.cpp (and integrates with whatever magic is
 needed internally at Apple)?  I'm also happy to attempt webkit.org
 side of that change if you'd prefer, but I suspect you know better
 what the contrains are.

Yup, it's on my list.

- Mark

 
 On Wed, Nov 2, 2011 at 4:47 PM, Adam Barth aba...@webkit.org wrote:
 On Wed, Nov 2, 2011 at 4:35 PM, Mark Rowe mr...@apple.com wrote:
 On 2011-11-02, at 16:32, Adam Barth wrote:
 On Wed, Nov 2, 2011 at 4:09 PM, Mark Rowe mr...@apple.com wrote:
 On 2011-11-02, at 13:23, Adam Barth wrote:
 As discussed previously, I think it would benefit the project to move
 WTF out of JavaScriptCore:
 
 https://lists.webkit.org/pipermail/webkit-dev/2010-December/015427.html
 https://lists.webkit.org/pipermail/webkit-dev/2011-February/015940.html
 
 Previously, we've been unable to do this because of Apple's internal
 build process.  In thinking about this problem again recently, I
 wonder if the following would work:
 
 1) Move JavaScriptCore.xcodeproj from
 Source/JavaScriptCore/JavaScriptCore.xcodeproj to
 Source/JavaScriptCore.xcodeproj.
 2) Change how Apple submits JavaScriptCore to the internal build
 process to submit Source as the code for JavaScriptCore instead of
 Source/JavaScriptCore.
 3) Move Source/JavaScriptCore/WTF to Source/WTF.
 
 Mark, do you have a sense for whether this plan is feasible?  If not,
 is there another approach that would work better?
 
 (If my understanding is correct, we could also apply this approach to
 the other xcodeproj files, which would let us get rid of
 ForwardingHeaders and move Source/WebCore/platform to
 Source/Platform.)
 
 There are a few related goals here that I'm aware of:
 a) Separate WTF out of JavaScriptCore since it doesn't logically belong 
 there, but was simply a convenient home for it.
 b) Separate WebCore/platform out of WebCore to help avoid layering 
 violations.
 c) Rework the Mac build process so that we can eliminate forwarding 
 headers and remove the duplication of .xcconfig files.
 
 Yes.  These are the goals.
 
 The process for addressing a) and b) will be similar:
 1) Move the relevant code from its current location to the new location.
 2) Create a new Xcode project that builds the desired output in the 
 appropriate fashion. Update other build systems as is applicable.
 3) Apple starts including the new project in our build process.
 
 I don't see any benefit or need to move existing Xcode projects as part 
 of this process.  Can you expand on why you included this in your 
 proposal?
 
 Based on our previous discussions, I was unsure how difficult (3) was
 on your end.  If we can make (a) and (b) happen in the near term
 without moving xcodeproj files around, that would make me a happy
 camper.
 
 The code moving and the new Xcode project is relatively easy. I'm not sure 
 what will be involved in updating all of the other build systems though.
 
 I'm happy to coordinate that part of the effort.
 
 I'm not entirely clear on what we'll need to do to tackle c). My current 
 feeling is that it will mainly involve reshuffling of Apple's build 
 processes rather than any significant changes to WebKit.
 
 Maybe we should aim to do (a) first, then (b), and then work on (c)
 once we've figured out what needs to happen on Apple's end?
 
 My recollection of the situation with WebCore/platform is that there are a 
 number of existing layering violations in some ports.  Given the approach 
 outlined above I suspect they may need to be addressed before we can start 
 making progress on b).
 
 Yes.  Fixing these issues is going to be a fair amount of work.
 Perhaps it would make sense to create a stub Platform project for now,
 which will let us move code from WebCore/platform into Platform as we
 clean up the dependencies.
 
 Adam
 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)

2011-11-02 Thread Mark Rowe

On 2011-11-02, at 13:23, Adam Barth wrote:

 As discussed previously, I think it would benefit the project to move
 WTF out of JavaScriptCore:
 
 https://lists.webkit.org/pipermail/webkit-dev/2010-December/015427.html
 https://lists.webkit.org/pipermail/webkit-dev/2011-February/015940.html
 
 Previously, we've been unable to do this because of Apple's internal
 build process.  In thinking about this problem again recently, I
 wonder if the following would work:
 
 1) Move JavaScriptCore.xcodeproj from
 Source/JavaScriptCore/JavaScriptCore.xcodeproj to
 Source/JavaScriptCore.xcodeproj.
 2) Change how Apple submits JavaScriptCore to the internal build
 process to submit Source as the code for JavaScriptCore instead of
 Source/JavaScriptCore.
 3) Move Source/JavaScriptCore/WTF to Source/WTF.
 
 Mark, do you have a sense for whether this plan is feasible?  If not,
 is there another approach that would work better?
 
 (If my understanding is correct, we could also apply this approach to
 the other xcodeproj files, which would let us get rid of
 ForwardingHeaders and move Source/WebCore/platform to
 Source/Platform.)

There are a few related goals here that I'm aware of:
a) Separate WTF out of JavaScriptCore since it doesn't logically belong there, 
but was simply a convenient home for it.
b) Separate WebCore/platform out of WebCore to help avoid layering violations.
c) Rework the Mac build process so that we can eliminate forwarding headers and 
remove the duplication of .xcconfig files.

The process for addressing a) and b) will be similar:
1) Move the relevant code from its current location to the new location.
2) Create a new Xcode project that builds the desired output in the appropriate 
fashion. Update other build systems as is applicable.
3) Apple starts including the new project in our build process.

I don't see any benefit or need to move existing Xcode projects as part of this 
process.  Can you expand on why you included this in your proposal?

I'm not entirely clear on what we'll need to do to tackle c). My current 
feeling is that it will mainly involve reshuffling of Apple's build processes 
rather than any significant changes to WebKit.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)

2011-11-02 Thread Mark Rowe

On 2011-11-02, at 16:32, Adam Barth wrote:

 On Wed, Nov 2, 2011 at 4:09 PM, Mark Rowe mr...@apple.com wrote:
 On 2011-11-02, at 13:23, Adam Barth wrote:
 As discussed previously, I think it would benefit the project to move
 WTF out of JavaScriptCore:
 
 https://lists.webkit.org/pipermail/webkit-dev/2010-December/015427.html
 https://lists.webkit.org/pipermail/webkit-dev/2011-February/015940.html
 
 Previously, we've been unable to do this because of Apple's internal
 build process.  In thinking about this problem again recently, I
 wonder if the following would work:
 
 1) Move JavaScriptCore.xcodeproj from
 Source/JavaScriptCore/JavaScriptCore.xcodeproj to
 Source/JavaScriptCore.xcodeproj.
 2) Change how Apple submits JavaScriptCore to the internal build
 process to submit Source as the code for JavaScriptCore instead of
 Source/JavaScriptCore.
 3) Move Source/JavaScriptCore/WTF to Source/WTF.
 
 Mark, do you have a sense for whether this plan is feasible?  If not,
 is there another approach that would work better?
 
 (If my understanding is correct, we could also apply this approach to
 the other xcodeproj files, which would let us get rid of
 ForwardingHeaders and move Source/WebCore/platform to
 Source/Platform.)
 
 There are a few related goals here that I'm aware of:
 a) Separate WTF out of JavaScriptCore since it doesn't logically belong 
 there, but was simply a convenient home for it.
 b) Separate WebCore/platform out of WebCore to help avoid layering 
 violations.
 c) Rework the Mac build process so that we can eliminate forwarding headers 
 and remove the duplication of .xcconfig files.
 
 Yes.  These are the goals.
 
 The process for addressing a) and b) will be similar:
 1) Move the relevant code from its current location to the new location.
 2) Create a new Xcode project that builds the desired output in the 
 appropriate fashion. Update other build systems as is applicable.
 3) Apple starts including the new project in our build process.
 
 I don't see any benefit or need to move existing Xcode projects as part of 
 this process.  Can you expand on why you included this in your proposal?
 
 Based on our previous discussions, I was unsure how difficult (3) was
 on your end.  If we can make (a) and (b) happen in the near term
 without moving xcodeproj files around, that would make me a happy
 camper.

The code moving and the new Xcode project is relatively easy. I'm not sure what 
will be involved in updating all of the other build systems though.

 I'm not entirely clear on what we'll need to do to tackle c). My current 
 feeling is that it will mainly involve reshuffling of Apple's build 
 processes rather than any significant changes to WebKit.
 
 Maybe we should aim to do (a) first, then (b), and then work on (c)
 once we've figured out what needs to happen on Apple's end?

My recollection of the situation with WebCore/platform is that there are a 
number of existing layering violations in some ports.  Given the approach 
outlined above I suspect they may need to be addressed before we can start 
making progress on b).

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)

2011-11-02 Thread Mark Rowe

On 2011-11-02, at 16:42, Darin Adler wrote:

 On Nov 2, 2011, at 4:09 PM, Mark Rowe wrote:
 
 There are a few related goals here that I'm aware of:
 a) Separate WTF out of JavaScriptCore since it doesn't logically belong 
 there, but was simply a convenient home for it.
 b) Separate WebCore/platform out of WebCore to help avoid layering 
 violations.
 c) Rework the Mac build process so that we can eliminate forwarding headers 
 and remove the duplication of .xcconfig files.
 
 The process for addressing a) and b) will be similar:
 1) Move the relevant code from its current location to the new location.
 2) Create a new Xcode project that builds the desired output in the 
 appropriate fashion. Update other build systems as is applicable.
 3) Apple starts including the new project in our build process.
 
 Step (2) here involves coming up with a good solution for export control in 
 both the WTF and platform cases. Today we use an explicit .exp file for 
 JavaScriptCore and WebCore on Mac and I believe a .def file in the Apple 
 Windows WebKit port. So there might be a necessary first step of moving to a 
 different export approach. And I know someone has been working on that.

My current line of thinking was that WTF would build as a static library. 
JavaScriptCore's existing mechanism for exporting symbols should be sufficient 
to ensure that the necessary WTF symbols are still exposed.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] How does a *Prefix.h work on other platforms?

2011-09-07 Thread Mark Rowe

On 2011-09-07, at 21:22, Xianzhu Wang (王显著) wrote:

 Hi,
 
 There are some *Prefix.h files that I guess are injected as header files into 
 *.cpp files when compiling with xcode. I guess on other platforms they are 
 just no use and the source files should include all necessary header files, 
 right?
 
 However, a file in question is Tools/TestWebKitAPI/TestWebKitAPIPrefix.h 
 which injects '#include gtest/gtest.h' the unit test source files which 
 don't have the includes. AFAIK TestWebKitAPI works on Mac and Windows, but I 
 haven't found anything in TestWebKitAPI.vcproj for injecting 
 TestWebKitAPIPrefix.h into the source files. How does this work on Windows?

Tools/TestWebKitAPI/Configurations/TestWebKitAPICommon.vsprops: 
ForcedIncludeFiles=TestWebKitAPIPrefix.h

- Mark


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Snow Leopard Leaks Bot out of Disk Space

2011-08-08 Thread Mark Rowe

On 2011-08-08, at 17:16, Eric Seidel wrote:

 http://build.webkit.org/builders/SnowLeopard%20Intel%20Leaks/builds/18482/steps/layout-test/logs/stdio
 
 2011-08-08 16:03:36,710 67413 manager.py:1403 ERROR worker/0 raised
 OSError('[Errno 28] No space left on device:
 '/var/folders/dR/dRbf9KVoHs0rNZjRONbHTU+++TI/-Tmp-/DumpRenderTree-CL_oFh''):
 
 It's possible that the out-of-disk space is entirely my fault.  I just
 switched the bot over to NRWT today and maybe I'm writing gigs of data
 to the HD somehow.
 
 If someone with access to the bot could SSH in, clean up a little, and
 tell me if I caused the out of disk, that would be fantastic.

The issue is that the AppleSpell process is inheriting the environment from the 
process that required it.  On the leaks bot this is DumpRenderTree with 
MallocStackLogging=YES set.  AppleSpell appears to be a long-running service 
that never exits on its own.  This causes its stack log file to grow without 
bound.  I've cleaned up the disk space it was using for now.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Time for the next 32bit hack?

2011-07-20 Thread Mark Rowe

On 2011-07-20, at 00:35, Nikolas Zimmermann wrote:

 Good morning fellow WebKit crowd,
 
 Leopard fails to link since a while.
 
 Ld 
 /Volumes/Big/WebKit-BuildSlave/leopard-intel-release/build/WebKitBuild/Release/WebCore.framework/Versions/A/WebCore
  normal i386
 cd 
 /Volumes/Big/WebKit-BuildSlave/leopard-intel-release/build/Source/WebCore
 setenv MACOSX_DEPLOYMENT_TARGET 10.5
 /Developer/usr/bin/g++-4.2 -arch i386 -dynamiclib 
 -L/Volumes/Big/WebKit-BuildSlave/leopard-intel-release/build/WebKitBuild/Release
  
 -F/Volumes/Big/WebKit-BuildSlave/leopard-intel-release/build/WebKitBuild/Release
  -F/System/Library/Frameworks/Carbon.framework/Frameworks 
 -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks 
 -F/System/Library/Frameworks/CoreServices.framework/Frameworks 
 -F/System/Library/PrivateFrameworks -filelist 
 /Volumes/Big/WebKit-BuildSlave/leopard-intel-release/build/WebKitBuild/WebCore.build/Release/WebCore.build/Objects-normal/i386/WebCore.LinkFileList
  -Wl,--no-demangle -exported_symbols_list 
 /Volumes/Big/WebKit-BuildSlave/leopard-intel-release/build/WebKitBuild/Release/DerivedSources/WebCore/WebCore.exp
  -install_name 
 /Volumes/Big/WebKit-BuildSlave/leopard-intel-release/build/WebKitBuild/Release/WebCore.framework/Versions/A/WebCore
  -mmacosx-version-min=10.5 -Wl,-dead_strip -lWebCoreSQLite3 -lobjc -lANGLE 
 -allowable_client WebCoreTestSupport -sub_library libobjc -umbrella WebKit 
 -framework Accelerate -framework ApplicationServices -framework AudioToolbox 
 -framework AudioUnit -framework Carbon -framework Cocoa -framework CoreAudio 
 -framework IOKit -framework JavaScriptCore -licucore -lobjc -lxml2 -lz 
 -framework OpenGL -framework QuartzCore -framework SystemConfiguration 
 -Wl,-single_module -compatibility_version 1 -current_version 535.1 -o 
 /Volumes/Big/WebKit-BuildSlave/leopard-intel-release/build/WebKitBuild/Release/WebCore.framework/Versions/A/WebCore
 ld: in /System/Library/Frameworks//AppKit.framework/AppKit, can't map file, 
 errno=12
 collect2: ld returned 1 exit status
 I've turned on several more AllInOne files on my local Snow Leopard 32bit 
 machine, in order to get it to build in debug mode (I keep these local hacks 
 around since at least 6 months, since then 32bit dbg builds are failing for 
 me, w/o tricks).
 It seems we have to turn on more AllInOne files
 
 Maybe anyone wise here knows other tricks how to get 32bit builds to work 
 again w/o having to build lots of cpp files in AllInOne mode.

I'm inclined to say that building on a 32-bit only SnowLeopard machine isn't a 
configuration that we should support going forward.  That means that the 
problem will address itself when Leopard support goes away.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] LayoutTests results fallback graph

2011-07-10 Thread Mark Rowe

On 2011-07-10, at 10:52, Adam Barth wrote:

 Hi webkit-dev,
 
 In trying to understand how our LayoutTest results system works, I've
 created a digram of the fallback graph among the various
 platform-specific directories:
 
 https://docs.google.com/drawings/d/1z65SKkWrD4Slm6jobIphHwwRADyUtjOAxwGBVKBY8Kc/edit?hl=en_US
 
 Unfortunately, the fallback graph is not a tree, as one might imagine
 initially.  I'd like to propose two small changes, which will
 hopefully make the system more sensible globally.  I'm happy to do all
 the work required to make these changes:
 
 1) The win port should fall back either to all (the platform
 independent results) or to mac, but not to mac-snowleopard, as it
 does currently.  (I slightly prefer all, but mac would also be
 fine with me.)

I'd argue that falling back to mac doesn't make any sense.  The regression 
tests are run against a WebKit using the latest shipping Safari's version of 
the underlying dependencies.  That almost always corresponds to the latest 
shipping Mac OS X release's components, and not to the components from future 
versions of Mac OS X.

I also think that falling back to all would only be advisable if we were to 
also switch Windows DRT away from the legacy Mac-style form controls and 
rebaseline all of the Windows test results. We've shied away from this in the 
past because it would result in a big increase in the number of 
Windows-specific results.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] LayoutTests results fallback graph

2011-07-10 Thread Mark Rowe

On 2011-07-10, at 12:46, Adam Barth wrote:

 On Sun, Jul 10, 2011 at 12:38 PM, Mark Rowe mr...@apple.com wrote:
 On 2011-07-10, at 10:52, Adam Barth wrote:
 Hi webkit-dev,
 
 In trying to understand how our LayoutTest results system works, I've
 created a digram of the fallback graph among the various
 platform-specific directories:
 
 https://docs.google.com/drawings/d/1z65SKkWrD4Slm6jobIphHwwRADyUtjOAxwGBVKBY8Kc/edit?hl=en_US
 
 Unfortunately, the fallback graph is not a tree, as one might imagine
 initially.  I'd like to propose two small changes, which will
 hopefully make the system more sensible globally.  I'm happy to do all
 the work required to make these changes:
 
 1) The win port should fall back either to all (the platform
 independent results) or to mac, but not to mac-snowleopard, as it
 does currently.  (I slightly prefer all, but mac would also be
 fine with me.)
 
 I'd argue that falling back to mac doesn't make any sense.  The regression 
 tests are run against a WebKit using the latest shipping Safari's version of 
 the underlying dependencies.  That almost always corresponds to the latest 
 shipping Mac OS X release's components, and not to the components from 
 future versions of Mac OS X.
 
 There appears to be almost zero practical different between win
 falling back to mac versus falling back to mac-snowleopard:
 
 abarth@quadzen:~/git/webkit/LayoutTests/platform$ find mac -name *.png | wc 
 -l
6688
 abarth@quadzen:~/git/webkit/LayoutTests/platform$ find
 mac-snowleopard/ -name *.png | wc -l
   3

I'm not sure what that is meant to convey.  What you're proposing is changing 
the fallback path for the Windows port from one that is conceptually correct 
with one that is incorrect.  Neither your emails so far nor the diagram in your 
initial message have provided any explanation as to why this is.  Perhaps you'd 
like to expand on what purpose this proposed change has and what benefits it 
would provide.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] LayoutTests results fallback graph

2011-07-10 Thread Mark Rowe

On 2011-07-10, at 13:20, Adam Barth wrote:

 Sure.  I'll highlight the relevant section of my original email:
 
 On Sun, Jul 10, 2011 at 10:52 AM, Adam Barth aba...@webkit.org wrote:
 These changes have the following virtues:
 
 A) The resulting fallback graph will be a tree, making the fallback
 graph easier to understand for both humans and automated tools.

I don't see how Windows falling back to mac-snowleopard has any effect on that. 
 It's no different than mac-leopard in that regard.  Then again, maybe the 
diagram is trying to convey something that I'm missing due to having no idea 
what the difference is between the myriad of different line styles in the 
diagram.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] LayoutTests results fallback graph

2011-07-10 Thread Mark Rowe
On Jul 10, 2011, at 13:57, Adam Barth aba...@webkit.org wrote:

 On Sun, Jul 10, 2011 at 1:26 PM, Mark Rowe mr...@apple.com wrote:
 On 2011-07-10, at 13:20, Adam Barth wrote:
 Sure.  I'll highlight the relevant section of my original email:
 
 On Sun, Jul 10, 2011 at 10:52 AM, Adam Barth aba...@webkit.org wrote:
 These changes have the following virtues:
 
 A) The resulting fallback graph will be a tree, making the fallback
 graph easier to understand for both humans and automated tools.
 
 I don't see how Windows falling back to mac-snowleopard has any effect on 
 that.  It's no different than mac-leopard in that regard.  Then again, maybe 
 the diagram is trying to convey something that I'm missing due to having no 
 idea what the difference is between the myriad of different line styles in 
 the diagram.
 
 Notice that the circle for win has two arrows emanating from it.
 One of those arrows goes to mac and the other goes to
 mac-snowleopard.  That means that of the fallback paths that transit
 win, one path flows through mac-snowlepard where as the remainder
 flow through mac.  If we change win to fall back to mac, then
 the graph becomes more tree-like.  (If make change (2) as well, then
 the graph globally becomes a tree.)

Can you please clarify what the edges in your diagram, along with what the 
different line styles, represent?

- Mark

Sent from my iPhone


 
 Having the fallback graph not be a tree causes some strange and
 confusing anomalies, which I'd be happy to explain if you don't see
 the value in using a fallback tree rather than a fallback DAG.
 
 Adam
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] LayoutTests results fallback graph

2011-07-10 Thread Mark Rowe
On Jul 10, 2011, at 14:27, Adam Barth aba...@webkit.org wrote:

 On Sun, Jul 10, 2011 at 2:06 PM, Mark Rowe mr...@apple.com wrote:
 On Jul 10, 2011, at 13:57, Adam Barth aba...@webkit.org wrote:
 On Sun, Jul 10, 2011 at 1:26 PM, Mark Rowe mr...@apple.com wrote:
 On 2011-07-10, at 13:20, Adam Barth wrote:
 Sure.  I'll highlight the relevant section of my original email:
 
 On Sun, Jul 10, 2011 at 10:52 AM, Adam Barth aba...@webkit.org wrote:
 These changes have the following virtues:
 
 A) The resulting fallback graph will be a tree, making the fallback
 graph easier to understand for both humans and automated tools.
 
 I don't see how Windows falling back to mac-snowleopard has any effect on 
 that.  It's no different than mac-leopard in that regard.  Then again, 
 maybe the diagram is trying to convey something that I'm missing due to 
 having no idea what the difference is between the myriad of different line 
 styles in the diagram.
 
 Notice that the circle for win has two arrows emanating from it.
 One of those arrows goes to mac and the other goes to
 mac-snowleopard.  That means that of the fallback paths that transit
 win, one path flows through mac-snowlepard where as the remainder
 flow through mac.  If we change win to fall back to mac, then
 the graph becomes more tree-like.  (If make change (2) as well, then
 the graph globally becomes a tree.)
 
 Can you please clarify what the edges in your diagram, along with what the 
 different line styles, represent?
 
 Sure.

Thanks. My confusion here comes from the idea that Windows falling back on 
SnowLeopard causes some sort of non-tree-like complexity that other platforms 
falling back via SnowLeopard aren't also subject to. The behaviour of Leopard 
and Windows seems incredibly similar in this regard so I'm very unclear as to 
why only Windows is problematic.

There's an additional confusing element here:  Only a subset of Lion-specific 
results are currently checked in. The difference between mac and 
mac-snowleopard results is likely much bigger than you realise.

- Mark

Sent from my iPhone

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] LayoutTests results fallback graph

2011-07-10 Thread Mark Rowe
We seem to be talking past one another. Why are there two edges originating at 
win, but not mac-leopard?

Sent from my iPhone

On Jul 10, 2011, at 15:23, Adam Barth aba...@webkit.org wrote:

 On Sun, Jul 10, 2011 at 2:50 PM, Mark Rowe mr...@apple.com wrote:
 On Jul 10, 2011, at 14:27, Adam Barth aba...@webkit.org wrote:
 On Sun, Jul 10, 2011 at 2:06 PM, Mark Rowe mr...@apple.com wrote:
 On Jul 10, 2011, at 13:57, Adam Barth aba...@webkit.org wrote:
 On Sun, Jul 10, 2011 at 1:26 PM, Mark Rowe mr...@apple.com wrote:
 On 2011-07-10, at 13:20, Adam Barth wrote:
 Sure.  I'll highlight the relevant section of my original email:
 
 On Sun, Jul 10, 2011 at 10:52 AM, Adam Barth aba...@webkit.org wrote:
 These changes have the following virtues:
 
 A) The resulting fallback graph will be a tree, making the fallback
 graph easier to understand for both humans and automated tools.
 
 I don't see how Windows falling back to mac-snowleopard has any effect 
 on that.  It's no different than mac-leopard in that regard.  Then 
 again, maybe the diagram is trying to convey something that I'm missing 
 due to having no idea what the difference is between the myriad of 
 different line styles in the diagram.
 
 Notice that the circle for win has two arrows emanating from it.
 One of those arrows goes to mac and the other goes to
 mac-snowleopard.  That means that of the fallback paths that transit
 win, one path flows through mac-snowlepard where as the remainder
 flow through mac.  If we change win to fall back to mac, then
 the graph becomes more tree-like.  (If make change (2) as well, then
 the graph globally becomes a tree.)
 
 Can you please clarify what the edges in your diagram, along with what the 
 different line styles, represent?
 
 Sure.
 
 Thanks. My confusion here comes from the idea that Windows falling back on 
 SnowLeopard causes some sort of non-tree-like complexity that other 
 platforms falling back via SnowLeopard aren't also subject to. The behaviour 
 of Leopard and Windows seems incredibly similar in this regard so I'm very 
 unclear as to why only Windows is problematic.
 
 Being a tree is a global property, not a local property.  There are
 two edges emanating from win.  In order for the graph to be a tree
 one of them must be removed.  Neither one, in isolation, makes the
 graph not a tree.
 
 There's an additional confusing element here:  Only a subset of 
 Lion-specific results are currently checked in. The difference between mac 
 and mac-snowleopard results is likely much bigger than you realise.
 
 Ah, well, I, of course, can't see invisible results.
 
 Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] LayoutTests results fallback graph

2011-07-10 Thread Mark Rowe
Ok, the fact that chromium-win's fallback behaviour uses win results but 
doesn't match win's fallback behaviour is what I was missing. Couldn't we also 
address that by changing the behaviour of chromium-win?

- Mark

Sent from my iPhone

On Jul 10, 2011, at 15:55, Adam Barth aba...@webkit.org wrote:

 Because the LayoutTest fallback graph is a mess, hence this email thread.  :)
 
 More proximately, because when the chromium-mac-leopard (for
 example) fallback path flows through mac-leopard, it flows to
 mac-snowleopard alongside the fallback path that originates with
 mac-leopard.  Now, in the case of win, when the chromium-win
 (for example) fallback path flows through win, it flows thereafter
 to mac directly whereas the fallback path that originates with win
 takes a detour by way of mac-snowleopard.  The fact that these two
 fallback paths diverge at this point is one of the reasons the
 fallback graph is not a tree.
 
 Adam
 
 
 On Sun, Jul 10, 2011 at 3:32 PM, Mark Rowe mr...@apple.com wrote:
 We seem to be talking past one another. Why are there two edges originating 
 at win, but not mac-leopard?
 
 Sent from my iPhone
 
 On Jul 10, 2011, at 15:23, Adam Barth aba...@webkit.org wrote:
 
 On Sun, Jul 10, 2011 at 2:50 PM, Mark Rowe mr...@apple.com wrote:
 On Jul 10, 2011, at 14:27, Adam Barth aba...@webkit.org wrote:
 On Sun, Jul 10, 2011 at 2:06 PM, Mark Rowe mr...@apple.com wrote:
 On Jul 10, 2011, at 13:57, Adam Barth aba...@webkit.org wrote:
 On Sun, Jul 10, 2011 at 1:26 PM, Mark Rowe mr...@apple.com wrote:
 On 2011-07-10, at 13:20, Adam Barth wrote:
 Sure.  I'll highlight the relevant section of my original email:
 
 On Sun, Jul 10, 2011 at 10:52 AM, Adam Barth aba...@webkit.org 
 wrote:
 These changes have the following virtues:
 
 A) The resulting fallback graph will be a tree, making the fallback
 graph easier to understand for both humans and automated tools.
 
 I don't see how Windows falling back to mac-snowleopard has any effect 
 on that.  It's no different than mac-leopard in that regard.  Then 
 again, maybe the diagram is trying to convey something that I'm 
 missing due to having no idea what the difference is between the 
 myriad of different line styles in the diagram.
 
 Notice that the circle for win has two arrows emanating from it.
 One of those arrows goes to mac and the other goes to
 mac-snowleopard.  That means that of the fallback paths that transit
 win, one path flows through mac-snowlepard where as the remainder
 flow through mac.  If we change win to fall back to mac, then
 the graph becomes more tree-like.  (If make change (2) as well, then
 the graph globally becomes a tree.)
 
 Can you please clarify what the edges in your diagram, along with what 
 the different line styles, represent?
 
 Sure.
 
 Thanks. My confusion here comes from the idea that Windows falling back on 
 SnowLeopard causes some sort of non-tree-like complexity that other 
 platforms falling back via SnowLeopard aren't also subject to. The 
 behaviour of Leopard and Windows seems incredibly similar in this regard 
 so I'm very unclear as to why only Windows is problematic.
 
 Being a tree is a global property, not a local property.  There are
 two edges emanating from win.  In order for the graph to be a tree
 one of them must be removed.  Neither one, in isolation, makes the
 graph not a tree.
 
 There's an additional confusing element here:  Only a subset of 
 Lion-specific results are currently checked in. The difference between mac 
 and mac-snowleopard results is likely much bigger than you realise.
 
 Ah, well, I, of course, can't see invisible results.
 
 Adam
 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] LayoutTests results fallback graph

2011-07-10 Thread Mark Rowe

On 2011-07-10, at 18:21, Adam Barth wrote:

 On Sun, Jul 10, 2011 at 6:20 PM, Mark Rowe mr...@apple.com wrote:
 On 2011-07-10, at 17:54, Adam Barth wrote:
 Yes.  As I said before:
 
 On Sun, Jul 10, 2011 at 3:23 PM, Adam Barth aba...@webkit.org wrote:
 Being a tree is a global property, not a local property.  There are
 two edges emanating from win.  In order for the graph to be a tree
 one of them must be removed.  Neither one, in isolation, makes the
 graph not a tree.
 
 Great.  Then I'd suggest we fix the Chromium Windows fallback path since 
 there are reasons not to change the regular Windows fallback path.
 
 Ok.  Thanks for taking the time to understand the issue.

Hopefully you'll remember this exchange in the future when you're about to send 
out mysterious, unlabeled diagrams :)

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] The WebKit2 bot is failing 100% of the tests

2011-07-01 Thread Mark Rowe

On 2011-06-30, at 23:51, Adam Barth wrote:

 The WebKit2 bot seems to be failing 100% of the tests:
 
 http://build.webkit.org/waterfall?show=SnowLeopard%20Intel%20Release%20(WebKit2%20Tests)
 
 The regression range appears to be the following:
 
 http://trac.webkit.org/log/trunk?rev=90166stop_rev=90160verbose=on
 
 That regression range has four patches that appear related to WebKit2,
 mostly related to API versioning.  I don't know enough about WebKit2
 to dig us out of this one, but hopefully someone on this list does.

It was one of my changes that broke this.  I went ahead and landed a fix in 
r90224.  Is there some reason that you didn't file a bug report about this 
issue or even email me directly about it?  If you'd done either of these things 
I would have seen it last night and had this fixed much sooner.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Proposal: Commit messages should start with a one-line summary of the change

2011-06-30 Thread Mark Rowe

On 2011-06-30, at 13:28, Adam Roben wrote:

 I'd like to propose that WebKit commit messages start with a one-line summary 
 of the change.
 
 This change would have two benefits:
 
 1) It would make it much easier to understand at a glance what the change 
 actually does.
 
 Our commit logs usually include a bug title, but the bug title only tells you 
 about the problem, not about the solution.
 
 2) It would make many of our tools work better.
 
 For instance, http://trac.webkit.org/log/trunk shows the first 75 
 characters or so of the commit message. Right now it's just a wall of dates 
 and author names, which are already shown in other parts of the UI. It would 
 show much more useful information if we had a one-line summary at the top of 
 the commit message. As another example, pretty much all git-based tools 
 assume the commit message starts with a one-line summary (e.g., git log 
 --pretty=oneline, gitk, webkit-patch post-commits, etc.), and work much 
 better when that is the case.
 
 Since our commit messages are almost always just a copy of our ChangeLog 
 entries, this should apply to ChangeLog entries too. Specifically, I suggest 
 one line be added to our ChangeLog template, yielding the following:


 2011-06-30  Adam Roben  aro...@apple.com
 
Need a one-line summary of your change (OOPS!)
 
Reviewed by NOBODY (OOPS!).
 
Need a short description and bug URL (OOPS!)
 
* FileIModified.cpp:

Most ChangeLog entries already have a one-line summary immediately after the 
Reviewed by line.  I'm not sure that there's any benefit to reordering these 
parts of the ChangeLog.

 Given this format, commit-log-editor will put the summary right at the top of 
 the commit log. webkit-patch will require modifications to do this correctly, 
 as represented by https://bugs.webkit.org/show_bug.cgi?id=26755.

commit-log-editor already does the right thing given our current format.  It's 
just that many people have switched to using webkit-patch, and it was never 
taught the correct format for commit messages.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Tiger

2011-05-03 Thread Mark Rowe

On 2011-05-03, at 10:58, Eric Seidel wrote:

 It looks like Tiger support in WebKit is slowly being removed.  There
 no longer is a libWebKitSystemInterfaceTiger.a in the project, nor is
 there a Tiger buildbot or tiger expectations.
 
 Can we go ahead and kill all the ifdefs too?  Or is it too early to
 call Tiger dead?

What ifdefs are you referring to?

- Mark


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.

2011-04-30 Thread Mark Rowe
This seems rather Chrome-centric for a webkit.org blog post.

- Mark

On 2011-04-30, at 01:55, Pavel Feldman wrote:

 An update.
 
 Pavel
 
 WebKit Remote Debugging
 Posted by Pavel Feldman on Saturday, April 30th, 2011 at 1:53 am
 As you might know, WebKit Web Inspector (aka Chrome Developer Tools) is 
 implemented as an HTML + CSS + JavaScript web application. What you might not 
 know is that Web Inspector can run outside of the rendering engine 
 environment and still provide complete set of its features to the end user.
 
 Debugging over the wire
 
 Running debugger outside the rendering engine is interesting because mobile 
 platforms do not often provide enough screen real estate for quality 
 debugging; they have network stack and CPU specifics that often affect page 
 load and runtime. Still, they are based on the WebCore rendering engine, they 
 could have Web Inspector instrumentation running and hence expose valuable 
 debugging information to the end user. Now that Web Inspector is functioning 
 out-of-process over the serialized-message-channel, attaching Web Inspector 
 window to the remote rendering engine is possible. Here is an example of the 
 remote debugging session using Chrome Developer Tools:
 
 1. Start your target browser (recent Chromium build or Google Chrome will do) 
 with the remote-debugging-port command line switch:
 
 Chromium.app/Contents/MacOS/Chromium --remote-debugging-port=9222
 
 2. Open several pages there.
 
 3. Navigate to the given port from your client browser instance (WebKit 
 nightly or another Chrome instance will do) and it will list inspectable 
 pages opened in the browser as web links.
 
 
 4. Follow any of these links to start remote debugging session for the 
 corresponding page.
 
 
 You will find remote debugging interface very similar to the Web Inspector / 
 Chrome Developer Tools and here is why:
 
 Target Chrome browser acts as a web server bound to the port 9222 on the 
 localhost.
 Once you follow the link, your client browser fetches HTML, JavaScript and 
 CSS files of the Developer Tools front-end over HTTP.
 Upon load event, Developer Tools establishes Web Socket connection back to 
 the target browser and starts interchanging JSON messages with it.
 In fact, pretty much the same scenario takes place within any WebKit-based 
 browser when user opens Web Inspector. The only difference is that the 
 transports being used for the JSON message interchange may vary. Note, that 
 in case of mobile devices, front-end files can also be served from the cloud.
 
 Remote Debugging Protocol
 
 Another scenario for remote debugging is IDE integration. Web IDEs would like 
 to provide seamless debugging experience integrated into their environments 
 to the end user. Exposing unified WebKit remote debugging protocol would 
 allow them to use alternate front-ends for the WebKit debugging.
 
 Under the hood, Web Inspector front-end is talking to the browser backend by 
 means of the Remote Debugging Protocol. This protocol is based on the 
 JSON-RPC 2.0 specification. It is bidirectional: clients send asynchronous 
 requests to the server, server responds to these requests and/or generates 
 notifications. Since API surface for general purpose web debugging is huge, 
 we divided it into a number of domains. Each domain contains requests and 
 notifications specific to some area. Here is the list of the domains 
 supported so far:
 
 Browser Debugger – allows setting breakpoints on particular DOM operations 
 and events. JavaScript execution will stop on these operations as if there 
 was a regular breakpoint set.
 Console – defines methods and events for interaction with the JavaScript 
 console.
 CSS – exposes raw CSS read / write operations.
 Debugger – exposes JavaScript debugging functions; allows setting and 
 removing breakpoints, stepping through execution, exploring stack traces, etc.
 DOM – This domain exposes DOM read/write operations.
 Network – allows tracking network activities of the page; exposes information 
 about HTTP and WebSocket requests and responses, their headers, bodies, raw 
 timing, etc.
 Page – actions and events related to the inspected page.
 Runtime – exposes JavaScript runtime by means of remote evaluation and mirror 
 objects.
 Timeline – provides its clients with instrumentation records that are 
 generated during the page runtime.
 You can find JSON schema defining the protocol here. For your convenience, we 
 generated documentation from this schema and published it on the Chrome 
 DevTools page. Note that there are few unlisted domains such as Application 
 Cache, DOM Storage, and Database, but they are not ready for the prime time 
 yet.
 
 What’s next
 
 We are now open to the feedback on the WebKit Remote Debugging Protocol. We 
 will collect all the feedback in the form of the bug reports and the Chrome 
 DevTools forum messages. We will then address initial feedback, polish the 
 protocol a bit and publish its 

Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.

2011-04-30 Thread Mark Rowe

On 2011-04-30, at 22:11, Pavel Feldman wrote:

 I see. It might be unfortunate branding, but the large amount of Web 
 Inspector users refer to it as Developer Tools. We use every opportunity to 
 tell users that it is the same thing, but this is not enough. The first 
 question we always get is Do you guys upstream any of your Chrome Dev Tools 
 code into the WebKit?. Which sounds crazy, because 100% of the code is 
 upstream. So it is probably just me trying to use both names to fix this. It 
 sounds like I should be more formal in this case and make the letter of the 
 post conform to its WebKit spirit.
 
 - I changed the phrasing to use Web Inspector only, there is no mention of 
 Chrome Dev Tools anymore.
 - Removed all Chrome mentions as well
 - There is now single mention of Chromium in the example scenario that I am 
 eager to keep. I truly believe that the example makes the post more lively. 
 There is nothing easier than posting this whole thing at chromium.org, but it 
 will harm the unified WebKit Remote Debugging Protocol message we are 
 trying to deliver.
 
 provocativeIn return, can I ask to rename the WebKit blog from Surfin' 
 Safari to something more WebKit-specific?/provocative

I've wondered the same thing myself on several occasions.

 So here is another update (posting the first topics that have changed). Mark, 
 Evan, do you think it is better now?

The update certainly addresses my concerns.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] OSX 64 bit plugin support not ready

2011-04-26 Thread Mark Rowe

On 2011-04-26, at 05:11, Alan Swartz wrote:

 That's good to know.  It's not the support of the Cocoa event model and 
 CoreGraphics that appears broken, it's that the code that checks these 
 options appears to be compiled out by the NP_NO_CARBON #define for 64 bit 
 builds in PlugInViewMac.mm.
  
 With the current code, I don't see how any NPAPI plug-ins could work on OSX 
 on 64-bit builds.

It's worth noting that what Kevin stated applies to Netscape plug-ins loaded 
via the Mac port of WebKit.  The Qt port of WebKit uses a different 
implementation of the Netscape plug-in API than the Mac port.  My reading of 
the Qt NPAPI implementation brings me to a similar conclusion to that which you 
reached: when NP_NO_CARBON is not defined the code in PluginViewMac.mm will not 
allow any  plug-ins to be loaded.  It's also worth noting that there does not 
appear to be any code in PluginViewMac.mm to deal with the Cocoa event model.  
This suggests that there is a non-trivial amount of work required in order for 
it to support plug-ins on 64-bit Mac OS X.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] UA string changes blog draft

2011-03-25 Thread Mark Rowe

On 2011-03-25, at 12:07, Peter Kasting wrote:

 On Fri, Mar 25, 2011 at 11:44 AM, Peter Kasting pkast...@google.com wrote:
 I've incorporated all the existing feedback into the draft.  Feel free to 
 take another look.
 
 Since some folks seem to be unable to see the draft even while logged in, 
 here's the new fulltext.
 
 PK
 
 ---
 
 User Agent String Changes On WebKit Trunk
 Posted by Peter Kasting on Friday, March 25th, 2011 at 11:44 am
 Recently some changes to the User Agent (UA) string have landed. These 
 changes are designed to add UA string detail, remove redundancy, and increase 
 compatibility with Internet Explorer, and are happening in conjunction with 
 similar changes in Firefox 4.
 
 Here are the equivalent post-change UA strings:
 
 Mozilla/5.0 (Windows NT 6.0; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) 
 Version/5.0.3 Safari/534.24
 
 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_7) AppleWebKit/534.24 (KHTML, 
 like Gecko) Version/5.0.3 Safari/534.24
 

Is there some reason why these examples use manufactured Safari build numbers?  
It's implausible that a version of Safari with a build number of 534.24 would 
ever claim to be version 5.0.3.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] UA string changes blog draft

2011-03-25 Thread Mark Rowe

On 2011-03-25, at 12:56, Peter Kasting wrote:

 On Fri, Mar 25, 2011 at 12:54 PM, Mark Rowe mr...@apple.com wrote:
 Is there some reason why these examples use manufactured Safari build 
 numbers?  It's implausible that a version of Safari with a build number of 
 534.24 would ever claim to be version 5.0.3.
 
 Sorry, I wasn't sure what the right numbers were.  What would be a more 
 accurate number?  I'd be happy to change it.

I'm not sure what you're asking here.  Safari 5.0.3 will always report a build 
version of 533.19.4. Safari 5.0.4 will always report a build version of 
533.20.27. You already used the former in your before examples.  You have 
also been inconsistent about the WebKit version number.  In the before 
version for the Mac user agent string you've included the + suffix that 
indicates an engineering build (from a local build or nightly).  This isn't 
present in the Windows before version or either of the after versions.  
Since that component isn't relevant to the point you're trying to make it seems 
like it would be preferable for it to be consistent between examples.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Build system update

2011-03-23 Thread Mark Rowe

On 2011-03-22, at 23:50, Adam Barth wrote:

 On Tue, Mar 22, 2011 at 8:14 PM, Mark Rowe mr...@apple.com wrote:
 On 2011-03-22, at 19:16, Adam Barth wrote:
 WebKit-folk,
 
 With a bunch of help from Dimitri and Eric, we now have a functioning
 GYP-based build for the Apple Mac port.  There are still a couple bugs
 we need to fix before this build system is ready for production
 (they're filed as blocking Bug 55018, if you're curious).  If you'd
 like to try out the GYP-based build, you can invoke it (on a Mac) as
 follows:
 
 ./Tools/Scripts/build-webkit --gyp
 
 Is this expected to work?  Running the command quoted above results in a 
 build failure in JavaScriptCore for me (jsc is unable to find UString.h).
 
 I'm not sure how to test with a case-sensitive file system on Mac.  (I
 didn't even know that was possible.)  How can I test that case?

Short of formatting a volume as case-sensitive HFS+, you can use Disk Utility 
to create a read/write disk image containing case-sensitive HFS+ and then 
perform a build on that disk image.

 If you just want to look at the generated project files, you can
 generate them using this command:
 
 ./Tools/Scripts/generate-project-files
 
 That script will create
 Source/JavaScriptCore/gyp/JavaScriptCore.xcodeproj and
 Source/WebCore/gyp/WebCore.xcodeproj (as well as a JavaScriptGlue
 project file, which you should feel free to ignore).
 
 Is it useful for me to file bugs about these generated projects?
 
 Definitely.  I appreciate your feedback.  If you can file them as
 blocking Bug 55018, that will ensure that they don't get lost.  I can
 check to make sure all the webkit.org requirements are satisfied, but
 I'm unable to verify that all the Apple-internal requirements are
 satisfied because they are opaque to me.

None of the issues I mentioned about the project file are related to any 
specific constraints that our build system places on us.  My primary concern 
here is ensuring that the Mac build system is understandable, repeatable, and 
easy to debug.  While some of the issues I've raised may seem picky, they're 
all things that contribute to that goal.


 A few issues I noticed while skimming the Xcode project files…
 The source is all hidden two levels deep in the hierarchy (inside a group 
 named ..?).
 There's an oddly-named BUILT_PRODUCTS_DIR group.
 There's a mysterious ForwardingHeaders group.
 The .xcconfig files are in the Source group.
 The script build phases are unnecessarily verbose ('Action …' or 
 'Postbuild …' where only '…' is meaningful).
 
 Yeah, these things are not very aesthetic.  They've been on my list to
 fix, but I haven't considered them to be a blocking issue to date.  Do
 you consider these blocking issues?  I'm happy to fix them, but I'd
 like to prioritize blocking issues.

These are the types of issues that make life confusing for anyone that wants to 
use the Xcode project for editing, debugging, or to simply get a feel for the 
project.  They certainly have no impact on the actual building of the code.

 Product names for targets are redundantly declared in the Xcode project when 
 they're already defined in the .xcconfig files.
 
 My plan for this issue is to remove the product names from the
 xcconfig files once they're not needed by the generated xcodeproj
 files.

That seems backwards.  JavaScriptCore.xcconfig defines how to create 
JavaScriptCore.framework.  The name of the framework (e.g., PRODUCT_NAME) is an 
important part of that, much like the install path, Info.plist file, etc.  I 
don't see how we benefit from that information being spread around.

 There are mysterious extra settings in the Xcode project that serve no 
 apparent purpose (EXECUTABLE_PREFIX, INTERMEDIATE_DIR, 
 SHARED_INTERMEDIATE_DIR, WRAPPER_PREFIX, ALWAYS_SEARCH_USER_PATHS?)
 
 Are these harmful?  We could figure out how to stop GYP from
 generating them, but I'm not aware of any problem they cause.

They're only harmful in the sense that they make it harder to understand the 
configuration of the Xcode project, which makes it harder to track down 
build-related issues.

 The default configuration is Debug rather than Production.
 
 Thanks.  I thought I had fixed that, but I'll investigate this issue
 some more.  I understand that this is a hard requirement.
 
 Updating Info.plist is done via a separate aggregate target rather than 
 simply being a script phase.
 
 Does that cause a problem?  The two seem equivalent.

There are plenty of roundabout ways in which one can achieve the same result.  
That doesn't make them equally good.

 The main advantage of this build system over the existing Apple Mac
 build system is that the list of files is shared between this build
 system and the Chromium build system.  That means one fewer location
 to update when adding, removing, or renaming a file.  Over time, we
 should be able to share more between the build systems (because they
 are written in a common language) and to share the list of files

Re: [webkit-dev] Build system update

2011-03-23 Thread Mark Rowe

On 2011-03-23, at 03:33, Adam Barth wrote:

 On Wed, Mar 23, 2011 at 12:22 AM, Mark Rowe mr...@apple.com wrote:
 On 2011-03-22, at 23:50, Adam Barth wrote:
 On Tue, Mar 22, 2011 at 8:14 PM, Mark Rowe mr...@apple.com wrote:
 
 Product names for targets are redundantly declared in the Xcode project 
 when they're already defined in the .xcconfig files.
 
 My plan for this issue is to remove the product names from the
 xcconfig files once they're not needed by the generated xcodeproj
 files.
 
 That seems backwards.  JavaScriptCore.xcconfig defines how to create 
 JavaScriptCore.framework.  The name of the framework (e.g., PRODUCT_NAME) is 
 an important part of that, much like the install path, Info.plist file, etc. 
  I don't see how we benefit from that information being spread around.
 
 The information about how to create JavaScriptCore.framework is
 already spread around to a certain extent.  For example,
 JavaScriptCore.xcconfig does not contain the list of files that need
 to be built or information about the dependencies.  I'm having a hard
 time seeing what the practical difference is between specifying the
 product name in the xcodeproj file or the xcconfig file.

What's the argument for changing where it is specified?  Is it simply because 
gyp doesn't know better?

 One area that I could use some help from one or more Apple folks is
 making sure that this build system integrates properly with Apple's
 internal build system.  Based on my (incomplete!) understanding of
 Apple's internal build system, there are at least two options:
 
 1) Apple's internal build system consumes Source in its entirety and
 builds a master WebKit.xcodeproj (or a Makefile), which abstracts
 further details about the build, such as how subsequent xcodeproj are
 created or how many libraries WebKit is factored into (e.g., letting
 us extract WTF from JavaScriptCore).
 
 Making that particular change is completely unrelated to GYP.
 
 My understanding is that it would solve the Apple internal build
 system integration issue because the Apple internal build system would
 transfer control to the master WebKit.xcodeproj, which could then
 invoke GYP to generate the remaining xcodeproj files.
 
 I'm not particularly keen on a solution that involves manually invoking 
 xcodebuild to build projects.  It becomes very complicated to ensure that 
 the correct settings, including any overridden settings, make it down to the 
 nested invocations of xcodebuild.
 
 I'm not sure I've correctly communicated how I envision this approach
 working.  If approach (2) doesn't work out for whatever reason, I can
 build a mockup of how this would work, which will be more concrete.

You'll need to provide more detail then because I cannot see how this would 
work in a manner that doesn't cause the problems I have noted.

 2) For each submission to Apple's internal build system, we create a
 branch, generate xcodeproj files, and check them into the branch.
 Apple's internal build system can then svn export the branch and see
 xcodeproj files, as today.
 
 While this is certainly technically feasible, it would add a huge amount 
 of overhead to the process of performing a submission.
 
 How often do you submit WebKit to the Apple internal build system?  If
 that's sensitive information, I'm just looking for an order of
 magnitude (e.g., every revision, every hour, every day, every week).
 As a reference, the Chromium project creates one branch per day for
 daily builds.
 
 I don't see how the frequency is relevant.
 
 The relevancy arises from the observation that the overhead is
 proportional to the frequency.  If we only submit WebKit to Apple's
 internal build system once a week, then this approach won't cause too
 much branch proliferation.  If, on the other hand, we're submitting
 every revision, then we're talking about doubling or tripling the
 revision burn rate, which might not be desirable.

The rate at which we use SVN revisions or the number of branches isn't of 
particular concern to me.  The simple fact is that your proposal turns a 
single, trivial operation (create a tag) in to a sequence of more complicated 
operations (create a branch, check it out, run a script to generate a bunch of 
files, test that it builds, commit the new files, create a tag).  What used to 
be a single command-line operation that took a second to run is now a series of 
operations that takes 5+ minutes to complete.

 In any case, I'm glad we've found a technically feasible solution.
 
 We've had at least one technically feasible solution from day zip: check in 
 the generated project files.
 
 From my perspective, approach (2) is more desirable than checking in
 generated project files because approach (2) encapsulates
 Apple-internal build process to Apple folks, more specifically to the
 Apple folks who interact with the Apple-internal build system.
 Checking in generated project files, on the other hand, imposes a
 maintenance burden on all WebKit

Re: [webkit-dev] Build system update

2011-03-23 Thread Mark Rowe

On 2011-03-23, at 13:49, Adam Barth wrote:

 On Wed, Mar 23, 2011 at 1:33 PM, David Levin le...@google.com wrote:
 On Wed, Mar 23, 2011 at 12:17 PM, Adam Barth aba...@webkit.org wrote:
 $ time git svn rebase
 [... update my working copy from changes during lunch (four revisions)
 ...]
 real1m10.316s
 user0m8.194s
 sys 0m16.400s
 
 $ time ./Tools/Scripts/generate-project-files
 real0m4.339s
 user0m3.888s
 sys 0m0.269s
 
 which is about 6.1% overhead on an almost trivial update.  We can also
 reduce this overhead to zero in many cases by detecting that we don't
 need to re-generate the project files if the inputs to the generation
 process haven't changed.
 
 It looks like you are using a slow mechanism for syncing. :)
 TLDR version: 8% overhead for updating 191 revisions. 49% overhead for
 trivial sync (3 revisions) -- in addition to the added complexity (when I
 sync or switch branches in git).
 Here's my results for updating 191 revisions (81605 through 81796).
 
 $ time git fetch  time git svn rebase
 
 fetch, svn rebase times
 real 0m21.071s, 0m36.195s
 user 0m2.271s, 0m3.205s
 sys 0m0.497s, 0m9.428s
 total 57 seconds for a nontrivial update.
 $ time ./Tools/Scripts/generate-project-files
 real 0m4.642s
 user 0m4.243s
 sys 0m0.322s
 
 An 8% overhead on a non-trivial sync.
 
 For a trivial update of 3 revisions:
 real 0m3.490s, 0m6.017s
 user 0m0.932s, 0m2.266s
 sys 0m0.184s, 0m2.824s
 For a total of 9.5 seconds.
 
 The generate project files step remained the same, so this adds a 49%
 overhead for a trivial sync.
 It also adds time (and complications) whenever I switch branches in git.
 dave
 PS For chromium, my experience is
 $ time gclient runhooks --force
 real 0m42.459s
 user 0m29.236s
 sys 0m2.543s
 I don't know enough about chromium build system and gyp to know why it is an
 order of magnitude slower, but this overhead is noticeable and annoying
 there. I love the idea of a one project file system, but I have concerns
 about project file generation on sync becoming the norm in WebKit. fwiw, I
 checked how many gyp files were in chromium and it appeared within 20%.
 
 There seem to be four approaches to improving this situation:
 
 1) Check in the generated project files.  In this approach, only one
 person pays the cost of generating the project files.
 
 2) Make generate-project-files run faster.  I haven't looked at what's
 taking 4 seconds, but it seems entirely possible that we can improve
 the performance.
 
 3) Avoid running generate-project-files when not necessary.  This
 approach would improve the performance of the trivial sync, for
 example.
 
 4) Run generate-project-files at time other than sync.  For example,
 we could run generate-project-files as part of build-webkit, which
 already takes more more than 4 seconds, leading to a lower percentage
 overhead.

People build much more frequently than the update, so 4 would have to be done 
in conjunction with 2 and/or 3.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Build system update

2011-03-22 Thread Mark Rowe

On 2011-03-22, at 19:16, Adam Barth wrote:

 WebKit-folk,
 
 With a bunch of help from Dimitri and Eric, we now have a functioning
 GYP-based build for the Apple Mac port.  There are still a couple bugs
 we need to fix before this build system is ready for production
 (they're filed as blocking Bug 55018, if you're curious).  If you'd
 like to try out the GYP-based build, you can invoke it (on a Mac) as
 follows:
 
 ./Tools/Scripts/build-webkit --gyp

Is this expected to work?  Running the command quoted above results in a build 
failure in JavaScriptCore for me (jsc is unable to find UString.h).

 If you just want to look at the generated project files, you can
 generate them using this command:
 
 ./Tools/Scripts/generate-project-files
 
 That script will create
 Source/JavaScriptCore/gyp/JavaScriptCore.xcodeproj and
 Source/WebCore/gyp/WebCore.xcodeproj (as well as a JavaScriptGlue
 project file, which you should feel free to ignore).

Is it useful for me to file bugs about these generated projects?

A few issues I noticed while skimming the Xcode project files…
The source is all hidden two levels deep in the hierarchy (inside a group named 
..?).
There's an oddly-named BUILT_PRODUCTS_DIR group.
There's a mysterious ForwardingHeaders group.
The .xcconfig files are in the Source group.
The script build phases are unnecessarily verbose ('Action …' or 'Postbuild 
…' where only '…' is meaningful).
Product names for targets are redundantly declared in the Xcode project when 
they're already defined in the .xcconfig files.
There are mysterious extra settings in the Xcode project that serve no apparent 
purpose (EXECUTABLE_PREFIX, INTERMEDIATE_DIR, SHARED_INTERMEDIATE_DIR, 
WRAPPER_PREFIX, ALWAYS_SEARCH_USER_PATHS?)
The default configuration is Debug rather than Production.
Updating Info.plist is done via a separate aggregate target rather than simply 
being a script phase.

 The main advantage of this build system over the existing Apple Mac
 build system is that the list of files is shared between this build
 system and the Chromium build system.  That means one fewer location
 to update when adding, removing, or renaming a file.  Over time, we
 should be able to share more between the build systems (because they
 are written in a common language) and to share the list of files
 between more ports.
 
 One area that I could use some help from one or more Apple folks is
 making sure that this build system integrates properly with Apple's
 internal build system.  Based on my (incomplete!) understanding of
 Apple's internal build system, there are at least two options:
 
 1) Apple's internal build system consumes Source in its entirety and
 builds a master WebKit.xcodeproj (or a Makefile), which abstracts
 further details about the build, such as how subsequent xcodeproj are
 created or how many libraries WebKit is factored into (e.g., letting
 us extract WTF from JavaScriptCore).

Making that particular change is completely unrelated to GYP.

 2) For each submission to Apple's internal build system, we create a
 branch, generate xcodeproj files, and check them into the branch.
 Apple's internal build system can then svn export the branch and see
 xcodeproj files, as today.

While this is certainly technically feasible, it would add a huge amount of 
overhead to the process of performing a submission.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Build system update

2011-03-22 Thread Mark Rowe

On 2011-03-22, at 21:28, Eric Seidel wrote:

 On Tue, Mar 22, 2011 at 8:14 PM, Mark Rowe mr...@apple.com wrote:
 
 On 2011-03-22, at 19:16, Adam Barth wrote:
 
 WebKit-folk,
 
 With a bunch of help from Dimitri and Eric, we now have a functioning
 GYP-based build for the Apple Mac port.  There are still a couple bugs
 we need to fix before this build system is ready for production
 (they're filed as blocking Bug 55018, if you're curious).  If you'd
 like to try out the GYP-based build, you can invoke it (on a Mac) as
 follows:
 
 ./Tools/Scripts/build-webkit --gyp
 
 Is this expected to work?  Running the command quoted above results in a 
 build failure in JavaScriptCore for me (jsc is unable to find UString.h).
 
 Interesting.  I just did a clean build (rm -rf WebKitBuild) with ToT
 and was unable to reproduce.  But I'd *love* to see the logs if you
 still have them.

The logs aren't accessible to me right now.  My suspicion is that it may be 
related to building on a case-sensitive filesystem.  It should be relatively 
easy to test this theory using a case-sensitive read/write disk image.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


  1   2   3   4   >