Re: [webkit-dev] Code Style: Opinion on returning void

[Nico Weber]

On Thu, Feb 21, 2019 at 12:31 PM Darin Adler  wrote:

> I tried not to weigh in on this, but my view on the materials we should
> use to build the bike shed must be shared!
>
> Generally it seems neat to be able to make the code slightly more tight
> and terse by merging the function call and the return into a single
> statement.
>
> Other than not being accustomed to it, I have noticed three small things I
> don’t like about using “return” with a call to a void-returning function.
>
> - You can’t use this idiom when you want to ignore the result of a
> function, only if the function actually returns void. Often functions are
> designed with ignorable and often ignored return values. For example, it’s
> common to call something that might fail and have a good reason to ignore
> whether it failed or not. The idiom we are discussing requires treating
> those functions differently from ones that return void. If you refactor so
> that a function now returns an ignorable return value you need to visit all
> the call sites using return and change them into the two line form.
>

That works, you just have to spell it `return (void)non_void_fun();` :D


>
> - It works for return, but not for break. I’ve seen at least one case
> where someone filled a switch statement with return statements instead of
> break statements so they could use this more-terse form. Now if we want to
> add one line of code after that switch, we need to convert all those cases
> into multi-line statements with break.
>
> - Unless it’s mandatory, it’s a case where two programmers can make
> different style choices. If both forms are acceptable, then it introduces a
> little bit of disorder into our code.
>
> One thing I like about it is that since “pass along the return value from
> this inner function to this outer function” can be written this way, the
> code can then survive refactorings where both the inner and outer functions
> might gain or lose the return value.
>
> — Darin
> ___
> 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] WebCore/platform standalone library

[Nico Weber]

On Fri, Mar 20, 2015 at 9:56 AM, Simon Fraser 
wrote:

> On Mar 20, 2015, at 9:27 AM, Darin Adler  wrote:
>
> >> On Mar 19, 2015, at 2:49 PM, Maciej Stachowiak  wrote:
> >>
> >> This almost makes me want to suggest a jokey name for Platform. I can’t
> off the top of my head think of a good expansion of OMG, though. Or BBQ.
> >
> > I am not a pro at this, but here are a few tries: Lower-level Object
> Library. Algorithm Reuse Framework. New Framework for WebCore, New System
> Framework for WebCore.
>
> Platform Obfuscation Source.
>

Web Utility Belt With Useful Behavior.


>
> Simon
>
> ___
> 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] Ports not building as C++11?

[Nico Weber]

FYI: In gcc 4.7, things like "foo%"PRIuS are hard errors due to
user-defined literals (it's a disablable warning in clang and gcc4.8, and
gcc4.6 is fine since it doesn't implement user-defined literals yet), and
some system headers (dbus1.0, dbus1.2, probably others) contain code like
that. I'd encourage you to try actually building WebKit in c++11 mode with
your port to check if you run into anything like that.

Nico


On Mon, Jul 29, 2013 at 10:42 AM, Patrick East  wrote:

>  There is support for C++11 on Windows Embedded Compact 2013 using the
> newer VC11 compiler, but for CE 5, 6, or WEC 7 they will not be able to
> support it since they are limited to the VC9 compiler. Afaik there doesn’t
> appear to be any plans from Microsoft to back-port the newer compiler and
> run time to support older versions of CE.
>
> ** **
>
> I realize that CE 5, 6, and 7 are probably not top priorities for the
> community, but these changes will basically force dropping support for
> those platforms. We do have some interest in keeping WebKit working for our
> downstream build, so if it’s possible to make this change over to using
> C++11 in a way that can allow for building without the new features that
> would be ideal. If there is anything we can do that help make this happen
> let me know.
>
> ** **
>
> Thanks!
>
> ** **
>
> *Patrick East* | Software Engineer 
>
> +1 425.519.5912 | patri...@bsquare.com 
>
> Bsquare │Forging Smart Connections
>
> www.bsquare.com 
>
> ** **
>
> ** **
>
> ** **
>
> *From:* webkit-dev-boun...@lists.webkit.org [mailto:
> webkit-dev-boun...@lists.webkit.org] *On Behalf Of *Brent Fulgham
> *Sent:* Saturday, July 27, 2013 3:04 PM
> *To:* Anders Carlsson
> *Cc:* WebKit Development
> *Subject:* Re: [webkit-dev] Ports not building as C++11?
>
> ** **
>
> The only platform I know cannot support C++11 is WinCE, and that port is
> in favor of making the move to C++11 in anticipation of updated build tools
> from Microsoft.
>
> ** **
>
> What other platform are we talking about here? The GNU compilers have
> supported C++11 for a long time.
>
> ** **
>
> -Brent
>
> Sent from my iPhone
>
>
> On Jul 26, 2013, at 8:12 PM, Anders Carlsson  wrote:**
> **
>
>  ** **
>
> On Jul 26, 2013, at 8:09 PM, Allan Sandfeld Jensen 
> wrote:
>
>
>
> 
>
> On Friday 26 July 2013, Anders Carlsson wrote:
>
> 
>
> Hi everyone,
>
> when Oliver landed his “let’s break everything” patches in JSC the other
> day, I noticed that some of the follow-up build fixes by other ports were
> removing use of C++11 features (mainly nullptr).
>
> Are there any ports that aren’t building as C++11? If so, why not?
>
> Yes, and because C++11 is not supported on all the platforms we support. *
> ***
>
> ** **
>
> Could you please elaborate? What compilers are you using?
>
>
>
> 
>
> We don't all have the option to not care about the platforms of a certain
> fruit
> themed vendor's 1 or 2 year old operating systems.
>
> ** **
>
> I don’t think this comment adds anything constructive.
>
> ** **
>
> Thanks,
>
> - Anders
>
>  ___
> 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] Compiling WebKit up to 25% faster in Windows?

[Nico Weber]

On Wed, Mar 27, 2013 at 12:05 PM, Brent Fulgham  wrote:

> Hi Daniel,
>
> On Tue, Mar 26, 2013 at 11:21 AM, Daniel Bratell wrote:
>
>> As an experiment we took the (chromium) project webcore_dom, that
>> normally compiles in 56 seconds in Windows on a generic computer and
>> "fixed" it. Removing the many include paths in the build system and instead
>> specifying the path in the include directives changed that to 42 seconds, a
>> 25% reduction.
>>
>
> I thought that much of this was supposed to be addressed by the use of
> precompiled headers.  Presumably, if the header files are properly
> incorporated into the PCH, shouldn't any gains from relative paths be
> small? Obviously your statistic says otherwise, but I'm not sure that a
> single test on a single system is definitive proof of anything.
>

I thought PCHs are mostly for system headers that don't change often (
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/WebCore/WebCorePrefix.h&q=WebCorePrefix&sq=package:chromium&type=cs),
else every .h change would require recompiling _all_ cc files, no?


>
> Did you run the test multiple times to get a feel for how reproducible the
> improvements was? I know I have fooled myself in the past into thinking I
> had improved something, only to discover that unrelated computer activity
> (e.g., backups, virus scans, etc.) were contributing to slow build times.
>
> -Brent
>
>
> ___
> 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] Compiling WebKit up to 25% faster in Windows?

[Nico Weber]

On Tue, Mar 26, 2013 at 4:51 PM, Daniel Bratell  wrote:

> Den 2013-03-26 21:20:10 skrev Dirk Pranke :
>
>
>  If we have consensus that we should just switch to paths relative to
>> Source
>> (or maybe a couple different options), that would be (IMO) a big win. It
>> sounds like Daniel & co. have already done the big bang conversion.
>>
>
> Not the whole conversion, no. Just enough to confirm the suspicion that it
> affects compile time in Windows.
>
> As other people in the thread have mentioned there are some tricky areas
> so before investing too much time in this, it seemed to be best to check
> with people with longer experience of the code if there was something we've
> missed.
>
> Though the conversion is scripted so it can possibly be applied to large
> portions of the source code and then the tricky areas can be manually fixed.


Can you share your scripts, so that we can measure how this changes things
on other platforms?

Thanks!
Nico


>
>
> /Daniel
>
> __**_
> 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] Proposal: Make Ninja the default build-system for build-webkit --chromium

[Nico Weber]

On Tue, Jan 22, 2013 at 2:22 AM, Nico Weber  wrote:
> On Sat, Jan 12, 2013 at 9:49 PM, Nico Weber  wrote:
>> On Tue, Dec 11, 2012 at 3:43 PM, Eric Seidel  wrote:
>>> Nevermind.  After further discussion with Nico, this can't work yet.
>>>
>>> Ninja is currently configured to use a non-webkitty "out" build
>>> directory, which is undoubtably going to confus some scripts/bots.
>>>
>>> We'll try this again at a later time.  Apologies for the noise.
>>
>> If you build WebKit/chromium on Linux (i.e. Chromium/Linux and
>> Chromium/Android), you're now using ninja. The Chromium Linux Release
>> and Chromium Android Release build bots seem to be working fine.
>>
>> Admire the exciting build output:
>> http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/65467/steps/compile-webkit/logs/stdio
>>
>> Let us know if anything is not working for you.
>>
>> (If you must use make, you can pass --no-ninja to update-webkit, and
>> build-webkit will use make again. If you do this, please let me know
>> why.)
>
> Chromium/Mac webkit builds now uses ninja by default too. The bot's
> build output is now a little more concise:
> http://build.webkit.org/builders/Chromium%20Mac%20Release/builds/53889/steps/compile-webkit/logs/stdio
>
> On my laptop, full builds are 10% faster and empty builds (the minimum
> time you need to wait for a build) are 30x as fast.
>
> If you still need xcodebuild, you can pass --no-ninja to
> update-webkit. Please let us know if and why you do this.
>
> Nico
>
> ps: Switching Chromium/Windows is blocked on http://crbug.com/169945,
> so it probably won't happen soon.

…and windows is now done, too. Thanks to dpranke for helping with this!
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Removing ENABLE(WEB_INTENTS) code

[Nico Weber]

Going once, going twice…

https://bugs.webkit.org/show_bug.cgi?id=109501

On Sat, Feb 2, 2013 at 3:09 PM, Sam Weinig  wrote:
> Sounds good to me as well.
>
> -Sam
>
> On Jan 30, 2013, at 3:54 PM, Nico Weber  wrote:
>
>> Hi,
>>
>> I'd like to delete all the ENABLE(WEB_INTENTS) code. As far as I know,
>> nobody ever shipped this and nobody intents to. Please speak up if
>> you'd like that code to stick around.
>>
>> Nico
>> ___
>> 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] Common build system (was Re: WebKit Wishes)

[Nico Weber]

http://www.haskell.org/haskellwiki/Wadlers_Law

On Tue, Feb 5, 2013 at 12:16 PM, Eric Seidel  wrote:
> I'm curious if YAML was ever considered?  I have very limited
> experience with YAML, except for Google App Engine config files.
>
> It's very python parse-able? :)
>
> On Tue, Feb 5, 2013 at 11:55 AM, Mark Mentovai  wrote:
>> You’re not supposed to use arbitrary Python, it’s highly discouraged. We
>> have a linter that keeps you from doing things you’re not supposed to do
>> (like this), but it slows things down, so it’s not part of the “standard”
>> GYP run that developers normally use. It can run as a pre-commit script or
>> test on the bot or something else. Used as we’re using it, GYP basically is
>> simple JSON, except the rules about commas are looser and # introduces
>> comments.
>>
>>
>> On Tue, Feb 5, 2013 at 2:47 PM, Ryosuke Niwa  wrote:
>>>
>>> On Tue, Feb 5, 2013 at 6:09 AM, Mark Mentovai  wrote:

 The parser (and the grammar) works the way it does because it’s just
 Python
>>>
>>>
>>> This works great for people who like Python syntax but not for someone
>>> like myself who dislikes Python syntax.
>>>
>>> I also find it particularly annoying that people can use whatever Python
>>> constructs they want to use in GYP. It dramatically reduces language
>>> portability because you need to support quite a few Python constructs and
>>> quirks in order to correctly parse GYP.
>>>
>>> I personally would have much preferred for it be a simple JSON file.
>>>
>>> - R. Niwa
>>>
>>
>>
>> ___
>> 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] Common build system (was Re: WebKit Wishes)

[Nico Weber]

On Sat, Feb 2, 2013 at 4:58 PM, Adam Barth  wrote:
> Ninja has extremely fast incremental builds and can be generated by
> GYP.  Here are some stats from a year ago:
>
> https://plus.google.com/101038813433650812235/posts/irc26fhRtPC
>
> Ninja has gotten even faster since then.  If you're interested in
> trying it out, you can play around with incremental builds of the
> Chromium port on Mac or Linux.

You can also look at the build output from the chromium bots.

Empty build in 1s:
http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/66807/steps/compile-webkit/logs/stdio
Build with a few files changed in 15s:
http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/66800/steps/compile-webkit/logs/stdio

…and this is on fairly slow bots. On my SSD-equipped laptop, I can do
incremental rebuilds of all of chrome after touching one (cpp or mm)
file in 2-6s.

>
> Adam
>
>
> On Fri, Feb 1, 2013 at 4:58 PM, Balazs Kelemen  wrote:
>> I think one important aspect of build systems was not considered yet int
>> this conversation: speed. The time an incremental build takes has a great
>> effect on developer productivity. I don't think any of the meta-build
>> systems we use does a great job here - although I only have experiences with
>> qmake, cmake and autotools (and I don't have an SSD that could help
>> somewhat).
>>
>> The technic I found useful here is to avoid calling build-webkit always and
>> instead just rebuild the subproject you have edited, so I think it is
>> important to have a build system that supports it. Let me share my
>> experiences here.
>>
>> With qmake nowadays this work perfectly. The developer build is producing a
>> shared library for every subdir (WTF, JavaScriptCore, WebCore, WebKit2),
>> which means you only need to call make in the specific subdirectory (i.e. if
>> I only touched WebKit2 files I do "make -C
>> WebKitBuild/Release/Source/WebKit2" which is pretty quick). Still WebCore is
>> so big that make is quite slowly find out the files you actually edited and
>> need to be rebuilt. What could help here is to devide WebCore into smaller
>> parts, like the ongoing work of extracting Platform. Maybe the next logical
>> candidate could be svg (I don't have real knowledge about how feasible it
>> is).
>>
>> Note that I don't come up with qmake because I would like to recommend it as
>> the one and only build system (in fact it has a ridiculously inconvenient
>> syntax, and a lot of bugs), just as an example.
>>
>> With Cmake fast incremental rebuilds are also possible, maybe in a bit more
>> complicated way. When working with the EFL port I found a quick rule for
>> WebKit2 in the generated makefile. Although the makefiles are usually call
>> back to Cmake, and make is not faster than build-webkit, if you use the
>> special fast target, which is something like eflWebKit/fast (i.e. make -C
>> WebKitBuild/Release/Source/WebKit2 eflWebKit/fast), it will not check
>> dependencies but just rebuild the files that have changed. I did not find a
>> similar thing for WebCore, I guess because it is not built as a shared
>> library.
>>
>> What I dislike in Cmake is that I am disappointed by how slow a normal
>> incremental build with it (i.e. build-webkit). qmake is not faster at all,
>> but it generate plain makefiles that typically no call back to qmake if not
>> specified explicitly to do so, and directly calling make is faster, yet it
>> can handle most of the non-trivial changes, for example editing a generator
>> file. I don't know gyp, so I wonder about how would it do in this comparison
>> (but I guess it generates simple makefiles as well, so it's similar than
>> qmake in this manner.)
>>
>> I hope I added something to this conversation that is worth to consider with
>> my late nightly brain dump.
>>
>> -kbalazs
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> On Fri, Feb 1, 2013 at 4:58 PM, Balazs Kelemen  wrote:
>> I think one important aspect of build systems was not considered yet int
>> this conversation: speed. The time an incremental build takes has a great
>> effect on developer productivity. I don't think any of the meta-build
>> systems we use does a great job here - although I only have experiences with
>> qmake, cmake and autotools (and I don't have an SSD that could help
>> somewhat).
>>
>> The technic I found useful here is to avoid calling build-webkit always and
>> instead just rebuild the subproject you have edited, so I think it is
>> important to have a build system that supports it. Let me share my
>> experiences here.
>>
>> With qmake nowadays this work perfectly. The developer build is producing a
>> shared library for every subdir (WTF, JavaScriptCore, WebCore, WebKit2),
>> which means you only need to call make in the specific subdirectory (i.e. if
>> I only touched WebKit2 files I do "make -C
>> WebKitBuild/Release/So

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

[Nico Weber]

This is a lovely discussion to have every now and then :-)

Maybe the file add/move/delete tool that someone wrote could land
without xcode support for now? Then the pain of moving files is
reduced to two systems (xcode and everyone else), and that's something
that's at least tractable.

Nico

On Thu, Jan 31, 2013 at 12:31 PM, Dirk Pranke  wrote:
> On Thu, Jan 31, 2013 at 9:14 AM, Patrick Gansterer  wrote:
>>
>> Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak:
>>
>>
>> On Jan 31, 2013, at 1:56 AM, Patrick Gansterer  wrote:
>>
>> Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:
>>
>> On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger 
>> wrote:
>>>
>>> Another option is to add a webkit-patch command for modifying the build
>>> files. That way, the syntax doesn't need to be overly human friendly. There
>>> was also some attempt to write a tool to add files automatically:
>>> https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that such a
>>> tool becomes easier if it would only modify one source of truth and
>>> generates all other artifacts such as Xcode projects from it.
>>
>>
>> I don't want build file's syntax to be so human unfriendly that I need a
>> tool for it.
>>
>> Often times, these syntax problems can be improved dramatically by simple
>> changes. e.g. we had a similar discussion about TestExpectation syntax, and
>> I'm much happier with the new syntax even though the new syntax is
>> functionally equivalent to the old one, and two syntaxes are very similar.
>>
>> On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe  wrote:
>>>
>>> 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.
>>
>>
>> Yeah. In fact, we can just come up with whatever syntax we like and convert
>> it to the existing gyp format if the syntax was the biggest issue.
>>
>>
>> Do we want to define the whole build system (including information how to
>> invoke the generators) with the new system, or is a "simple" list for the
>> input files sufficient? IMHO adding a new generator build step happens very
>> rarely. So maybe we can spit the "input file list" (mainly *.cpp and *.idl)
>> into new files.
>> Then GYP and CMake can read them and generate the build system out of them
>> directly (like they to already today) instead of listing the files in the
>> *.gpyi and *.cmake. This might work for other systems like qmake too.
>> For XCode we can maybe have a "template XCode project" and generate the
>> "work XCode project" with a script. This script then only need to fill in
>> the files from the "input file list" into the "template XCode project".
>> Defining the feature flags can be done like Maciej suggested with "Port.h"
>> files.
>>
>>
>> I think it would be better to adapt an existing meta build system to our
>> needs than to make one from scratch, unless we find that completely
>> impractical.
>>
>> In particular, gyp and cmake both know how to handle generated sources, and
>> while it may not be super common to make a new type of generated source,
>> it's bad for hackability of the project of doing so is super hard. We get a
>> lot of hackability benefits from using various kinds of generated sources,
>> many first introduced in the days when we had a lot fewer build systems. So
>> in my mind, they are already ahead of a hypothetical "simple" system.
>>
>>
>> Do you want to kick the requirements of the smaller ports from trunk or do
>> you think that e.g. a qmake generate for GYP makes sense?
>> AFAIK e.g. QtWebKit is shipped with Qt, which uses qmake as build system,
>> where CMake/GYP is not an option.
>>
>
> It could certainly make sense for us to add Autotools and Qmake
> generators to GYP; I'm less certain if a CMake generator makes much
> sense, but I haven't thought about it as much. I'm not super familiar
> with any of these three tools, so I could be dead wrong.
>
>> I completely agree that creating a new meta meta build system isn't a good
>> idea, but sharing the common parts (which reduce the daily productivity)
>> might be a step in the right direction. Using simple text files which
>> contain the list of files (like the gpyi files already do today) isn't a new
>> build system. It only offers the existing meta build systems (CMake, GYP,
>> autotools, qmake) to use a common base.
>>
>> The remaining build systems can be ported to one of these systems or be
>> adopted to use this file lists too.
>>
>> -- Patrick
>
> I suspect that we would quickly find that we would want some sort of
> support for conditionals and/or file inclusion in our "simple text
> files", at which point you basically get a meta-meta-build system :).
> I don't actually think such a thing is that bad of an idea, but it's
> all in the details.
>
> I would like to find a solution w

[webkit-dev] Removing ENABLE(WEB_INTENTS) code

[Nico Weber]

Hi,

I'd like to delete all the ENABLE(WEB_INTENTS) code. As far as I know,
nobody ever shipped this and nobody intents to. Please speak up if
you'd like that code to stick around.

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

Re: [webkit-dev] Proposal: Make Ninja the default build-system for build-webkit --chromium

[Nico Weber]

On Sat, Jan 12, 2013 at 9:49 PM, Nico Weber  wrote:
> On Tue, Dec 11, 2012 at 3:43 PM, Eric Seidel  wrote:
>> Nevermind.  After further discussion with Nico, this can't work yet.
>>
>> Ninja is currently configured to use a non-webkitty "out" build
>> directory, which is undoubtably going to confus some scripts/bots.
>>
>> We'll try this again at a later time.  Apologies for the noise.
>
> If you build WebKit/chromium on Linux (i.e. Chromium/Linux and
> Chromium/Android), you're now using ninja. The Chromium Linux Release
> and Chromium Android Release build bots seem to be working fine.
>
> Admire the exciting build output:
> http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/65467/steps/compile-webkit/logs/stdio
>
> Let us know if anything is not working for you.
>
> (If you must use make, you can pass --no-ninja to update-webkit, and
> build-webkit will use make again. If you do this, please let me know
> why.)

Chromium/Mac webkit builds now uses ninja by default too. The bot's
build output is now a little more concise:
http://build.webkit.org/builders/Chromium%20Mac%20Release/builds/53889/steps/compile-webkit/logs/stdio

On my laptop, full builds are 10% faster and empty builds (the minimum
time you need to wait for a build) are 30x as fast.

If you still need xcodebuild, you can pass --no-ninja to
update-webkit. Please let us know if and why you do this.

Nico

ps: Switching Chromium/Windows is blocked on http://crbug.com/169945,
so it probably won't happen soon.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal: Make Ninja the default build-system for build-webkit --chromium

[Nico Weber]

On Tue, Dec 11, 2012 at 3:43 PM, Eric Seidel  wrote:
> Nevermind.  After further discussion with Nico, this can't work yet.
>
> Ninja is currently configured to use a non-webkitty "out" build
> directory, which is undoubtably going to confus some scripts/bots.
>
> We'll try this again at a later time.  Apologies for the noise.

If you build WebKit/chromium on Linux (i.e. Chromium/Linux and
Chromium/Android), you're now using ninja. The Chromium Linux Release
and Chromium Android Release build bots seem to be working fine.

Admire the exciting build output:
http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/65467/steps/compile-webkit/logs/stdio

Let us know if anything is not working for you.

(If you must use make, you can pass --no-ninja to update-webkit, and
build-webkit will use make again. If you do this, please let me know
why.)

Nico

>
> http://trac.webkit.org/changeset/137375
>
> On Tue, Dec 11, 2012 at 3:33 PM, Eric Seidel  wrote:
>> This is now complete:
>> http://trac.webkit.org/changeset/137371
>>
>> I'm watching the bots.  Please contact me if you have any trouble.
>>
>> Thank you all for your feedback.
>>
>> On Mon, Dec 10, 2012 at 10:11 AM, Dirk Pranke  wrote:
>>> On Mon, Dec 10, 2012 at 1:30 AM, Jochen Eisinger  
>>> wrote:
 Will the buildbots use ninja or the "native" build tools?

 My only concern is that we're catching problems with e.g. MSVS only after 
 we
 roll the WebKit deps in chromium and one of the MSVS bots starts failing.

>>>
>>> Eric is only suggesting changing update-webkit and build-webkit, which
>>> means that only the webkit.org bots would be affected. As long as the
>>> chromium.org canaries are still using chromium checkouts (and the
>>> native build systems), we'll still have coverage.
>>>
>>> Of course, your point is still valid for other scenarios where we
>>> don't have coverage of what we use on the official builds, but as Nico
>>> pointed out in a separate thread, so far this hasn't been a frequent
>>> problem.
>>>
>>> -- Dirk
> ___
> 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: Make Ninja the default build-system for build-webkit --chromium

[Nico Weber]

On Mon, Dec 10, 2012 at 1:30 AM, Jochen Eisinger  wrote:
> Will the buildbots use ninja or the "native" build tools?
>
> My only concern is that we're catching problems with e.g. MSVS only after we
> roll the WebKit deps in chromium and one of the MSVS bots starts failing.

The idea is that gyp tries to write ninja files that behave as similar
as possible to xcodebuild / devenv (or msbuild). In practice, this
seems to work pretty well and it's rare that a ninja build works while
xcodebuild doesn't -- well enough that all the chromium trybots use
only ninja.

Nico

>
> Otherwise, I'm all for switching to ninja.
>
> best
> -jochen
>
> On Sat, Dec 8, 2012 at 9:29 AM, Eric Seidel  wrote:
>>
>> If you don't work on the Chromium port, feel free to ignore.
>>
>>
>> If you work on the Chromium port of WebKit and do not use Ninja as you
>> build system (GYP_GENERATORS='ninja' or update-webkit --chromium
>> --ninja) I want to hear from you!
>>
>> As far as I can tell, the vast majority of Chromium contributors use
>> Ninja as their build system of choice.  Particularly for
>> Chromium-Android contributors this seems to be true.
>>
>> With that knowledge, I have posted a patch to make update-webkit
>> ---chromium/--chromium-android generate Ninja build files instead of
>> platform-native build files (XCode, Visual Studio, Make, etc.) by
>> default.  This of course only affects the chromium port.
>>
>> https://bugs.webkit.org/show_bug.cgi?id=104434
>>
>> Thanks!
>>
>>
>> p.s. If you don't already know:
>> update-webkit --chromium --ninja
>> build-webkit --chromium
>> is all you need to use Ninja today.  You don't even need to have
>> installed/built your own copy of ninja (Chromium has done that for
>> you).
>>
>> p.p.s. Ninja is awesome. Awesomely quiet. Awesomely fast.
>> http://martine.github.com/ninja/
>> ___
>> 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] About text decoration wavy style implementation on Skia platform

[Nico Weber]

On Mon, Nov 5, 2012 at 5:18 AM, Bruno Abinader  wrote:
> Hi all,
>
> I am implementing the CSS3 text decoration style "wavy" for Skia platform
> [3], and I would like to know a few things (please let me know if this is
> not the right mailing list to ask this):
>
> - There is already a "spelling line" style implementation which mimics
> "wavy" style behavior, only with its own colors and theme. While Skia uses a
> custom, inline bitmap for rendering the red waves, other toolkits such as
> Cairo and Qt implements a function called "drawErrorUnderline" which renders
> the waves based on a given bounding rectangle. These are triggered by the
> drawLineForDocumentMarker function.
>
> - Individual implementations of the "wavy" style are popping up for each
> platform (ie. Qt [1] and Cairo [2] already have their implementations
> pending review).
>
> I see we can go both ways here:
>
> 1. Adapt the already implemented functions to support custom colors (as
> defined by "-webkit-text-decoration-color", for example). While this looks
> easier on Qt and Cairo platforms, since drawErrorUnderline already gives
> everything we need, we would need to find a consensus on the custom bitmap
> usage for Skia platform. Of course, this would include updating the Qt [1]
> and Cairo [2] patches to support this approach.
>
> 2. Continue with individual implementations of the wavy style as we're doing
> now. I'm afraid this option would involve code duplication.
>
> IMO we should adopt first option, rename the drawErrorUnderline to
> drawWavyLine (as suggested by KyungTae Kim), and find a solution for the
> Skia custom bitmap approach.
>
> What do you guys think?

The spelling underline on OS X is not a wavy line. If you end up
changing the skia code, please make sure the chromium/mac spelling
underline doesn't become a wavy line.

Nico

>
> Links:
> [1] https://bugs.webkit.org/show_bug.cgi?id=93507
> [2] https://bugs.webkit.org/show_bug.cgi?id=94110
> [3] https://bugs.webkit.org/show_bug.cgi?id=93509
>
> Best,
>
> --
> Bruno de Oliveira Abinader
> Software Engineer @ basysKom GmbH
> WebKit committer / Nokia Certified Qt Specialist
>
>
> ___
> 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] Pre-proposal: Adding a Coverity instance for WebKIt

[Nico Weber]

On Tue, Sep 18, 2012 at 8:11 AM, James Hawkins  wrote:
> Hey folks,
>
> TL;DR - If you have opinions one way or another about having a Coverity
> instance available for WebKit developers, please respond to this message.

I don't have an opinion, but:

> Coverity is a static analysis tool [1] which scans source code and reports
> defects in the code.  We've been using Coverity to find defects in Chrome
> for a while now, and though there is sometimes a bit of subjectivity
> involved in the defect types (e.g. whether a return value should be
> checked), the signal is generally high.
>
> Off the top of my head, the following are the defects I spend most of my
> time fixing:
> * Uninitialized variables (including member variables).
>   - Chrome has had at least 4 crash fixes in the past few months due to this
> defect (which were caught by Coverity).

This sounds very useful. Do you know how this is done? If you have a
class whose constructor calls a clear() function which sets all
variables, will it warn about the constructor not initializing all
members? If so, how do you suppress the warning in this case?

(There was a thread on the clang mailing list on having a warning like
this, and we couldn't come up with a good way to handle this case.)

> * Passing large parameters by value.
>   - Generally a trivial fix.  I don't have performance data to say what
> affect fixing these hash, but 'death by a thousand cuts' eh?

I have seen at least three crashes in the last few months that were
cause by changes to fix this warning (something that used to be a
copied object became a dangling reference). I'm not sure this warning
is worth it.

> * Forward/Reverse/I - Nulls.
>   - Coverity is very good at understanding when a value is NULL and the tool
> will tell you which code paths are using a NULL value.
> * Tons of security issue-causing defects.
>
>
> I'd like to propose adding a Coverity instance for the WebKit community, but
> I want to make sure there's general support before writing up the detailed
> proposal.
>
> A few details:
> * Google will front the cost of the license (non-zero...very far from zero)
> and the infrastructure.
> * I'd leave it up to the WebKit leadership to decide who has access (most
> likely limited to WebKit committers for security purposes).
>
> The biggest rationale is to provide a strong defect signal for the entire
> WebKit community, which would directly impact the success of all
> WebKit-based projects.  Coverity has provided free licenses for unsponsored
> (by larger corporations anyway) open-source projects; this has resulted in
> significant improvements [2] to the code bases of these projects, one of
> which I was directly involved with years ago (Wine).
>
> Let me know if you love the idea or hate it.
>
> Thanks,
> James
>
>
> [1] http://www.coverity.com/products/static-analysis.html
> [2]
> http://softwareintegrity.coverity.com/coverity-scan-2011-open-source-integrity-report-registration.html
> - registration required now :(
>
>
> ___
> 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] ninja build available for chromium/mac, empty builds up to 20x as fast

[Nico Weber]

Hi,

we recently made the webkit/chromium/mac port buildable with ninja, a
new build system focused on build speed
(http://martine.github.com/ninja/). I don't have any numbers for
webkit standalone builds, but in a chromium checkout ninja is 20x as
fast as make on empty builds (1s instead of 20s), and 120x as fast as
xcodebuild.

Giving it a try is easy:

  Tools/Scrips/update-webkit --chromium --ninja
  Tools/Scripts/build-webkit --chromium

The output will appear in out/Release (or out/Debug if you do a debug build).

Nico

ps: If anybody is doing standalone webkit/chromium/linux builds: It's
very easy to make that work with ninja, too.
pps: Build perf numbers for make vs ninja for chromium builds:
https://plus.google.com/101038813433650812235/posts/irc26fhRtPC
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] chromium-cg-mac results

[Nico Weber]

Hi Adam,

On Tue, Jan 3, 2012 at 3:00 PM, Adam Barth  wrote:
> Hi Elliot,
>
> It looks like Chromium Mac has successfully moved to Skia.

I'd wait with this assessment until a version of Chrome with Skia has
shipped to stable. Things are looking really good so that should be
smooth sailing, but it's a bit early to say we're "successfully moved"
:-)

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

Re: [webkit-dev] Removing Support for Python 2.5

[Nico Weber]

The chromium port still has a bot that runs tests (but doesn't build) on 10.5.

Nico

On Fri, Nov 4, 2011 at 3:20 PM, Eric Seidel  wrote:
> Now that Apple has removed the Leopard build bot (and presumably
> stopped supporting WebKit on Leopard), all webkit platforms I know of
> have Python 2.6 or higher.
>
> My plan is to remove all of our 2.5 supporting code in the next week,
> requiring Python 2.6 or later for WebKit.
>
> Let me know if this will be an issue for you.
>
> 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] [chromium] make build for chromium/mac (build twice as fast!) & clang for chromium/linux

[Nico Weber]

If you're now getting

  clang: error: unable to execute command: posix_spawn failed: Exec format error

when ld is running, you're probably using Dave Levin's fake ld script
without a she-bang line. Add "#!/bin/bash" to the first line of your
/usr/bin/ld script in that case. (Or, if you're using the make build,
ld is now serialized by default, so you can just mv /usr/bin/real-ld
back to /usr/bin/ld.)

Nico

On Fri, Oct 21, 2011 at 1:37 PM, Nico Weber  wrote:
> Hi,
>
> if you don't work on the chromium webkit port for mac or linux, you
> can stop reading now.
>
> Three announcements about stand-alone webkit/chromium checkouts:
>
> 1.) Chromium/mac is now compiled with clang instead of gcc by default.
> This happens automatically, you don't need to do anything (on your
> local dev box, too). If you were wondering why compiler diagnostics
> are so much better all of a sudden, this is why. On my machine, this
> also brought the time for a full build from 23 minutes to 17 minutes.
>
>
> 2.) Chromium/mac can now optionally be built with make instead of
> xcodebuild. To do this, run update-webkit with GYP_GENERATORS set to
> make like this:
>
>    GYP_GENERATORS=make Tools/Scripts/update-webkit --chromium
>
> build-webkit will then use make instead of xcodebuild, and
> new-run-webkit-tests will use the make-produced binary. On my machine,
> this reduced full build times from 17 minutes to 12 minutes (50% of
> the original gcc & xcodebuild build time). If you build from within
> the Xcode IDE as opposed to on the command line, the speed-up might be
> a bit smaller. (To switch back to xcodebuild, run the command again
> without GYP_GENERATORS set, and delete the out/ folder.)
>
> (Note that this uses mac xcode_settings in the gyp files, not the
> linux-specific variables like cflags. This should hopefully make it
> fairly unlikely that the behavior of the make build and the xcode
> build diverge much.)
>
>
> 3.) As a side effect, the linux make build now supports clang as well.
> To use clang on linux, run
>
>    Source/WebKit/chromium/tools/clang/scripts/update.sh  # get clang,
> happens automatically on mac
>    GYP_DEFINES=clang=1 Tools/Scripts/update-webkit --chromium
>
> and then build like you normally would (`build-webkit --chromium`). On
> linux, this mostly gets you better diagnostics, the build doesn't get
> all that much faster (it goes from 9:40 minutes with gcc4.4. to 8:30
> minutes with clang on my linux box – only about 12% faster, and
> probably even less if you use a distributed build system).
>
>
> Let me know if you run into any issues.
>
> Nico
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] [chromium] make build for chromium/mac (build twice as fast!) & clang for chromium/linux

[Nico Weber]

Hi,

if you don't work on the chromium webkit port for mac or linux, you
can stop reading now.

Three announcements about stand-alone webkit/chromium checkouts:

1.) Chromium/mac is now compiled with clang instead of gcc by default.
This happens automatically, you don't need to do anything (on your
local dev box, too). If you were wondering why compiler diagnostics
are so much better all of a sudden, this is why. On my machine, this
also brought the time for a full build from 23 minutes to 17 minutes.


2.) Chromium/mac can now optionally be built with make instead of
xcodebuild. To do this, run update-webkit with GYP_GENERATORS set to
make like this:

GYP_GENERATORS=make Tools/Scripts/update-webkit --chromium

build-webkit will then use make instead of xcodebuild, and
new-run-webkit-tests will use the make-produced binary. On my machine,
this reduced full build times from 17 minutes to 12 minutes (50% of
the original gcc & xcodebuild build time). If you build from within
the Xcode IDE as opposed to on the command line, the speed-up might be
a bit smaller. (To switch back to xcodebuild, run the command again
without GYP_GENERATORS set, and delete the out/ folder.)

(Note that this uses mac xcode_settings in the gyp files, not the
linux-specific variables like cflags. This should hopefully make it
fairly unlikely that the behavior of the make build and the xcode
build diverge much.)


3.) As a side effect, the linux make build now supports clang as well.
To use clang on linux, run

Source/WebKit/chromium/tools/clang/scripts/update.sh  # get clang,
happens automatically on mac
GYP_DEFINES=clang=1 Tools/Scripts/update-webkit --chromium

and then build like you normally would (`build-webkit --chromium`). On
linux, this mostly gets you better diagnostics, the build doesn't get
all that much faster (it goes from 9:40 minutes with gcc4.4. to 8:30
minutes with clang on my linux box – only about 12% faster, and
probably even less if you use a distributed build system).


Let me know if you run into any issues.

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

Re: [webkit-dev] Do you compile with ENABLE_SVG diabled?

[Nico Weber]

Hi Eric,

chromium's mac tryservers (which are similar to webkit's EWS) all
build with svg disabled.

Nico

On Fri, Sep 9, 2011 at 2:42 PM, Eric Seidel  wrote:
> I am interested in removing the ENABLE_SVG define, and all associated
> sub-defines
>
> ENABLE_SVG_ANIMATION
> ENABLE_SVG_AS_IMAGE
> ENABLE_SVG_FONTS
> ENABLE_SVG_FOREIGN_OBJECT
> ENABLE_SVG_USE
>
> SVG is part of HTML5, and all major ports compile and ship with SVG
> enabled (and have for years).
>
> Please let me know if you are compiling with ENABLE_SVG disabled.
>
> -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] Git mirror out of sync?

[Nico Weber]

The first non-syned revision is http://trac.webkit.org/changeset/93167
, which is a huge directory move. This might just be slow to handle in
git?

On Wed, Aug 17, 2011 at 1:28 PM, David Levin  wrote:
> From an irc conversation, it sounds like this is being worked on but
> "git-svn just hangs, hard to tell why its broken"
> dave
>
> On Wed, Aug 17, 2011 at 7:56 AM, Nico Weber  wrote:
>>
>> Hi,
>>
>>  git fetch origin && git log origin/master
>>
>> suggests that the git mirror stopped syncing at r93166. Can someone kick
>> it?
>>
>> Thanks,
>> Nico
>> ___
>> 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] Git mirror out of sync?

[Nico Weber]

Hi,

  git fetch origin && git log origin/master

suggests that the git mirror stopped syncing at r93166. Can someone kick it?

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

Re: [webkit-dev] commit-queue platform musical chairs

[Nico Weber]

I noticed that the commit-queue is a lot zippier now. Thanks!

Nico

On Wed, Jun 8, 2011 at 1:57 PM, Adam Barth  wrote:
> Update: The new commit-queue nodes run about 6x faster than the old
> nodes (wow).  We're now fully switched over and have re-allocated the
> Mac Minis to the mac-ews, which should give us enough capacity to run
> the tests on Mac for every patch that's up for review.
>
> Adam
>
>
> On Sat, Jun 4, 2011 at 2:33 AM, Adam Barth  wrote:
>> Up until now, we've been running the commit-queue on a cluster of Mac
>> Minis, but building WebKit on these machines takes on the order of an
>> hour and a half, making the commit-queue slow.  EC2 offers much
>> stronger machines, but unfortunately does not offer Mac OS X (likely
>> due to licensing restrictions).  We're experimenting with running the
>> commit-queue on EC2 using the Chromium Linux port.  Currently, we've
>> got both kinds of nodes running so we can compare their effectiveness.
>>
>> I have a slight worry that most developers use the Mac port, and
>> running the commit-queue in a different configuration might cause some
>> trouble.  If something bad happens, please let me know.  We might need
>> to add some more checks to make sure the commit-queue doesn't break
>> Mac.
>>
>> Thanks for your patience,
>> 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] Build system update

[Nico Weber]

On Fri, Mar 25, 2011 at 10:59 AM, Maciej Stachowiak  wrote:
>
> In addition to your comments, I also find the gyp syntax somewhat unpleasant. 
> In particular, in .gypi lists of files to compile, ever entry is 
> double-quoted, comma-separated, line-separated, and then grouped in multiple 
> levels of braces. This is noisier than any of our current formats except the 
> XML-based ones. It seems like a newline-separated list, possibly indented, 
> should be sufficient.
>
> For .gyp files themselves, I admit I don't have a clear understanding of what 
> they are actually doing, so it's hard for me to say if the syntax they use is 
> good or not.
>
> I think in general the trick of making the files essentially Python code is 
> (presumably) handy for Python experts but not easy to read for anyone else.

It's just python directory literals, which is virtually identical to json.

Nico

>
> But I am assuming syntax-level things can be fixed once we have things 
> working for more ports, and doesn't necessarily need to be a showstopper to 
> initial adoption. Perhaps after successfully deploying gyp for one additional 
> port, the right next steps are to make sure the experience is smooth and 
> enjoyable for WebKit hackers, before propagating it further.
>
> Regards,
> Maciej
>
> On Mar 24, 2011, at 9:49 PM, Brent Fulgham wrote:
>
>> Hi Dimitri,
>>
>> 
>>
>> On Mar 24, 2011, at 9:24 AM, Dimitri Glazkov wrote:
>>
>>> \With the gyp conversion at this stage, we now have a possible solution
>>> to this problem. Given that there aren't any other viable alternatives
>>> in the present, please consider the most productive way of
>>> contributing: filing well-formulated bugs, blocking bug 55018
>>> (https://bugs.webkit.org/showdependencytree.cgi?id=55018&hide_resolved=1).
>>> We can then discuss these specific problems and adjust the shape of
>>> the solution accordingly.
>>
>> While I applaud the idea of a unified build system, my own experience trying 
>> to get gyp working has been a uniformly frustrating experience.
>>
>> Imagine for a moment that rather than being a Chromium developer, long 
>> schooled in the use of gyp and the various build components needed to 
>> support it, you are a lowly external developer who just wishes to build 
>> WebKit.  Out of curiosity, I took a stab at playing with gyp again this 
>> evening:
>>
>> 1. The top Google hit for "gyp build system" takes me to an exhaustive 
>> specification of the gyp input file syntax format.  If I click on the 
>> "Project Home" link, I find no information on downloading or installing the 
>> system.  Presumably I can download the source and somehow generate the tool.
>>
>> 2. If I go to the User Documentation page 
>> (http://code.google.com/p/gyp/wiki/GypUserDocumentation), I am instructed on 
>> how to draft my own gyp files to build things.  But why would I care when I 
>> can't even try the software out on an existing project, like WebKit?
>>
>> Once I download the gyp sources and 'build' them using the included 
>> "setup.py", it's not clear what to do with them:
>>
>> link:Source brent$ gyp .
>> Traceback (most recent call last):
>>  File "/usr/local/bin/gyp", line 18, in 
>>    sys.exit(gyp.main(sys.argv[1:]))
>>  File "/Library/Python/2.6/site-packages/gyp/__init__.py", line 374, in main
>>    '--depth as a workaround.'
>> Exception: Could not automatically locate src directory.  This is a 
>> temporary Chromium feature that will be removed.  Use --depth as a 
>> workaround.
>> link:Source brent$ gyp ./gyp
>> Traceback (most recent call last):
>>  File "/usr/local/bin/gyp", line 18, in 
>>    sys.exit(gyp.main(sys.argv[1:]))
>>  File "/Library/Python/2.6/site-packages/gyp/__init__.py", line 374, in main
>>    '--depth as a workaround.'
>> Exception: Could not automatically locate src directory.  This is a 
>> temporary Chromium feature that will be removed.  Use --depth as a 
>> workaround.
>> link:Source brent$ gyp help
>> Traceback (most recent call last):
>>  File "/usr/local/bin/gyp", line 18, in 
>>    sys.exit(gyp.main(sys.argv[1:]))
>>  File "/Library/Python/2.6/site-packages/gyp/__init__.py", line 374, in main
>>    '--depth as a workaround.'
>> Exception: Could not automatically locate src directory.  This is a 
>> temporary Chromium feature that will be removed.  Use --depth as a 
>> workaround.
>> link:Source brent$
>>
>> I kind of hate gyp!
>>
>> Compare that to the native Xcode projects, CMake files, or normal GNU 
>> Makefiles.  These other solutions almost always JUST WORK, because if you 
>> can build any software on your machine, you must have used one of these 
>> options.
>>
>> I don't use gyp for anything, I don't have it installed, and its not clear 
>> how to go about using it.
>>
>> Please don't further raise the barrier of entry to new WebKit developers by 
>> adding yet another obscure build requirement to the system.  :-(
>>
>> Thanks,
>>
>> -Brent
>>
>>
>>
>>
>
> ___
> webk

Re: [webkit-dev] Bools are strictly worse than enums

[Nico Weber]

On Fri, Dec 3, 2010 at 1:45 PM, Ryosuke Niwa  wrote:
> On Fri, Dec 3, 2010 at 1:37 PM, David Hyatt  wrote:
>>
>> The only exception I would make to this rule is if all the call sites use
>> variables and never pass in raw true or false.  In that case there's no loss
>> of readability, and whether you use an enum vs. a bool is irrelevant.
>> I think in general the rule should be "Keep your call sites readable, and
>> convert to enums if you find that the call sites are becoming inscrutable."
>
> That rule makes sense to me.
> On Fri, Dec 3, 2010 at 1:40 PM, Eric Seidel  wrote:
>>
>> Dave, I'm not sure I understand your exception.  Could you give an
>> example?
>
> I think what he means is that
> bool doSomething();
> void doSomethingElse(bool);
> and the only case we always call doSomethingElse with a return value of some
> function or with a variable:
> doSomethingElse(doSomething());
> doSomethingElse(shouldNotDoSomethingElse);
> etc...
> and we never call it with raw true/false:
> doSomethingElse(true)
> doSomethingElse(false)

Out of curiosity, what do people think of

doSomethingElse(/*paramName=*/true);

when calling an existing function that takes a bool?

Nico

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

Re: [webkit-dev] Accelerated 2D Tesselation Implementation

[Nico Weber]

On Fri, Aug 27, 2010 at 10:51 AM, Chris Marrin  wrote:
>
> On Aug 27, 2010, at 10:32 AM, Nico Weber wrote:
>
>> On Fri, Aug 27, 2010 at 10:18 AM, Chris Marrin  wrote:
>>>
>>> Hi Ken,
>>> It would help me, and I think many others, if we could have a discussion of
>>> how exactly your tessellation logic works and what it is intended to do. For
>>> instance, is the algorithm you're using based on Loop-Blinn? I'm a bit
>>> familiar with that algorithm and some of the problems it has with rendering
>>> this type of geometry. For instance, there are typically anti-aliasing
>>> artifacts at the points where the interior triangles touch the edges. These
>>> are described in section 5.1 of the paper and the authors added additional
>>> (and not well described) logic to solve the problem.
>>> If you could describe your algorithm a bit and show some expected results
>>> with typical cases, that would be really helpful.
>>> For those not familiar with Loop-Blinn, here is a link to their original
>>> paper, presented at Siggraph 2005:
>>> Resolution Independent Curve Rendering using Programmable Graphics ...
>>> It's a great algorithm for rendering resolution independent 2D objects using
>>> the GPU. It has potential to render both 2D shapes (as used in Canvas and
>>> SVG) and text glyphs. It's advantage is that once you generate the triangles
>>> for the shape, you can render the shape at any resolution. It's disadvantage
>>> is that the triangle generation is quite expensive, so mutating shapes can
>>> potentially be slower than a simpler resolution dependent tessellation.
>>
>> I think there's a variant of the algorithm that uses the stencil
>> buffer polygon rendering method (
>> http://zrusin.blogspot.com/2006/07/hardware-accelerated-polygon-rendering.html
>> ) instead of triangulation. The paper I think I read on that only
>> covered quadratic splines, but maybe somehow has extended that method
>> to cubic splines by now?
>
> It looks like that technique deals with polygons, so as long as you convert 
> the shape to a piecewise linear curve it seems like it can handle any curve 
> form, right?

What I linked is how to render polygons with the z buffer.
http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html says:

"""Recently, Kokojima et al. 2006 presented a variant on our approach
for quadratic splines that used the stencil buffer to avoid
triangulation. Their idea is to connect all points on the curve path
and draw them as a triangle fan into the stencil buffer with the
invert operator. Only pixels drawn an odd number of times will be
nonzero, thus giving the correct image of concavities and holes. Next,
they draw the curve segments, treating them all as convex quadratic
elements. This will either add to or carve away a curved portion of
the shape. A quad large enough to cover the extent of the stencil
buffer is then drawn to the frame buffer with a stencil test. The
result is the same as ours without triangulation or subdivision, and
needing only one quadratic curve orientation. Furthermore, eliminating
the triangulation steps makes high-performance rendering of dynamic
curves possible. The disadvantage of their approach is that two passes
over the curve data are needed. For static curves, they are trading
performance for implementation overhead."""

Maybe someone extended Kokojima et al's work to cover cubic splines.

>
> -
> ~Chris
> cmar...@apple.com
>
>
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Accelerated 2D Tesselation Implementation

[Nico Weber]

On Fri, Aug 27, 2010 at 10:18 AM, Chris Marrin  wrote:
>
> Hi Ken,
> It would help me, and I think many others, if we could have a discussion of
> how exactly your tessellation logic works and what it is intended to do. For
> instance, is the algorithm you're using based on Loop-Blinn? I'm a bit
> familiar with that algorithm and some of the problems it has with rendering
> this type of geometry. For instance, there are typically anti-aliasing
> artifacts at the points where the interior triangles touch the edges. These
> are described in section 5.1 of the paper and the authors added additional
> (and not well described) logic to solve the problem.
> If you could describe your algorithm a bit and show some expected results
> with typical cases, that would be really helpful.
> For those not familiar with Loop-Blinn, here is a link to their original
> paper, presented at Siggraph 2005:
> Resolution Independent Curve Rendering using Programmable Graphics ...
> It's a great algorithm for rendering resolution independent 2D objects using
> the GPU. It has potential to render both 2D shapes (as used in Canvas and
> SVG) and text glyphs. It's advantage is that once you generate the triangles
> for the shape, you can render the shape at any resolution. It's disadvantage
> is that the triangle generation is quite expensive, so mutating shapes can
> potentially be slower than a simpler resolution dependent tessellation.

I think there's a variant of the algorithm that uses the stencil
buffer polygon rendering method (
http://zrusin.blogspot.com/2006/07/hardware-accelerated-polygon-rendering.html
) instead of triangulation. The paper I think I read on that only
covered quadratic splines, but maybe somehow has extended that method
to cubic splines by now?

Nico

> -
> ~Chris
> cmar...@apple.com
>
>
>
>
> ___
> 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] style question for empty for loops

[Nico Weber]

On Thu, Aug 26, 2010 at 11:49 AM, Darin Adler  wrote:
> On Aug 26, 2010, at 11:35 AM, Chris Fleizach wrote:
>
>>     for (...; ...; ...) { }
>
> This seems OK.
>
>>     for (...; ...; ...)
>>     { }
>
> The above is definitely not allowed, because braces go on the line with the 
> "for".
>
> The other possibilities are:
>
> C)
>    for (...)
>        ;
>
> D)
>    for (...) {
>    }
>
> E)
>    for (...) {
>        // intentionally-empty loop body.
>    }
>
> I would probably use (C) in code I was writing. This doesn’t come up much.

FWIW, clang warns about (C) but doesn't warn about the others (at
least on high warning levels).

Nico

>
>    -- Darin
>
> ___
> 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] Not enough space message when linking webkit (lots of free disk space)

[Nico Weber]

Are you using a 32 bit linker? Maybe it's running out of address space.

Nico

On Sun, Aug 22, 2010 at 12:32 PM, Chris Hatko  wrote:
> I'm running revision 65648  and building cairo-win32 release I'm getting "Not
> enough space" when linking WebKit project. I have 40Gig free space on
> this drive and 4Gigs of ram.
>
> Linking...
> 11>fatal error C1083: Cannot open compiler intermediate file:
> 'C:\cygwin\home\HATKO\WebKit\WebKitBuild\lib\WebKitLib.lib': Not
> enough space
> 11>LINK : fatal error LNK1257: code generation failed
> 11>Build log was saved at
> "file://C:\cygwin\home\HATKO\WebKit\WebKitBuild\obj\WebKit\Release_Cairo\BuildLog.htm"
> 11>WebKit - 1 error(s), 1 warning(s).
>
> Any idea what I can try?
>
> Thanks,
>
> Chris
> ___
> 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] CMake as a build system?

[Nico Weber]

This is from an earlier thread on this issue on webkit-dev:

"""
We also considered CMake, and had it demonstrably working for some of
our smaller projects as well.  Unfortunately, transitioning to CMake
would have required moving everything over at once, without allowing
for some existing projects to be maintained "by hand" during a
transition period.  CMake-generated files contain absolute paths, so a
.tar or .zip of the source tree could not be primed with CMake output,
complicating the "bootstrapping" process for new contributors.  A less
significant factor was that CMake introduced an additional binary
build prerequisite, which would have had to have been installed
everywhere.  Python is already a prerequisite for Chromium, so a
Python tool was easier to deploy.
"""

Nico

(I'm not involved with gyp at all, I just remembered that old thread)

On Fri, Apr 16, 2010 at 6:45 PM, Maciej Stachowiak  wrote:
>
> On Apr 16, 2010, at 5:50 PM, Bill Hoffman wrote:
>
>> On Fri, Apr 16, 2010 at 6:38 PM, Peter Kasting 
>> wrote:
>>>
>>> On Fri, Apr 16, 2010 at 3:35 PM, Maciej Stachowiak  wrote:

 I'm curious if the Chromium folks who created Gyp had any specific
 reason
 that they ruled out CMake as an option. (I have heard that it was
 considered
 and rejected.)
>>>
>>
>> I belive I can answer that.  During my talk at google, I met with with
>> Mark Mentovai and talked to him about Gyp and CMake.  The main thing
>> that he was trying to avoid was the requirement that CMake be
>> installed for the build.  That is true, CMake does have to be
>> installed.  However, CMake is installed on more an more systems.   The
>> cmake.org site has about 2K downloads per day, and most linux distros
>> include CMake.   With KDE using CMake, it has become pretty easy to
>> get.   Apple is also using CMake for the LLVM project, so it should be
>> installed and accepted at Apple.  I worked with Doug Gregor of the
>> LLVM team to help him convince the Apple testing folks to allow for
>> CMake to be installed.
>
> FWIW, I don't have CMake installed, and I have everything a typical Apple
> developer would have and then some. I'm running SnowLeopard and the latest
> Xcode. CMake is also not installed by default on Windows and I am not sure
> if it comes with the cygwin distribution we use.
>
> When you say "installed", does that mean it *has* to be in some system
> location? Could it be "installed" somewhere in the WebKit build tree? Our
> scripts download certain needed tools and libraries by default, so at least
> from the WebKit POV this is not necessarily a showstopper.
>
> Also: how hard is the dependency on being "installed"? Is this a solvable
> problem if it turns out to be a showstopper for some folks?
>
>
> And finally, I'd still like to hear from the Chromium folks whether there
> were any other issues. This one seems fairly minor.
>
> Regards,
> Maciej
>
> ___
> 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