Re: [webkit-dev] If you like writing memory smashers, you'll love this
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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 ?
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?
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)
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)
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)
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)
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)
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)
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
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
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?
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
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?
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?
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?
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?
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
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
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
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
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
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?
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
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
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
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
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?
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?
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?
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
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
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
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
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
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
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
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
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
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
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
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
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)
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)
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)
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)
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)
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?
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
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?
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
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
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
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
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
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
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
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
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
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.
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.
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
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
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
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
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
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
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
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
[webkit-dev] A question about new-run-webkit-tests
On 2011-03-17, at 23:50, Ojan Vafai wrote: * For now, it only works with the bots that use new-run-webkit-tests. If anyone is interested in adding old-run-webkit-tests support, ping me. It should be relatively easy. Can someone explain the new-run-webkit-tests situation to me? The name suggests it is intended to replace run-webkit-tests. It's been more than a year since it was added and it obviously hasn't replaced run-webkit-tests. As best as I can tell it's not used by any ports unless one happens to invoke it directly. It appears to has new functionality that run-webkit-tests lacks, but on the same note it appears to lack functionality that run-webkit-tests provides. Can someone please clarify the situation? Thanks, - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A question about new-run-webkit-tests
On 2011-03-18, at 14:22, Dirk Pranke wrote:
* There are GTK bots that run NRWT as well as the Chromium bots
Where? None of the bots on build.webkit.org use it as far as I can tell. And
the run-webkit-tests script contains the following:
sub useNewRunWebKitTests()
{
# Change this check to control which platforms use
# new-run-webkit-tests by default.
# Example: return runningOnBuildBot() isLeopard();
# would enable new-run-webkit-tests on only the leopard buildbots.
return 0;
}
- Mark
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A question about new-run-webkit-tests
On 2011-03-18, at 14:22, Dirk Pranke wrote: In short, what Adam just said :) In long(-er), Your annoyance is quite understandable. Not annoyed, just confused by the existence of two similar-but-subtly-different tools. I won't go into the reasons for the delay, but the major technical reason has been fixed, finally. These are the issues that I am aware of that remain: * There are GTK bots that run NRWT as well as the Chromium bots * I have been in conversations a bit w/ wms and lforschler to get the apple mac port using it * There are a couple of known minor bugs with the mac port Are they tracked in Bugzilla? * There are some known minor features missing Ditto? * There are known issues with the apple win port not working (this is probably the biggest issue keeping things from working, but it shouldn't be too hard to surmount). Ditto? I hope to make rapid progress on all of these fronts, and pull together all of the others issues into a single fairly easily trackable spot. I would like to be able to either say we're fully cut over or at least give a good update at the meeting in April. Thanks for the update. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
