Re: [webkit-dev] Purging as much memory as possible

[Peter Kasting]

On Fri, Oct 2, 2009 at 2:42 PM, James Robinson  wrote:

> On Fri, Oct 2, 2009 at 12:10 PM, Peter Kasting wrote:
>
>> On Fri, Oct 2, 2009 at 11:13 AM, Geoffrey Garen  wrote:
>>>
>>> Live items cannot be removed from the cache.
>>
>>
>> Yeah, I think that is what I'm seeing.
>>
>> Assume the page is not being painted (e.g. the window is minimized).  Is
>> there a way to turn the "live" items into dead ones so they can be flushed?
>>  Obviously the instant we repaint we will have to obtain these again.
>>
>> Even if this is possible, it might be _too_ aggressive, but first I just
>> wonder if it can be done at all.
>>
>
> It appears that FontCache::invalidate() does this based on the
> implementation - is that correct?  I'm not seeing any callers (but that
> might just be Visual Studio being stupid).
>

We're talking about the object cache ("cache()" rather than "fontCache()").

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

Re: [webkit-dev] Purging as much memory as possible

[Peter Kasting]

On Fri, Oct 2, 2009 at 11:13 AM, Geoffrey Garen  wrote:
>
> Live items cannot be removed from the cache.


Yeah, I think that is what I'm seeing.

Assume the page is not being painted (e.g. the window is minimized).  Is
there a way to turn the "live" items into dead ones so they can be flushed?
 Obviously the instant we repaint we will have to obtain these again.

Even if this is possible, it might be _too_ aggressive, but first I just
wonder if it can be done at all.

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

Re: [webkit-dev] Purging as much memory as possible

[Peter Kasting]

On Thu, Oct 1, 2009 at 11:26 PM, Zoltan Herczeg wrote:

> see QWebSettings::clearMemoryCaches() (WebKit/qt/Api/qwebsettings.cpp) to
> clear memory caches


Thanks, this is super-helpful.

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

[webkit-dev] Purging as much memory as possible

[Peter Kasting]

In Chromium, we have various events that we'd like to respond to by freeing
as much memory as possible.  (One example is system sleep, where we'd like
to dump memory before sleeping to avoid having to page it back in after
waking.)

I'm trying to find what areas in WebCore are good candidates for this kind
of work.  So far I've found WebCore::Cache, which is a singleton per
process, on which I can call setCapacity(..., ..., 0) to try and flush as
much as possible.

It's also been suggested to me that the Glyph cache is a good candidate; I
haven't quite figured out how this works, although I have found mitz'
recently-added showGlyphPageTree() function that I can probably use to do
some investigation.

My questions are:
* I notice that even when I set the WebCore::Cache capacity to zero, I can't
necessarily dump _everything_ out of it.  Is there some other set of calls I
should make to drop more references somewhere?
* Does anyone already know the likely footprint of the Glyph cache, or how
to clear it?
* Are there other obvious places to look?  Certainly the JS engine can hold
a lot of memory, but that's outside the scope of this question; I'm just
looking in WebCore.  Any other caches I can dump?

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

Re: [webkit-dev] Runtime setting for incomplete features

[Peter Kasting]

On Wed, Sep 23, 2009 at 6:03 PM, Maciej Stachowiak  wrote:

> My thinking on the topic is basically this:
> A) For experimental features, it makes sense to make them disappear
> completely when turned off, since turning them on is an unusual and
> experimental state.
> B) For end-user features that are on by default but have a preference to
> turn them off, having APIs appear and disappear fragments the platform.
>

I believe most of the cases where this occurs in Chromium are instances of
A.  We don't tend to expose prefs to do B.

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

Re: [webkit-dev] Limiting slow unload handlers (Re: Back/forward cache for pages with unload handlers)

[Peter Kasting]

On Thu, Sep 17, 2009 at 4:17 PM, Maciej Stachowiak  wrote:

> Another obvious difference is that the beforeunload event is dispatched
> earlier in the navigation process and its handlers may cancel the
> navigation.
>

Right, hence Ojan's prior comment, "If you're not prompting the user to stay
on the page..."

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

Re: [webkit-dev] Limiting slow unload handlers (Re: Back/forward cache for pages with unload handlers)

[Peter Kasting]

On Thu, Sep 17, 2009 at 12:14 PM, Darin Fisher  wrote:

> At any rate, I think I'm persuaded by your arguments.  Adam made a similar
> argument the other day too.  It seems reasonable to make Image behave this
> way when created in certain contexts.  We should probably include
> beforeunload and pagehide handlers since we have evidence that people do the
> same thing in beforeunload that they do in unload.  I include pagehide given
> the recent change to WebKit's page cache insertion policy.  We might even
> want to allow it in anchor tag click handlers for completeness.
>
> We should probably still consider an  implementation, but I agree
> that it doesn't have to be the only tool that we provide.
>

This conversation addresses the portion of the problem involving what
solutions we offer authors as an alternative to what they have today.

Any additional thoughts on the issue of how to make unload handlers fast in
the meantime?  It seems like we haven't reached agreement, particularly on
the issue of whether a timeout-based solution has worrisome possible
negative effects.

Perhaps there is some way to measure the efficacy and side effects of one or
both of these changes, so that we can experiment with them.  It's pretty
easy for us to add a histogram of unload handler wall-clock times, but I'm
not sure how we would detect the case that a timeout had prevented the JS
engine from executing enough of the unload handler (due to
swapping/GC/whatever).

At the very least, inserting John's change along with a histogram would
probably help answer questions like Maciej's earlier ones about how
prevalent this technique is and how much it harms users.

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

Re: [webkit-dev] Limiting slow unload handlers (Re: Back/forward cache for pages with unload handlers)

[Peter Kasting]

On Wed, Sep 16, 2009 at 2:54 PM, Adam Barth  wrote:

> By the way, I fully expect to be overruled (outvoted?) here.
> Unfortunately, that bug is degenerating into as complicated a
> discussion as the downstream bug that started this discussion.  Many
> folks seem to have thought carefully about this issue.


FWIW, I think it took Darin and John something like an hour of face-to-face
discussion with me to convince me that this really was the best tradeoff.
 It's an extremely complex (and frustrating) issue, and it's hard to boil
things down to succinct points on a bug (though I have tried).

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

Re: [webkit-dev] Limiting slow unload handlers (Re: Back/forward cache for pages with unload handlers)

[Peter Kasting]

On Wed, Sep 16, 2009 at 2:21 PM, Maciej Stachowiak  wrote:

> I think that setting an upper bound on the amount of time that can be spent
> in all unload handlers is a better solution than hacking the behavior of the
> Date API. Because (a) It's less likely to have unexpected side effects; and
> (b) there's no way for content authors to work around it, so we are less
> likely to end up in an "arms race" situation. There were worries expressed
> that swapping or context switching might trigger false positives, but I
> expect this is unlikely in practice, based on our experience with the slow
> script dialog.
>

These were also my arguments.  And I think all of us agree that in principle
setting a generic execution limit would be better.  In practice, we have
strong reason to believe that false positives will be common with wall clock
implementations, at least for Chromium (because of our multiprocess design,
renderer swapping is actually a huge issue for us currently, which we're
trying to address), and that it's still easy for authors to work around this
even at low values like 100 ms (instead of 8 200 ms handlers, just kick off
32 50 ms handlers.  Repeat ad infinitum).

The goal of this change is to approximate an execution limit in a way that
does not suffer from false positives and is also reasonable for a JS engine
to implement, and to do it temporarily while providing  until the
point when measurements show that authors have in general switched to use
that.

As I tried to say on the bug, even the worst possible outcome, an "arms
race", doesn't actually result in net harm, and if it happens, we can decide
whether to try and shift the approach to be more like this, or to give up
and rip out the hack entirely.

>From reading the comments in the bug, it does not look like we have
> consensus on the right approach, even among Chrome developers.
>

This is correct, but somewhat misleading.  Adam is to my knowledge the one
Chromium developer, who only recently encountered this idea, who currently
disagrees, compared to a large number of us who agree.

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

Re: [webkit-dev] Limiting slow unload handlers (Re: Back/forward cache for pages with unload handlers)

[Peter Kasting]

On Wed, Sep 16, 2009 at 1:53 PM, Maciej Stachowiak  wrote:

> I think a good way to deal with poorly written unload handlers is to
> temporarily set the slow script timeout to a much lower value during
> execution of unload. This would not require any JS-engine-specific changes
> to work.


There are two problems with this.

First is the problem that, assuming today's "slow script" UI, this results
in users being pestered about whether to kill the page that is trying to
unload, which is unacceptable -- it effectively means that frequently,
clicking a link or a close box results in a dialog box.  The obvious answer
is to modify the UX to just kill the script unilaterally without asking the
user,at which point this becomes equivalent to my earlier proposal to simply
terminate scripts after some amount of time, which is flawed (and can result
in dataloss) due to wall clock time being a poor measure of script execution
in some cases.  (Consider a user closing a window full of tabs run in
background processes that have been idle for some time and the OS has
swapped out.)

The better option, as Adam noted on the bug, is one in which the JS engine
itself measures how much work has been performed.  A count of instructions
or function calls is a truer measure than the proposed count of time checks,
but imposes costs on the JS engine that the V8 team have argued are
unacceptably high, and has little real-world benefit (at the moment) over
the current proposal, which approximates the same result in the types of
unload handlers we see today.  If authors modify how they write their
scripts, we may need to revisit what an appropriate approximation would be,
but the hope is to give them  at the very beginning, which benefits
both them and their readers.

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

Re: [webkit-dev] Back/forward cache for pages with unload handlers

[Peter Kasting]

On Wed, Sep 16, 2009 at 1:52 PM, Brady Eidson  wrote:

> At some point when I wasn't paying close attention, this thread started to
> talk about two different things that both happened to be related to unload
> handlers.
>
> I think:
> 1 - We all agree that the Page Cache is good
> 2 - We all agree that when a page has XHR in its unload handler and spins a
> busy loop, that makes leaving the page slower.
> 3 - We all agree that moving that XHR from unload to pagehide would not
> make leaving the page any faster.
>
> I think https://bugs.webkit.org/show_bug.cgi?id=29193 is completely
> orthogonal to the issue of improving what types of pages can go into the
> Page Cache.
>

Yes, that's all true.  I'm not sure why my comment caused so much confusion.
 It wasn't trying to deny any of the above, rather it was simply suggesting
that (extremely) slow unload handlers might make this change's benefits hard
for users to see, especially if they are copied into pagehide handlers.  As
you note, this is irrelevant when considering what can go in the bfcache; it
is only relevant when considering the entire problem of "how do we make all
page transitions fast".

I hope that helps?

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

Re: [webkit-dev] Back/forward cache for pages with unload handlers

[Peter Kasting]

On Wed, Sep 16, 2009 at 1:33 PM, Brady Eidson  wrote:

> Oliver is correct.
> The Page Cache will never be able to make *leaving a page* any faster.  But
> it can make *returning* to a page instantaneous.
>
> This is a Good Thing™
>

I think we're all agreeing with each other.  At least, this is what I was
trying to agree with when I said "Yes, that's completely accurate".

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

Re: [webkit-dev] Back/forward cache for pages with unload handlers

[Peter Kasting]

On Wed, Sep 16, 2009 at 11:23 AM, Geoffrey Garen  wrote:
>
> Prior to r48388, things that could make the back button slow:
> 1. An unload handler in the page you're leaving.
> 2. Reloading the page you're going back to.
>
> Post r48388, things that could make the back button slow:
> 1. An unload handler in the page you're leaving.
>

Yes, that's completely accurate.  I am only suggesting that item 1 dominates
item 2.

BTW, w.r.t. making unload handlers faster, we haven't actually sped anything
up yet, but we're getting closer to converging on an implementation + plan
for the future.  I intend to write something on the relevant bug in a few
minutes.

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

Re: [webkit-dev] Back/forward cache for pages with unload handlers

[Peter Kasting]

On Tue, Sep 15, 2009 at 11:35 PM, Brady Eidson  wrote:

> I perceive the worse case outcome of the experiment to be that we change
> the behavior back, but we will have educated web developers about pagehide
> and evangelized at least a few of them into switching over.
>

When you blog about this, make sure to make it clear to developers that they
need to detect whether pagehide is available rather than sniffing the UA
string for WebKit (even "WebKit version >= x") since other WebKit-based
browsers without a bfcache won't have this.

Given some of our (Chromium-team) recent investigation into the contents of
unload handlers, I'm not sure how much this move will help users, even if
you don't revert it.  Lots of unload handlers busy-wait while doing async
XHR in order to try to guarantee delivery of tracking pings.  Authors will
probably elect to copy this code to the pagehide handler rather than moving
it, and the experience for users is still going to be extremely sluggish
navigation out of these pages.

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

Re: [webkit-dev] take 2: unwritten rules of webkit style

[Peter Kasting]

On Thu, Sep 3, 2009 at 3:46 PM, Darin Adler  wrote:

> On Sep 3, 2009, at 8:43 AM, David Levin wrote:
>
> There should only be a single space before end of line comments. An
> exception is if one is lining up several end of line comments.
>
>
> I don’t think we should have this exception.
>
> Things manually lined up in source code generally create a small
> maintainability problem. You can’t rename things without re-lining things
> up, and if you make other types code changes without noticing the lined-up
> comments the code ends up looking messy an peculiar.
>

The common place to do this is on a set of constants/enum values, where I
don't think the objections you raise are a big deal.

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

Re: [webkit-dev] static const

[Peter Kasting]

On Wed, Sep 2, 2009 at 11:20 AM, Albert Wong (王重傑) wrote:

> I think there is also a slight difference between "const" versus "static
> const" in a function scope.
>

"static" has a completely different meaning in a function scope than a
file/namespace scope.  I think we were only discussing the former.

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

Re: [webkit-dev] static const

[Peter Kasting]

On Wed, Sep 2, 2009 at 9:55 AM, Alexey Proskuryakov  wrote:

> I don't have a normative reference at hand, but I'm fairly sure that both
> give internal linkage in C++ (unlike in C).
>
>
> http://stackoverflow.com/questions/998425/why-does-const-imply-internal-linkage-in-c-when-it-doesnt-in-c
> http://bytes.com/topic/c/answers/62013-const-has-internal-linkage-c


Interesting; I hadn't heard this before.

It has been a number of years since I read the relevant specs.  My
probably-faulty memory recalls things about most C compilers having a
concept of "common" linkage, where "int a;" defined in both foo.c and bar.c
would be accepted by the linker and turned into a single symbol.  Whether
this was the default varied, but apparently a lot of older C code depended
on it...

I had also thought that C++ aimed to have all file-scope objects (not just
const ones) have internal linkage unless declared "extern", but I had
thought that wasn't actually the case.

So apparently the only part I'm confident on is that Stroustrup deprecated
"static" for internal linkage and recommends anonymous namespaces in the
general case :)

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

Re: [webkit-dev] unwritten rules of webkit style

[Peter Kasting]

On Wed, Sep 2, 2009 at 9:44 AM, Adam Barth  wrote:

> On Wed, Sep 2, 2009 at 11:31 AM, Alexey Proskuryakov wrote:
> > As an aside, is there any practical difference between "static const" and
> > "const" in C++? The only difference I'm aware of is that the former is
> > deprecated in the standard.
>
> I bet they're different in the light of const_cast, but const_cast
> shines a lot of light on things that shouldn't be visible.
>
>
Darin and I have commented on this topic in a separate thread.  However I'll
say here that the constness of the two objects is precisely the same (no
const_cast<>() difference).

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

Re: [webkit-dev] unwritten rules of webkit style

[Peter Kasting]

On Wed, Sep 2, 2009 at 8:40 AM, David Levin  wrote:

> *Comments
> * There should be a *single* space after punctation and before the next
> sentence.
>
> There should only be a single space before end of line comments.
>

I don't think either of these are unwritten rules.  Both (especially the
second) are frequently seen with two spaces.  I frequently see "close of #if
or namespace" EOL comments with one space before //, and other EOL comments
with two.  I wouldn't mind standardizing (my preference is two spaces) but
I'm not sure we can yet.

*Indentation*
> Additional clauses in a conditional may be indented 4 extra spaces to
> visually separate them from the statement to be executed.
>
>
> Like this
>
> if (condition1 && condition2)
> statement;
>
>
I note you used "may" instead of "should" or "must".  It seems like we
should pick the right thing and say "must".  My reading of the current style
guide is that the current recommended indentation for this case is:
if (long_condition1
&& long_condition2
&& long_condition3)
statement;

I don't believe I've seen cases like the one you give.

*Misc*
> Files who should end with newlines.
>

s/who//.  In fact it might be clearer to say "Files should end with a
trailing newline".

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

Re: [webkit-dev] static const

[Peter Kasting]

On Wed, Sep 2, 2009 at 9:32 AM, Darin Adler  wrote:

> On Sep 2, 2009, at 9:31 AM, Alexey Proskuryakov wrote:
>
>  As an aside, is there any practical difference between "static const" and
>> "const" in C++? The only difference I'm aware of is that the former is
>> deprecated in the standard.
>>
>
> I believe the former gives internal linkage and the latter external
> linkage, so I always use the former for things defined in a source file and
> not declared in a header file and the latter for things defined or declared
> in a header file.


This is correct (both about linking and about "static" being deprecated in
C++).  Note that Stroustrup's recommendation is to use an anonymous
namespace around source-file-local variables and functions rather than
declaring them static (due to its deprecation).  From my recollection this
is not precisely equivalent in meaning but it is nearly so.  I have seen and
used both in WebKit (although "static" is more common) and I believe the
Google style guide also allows both.

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

Re: [webkit-dev] GlobalScript API.

[Peter Kasting]

On Mon, Aug 31, 2009 at 6:44 PM, Dimitri Glazkov wrote:

> > Having said that, I do think the global script object idea is a bad idea.
>
> I am not convinced it's awesome either. But thought the same (and
> still do) about HTML5 database, and yet here it is in the standard :)
>
> Ultimately, as Dmitry said, it will be developers who vote on this.
> What they will pick may not be pristinely designed multi-threaded
> APIs, but hairy, hard-to-get-right other specs that we browser
> developers would've preferred them not to.
>

I'm mainly concerned with the deleterious effects on UAs such APIs can
cause.  Look how much pain we suffer because of sync XHR, or the nasty
tendency of pages to unnecessarily share script context (e.g. between Gmail
and every page opened from within it).  I haven't looked into the details of
the GlobalScript API enough but my worry is that it might contribute to
making problems like the latter worse, or just increasing the complexity and
bugginess of the codebase in general...

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

Re: [webkit-dev] GlobalScript API.

[Peter Kasting]

On Mon, Aug 31, 2009 at 6:09 PM, Dmitry Titov  wrote:

> I'm hoping to get your advice on Global Script proposal and how to start
> implementing it as an 'experimental API' since it's not standardized yet.
>

That sounds a little optimistic when so far the feedback from Hixie is "I
haven't added the Global Script Object proposal to HTML5. ... I really don't
think it is the direction we should be taking the platform in."  I realize
that there have been subsequent comments objecting to that viewpoint, I'm
just saying that pushing boldly ahead seems... early.

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

Re: [webkit-dev] Standing of the WINCE port

[Peter Kasting]

On Fri, Aug 28, 2009 at 12:14 PM, George Staikos  wrote:

> The development of Iris Browser for Windows CE has been suspended, but we
> still plan to contribute to WebKit as a project and this does not preclude
> working on code specific to a given port.  I think there is clearly enough
> interest in the Windows CE port to keep it around, and the impact on the
> tree is really not that big.  The more intrusive changes that were done by
> Torch Mobile were specific to certain classes of features, really.  I see no
> reason to pull it out.
>

I'm not opposed to leaving things in.  I am curious as to the future of
certain specific features.  For example, the WinCE port as written had a lot
of Image system changes, and while I don't think they would have landed
as-is, they were prompting discussion about how to redesign some of the
Image subsystem to accommodate them.  If we're still hoping to land these
changes (in some form) it imposes a different set of design constraints than
if we're not.

Anyway, thanks for the reply.

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

Re: [webkit-dev] Standing of the WINCE port

[Peter Kasting]

On Wed, Aug 26, 2009 at 10:00 PM, Adam Barth  wrote:

> Is the WINCE port in a bad standing of some sort, or can reviews of
> WINCE patches proceed as normal?
>

On a related note, I have heard rumors that the acquisition of Torch Mobile
means that their development of a WinCE-based browser will cease.  I suspect
that those developers may be unable to comment about this (if so, if you're
able to say a simple "can't comment", that'd be helpful), but if they are
not, I am curious whether the WinCE port still has momentum and we should
continue working to get it in the tree, or if it is dead (in which case we
should probably pull out some of the parts that are landed).

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

Re: [webkit-dev] Whitespace changes

[Peter Kasting]

On Wed, Aug 26, 2009 at 10:43 PM, David Levin  wrote:

> fwiw, I know that the check-webkit-style checks for trailing whitespace
> (and I approved that change - sorry), but I think it should probably be
> removed.
>

Since opinions were requested, I'm in favor of both the check-webkit-style
change here and Adam's patch, as well as other cleanup patches.  Maintaining
a cultural attitude that is widely positive towards cleanup makes people
feel less reticent about cleaning up, and taking ownership of, code;
frowning on certain types of cleanup makes people less likely to do _any_
cleanup.

As far as blame annotations, I don't mind paging past a cleanup change when
trying to do archaeology on code; I have to go past enough other changes
already that one more doesn't make much of a difference overall.

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

Re: [webkit-dev] Implementation thoughts on HTML5 elements

[Peter Kasting]

On Wed, Aug 26, 2009 at 6:20 PM, Anthony Ricaud  wrote:

> So what about number implementation ?


I have no idea what state number is currently in so I have avoided
commenting on it.  I know the intent was to provide a spinbox, and that
there have been people actively working on it recently, but that's all.

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

Re: [webkit-dev] I *HATE* CHANGELOGS!!!

[Peter Kasting]

On Wed, Aug 26, 2009 at 5:44 PM, Maciej Stachowiak  wrote:

> Another possibility is to have a review site (bugzilla?) be the canonical
> place for log entries until they get committed. At commit time, a tool would
> pull from this location.
>

This is probably the closest analog to how the Chromium disciplines are
concretely implemented.

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

Re: [webkit-dev] I *HATE* CHANGELOGS!!!

[Peter Kasting]

On Wed, Aug 26, 2009 at 4:51 PM, Darin Adler  wrote:

> I get lots of history about the bug, including bug numbers that point me at
> bugs.webkit.org and even Apple’s internal Radar. And I often use the date
> to follow up reading the change in trac.
>
> On the projects I’ve worked on with more low key change description
> disciplines, I find that check-in comments or their equivalents are vague,
> and missing critical information like the name of the reviewer, whether the
> code is tested, the nature of the bug being fixed, and the nature of the
> fix.
>
> I agree that in theory we could find a different way of doing the project
> that still encourages people to communicate these things, but I am
> skeptical.


Detailed descriptions, bug links, test instructions, and a link back to the
entire original review history are all part of Chromium commits, yet we
don't use ChangeLogs.  I think discipline about what to include + tooling to
support it are orthogonal to a project's use of a ChangeLog as the mechanism
for conveying this information.

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

Re: [webkit-dev] Implementation thoughts on HTML5 elements

[Peter Kasting]

On Wed, Aug 26, 2009 at 3:57 PM, Oliver Hunt  wrote:

> The site doesn't rely on the UA providing a nice UI, but by setting these
> attributes it allows a UA that *can* provide an enhanced user experience to
> do so.  For instance type=search does not have to do anything, but on UAs
> that support it, it can maintain things like search history or whatnot.
>
> There is also the potential for these attributes to allow improved support
> for accessibility or input methods.
>

Yes, I completely agree.  In fact that's much of the point for things like
tel (especially on mobile phones).

On Wed, Aug 26, 2009 at 3:59 PM, Alex Russell 
 wrote:

> Lots of stuff on the web is best-effort, particularly when system
> integration is the point. I'm not sure that saying "the experience
> will be different" changes what semantics should be available to
> authors in any way.


I wasn't suggesting changing any semantics available to authors.  I am fine
with these types.

My comments are narrowly directed at Anthony Ricaud's comment that
"...email, url, tel ... are exposed but without new functionality. Before
that, a simple test ... was sufficient to provide an alternative via
Javascript if necessary. And it goes against the philosophy of testing the
functionality instead of relying on browser sniffing."  I am saying that
there is nothing _wrong_ with the current WebKit implementations of email,
url, tel, search.

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

Re: [webkit-dev] Implementation thoughts on HTML5 elements

[Peter Kasting]

On Wed, Aug 26, 2009 at 3:49 PM, Anthony Ricaud  wrote:

> For other types (email, tel, url), sure, authors can't implement anything
> similar. But they can style them differently, offer indications on how to
> fill them, etc. One of the reason to use new input types in HTML5 is that
> they degrade gracefully, offering hooks to authors to enhance their pages
> for browsers not supporting them while providing the "native" version for
> browsers supporting them. That's no longer possible if new types are exposed
> without new functionality.
>

Yes, you said as much already.  I maintain that there's no UI for email,
tel, url that authors can expect a UA to provide, and not providing things
like integration with a system address book is not "exposing a new type
without new functionality" in the sense that the UA is somehow lacking
something in the spec.

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

Re: [webkit-dev] Implementation thoughts on HTML5 elements

[Peter Kasting]

On Wed, Aug 26, 2009 at 3:34 PM, Maciej Stachowiak  wrote:

> I'd like to see the Mac port of WebKit offer completion based on the system
> address book. I think a lot of the times when you enter an email address on
> the Web, it's one of your own. Providing a way for Web-based Mail clients to
> integrate as a provider of address information sounds like it would be
> valuable, not just for  but for other apps on the OS.
> Perhaps GMail needs some way to plug in and provide its data to other apps.
> One existing way that would work with Mac OS X (and I expect Windows and
> Linux too) is for GMail to provide LDAP access.
>

Both those would be great.  But presumably tangential?  You are more likely
than I to know the relevant APIs on Mac tto file a good bug for this...

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

Re: [webkit-dev] Implementation thoughts on HTML5 elements

[Peter Kasting]

On Wed, Aug 26, 2009 at 3:23 PM, Michelangelo De Simone
wrote:

> 2009/8/27 Peter Kasting :
> > Consider that if the user uses a web mail app (e.g. Gmail) the UA will
> have
> > no way of getting that data.  In fact, the UA may not even know what mail
> > client the user prefers to use, especially if he uses several different
> > ones.
>
> Implementing such functionality in a port-specific way may address
> this


My main point is that it's clearly not possible to offer an identical
experience for all users in all UAs, so I can't see how a web author could
be relying on such a thing, and thus I can't see how _not_ having it in the
current WebKit implementation is somehow harming web authors.

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

Re: [webkit-dev] Implementation thoughts on HTML5 elements

[Peter Kasting]

On Wed, Aug 26, 2009 at 3:04 PM, Michelangelo De Simone
wrote:

> speaking about type=email a UI element which fetches
> email addresses from user's address book seems a happy choice to me.


Consider that if the user uses a web mail app (e.g. Gmail) the UA will have
no way of getting that data.  In fact, the UA may not even know what mail
client the user prefers to use, especially if he uses several different
ones.

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

Re: [webkit-dev] Implementation thoughts on HTML5 elements

[Peter Kasting]

On Wed, Aug 26, 2009 at 2:59 PM, Anthony Ricaud  wrote:

> Sorry, I wasn't clear enough in my explanation. I was talking about
> functionality such as Adress Book or History connection (for email, tel or
> url) or + and - buttons for numbers. The kind of features that web
> developers expect when input.type != text (like in Opera)


I'm not sure why or how web developers are relying on type=email, tel, or
URL to have a UA hook to some sort of local address book or history.  "Why"
because such behavior is not specced anywhere (and is outside the scope of
HTML5) and is unlikely to be the same between browsers, and "how" because I
don't see how a web author would compensate in the case of no type=url
support (for example) by providing a hand-rolled history list -- that data
is not available to the author.

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

Re: [webkit-dev] Implementation thoughts on HTML5 elements

[Peter Kasting]

On Tue, Aug 25, 2009 at 11:21 PM, Maciej Stachowiak  wrote:

> - new  element types
>   These seem generally useful, and we already have some implemented to
> various extents (search, range, email, url tel). The only concern is the
> sheer number of date and time controls. 6 of the 13 new input types are for
> dates or times. Are there real use cases for all 6? Do all 6 exhaustively
> cover the types of time and date input you may want to do in forms?
>

Without commenting on whether the 6 are too many or too few, one nice thing
(based on both the spec and Opera's implementation of these) is that the
work to implement all 6 looks to not be dramatically more than the work to
implement just one.  Therefore concerns can probably remain focused on
whether this set meets the real needs of the web, without worrying about
implementation difficulty.

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

Re: [webkit-dev] LayoutTest results choose from which folder?

[Peter Kasting]

On Tue, Aug 25, 2009 at 4:38 PM, Dirk Pranke  wrote:

> Thanks for the explanation, that definitely helps. Out of curiosity,
> when do you make the
> platform switch? For example, when did mac stop equalling leopard and
> start equaling snowleopard?
>

"mac" doesn't "equal snowleopard" any more than it "equals leopard".  Note
that there's a mac-snowleopard folder right now, and test results in there
would be used by any current Mac preferentially to those in "mac".

"mac" just means "the results for when there isn't a different result set
for 10.x and below".

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

Re: [webkit-dev] Bugzilla Data Loss

[Peter Kasting]

On Thu, Aug 20, 2009 at 10:52 PM, Ryosuke Niwa  wrote:

> I realized that all patches I submitted in the past 17 hours were lost as
> well.


Yes; patches that landed in the tree are still landed (although their bugs
may have risen zombie-like from the grave) since the SVN repo was not
affected, but patches that were merely attached to bugs have vanished.
Hopefully you still have local copies and can re-attach them!

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

Re: [webkit-dev] JSC without Dependencies

[Peter Kasting]

On Mon, Aug 17, 2009 at 10:22 AM, Peter Kasting  wrote:

> I am unable to help you with this goal,
>

I thought this made it clear that I didn't _know_ whether JSC could be built
standalone, but I was informed privately that this looks like I'm saying
that it definitively can't.  For the record, I didn't intend to imply any
such thing.

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

Re: [webkit-dev] JSC without Dependencies

[Peter Kasting]

On Mon, Aug 17, 2009 at 9:19 AM, Brian Barnes  wrote:

> My interest in WebKit is integrating my game engine with JSC.  I'm far
> enough into the switch over that I've begun looking at compiling it on my
> own.  My goal -- which might be a fools errand -- is to create a win32 VS
> compile without dependencies.  I don't know if this is something that I
> could give back to the project or if it's at cross purposes with the
> project.


I am unable to help you with this goal, but if you don't care which JS
engine you use, note that V8 can be downloaded and compiled standalone (see
instructions at http://code.google.com/apis/v8/build.html ) and apparently
so can SpiderMonkey (instructions at
https://developer.mozilla.org/en/SpiderMonkey_Build_Documentation , I'm not
sure if this applies to TraceMonkey as I'm not in the loop on that engine).

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

Re: [webkit-dev] Leaks in layout tests

[Peter Kasting]

On Thu, Aug 13, 2009 at 12:20 PM, Peter Kasting  wrote:

> Is it expected that we wind up in JSC::Parser?  That seems odd to me, I
> would have expected us to be in V8::something.
>

Wow, I misread run-webkit-tests as run_webkit_tests (the Chromium script)
AND thought this was a chrome-team email instead of a webkit-dev one.  Don't
I look retarded.

Sorry for the noise :P

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

Re: [webkit-dev] Leaks in layout tests

[Peter Kasting]

On Thu, Aug 13, 2009 at 12:09 PM, Drew Wilson  wrote:

> WebCore::ScriptController::evaluate(WebCore::ScriptSourceCode const&)
> JSC::evaluate(JSC::ExecState*, JSC::ScopeChain&, JSC::SourceCode const&,
> JSC::JSValue)
> WTF::PassRefPtr
> JSC::Parser::parse(JSC::ExecState*, JSC::Debugger*,
> JSC::SourceCode const&, int*, JSC::UString*)
> JSC::Parser::parse(JSC::JSGlobalData*, int*, JSC::UString*)
> jscyyparse(void*)
> JSC::ParserArenaDeletable::operator new(unsigned long)
> WTF::fastMalloc(unsigned long)
> malloc
> malloc_zone_malloc
>

Is it expected that we wind up in JSC::Parser?  That seems odd to me, I
would have expected us to be in V8::something.

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

Re: [webkit-dev] Dependency tracking in the Qt build system

[Peter Kasting]

On Wed, Aug 12, 2009 at 10:21 PM, Adam Barth  wrote:

> On Wed, Aug 12, 2009 at 10:10 PM, Joe Mason
> wrote:
> > Shouldn't buildbots always be doing a from-scratch build to ensure a
> clean
> > environment anyway?
>
> My experience is that most buildbots do incremental builds.
> Minimizing cycle time is key to making the buildbot useful.


Plus, if buildbots never did incremental builds, problems like this one
would be much harder to notice, making life difficult on developers (who
certainly do incremental builds).

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

Re: [webkit-dev] resolve-ChangeLogs now seems to be broken the same was prepare-ChangeLog was before

[Peter Kasting]

On Mon, Aug 10, 2009 at 10:55 AM, Darin Adler  wrote:

> On Aug 10, 2009, at 10:53 AM, Peter Kasting wrote:
>
>  Try changing the last line of canonicalRelativePath() from:
>>
>>return File::Spec->abs2rel($absolutePath);
>>
>> to
>>
>>return File::Spec->abs2rel($absolutePath, Cwd::getcwd());
>>
>
> That seems to have fixed the problem.
>

Great.  Fix landed in r46988.  Thanks ddkilzer for a fast r+ :)

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

Re: [webkit-dev] resolve-ChangeLogs now seems to be broken the same was prepare-ChangeLog was before

[Peter Kasting]

On Mon, Aug 10, 2009 at 10:28 AM, Peter Kasting  wrote:

> On Mon, Aug 10, 2009 at 10:27 AM, Darin Adler  wrote:
>
>> $ resolve-ChangeLogs WebCore/ChangeLog
>> svn: warning:
>> '../../../../Volumes/Home/darin/Safari/OpenSource/WebCore/ChangeLog' is not
>> a working copy
>> WARNING:
>> ../../../../Volumes/Home/darin/Safari/OpenSource/WebCore/ChangeLog is not in
>> a conflicted state.
>>
>> Anyone know who broke this?
>
>
> I don't know, and haven't touched that any time recently, but since I fixed
> your prepare-ChangeLog problem I'll take a look at this one right now.
>

Hmm, not sure why ddkilzer's new code isn't working well.  Try changing the
last line of canonicalRelativePath() from:

return File::Spec->abs2rel($absolutePath);

to

return File::Spec->abs2rel($absolutePath, Cwd::getcwd());

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

Re: [webkit-dev] resolve-ChangeLogs now seems to be broken the same was prepare-ChangeLog was before

[Peter Kasting]

On Mon, Aug 10, 2009 at 10:27 AM, Darin Adler  wrote:

> $ resolve-ChangeLogs WebCore/ChangeLog
> svn: warning:
> '../../../../Volumes/Home/darin/Safari/OpenSource/WebCore/ChangeLog' is not
> a working copy
> WARNING: ../../../../Volumes/Home/darin/Safari/OpenSource/WebCore/ChangeLog
> is not in a conflicted state.
>
> Anyone know who broke this?


I don't know, and haven't touched that any time recently, but since I fixed
your prepare-ChangeLog problem I'll take a look at this one right now.

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

Re: [webkit-dev] parallel layout research

[Peter Kasting]

On Fri, Jul 31, 2009 at 12:08 PM, Adam Roben  wrote:

> On Jul 31, 2009, at 2:59 PM, Alex Russell wrote:
>
>  After a discussion this morning about the potential for parallel CSS
>> layout with Erik Aarvidson, he pointed out a group at Berkeley doing
>> research in this area:
>>
>>   http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/
>>
>
> I think Dave Hyatt was looking into parallelizing layout a few months ago.
> I'm sure he'd have some interesting thoughts on this and the idea in
> general.


Robert O'Callahan at Mozilla has also been interested in this topic, in
Gecko.

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

Re: [webkit-dev] NeverNull

[Peter Kasting]

On Tue, Jul 28, 2009 at 4:29 PM, Jozwiak, John wrote:

> Isn't the C++ "reference" annotation
>
>  char & x;
>
> tantamount to declaration of a pointer
>
>  char * x;
>
> to whom NULL assignment, as detectable at compile time, is a compile-time
> error?


Remember that you can't "reassign" a reference like you can a pointer
(though you can naively write code to do it, and it will compile, but it
won't do what you want).  This rules out the use of references in some
situations.

References are also more "subtle" in that you can write code that changes
things when it's not so obvious what's changing as when you use pointers.
 This is the primary reason that for example the Google style guide bans the
use of non-const references.

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

Re: [webkit-dev] NeverNull

[Peter Kasting]

On Tue, Jul 28, 2009 at 3:55 PM, Oliver Hunt  wrote:

> Personally i like the idea of having type system/compiler enforced null
> checking.
>

Note that eseidel's proposal is still a runtime check.  One could use
template specialization to write a class that gives a compile-time error if
you try to assign NULL directly to a pointer, but I'm not enough of a
template wizard to know if it could be made to catch all types of assignment
(e.g. if you could catch that when a NeverNull is initialized by an
existing Foo*, that existing pointer must not contain NULL).

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

Re: [webkit-dev] Proposal about integer types used in WebKit

[Peter Kasting]

On Sat, Jul 25, 2009 at 5:59 PM, James Cloos  wrote:

> Do note that, pedantically speaking, int32_t is not required to be 32
> bits long, just long enough to store any value which could be stored in
> a 32 bit integer.  Ie, it is perfectly acceptable for an arch to use a
> 64 bit integer for int32_t.  Or a 48 bit integer.  Or 36.   Plus, the
> storage can have additional padding bits beyond the bits which can be
> seen from C/C++/etc.
>

I think you are thinking of int_least32_t.  While I don't have a copy of C99
handy, a 1998 draft of it I found online says in section 7.8.1.1 that
int32_t (and family) are exact-width types, and may not be available if an
implementation cannot provide them, while int_least32_t (and family) are
guaranteed to be available, and have at least the specified size.

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

Re: [webkit-dev] Proposal about integer types used in WebKit

[Peter Kasting]

On Fri, Jul 24, 2009 at 12:46 PM, Darin Adler  wrote:

> Some of our code uses types like int32_t, uint32_t, int64_t, and uint64_t.
> I don’t see the point of doing this. I’d like to suggest that we always use
> int where we’d otherwise use int32_t except where there is some issue of
> integration with an underlying library.
>
> Am I missing something? Is there some real benefit to using types like
> int32_t instead of int in some places in our code and not others? If so,
> what are these critical places and what makes them different from the rest
> of the code?


Besides the issue of integration with an underlying library (for example,
ImageDecoder.h uses uint32_t in one place for Skia, because Skia itself uses
uint32_t there), there are three possibilities I can think of:

* Perhaps some places that use "long long" cause MSVC to barf, and
[u]int64_t may be a necessary typedef sometimes?

* int32_t self-documents that the fact that the type is 32 bits is
critically important to the code.  (Most places that use "int", e.g. in
simple loop indexes or for "small" values, may not particularly care about
its size.)  This is much more obvious than when "int" is used.

* What if we stop assuming LP64, or WebKit code gets borrowed for use by
other projects? Personally I'd prefer to allow coders to be explicit as this
increases portability of code between different environments.

Only the first of these is a serious issue, but honestly I don't see any
benefit to forbidding int32_t (as I assume it's currently only used in a few
places, most of which probably match #2 above).

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

Re: [webkit-dev] exposing the value of Accept-Language via window.navigation.acceptLanguage ?

[Peter Kasting]

2009/7/22 Jungshik Shin (신정식, 申政湜) 

> This email is to get opinions (for and against) on that in case the
> bug is not noticed by many. As pointed out by ap in the bug, perhaps,
> we have to bring this up in the WHATWG as well. Before I do that, it
> may not be a bad idea to know what others her think about it.


There doesn't seem any harm in simply emailing the WHATWG list with this
idea.  The folks on that list are probably a better audience for the
question of "should this be done for user agents in general".

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

Re: [webkit-dev] SVN on Windows and the merits of svn:eol-style

[Peter Kasting]

On Tue, Jul 21, 2009 at 5:06 PM, Adam Barth  wrote:

> It seems like we should either be consistent and set svn:eol-style:
> native in all the appropriate files or remove it from all of them.


Note that you don't always want "native" (at least I think you don't).  For
example, in Chromium we've ended up marking .cc/.h files, as well as .sh
files, as LF.  .sln/.vcproj are CRLF (although I'm less sure what the issue
there is... it seems like "native" had some subtle issue or other).

I tend to feel like eol-style is unilaterally good except for any hassle it
causes developers to go through (hence the importance of auto-props).  Even
having it on some files doesn't seem like a bad thing to me; I certainly
wouldn't go through the tree and remove it from things.  (In fact, removing
it from some of the scripts in WebKitTools would break my checkout.)

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

[webkit-dev] SVN on Windows and the merits of svn:eol-style

[Peter Kasting]

If you do not develop on Windows, you may skip to the "*** Question ***"
portion below.

*** PSA for Windows developers ***

Until now WebKit developers on Windows have had to use the Cygwin version of
svn, rather than a "standard" Windows svn, due to limitations in the WebKit
scripts, build process, etc.
On https://bugs.webkit.org/show_bug.cgi?id=27323 I have been working to
remove those roadblocks, and today I have locally succeeded in using my
Windows SVN to:
* check out
* update (via update-webkit and resolve-ChangeLogs)
* build (via build-webkit)
* run (via run-safari)
* prepare patches (via prepare-ChangeLog and svn-create-patch)
* apply and unapply patches (via svn-apply and svn-unapply)
* commit (using commit-log-editor)

Added bonus of a couple other fixes: I did this with a
WebKit-inside-Chromium checkout.  In theory this means projects that wish to
include WebKit from the master repository (via svn:externals or some other
mechanism) as part of their source tree may be able to develop in a single
checkout.

Not all these patches have been reviewed and landed yet, but things are
close.

*** Question ***

There is one roadblock to this setup.  SVN-on-Windows seems to have a bug
where sometimes (depending on the state of the repository and the checkout),
the diffs it produces for files without svn:eol-style set won't
apply/unapply cleanly, due to line ending issues.

The obvious workaround is to set svn:eol-style everywhere.  This has other
side benefits (e.g. preventing files from being checked in with mixed line
endings, and preventing line-ending-sensitive files from being changed
accidentally), and I am told by Eric Seidel that in fact some time ago Darin
Adler used to try and maintain something like this.  As a result, a large
portion of the WebKit tree already has this property set.

My question is, how desirable and feasible would it be to return to having
eol-style everywhere?

For a relevant anecdote, in Chromium we enforce that files have
svn:eol-style.  This was done using three steps:
* Scripts were used to find files lacking svn:eol-style and set it
appropriately.
* A commit hook was added to prevent developers from regressing this.
* We document a set of auto-props to configure SVN with, so that it will
automatically add eol-style on new files without developers having to do it
manually.

I am not capable of doing the first two of these steps myself, but there are
Chromium team members who could consult if we decided this was a desirable
path for WebKit.  The goal would be to minimize disruption and not cause any
ongoing annoyance.

Comments?

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

Re: [webkit-dev] svn-create-patch acting oddly lately

[Peter Kasting]

On Mon, Jul 20, 2009 at 2:52 PM, Darin Adler  wrote:

> On Jul 20, 2009, at 2:50 PM, Peter Kasting wrote:
>
>  my ($newdir) = @_;
>> my $before = Cwd::getcwd();
>> chdir $newdir;
>> my $after = Cwd::getcwd();
>>
>> That seems like it ought to work a lot better.
>>
>
> Yes, it does. Hooray!


Awesome.  I'll get this patch up for review.  Thanks for your patience
Darin!

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

Re: [webkit-dev] svn-create-patch acting oddly lately

[Peter Kasting]

On Mon, Jul 20, 2009 at 2:40 PM, Peter Kasting  wrote:

> It looks from here like the chdir call is causing curdir() to report the
> non-symbolic-link form of things.  If that's true, it seems like this
> workaround would work:
>
> ...
> my ($newdir) = @_;
> my $before = File::Spec->rel2abs( File::Spec->curdir() );
> + chdir $before;  # Try and force curdir() to report the directory without
> symbolic links.
> + $before = File::Spec->rel2abs( File::Spec->curdir() );
> chdir $newdir;
> my $after = File::Spec->rel2abs( File::Spec->curdir() );
> ...
>
> Could you try this and see if it works?
>
> Also, any Perl hackers are welcome to chip in here on how the current code
> should be improved.  I just looked up docs on the File::Spec module and saw
> them mentioning something about realpath() that might be relevant here...
>

Looking at this more, this code just looks wrong to me (although, like I
said, I know roughly zero Perl, so my instincts are not trustworthy).

Perhaps instead of the hack above, try adding "use Cwd;" to the top of the
file and then changing this to:

...
my ($newdir) = @_;
my $before = Cwd::getcwd();
chdir $newdir;
my $after = Cwd::getcwd();
...

That seems like it ought to work a lot better.

If that solves your problem, I'll get this reviewed and checked in.

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

Re: [webkit-dev] svn-create-patch acting oddly lately

[Peter Kasting]

On Mon, Jul 20, 2009 at 2:24 PM, Darin Adler  wrote:

> The key here is that "/Users/darin" is a symbolic link to
> "/Volumes/Home/darin" — you can probably reproduce this by putting the
> checkout directory inside a symbolic link.
>

Doesn't help on my Windows box at least... all my checkouts are rooted at
symbolic links.

 In determineSvnRoot(), $last is ".." and then $svnRoot ends up as
> "/Users/darin/Safari/OpenSource/WebKit/..", which seems bad. Is rel2abs
> supposed to handle that?


Not sure.  JoePeck and I have talked some on IRC since this code was from
his patch.  He says he's encountered rel2abs() behaving differently on
different systems.  I know so little about Perl that I'm not sure what to do
with that info.

In chdirAndGetDifference(), before is
> "/Users/darin/Safari/OpenSource/WebKit" and after is
> "/Volumes/Home/darin/Safari/OpenSource".


That's definitely bad, and seems like the source of this issue.

It looks from here like the chdir call is causing curdir() to report the
non-symbolic-link form of things.  If that's true, it seems like this
workaround would work:

...
my ($newdir) = @_;
my $before = File::Spec->rel2abs( File::Spec->curdir() );
+ chdir $before;  # Try and force curdir() to report the directory without
symbolic links.
+ $before = File::Spec->rel2abs( File::Spec->curdir() );
chdir $newdir;
my $after = File::Spec->rel2abs( File::Spec->curdir() );
...

Could you try this and see if it works?

Also, any Perl hackers are welcome to chip in here on how the current code
should be improved.  I just looked up docs on the File::Spec module and saw
them mentioning something about realpath() that might be relevant here...

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

Re: [webkit-dev] svn-create-patch acting oddly lately

[Peter Kasting]

On Mon, Jul 20, 2009 at 2:11 PM, Joseph Pecoraro wrote:
>
> Yes, I saw scm.py's solution literally yesterday while I was learning how
> to use bugzilla-tool because I switched to git.  In any case the newer
> revision uses a much better approach then the one in this changelog
> (Repository Root) and ultimately the best approach would be using the UUID
> like you suggested.
>

I can switch svn-create-patch to using UUID if there are benefits over using
the Repository Root; it'd literally be a four-character change.

In the meantime, I've tried and failed to recreate Darin's problem locally,
so I'm at the mercy of other people to report that they're having this
problem.

In case it helps, the relevant bugs where svn-create-patch was changed seem
to be bug 26999 (source of the original change eseidel mentions) and bug
27323 (source of my updates to the recently-added root calculation code).

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

Re: [webkit-dev] svn-create-patch acting oddly lately

[Peter Kasting]

On Mon, Jul 20, 2009 at 2:03 PM, Adam Barth  wrote:

> It's kind of sad that we have so many ways of finding the SVN root.
> The code in that link isn't right.  You need to look at the UUID to
> get the right answer.  See scm.py.


My update made us look at the Repository Root field instead of looking at
the error code returned by svn info.  It seems like in practice this should
be as good as the Repository UUID field.  Or do you think I should change
it?

Also, if you and/or Darin were on IRC, I could ask this without annoying all
the other folks on webkit-dev@ :)

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

Re: [webkit-dev] svn-create-patch acting oddly lately

[Peter Kasting]

On Mon, Jul 20, 2009 at 1:55 PM, Eric Seidel  wrote:

> It could also be from http://trac.webkit.org/changeset/45939.


Yes.  Knowing Darin's repository version would help narrow this down.

I am trying different things to see if I can reproduce locally.  Once I can
reproduce I will either fix the problem or back out the offending change
immediately.

If anyone else has this problem, and is up-to-date, please let me know here
or on IRC.  I would love to find out that this is in fact just a problem of
an out-of-date checkout but somehow I doubt it.

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

Re: [webkit-dev] svn-create-patch acting oddly lately

[Peter Kasting]

On Mon, Jul 20, 2009 at 1:28 PM, Darin Adler  wrote:

> My patches look like this now:
>
> $ svn-create-patch
> svn: Path '../..' ends in '..', which is unsupported for this operation


This warning was caused by a change of mine that I checked in a fix for at
noon on Friday.  It shouldn't still happen on an up-to-date
svn-create-patch.  If your svn-create-patch is at least r46054 and this is
happening, something is wrong.

Index:
> ../../../../../Users/darin/Safari/OpenSource/WebKit/mac/WebView/WebHTMLView.mm
> ===
> ---
> ../../../../../Users/darin/Safari/OpenSource/WebKit/mac/WebView/WebHTMLView.mm
>  (revision 46038)
> +++
> ../../../../../Users/darin/Safari/OpenSource/WebKit/mac/WebView/WebHTMLView.mm
>  (working copy)


This seems bad.  I haven't seen this locally but I could have caused it.  Is
there any svn repository for any of the directories above your WebKit
checkout?  If your checkout wasn't quite up-to-date above, does updating fix
this?

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

Re: [webkit-dev] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family)

[Peter Kasting]

On Tue, Jul 14, 2009 at 11:20 AM, Brent Fulgham  wrote:

> Do we feel that GYP is finally the right tool?
>

Well, unlike SCons we're actually building all our ports on top of GYP.  We
never actually expanded SCons to all platforms or addressed the problems we
had with it.

But I can't speak for eternity.  If some other tool comes up that's even
better then I imagine we'd switch to that.

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

Re: [webkit-dev] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family)

[Peter Kasting]

On Tue, Jul 14, 2009 at 9:24 AM, Kevin Ollivier wrote:

> Of course, the big question is if waf would have the same limitations as
> SCons in regards to doing this, but I think it's at least worth exploring.
> I'd be interested to know what limitations you guys ran into when trying to
> use SCons for this sort of thing. Of course, there will always be some
> things that would be hard to do with the IDE projects, but it may be
> possible for us to make use of waf there too, by using command line
> arguments to have it, for example, only generate the derived sources, which
> we could call from the IDE projects.
>

I don't really know enough about either waf or SCons to comment.  My
impression as a naive observer was that SCons had serious speed issues with
our build (especially the overhead for a null build).

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

Re: [webkit-dev] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family)

[Peter Kasting]

On Mon, Jul 13, 2009 at 1:56 PM, Maciej Stachowiak  wrote:

> One belated comment on this topic. It would be neat if some port agreed to
> be the guinea pig to see if gyp could plausibly work for more than Google's
> ports. The Wx port probably has the lowest resources of any complete port in
> the tree, so they might not be the best choice of experimental subject,
> particularly if for them the process required writing a new gyp back end and
> if they are not yet entirely comfortable going the gyp route.
>

Another note, based on some #chromium conversations: if someone passionate
made CMake (or any other tool) into something compelling enough to work
better for Chromium than gyp does (or at least to work close-to-as-well),
and that tool was more plausible for other ports in the WK tree to adopt, we
wouldn't be opposed in principle to using it.  The potential benefits of a
shared build system are clear, and we're not trying to tell people that
system has to be gyp; we're just probably not prepared to be the ones to go
determine other ports' needs and decide on the Build System To Rule Them
All.

If no one wants to do this, but other ports do want to try gyp, we can lend
them a hand in checking it out too.  Whatever makes things at least a little
easier.

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

Re: [webkit-dev] Please welcome GYP to the our dysfunctional build family

[Peter Kasting]

On Mon, Jul 13, 2009 at 12:24 PM, Mark Mentovai  wrote:

> We also considered CMake, and had it demonstrably working for some of
> our smaller projects as well.
>

BTW, Mark's list of issues with CMake is non-exhaustive (we can share more
if desired), but we're not trying to slag CMake - it's a good tool in a lot
of ways, it just didn't happen to be the right fit for us.

So perhaps the takeaway other ports should have from all this is not that
we're selling GYP as the be-all, end-all build tool for everyone, we're
simply noting that since it's in the tree and we're maintaining it, if other
people want to make use of it too, they'd be welcome if it fits their needs
the way it fits ours.

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

Re: [webkit-dev] ENABLE_FORM_VALIDATION

[Peter Kasting]

On Mon, Jul 13, 2009 at 10:47 AM, David Hyatt  wrote:

> I agree.  We should formalize this as policy too in my opinion.  Maybe
> something time-based, e.g., if you have an implementation of a new Web
> technology that is going to take > (1month?) to implement, then the feature
> should be landed inside ENABLE ifdefs (that can then be removed when the
> feature is sufficiently far along).
>

For Chromium this kind of time frame can be problematic, since there's
pretty much no guarantee of when a WebKit trunk build could be shipped as
(eventually) a stable Chromium/Google Chrome release.  Even having an
incomplete feature in the tree a few days can result in the incomplete
feature getting shipped to web authors.

There is a general problem here of "when is the WebKit trunk shippable by
third-parties", which is an issue too large and hairy for me to get into,
let alone propose concrete changes for.  However, if we simply had a policy
of "if a web author can detect and try to use the feature, but it doesn't
work right yet, then put it under a flag", that would at least take care of
this piece of the problem.

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

Re: [webkit-dev] ENABLE_FORM_VALIDATION

[Peter Kasting]

On Mon, Jul 13, 2009 at 10:40 AM, Darin Fisher  wrote:

> I'd like to propose that we add an ENABLE_FORM_VALIDATION flag (or
> something similarly named).  I'm writing this to webkit-dev because I want
> to make sure that other new web platform features that may be in development
> get similar treatment while they are still in development.  Any objections?
>

No objections, but I'd like to note that I'm about to back out the upstream
patch for this since in addition to this problem and it breaking the
Chromium build downstream (easy fix), it also has issues with bindings, and
it broke a layout test.  It's easier to just fix these all at once.

When it relands I will see if I can figure out what the ENABLE flag should
cover and make sure it's covered.  I'm concerned about other things already
in the tree with "valid" in their name, e.g. "readonly attribute boolean
willValidate" -- not sure if these should also be under the flag for now.

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

Re: [webkit-dev] Iterating SunSpider

[Peter Kasting]

On Tue, Jul 7, 2009 at 5:08 PM, Maciej Stachowiak  wrote:

> On Jul 7, 2009, at 4:19 PM, Peter Kasting wrote:
>
>> For example, the framework could compute both sums _and_ geomeans, if
>> people thought both were valuable.
>>
>
> That's a plausible thing to do, but I think there's a downside: if you make
> a change that moves the two scores in opposite directions, the benchmark
> doesn't help you decide if it's good or not. Avoiding paralysis in the face
> of tradeoffs is part of the reason we look primarily at the total score, not
> the individual subtest scores. The whole point of a meta-benchmark like this
> is to force ourselves to simplemindedly look at only one number.


Yes, I originally had more text like "deciding how to use these scores would
be the hard part", and this is precisely why.

I suppose that if different vendors wanted to use different criteria to
determine what to do in the face of a tradeoff, the benchmark could simply
be a data source, rather than a strong guide.  But this would make it
difficult to use the benchmark to compare engines, which is currently a key
use of SunSpider (and is a key failing, IMO, of frameworks like Dromaeo that
don't run identical code on every engine [IIRC]).

I think there's one way in which sampling the Web is not quite right. To
> some extent, what matters is not average density of an operation but peak
> density. An operation that's used a *lot* by a few sites and hardly used by
> most sites, may deserve a weighting above its average proportion of Web use.


If I understand you right, the effect you're noting is that speeding up
every web page by 1 ms might be a larger net win but a smaller perceived win
than speeding up, say, Gmail alone by 100 ms.

I think this is true.  One way to capture this would be to say that at least
part of the benchmark should concentrate on operations that are used in the
inner loops of any of n popular websites, without regard to their overall
frequency on the web.  (Although perhaps the two correlate well and there
aren't a lot of "rare but peaky" operations?  I don't know.)


> - GC load


I second this.  As people use more tabs and larger, more complex apps, the
performance of an engine under heavier GC load becomes more relevant.

It would be good to know what other things should be tested that are not
> sufficiently covered.


I think DOM bindings are hard to test and would benefit from benchmarking.
 No public benchmarks seem to test these well today.

* - For example, Mozilla's TraceMonkey effort showed relatively little
> improvement on the V8 benchmark, even though it showed significant
> improvement on SunSpider and other benchmarks. I think TraceMonkey speedups
> are real and significant, so this would tend to undermine my confidence in
> the V8 benchmark's coverage.


I agree that the V8 benchmark's coverage is inadequate and that the example
you mention illuminates that, because TraceMonkey definitely performs better
than SpiderMonkey in my own usage.  I wonder if there may have been an
opposite effect in a few cases where benchmarks with very simple tight loops
improved _more_ under TM than "real-world code" did, but I think the answer
to that is simply that benchmarks should be testing both kinds of code.

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

Re: [webkit-dev] Iterating SunSpider

[Peter Kasting]

I'm more verbose than Mike, but it seems like people are talking past each
other.

On Tue, Jul 7, 2009 at 3:25 PM, Oliver Hunt  wrote:

> If we see one section of the test taking dramatically longer than another
> then we can assume that we have not been paying enough attention to
> performance in that area,
>

It depends on what your goal with perf is.  If the goal is to balance
optimizations such that operation A always consumes the same time as
operation B, you are correct.  But is this always best?  The current design
says "yes".  The open question is whether that is the best possible design.

On Tue, Jul 7, 2009 at 3:58 PM, Geoffrey Garen  wrote:
>
> I also don't buy your conclusion -- that if regular expressions account for
> 1% of JavaScript time on the Internet overall, they need not be optimized.


I didn't see Mike say that regexes "did not need to be optimized".

If given an operation that occurs 20% of the time and another that occurs 1%
of the time, I certainly think it _might_ be appropriate to spend more
engineering effort on optimizing the first operation.  Knowing for sure
depends on how much you value the rarer cases, for reasons such as you give
next:

Second, it's important for all web apps to be fast in WebKit -- not just the
> ones that do what's common overall. Third, we want to enable not only the
> web applications of today, but also the web applications of tomorrow.


I strongly agree with these principles, but I don't see why the current
design necessarily does a better job of preserving them than all other
designs.  For example, let's say at the time SunSpider was created (and
everything was roughly equal-weighted) that one of the subtests tested a
horribly slow operation that would greatly benefit future web apps if it
improved substantially.  Unfortunately, the original equal-weighting
enshrines the slowness of this operation, relative to the others being
tested, such that if you begin to make it faster, the subtests become
unbalanced and you conclude that no further work on it is needed for the
time being.  This is a suboptimal outcome.

So in general, the question is: when some operation is slower than others,
what criteria can we use to make the best decisions about where to spend
developer effort?  Surely our greatest cost here is opportunity cost.

I accept Maciej's statement that the current design was intentional.  I also
accept that sums and geomeans each have drawbacks in guiding
decision-making.  I simply want to focus on finding the best possible design
for the framework.

For example, the framework could compute both sums _and_ geomeans, if people
thought both were valuable.  We could agree on a way of benchmarking a
representative sample of current sites to get an idea of how widespread
certain operations currently are.  We could talk with the maintainers of
jQuery, Dojo, etc. to see what sorts of operations they think would be
helpful to future apps to make faster.  We could instrument browsers to have
some sort of (opt-in) sampling of real-world workloads.  etc.  Surely
together we can come up with ways to make Sunspider even better, while
keeping its current strengths in mind.

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

Re: [webkit-dev] Iterating SunSpider

[Peter Kasting]

On Sat, Jul 4, 2009 at 11:47 AM, Mike Belshe  wrote:

> #3: The SunSpider harness has a variance problem due to CPU power savings
> modes.
>

This one worries me because it decreases the consistency/reproducibility of
test scores and makes it harder to compare engines or to track one engine's
scores over time.  For example, doing a bunch of CPU work just before
running the benchmark can affect whether and when the CPU throttles down
during the benchmark run.

Possible solution:
> The dromaeo test suite already incorporates the SunSpider individual tests
> under a new benchmark harness which fixes all 3 of the above issues.   Thus,
> one approach would be to retire SunSpider 0.9 in favor of Dromaeo.
> http://dromaeo.com/?sunspider  Dromaeo has also done a lot of good work to
> ensure statistical significance of the results.  Once we have a better
> benchmarking framework, it would be great to build a new microbenchmark mix
> which more realistically exercises today's JavaScript.
>

One complaint I have heard about the Dromaeo tests (not the harness) is that
the actual JS that gets run differs from browser to browser (e.g. because it
is a direct copy of a source library that does UA sniffing).  If this is
true it means that this suite as-is isn't useful to compare engines to each
other.

However, the Dromaeo _harness_ is probably a win as-is.

Of course, changing anything about Sunspider raises the question of
tracking historical performance.  Perhaps the harness could support
versioning, or perhaps people are simply willing to say "Sunspider
1.0 scores cannot be compared to Sunspider 0.9 scores".  I believe this is
the approach the V8 benchmark takes.

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

Re: [webkit-dev] ChangeLog

[Peter Kasting]

On Fri, Jul 3, 2009 at 10:55 AM, Darin Adler  wrote:

> It's backwards to say that the ChangeLog is a workaround for lack of tools.
> Some day we may see a tool that works so well that we’d be willing to forgo
> change logs, but we need to see that tool in action first to see that it
> functions so well it obviates the need for ChangeLog.
>

I once again suggest Rietveld, which has been suggested here before.

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

Re: [webkit-dev] Changes to prepare-ChangeLog

[Peter Kasting]

Since this seems to have become the new bikeshed, I'll chime in with my
color preference:


Reviewed by John Smith (jsm...@webkit.org)

https://bugs.webkit.org/show_bug.cgi?id=123456
Fix WebKit being not awesome enough.  Make five files more awesome.



FWIW, I agree with those who desire to ditch the ChangeLog.  WebKit is the
only project I've worked on that does such a thing, and I have never gotten
any benefit out of it, while I've gotten lots of headache (merge conflicts
especially).  On Chromium, patches are given a detailed ChangeLog-esque
description which is visible in the review tool and becomes the commit log
message as well (which links back to the review URL, and is also auto-pasted
into the original bug report).  This way from any of (bug system, commit
logs, review system) you can find information about a particular patch or
search for patches matching some comment.  This turns out to work quite well
in practice.  In WebKit I try to give my patches these sorts of comments
when I post them for review, but duplicating info between the ChangeLog and
the review comments always makes me write less than I otherwise would, and
review comments tend to get buried in the sea of noise from bugzilla.

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

Re: [webkit-dev] WebKit/EFL port 0.1 released.

[Peter Kasting]

On Mon, Jun 29, 2009 at 6:48 AM, tonikitoo (Antonio Gomes) <
toniki...@gmail.com> wrote:

> Since it has been asked, in a soon future we will be also start the
> process of trying to get WebKit/EFL [1] port also upstream'ed.
> @Olivier: in terms of a new port, how would "small patches" fit ?
> Actually, I was thinking about split up the port code into at least
> four patches (probably not small):
>
> * WebKit/
> * WebCore/
> * JavaScriptCore/
> * build system.
>
> Is that the right way to attach them to bugzilla ?
>

I suspect these will be far too large to review and need to be split into
much smaller patches.  You'll want to land individual features and
abstractions one at a time where possible.

For reference, landing the Chromium port (likely more complex than most
other ports as it needed both a different JS engine and multi-process
architectural support) took a number of months of full-time effort from
several engineers.

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

Re: [webkit-dev] Question about Constructors in WebKit JS Bindings

[Peter Kasting]

On Mon, Jun 22, 2009 at 9:53 PM, Adam Barth  wrote:

> On Mon, Jun 22, 2009 at 7:04 PM, Maciej Stachowiak wrote:
> > Your proposed alternative will have different behavior. It will use the
> > lexical global object of the calling JavaScript function, instead of the
> > global object originally associated with the Options constructor.
>
> Yes.  Almost everywhere you see this pattern it's incorrect.  We have
> this bug a lot.


To be clear, are you saying the original pattern, or the "simpler" one Drew
proposes is typically the incorrect one?  (I assume the latter.)

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

Re: [webkit-dev] JavaScriptCore in Windows Applications

[Peter Kasting]

On Mon, Jun 22, 2009 at 7:12 AM,  wrote:

> Thank you very much for your reply.  It was very helpful.  Unfortunately,
> I cannot compile your CallJS sample.  It appears that the 'afxwin.h' file
> is not present on my system.  Is it not possible to compile your sample
> with Visual C++ 2005 Express Edition with the Windows Server 2003 R2 SDK?


VC2005 Express has several intentionally-crippled bits, such as this, to
avoid cannibalizing sales of the non-free version.  I don't remember if this
particular issue was corrected in VS2008.  You may want to spring for a copy
of VS2005 Pro if it wasn't.

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

Re: [webkit-dev] Windows Multithread issue

[Peter Kasting]

2009/6/15 John Abd-El-Malek 

> Yes it's possible.  The Chromium port runs web views in different
> processes.  You can look at the design docs and source to see how it's done,
> that should give you an idea of what you have to do this on different
> threads.


Note that using distinct processes (as Chromium does) is quite different
than using distinct threads -- the latter would require a threadsafe
codebase, which in large part WebKit today is not (though Dave Hyatt has
been doing some prototyping work in this area recently).

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

Re: [webkit-dev] about webkit's license in chrome

[Peter Kasting]

2009/6/11 David Jones 

> As listed in http://code.google.com/chromium/terms.html#3rdparty ,
> there're three different licenses of webkit in chrome:
> BSD /LGPL 2/LGPL 
> 2.1
>
>
> Why?
>

For the same reason the Mozilla code lists three licenses: because the code
is tri-licensed.  It is offered simultaneously under three different
licenses.

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

Re: [webkit-dev] to reitveld or not to reitveld

[Peter Kasting]

On Thu, Jun 11, 2009 at 3:21 PM, Mark Rowe  wrote:

> Given what has been said so far I'm still not clear why Rietvald is a
> better option than Review Board.
>

I think it's because we have a bunch of people who are (a) familiar with
using it and/or (b) work on it and can fix any problems, whereas neither is
true for Review Board.

Also I haven't really heard much significantly "Review Board > Rietveld",
more the sense of "we could try these both out".

It seems like reading between the lines you're really uncomfortable with
Rietveld in principle.  Is there something about it that you feel is
inherently not going to work well?

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

Re: [webkit-dev] #16401 webkit glib / gobject bindings

[Peter Kasting]

This was a long message.  I couldn't figure out what it was saying (the
length discouraged me from trying too hard).  Perhaps you could summarize in
a sentence or two?  It seemed like something about DOM bindings for other
languages and whether or not people care?
I also tried to look at bug 16401, and even just comment 200, but both were
also incredibly long and I gave up.  Sorry.

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

Re: [webkit-dev] to reitveld or not to reitveld

[Peter Kasting]

Clarifications:

On Sat, Jun 6, 2009 at 3:02 PM, Peter Kasting  wrote:

> I'm not trying to be hyperbolic.
>

On the other hand, I could simply be flat-out wrong.  Although I did re-read
Ojan's email and I don't I see him as saying there'd be a lot of actual
coding needed to try Rietveld.

- Doesn't work with diff's generated by git.
>>
>
> I didn't realize git was formally supported by WebKit.  I assume git can
> generate diff/patch/svn-compatible diffs with some options (I am not a git
> user).
>

Also, a bunch of Chromium team members use git full-time, so I assume they
have in fact already solved this problem.

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

Re: [webkit-dev] to reitveld or not to reitveld

[Peter Kasting]

On Sat, Jun 6, 2009 at 1:48 AM, Mark Rowe  wrote:

> Per Ojan's original email it is not as simple as adding a few URLs to some
> scripts, code changes would be needed to make it suitable for our purposes.
>  Let's try and avoid hyperbole: it makes it difficult to have a reasonable
> discussion.
>

I'm not trying to be hyperbolic.  It is my sincere opinion that in fact the
changes are as simple as I mentioned.

Of the issues that Ojan mentioned in his original email, I see three that
> would need to be addressed before we could consider adopting Rietveld:
> - Currently tied to AppEngine.
>

I don't understand why this is problematic in the least, any more than
saying "Bugzilla is currently tied to being run by Bugzilla".  Why does it
matter what the backing implementation of Rietveld is?


> - Doesn't work with diff's generated by git.
>

I didn't realize git was formally supported by WebKit.  I assume git can
generate diff/patch/svn-compatible diffs with some options (I am not a git
user).

- UI is intimidating to newcomers.  This is clearly subjective, but since
> the goal here is to make the review process friendlier, especially for new
> contributors, I think it deserves calling out.
>

I find the Rietveld UI mostly easy to understand with one or two learning
bits.  It didn't intimidate me when I started using it.  It certainly was
far easier to understand than Bugzilla's review methods.  In my mind this is
a plus, not a minus.

Subjective, less important issues:
> - I'm not sure about keeping patches and the bugs that they address in
> separate systems.  It seems that discussion about a bug can end up split
> between the two systems.
>

This is not really much different from how right now bugs and IRC can both
serve as discussion points for an issue.  Generally in Chromium today bugs
get discussed on the bug, and patches get discussed on the patch.  If a
patch raises issues with a bug, we usually comment on the bug and note on
the patch as appropriate ("sorry, I don't think this bug should be
addressed.  See comments there.")


> - It's hard to spell.  Retyping it to fix the spelling makes me sad.
>

Other than this email series, I've never actually had to spell Rietveld.
 Certainly not while submitting, editing, reviewing, or landing patches :).
 I think this is irrelevant.

In summary, I did not realize that the WebKit community was even interested
in changing their review system before seeing these emails, but if they are,
I sincerely believe that Rietveld is far better than Bugzilla for patch
review and strong consideration should be given to simply dropping it in,
which I believe would be very easy to do.

PK

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

Re: [webkit-dev] to reitveld or not to reitveld

[Peter Kasting]

On Fri, Jun 5, 2009 at 11:43 PM, Mark Rowe  wrote:

> Dropping our existing practice of using Bugzilla for patch reviews is one
> way of addressing this.  Folding the more useful features of Rietveld in to
> Bugzilla to improve Bugzilla-based patch reviews is another.  We all seem to
> be in agreement that the tools involved with reviewing a patch have room for
> improvement, but
> I've not seen a compelling reason why the former is a better way forward.
>

If people were really interested in changing, then it would take probably
two orders of magnitude less effort to set up a Rietveld instance to
associate with Bugzilla (to the degree it currently can associate with the
Google Code bug tracker), as compared with improving Bugzilla.  The former
is basically adding a few URLs to some scripts, the latter is highly
nontrivial coding.  That seems compelling to me.

> (Right now it's about 10x easier for me to get a Chromium patch reviewed
> than a WebKit one just because a single shell command can create a Rietveld
> issue with my patch and set the description up for me.)
>
>
> This something of a non-sequiter, since it is trivial to create a script to
> do the same with Bugzilla.  I've heard mentions of a git-send-bugzilla
> script that does most of this already, and I'm sure it could easily be
> adapted for those preferring SVN.
>

True.  Still, I _have_ that script for Chromium, and I don't for WebKit :).

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

Re: [webkit-dev] to reitveld or not to reitveld

[Peter Kasting]

On Fri, Jun 5, 2009 at 9:13 PM, Darren VanBuren  wrote:

> I agree that using RPC is inefficient, and that we don't want to make the
> review process any more of a pain. We could also try writing our own code
> review software specifically designed to work with Bugzilla, so that we
> could run directly in the Bugzilla environment, and we could modify and
> retrieve bugs without throwing stuff around RPC channels, just by running
> some calls in the Bugzilla modules.
>

FWIW, in Chromium land we do all the patches *solely* on Rietveld, and never
touch the bug tracker at all with them.  We have tools that auto-update bugs
when patches are checked in and can provide handy links back and forth
between the tools, and that's enough.  I'm not a WebKit reviewer but I was a
Mozilla reviewer, which also does things on Bugzilla, and I don't miss the
ability to post a patch on a bug at all.  There is literally nothing in that
workflow that helps me review/land patches more easily, and it's still just
as easy to backtrack after the fact and find what got reviewed/landed
starting from a bug.  So if people who wanted to use Rietveld to do code
review didn't have obvious ways to attach those patches to Bugzilla bugs,
I'm not sure it would be a big stumbling block.  (Right now it's about 10x
easier for me to get a Chromium patch reviewed than a WebKit one just
because a single shell command can create a Rietveld issue with my patch and
set the description up for me.)

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

Re: [webkit-dev] Ruby design document

[Peter Kasting]

On Wed, Jun 3, 2009 at 5:04 PM, Roland Steiner wrote:

> However, if the consensus is that we should rather take those objects out
> (Ian Hickson doesn't seem to be a fan of complex ruby, either), then of
> course I can remove them from the code. The resulting object model would
> probably look like:
>
> ruby : RenderInline or RenderBlock (inline-block)
> ruby-run : RenderBlock (inline-block with inline children) - 1 or
> more
> ruby-base : RenderInline -> InlineFlowBox - 1
> ruby-text : RenderInline -> InlineFlowBox - 0 or 1 (could even
> allow 2, for both 'before' and 'after' positions)
>

Seems like it wouldn't be hard to add the complexity in later (as a second
pass) if we decide there's value there; in the meantime, writing the
simplest possible implementation has testing and code readability benefits.
 I suggest sticking with the simple stuff that's sufficient to do HTML5 as a
first pas.  When everything is in, tested and working, you can evaluate if
more complex support a la the current CSS3 spec is a good idea.  If so it'd
probably make sense to get HTMLx (whatever x is by then, perhaps 6) to agree
so that other browsers are all on board too.

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

Re: [webkit-dev] Ruby design document

[Peter Kasting]

On Wed, Jun 3, 2009 at 2:12 PM, Roland Steiner wrote:

> I am in the process of implementing ruby (text annotations, mainly used in
> East-Asian text), and would welcome if folks could give me feedback on my
> design document, esp. regarding the rendering/layouting:
>
> http://docs.google.com/View?id=dcgd8hk6_0ccsw4td4


Your doc mentions the CSS3 ruby specs, but not the HTML5 specs (e.g.
http://www.whatwg.org/specs/web-apps/current-work/#the-ruby-element ).  It
would be good to link to the HTML5 doc, and perhaps note differences between
the specs (I suggest implementing HTML5 in any cases where HTML5 and CSS3
differ).

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

Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs

[Peter Kasting]

On Mon, May 25, 2009 at 1:33 PM, Mark Rowe  wrote:

> Xcode and GCC on Mac OS X avoid this issue by building a map of header
> files in the project and their locations on disk, so the compiler doesn't
> have to walk the header entire search path every time you include a file.
>  It's unfortunate if other compilers aren't smart enough to work well with
> this incredibly common approach to #includes and header search paths.
>

FWIW, it's also clearer -- seeing at a glance to Foo.h is from
WebCore/platform versus WebCore/page is good information (and no one has
every single header's origin and meaning in their heads).

Increased clarity, fewer errors/conflicts, and a giant speedup on some
compilers seem worth the (IMO minor) cost of having to do a
search-and-replace when moving headers around.

I didn't really mean to derail the existing discussion, though.  This isn't
really the same topic.

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

Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs

[Peter Kasting]

On Mon, May 25, 2009 at 12:49 AM, Maciej Stachowiak  wrote:

> Now, the thing I _would_ like to change is to switch from pathless
> #includes to ones with relative paths -- but that's a totally different
> thread.
>
>
> That I definitely wouldn't like. It would make it much more painful to move
> files. What is the benefit? Maybe UI am missing something.
>

Massively decreased compile time.  We've measured and the time taken to
search the various #include paths is large.  Occasionally this pathless
solution can also cause issues when there are multiple headers with the same
name in the project (we ran into this a number of times over the course of
Chromium development).

On the Chromium side, we follow the Google style guide, which mandates paths
on #includes, and we've rearranged our entire source layout a number of
times.  It doesn't turn out to be a huge problem and the compile-speed
benefits are well worth it.

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

Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs

[Peter Kasting]

On Sun, May 24, 2009 at 11:17 PM, David Hyatt  wrote:

> Can you cite a particular class as an example?  I don't think we have any
> aversion to using per-port subclasses as long as we aren't incurring a
> vtable cost and as long as that class has no subclasses already.
>

I don't think you do either, which is part of why I said that I think when
this has come up it's been handled quite well.  I think historically most
things have been done using #ifdefs and that that's been changing as there
have been more (and more disparate) ports, which turn out to require a
variety of methods depending on the circumstances.

Perhaps the only complaint I can think of here is that sometimes the fear of
vtables seems (to me) to border on paranoia -- it doesn't hurt if the class
in question is completely off the critical path.  But I think that's a
pretty minor quibble.

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

Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs

[Peter Kasting]

On Sun, May 24, 2009 at 10:08 PM, Maciej Stachowiak  wrote:

> I don't think it should be discounted. It might be helpful to clarify why
> you think ifdefs are a bad solution.
>

Generally they make it more difficult to read the code (which is what I
spend 99% of the time doing) without really making it easier to find what's
in the build (which I only spend 1% of the time doing anyway).  The reason
for this latter is because there's a lot of files that look like they're
included but I actually don't care about, while if you go the "#include
foo_bar_gtk.cc" route to handle port-specific implementations, it can make
it harder for your IDE to determine that foo_bar_gtk.cc is an important file
(e.g. by doing "open foo_bar_gtk.cc" in its command line).  (This depends on
the IDE, of course.)

I would prefer to optimize for reading the code for my port, which generally
means as few #ifdefs as possible, and pushing as much logic into the build
system as possible (by including or not including various files).  It
implies things like preferring per-port subclasses to port-specific members
in the parent class, preferring to not include files rather than #ifdef
their contents away... basically, the opposite of all the decisions WebKit
looks to have taken :D

I don't think this is a big deal for most things, and I think the cases
where it is a big deal have been dealt with well when they've come up in the
past (from what I've seen as a third party -- usually Darin Fisher or
someone else on the team is running into them), so don't take this as a
disgruntled complaint against the current system.  It's just my preference.

Now, the thing I _would_ like to change is to switch from pathless #includes
to ones with relative paths -- but that's a totally different thread.

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

Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs

[Peter Kasting]

On Sun, May 24, 2009 at 12:19 AM, Maciej Stachowiak  wrote:

> On May 23, 2009, at 9:38 AM, David Kilzer wrote:
>
> There are essentially two options here:
>
> 1. Add #if/#endif guards to entire source files, but include every file in
> every build system.
>
> 2. Make each build system smart enough to exclude source files that
> implement a feature, thus pushing the policy decision down (up?) into the
> build system (which is where most of the decisions are made today anyway).
>
>
> I know there is a potential compile time tradeoff, but in some ways it
> would be nicer if all build systems built the same set of files, and we
> ifdef'd the contents. That would put the policy decisions all in one place
> (the port header).
>

It seems like build systems will already differ insofar as they include
various explicitly platform-specific files ("foo_bar_gtk.cc") so differing
more doesn't seem to hurt much.

My bias is always against #ifdefs so I feel more like David Kilzer does --
option #2 feels a lot cleaner to me.  On the other hand my experience is
much more with Chromium ports instead of WebKit ports so my opinion should
probably be discounted :)

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

Re: [webkit-dev] SharedWorkers alternate design

[Peter Kasting]

On Fri, May 22, 2009 at 12:30 PM, Darin Adler  wrote:

> Sadly we have not yet found a good verb for the common "get or create"
> idiom.


My own code uses "createObjectIfNeeded()" and similar variants.

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

Re: [webkit-dev] Review Queue

[Peter Kasting]

On Thu, May 21, 2009 at 10:08 PM, Maciej Stachowiak  wrote:

> If you want to r- a patch for a reason, such as being too big, or having
> feedback already that hasn't been addressed, that's fine. But I think it
> would be a bad idea to reject patches just because they haven't been
> reviewed for too long. And the other folks who have spoken up so far seem to
> agree.
>

I'm on the fence overall, but I can understand eseidel's position, so I'll
chime in so he's not all alone.

To use that same bug analogy, Mozilla actually _did_ that with their bug
database and found it extremely valuable.  Closing old bugs meant that the
1% that have serious, interested parties behind them that could still
reproduce spoke up, and those bugs stayed alive -- noticeably increasing the
quality of the bug pool.  While I don't think the same effect applies to
reviews two weeks old, it certainly does after, say, two months -- and in
the Chromium database I routinely ping people on old reviews that have
languished and eventually close them.

If the person submitting the patch is interested, and the message with the
r- is clear, getting an r- that says "if this still applies please re-ping"
is at the very worst an annoyance, not a disaster.

If the timeout was increased from two weeks to one month, and coupled with a
push that got the queue to zero patches and then implemented policies to
help it stay low in the future (which both Chromium and Mozilla lack, so you
don't feel too bad), I would be fully supportive.  As-is, I'm not sure it
helps as much, but I'm not ticked.

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

Re: [webkit-dev] Review Queue

[Peter Kasting]

On Thu, May 21, 2009 at 8:52 PM, Eric Seidel  wrote:

> Our current defacto policy requires involvement on both sides.
> Submitters need to be involved in finding people to review their
> patches.  Posting patches to the review queue does not automatically
> get you a review, except occasionally by Darin Adler or myself.


FWIW, I've always been told that WebKit etiquette is to not choose a
reviewer (even when you know who would be good) and just mark a patch r?.
 (This is a stark contrast to the Mozilla way of _always_ selecting a
reviewer.)

It would probably be good to clarify this kind of thing.

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

Re: [webkit-dev] ASYNC attribute for

[Peter Kasting]

On Tue, Apr 28, 2009 at 10:59 AM, Darin Adler  wrote:

> Bug 20710: WebKit should support defer and async on script elements
> https://bugs.webkit.org/show_bug.cgi?id=20710


Thanks for the link Darin, I had no idea that defer and async were already
in HTML5 :)

Steve, if you have any interest in writing a few tests for this kind of
functionality, that'd be awesome.  In the meantime, I will try and ping one
of the HTML5 folks here to note that this is an area we could prioritize
implementing.

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

[webkit-dev] ASYNC attribute for

[Peter Kasting]

Steve Souders, whom most of you have hopefully heard of due to his work with
YSlow etc., proposed something in one of the Chrome bug trackers that I
thought was more appropriate for WebKit in general, or perhaps HTML5 (Hixie:
CCed you so you can give feedback on where to send this).

I am pretty ignorant of all this stuff, so I'll just paste Steve's
slightly-edited proposal below for comment.

PK

***

It's great that WebKit has parallel script **downloading**. But... this
still blocks page rendering of all elements below the script and still
blocks all execution of subsequent JavaScript.

I'd like an ASYNC attribute to the SCRIPT tag that implied WebKit should go
ahead and render subsequent page elements and go ahead executing subsequent
JavaScript. This would make it easy for developers deploying standalone
features (carousel, widgets, etc.) to get better page behavior.

This is esp. important for ads. It's unlikely that we can make much progress
amongst ad services to adopt performance improvements that require even a
small amount of extra JS coding. It is more likely that we could make
inroads in getting them to add a simple "async" attribute.

The key to accomplish this is that the async-loaded scripts must be able to
preserve document.write. This opens up a lot of scenarios - I certainly
haven't thought them all through. But Opera has this capability, and in my
testing it works (see
http://www.stevesouders.com/blog/2008/09/11/delayed-script-execution-in-opera/
 ).
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] about WebKit Gif decoder

[Peter Kasting]

2009/3/28 haithem rahmani 

> Hi all,
>
> I noticed that webKit implements its own Gif decoder and doesn't use the
> extrenal library libgif.
>

Safari does not use the GIF decoder in the WebKit tree, but rather uses
CoreGraphics.

Other ports, such as Chromium and the Cairo port, do use the GIF decoder in
the tree.  I'm not sure we've ever compared against libgif.  I don't know
what its performance, compatibility and security characteristics are.

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

Re: [webkit-dev] about gif picture

[Peter Kasting]

On Mon, Feb 16, 2009 at 1:40 AM, zhenghe zhang wrote:

>when open a webpage, and there is a gif picture in the webpage, and
> the picture doesn't play. If I click the right mouse button, and the
> picture
> plays.


Have you updated to the very latest sources and rebuilt?  There were some
problems like this that were fixed a while back.

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

Re: [webkit-dev] Tamarin VM inside WebKit

[Peter Kasting]

On Mon, Jan 26, 2009 at 8:13 AM, haithem rahmani
wrote:

> Hi,
>
> Is there any plan to have the Tamarin (
> http://www.mozilla.org/projects/tamarin ) inside WebKit?
>

I doubt it.  What benefit would this give?  As far as I know, even Mozilla
does not plan to use Tamarin -- my recollection of their comments is that
the tracing and nanoJIT work they've pulled into TraceMonkey is the extent
of what they'll be taking from Tamarin going forward.

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

Re: [webkit-dev] Towards a Redistributable Windows WebKit

[Peter Kasting]

On Wed, Oct 22, 2008 at 10:39 PM, Brent Fulgham <[EMAIL PROTECTED]> wrote:

> I wanted to see if anyone had suggestions for a preferable way to address
> this problem, so that I can work on getting this last group of changes
> incorporated in WebKit proper for general use.


Have you looked at the work being done for the Chromium port?  It seems like
this port is currently similar to your goals: WebKit on Windows without
using Apple-specific libraries.  Obviously, it's not all in the tree yet,
but we're trying to get there.

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

Re: [webkit-dev] EOT Support in WebKit

[Peter Kasting]

On Fri, Oct 17, 2008 at 2:52 PM, David Hyatt <[EMAIL PROTECTED]> wrote:

> It's important to recognize that if you flip the EOT switch, you're going
> to end up using EOT over TTF in many cases.  In fact if IE *does* in end up
> skipping TTF files properly, the font you get in Chrome would actually
> depend on the specification order in the @font-face rule (you'd just end up
> randomly using EOT sometimes and TTF other times).  You'd be the only vendor
> subject to this issue by supporting both formats.
>

Unless we can convince Microsoft to support TTF.  Or other vendors end up
supporting EOT.  Or we write some crazy parser hack that prefers TTF over
EOT when both are available (ugh).

It's not clear to me whether "support EOT to make it easier to gain
marketshare in India and thus provide an alternative browser where authors
can deploy TTF" is a better long-term bet for the success of TTF than "try
to convince Microsoft to support TTF in IE".

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

Re: [webkit-dev] EOT Support in WebKit

[Peter Kasting]

On Fri, Oct 17, 2008 at 1:35 AM, David Hyatt <[EMAIL PROTECTED]> wrote:

> I believe this to be one of those rare cases.  Before making this
> decision, however, I would like to hear from representatives for the
> other WebKit ports.  In the absence of any strong vendor support, I do
> not believe we should add this code to the WebKit tree.


As noted on the bug, I believe the motivation for that patch is that a large
number of sites in India rely on EOT.

I'm not convinced that supporting EOT in the no-DRM way Hixie proposes is
harmful, although I wish it weren't needed.  Still, it's not harmful to
users (or technically impossible) in the same sort of way that, say,
supporting every ActiveX control would be.  Scanning the W3 thread very
briefly, it looks like all the DRM/licensing-related issues are people's
main complaints about EOT (that and "without them this doesn't buy you
anything over TTF", which is probably true, but IMO somewhat irrelevant).

I think you misstate yourself on the bug when you say Chrome is unwilling to
take the patch.  What you asked on IRC was whether one of us (i.e. the
Mountain View-based Chrome folks) was writing the patch.  We weren't, but
that doesn't mean we're opposed to taking it.  If it landed we would
probably be happy to have it, though I am not sure; it really came out of
the blue for us so I'm not sure we have a well-defined opinion.  In any
case, please do not say things like "neither Safari nor Chrome wants this".

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