Re: [webkit-dev] Spelling document markers: Design question

[Hajime Morrita]

On Tue, Mar 12, 2013 at 6:48 AM, Ryosuke Niwa  wrote:

> Thanks for the clarification.
>
> On Mon, Mar 11, 2013 at 9:35 AM, Rouslan Solomakhin <
> rouslan+web...@chromium.org> wrote:
>
>> On Sun, Mar 10, 2013 at 10:47 PM, Ryosuke Niwa  wrote:
>>
>>> On Thu, Mar 7, 2013 at 2:58 PM, Rouslan Solomakhin <
>>> rouslan+web...@chromium.org> wrote:
>>>
>>>> The contextual spellcheck in Chromium needs to identify the spellcheck
>>>> request that added spelling markers to the document.
>>>>
>>>
>>> What is contextual spellcheck?
>>>
>>
>> Contextual spellcheck in Chromium takes a sentence like "The duck says
>> quick" and marks the word "quick" as contextually misspelled. The
>> spellcheck would suggest "quack" instead of "quick". Although all words are
>> spelled correctly, the word "quick" makes less sense than "quack" in the
>> context of that sentence.
>>
>>
>>> This information will be used to provide a feedback loop to the
>>>> contextial spellcheck. I was thinking about adding an ID field to
>>>> DocumentMarkerDescription detail. Is this a correct approach?
>>>>
>>>
>>> I'm with morrita on this one but it's hard to answer this kind of a
>>> design question without understanding what you're trying to achieve.
>>>
>>
>> What we're trying to achieve is provide a feedback loop for the
>> spellcheck, so it can improve the suggestions over time. For the feedback
>> loop to work, we're going to assign unique identifiers to spellcheck
>> results and store the identifiers in markers. When the user performs any
>> operation on a spellcheck marker, the identifier from the marker will be
>> used in the feedback. User operations may include "Add to dictionary",
>> "Always ignore", "Select suggestion X", etc.
>>
>
> That sounds like a useful feature in general.
>
> On Mon, Mar 11, 2013 at 9:41 AM, Rouslan Solomakhin <
> rouslan+web...@chromium.org> wrote:
>
> On Sun, Mar 10, 2013 at 10:40 PM, Hajime Morrita 
>>  wrote:
>>
>>> There are DocumentMarker, or DocumentMakerDetails. Which do you have in
>>> your mind?
>>>
>>
>> I had DocumentMarkerDetails in mind. It seems to be the standard location
>> of auxiliary information for a document marker.
>>
>>
>>> Or you can possibly introduce another DocumentMakerDetails for the
>>> "contextual  marker". This approach might be cleaner. By introducing the
>>> new subclass, it won't interfere existing marker implementations. One
>>> caveat of this approach is that this needs extra heap allocations since
>>> DocumentMarkerDetails with unique IDs cannot be shared and will be
>>> allocated per marker.
>>>
>>
>> I like the approach with another DocumentMarkerDetails class. I would
>> like to have both description and identifier in my DocumentMarkerDetails.
>> Would it be OK to inherit from DocumentMarkerDescription?
>>
>
> I'd rather not add another subclass. That's even worse than
> modifying DocumentMarkerDetails IMO because this new subclass
> of DocumentMarkerDetails can't be shared among multiple markers.
>

> It seems okay for each DocumentMarker to directly have an identifier
> although we might want to if-def it depending on how big that identifier is.
>

On the other hand, if the ID is assigned per spellcheck request, not per
word, it can be shared in the requested sentence. So the overhead won't
that big. Also, API surface on DocumentMarkerController will be suffered by
the change, especially if we ifdef it. Considering that the contextual
spell checking (not grammatical checking) is virtually a chromium only
feature, it might be better to let the complexity cost small by just
extending DocumentMarkerDetails.

I'm fine with either way though. There isn't big difference here.


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

Re: [webkit-dev] Spelling document markers: Design question

[Hajime Morrita]

There are DocumentMarker, or DocumentMakerDetails. Which do you have in
your mind?

For me, it seems DocumentMarker is the right place to put such an ID since
DocumentMarkerDetails is an immutable, shared object and giving such ID
breaks the assumption for instance sharing.

Or you can possibly introduce another DocumentMakerDetails for the
"contextual  marker". This approach might be cleaner. By introducing the
new subclass, it won't interfere existing marker implementations. One
caveat of this approach is that this needs extra heap allocations since
DocumentMarkerDetails with unique IDs cannot be shared and will be
allocated per marker.

Sorry for my slow response. Hope this helps.



On Fri, Mar 8, 2013 at 7:58 AM, Rouslan Solomakhin <
rouslan+web...@chromium.org> wrote:

> Howdy folks,
>
> The contextual spellcheck in Chromium needs to identify the spellcheck
> request that added spelling markers to the document. This information will
> be used to provide a feedback loop to the contextial spellcheck. I was
> thinking about adding an ID field to DocumentMarkerDescription detail. Is
> this a correct approach?
>
> Thank you all for thoughts and suggestions!
>
> Cheers,
> Rouslan
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Perf Monitor (perf.webkit.org) has been launched

[Hajime Morrita]

On Mon, Feb 25, 2013 at 1:32 PM, Ryosuke Niwa  wrote:

> On Sun, Feb 24, 2013 at 7:56 PM, Hajime Morrita wrote:
>
>> Yay, it finally arrived!
>> I can see graphs only for html5-full-render test. Could we have links
>> for other test charts? Or aren't they ready yet?
>>
>
> You can look at each graph on Charts page.
>
Got it. Thanks!


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

Re: [webkit-dev] WebKit Perf Monitor (perf.webkit.org) has been launched

[Hajime Morrita]

Yay, it finally arrived!
I can see graphs only for html5-full-render test. Could we have links for
other test charts? Or aren't they ready yet?


On Mon, Feb 25, 2013 at 12:24 PM, Ryosuke Niwa  wrote:

> Hi all,
>
> We've replaced webkit-perf.appspot.com by perf.webkit.org.
> webkit-perf.appspot.com will be phased-out in the coming weeks.
>
> I'm going to check in the source code of perf.webkit.org into WebKit
> repository in coming months.
>
> - R. Niwa
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] AncestorChainWalker substance and style thoughts

[Hajime Morrita]

On Wed, Feb 20, 2013 at 4:29 AM, Dimitri Glazkov wrote:

> On Tue, Feb 19, 2013 at 3:50 AM, Antti Koivisto  wrote:
> > The problem with ComposedShadowTreeWalker is not that it is an iterator
> but
> > that it is ill-defined and complex. It calls back to non-trivial,
> mutating
> > functions on the structure being traversed
> > (ContentDistributor::distribute!). Simply traversing a tree with it can
> > apparently end up marking the tree for style recalc.
>
> This is a really good point. It encapsulates traversal of the composed
> tree, but this tree's integrity is maintained lazily, which means that
> as you traverse it, you could force the update. That ain't awesome.
>

We could possibly separate the recalculation of the composed tree from
style recalculation or attachment.

Even though the valid tree is computed lazily, the invalidation happens
eagerly, which triggers style recalculation. So we could let our style
recalc lifecycle to handle it and make distribute() to focus on calculating
distribution. This kind of clarification is apparently worth trying, an I
believe current design is close to that shape.

Filed http://wkb.ug/110280 for tracking.

--
morrita



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

Re: [webkit-dev] AncestorChainWalker substance and style thoughts

[Hajime Morrita]

AncestorChainWalker follows the style of ComposedShadowTreeWalker,
> which also breaks conventions like mutations-should-be-verbs. We also fix
> its style for integrity.
>
We *should*. It is yet to be done :-/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] AncestorChainWalker substance and style thoughts

[Hajime Morrita]

AncestorChainWalker follows the style of ComposedShadowTreeWalker,
which also breaks conventions like mutations-should-be-verbs. We also fix
its style for integrity.

Non-trivial tree traversal API in general should, IMO, be modeled after
recently introduced NodeTraversal.
Having separate namespaces allows us to keep Node API minimal. Also it is
stateless and simple.

I made NodeRenderingTraversal in that way.
AncestorChainWalker could be just merged to NodeRenderingTraversal.

Speaking of ComposedShadowTreeWalker, I think it is worth having a class
instead of namespace
since it holds configuration parameters to decide, for example, whether it
skips specific types of node.



On Tue, Feb 19, 2013 at 10:37 AM, Darin Adler  wrote:

> I am trying to learn about code related to shadow DOM that needs to be
> understood by anyone working on an part of the DOM.
>
> I have some questions and concerns about AncestorChainWalker. If there is
> a document I should be reading that covers these, please point me to it.
>
> The parentNode and parentElement functions are just plain old functions
> that are used to walk the ancestor chain of the normal DOM. But the shadow
> DOM AncestorChainWalker is a class. Why? It seems that it could just be a
> function with two return values. Is it more efficient to have it be a
> class? Can the operation be correctly done without storing
> m_distributedNode in a data member?
>
> There is a function in AncestorChainWalker named parent. That name is a
> noun, so the function should be a const function that returns a value.
> Since it’s not, the function name should be a verb phrase, such as
> advanceToParent, or event just “advance” since it’s in the context of an
> ancestor chain walker.
>
> The function crossingInsertionPoint should be named
> isCrossingInsertionPoint as the data member is. But also, since the walker
> sits still on a single node, I don’t think it makes sense to talk about the
> position as “is crossing”. It should be “just crossed” or something like
> that instead. Unless an insertion point is like a bridge and is not itself
> a “true node”.
>
> The function that returns the current node in the ancestor chain is named
> “get”. That’s not a good name, and should be avoided if possible. It could
> be named “node” or “currentNode” instead.
>
> -- Darin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Hajime Morrita]

Editing seems OK if we use GYP or CMake.
You can generate both Xcode and Ninja files against same source tree.
Debugging won't work though, at least for GYP-generated projects.
Its Ninja and Xcode builds have different directly structure.

If Xcode can attach gdb/llldb to an out-of-project executable for
debugging, it might work.
The dwarf debug metadata points the same source code after all.
But I have no idea whether it is possible.

--
morrita


On Tue, Feb 5, 2013 at 5:25 AM, Dirk Pranke  wrote:

> The short answer is, you can't.
>
> The fastest path is probably to get a working set of gyp files for the
> apple mac wk2. I'm going to start working on this just to see how far
> of we are (Adam's work from a year or two ago had JSC and WebCore
> building, but wasn't too functional beyond that; even so, it's
> probably a good starting point).
>
> -- Dirk
>
> On Sun, Feb 3, 2013 at 1:22 PM, Dean Jackson  wrote:
> > OK, this sounds fantastic. And I've noticed how much faster Chromium
> > incrementally builds using ninja when I've done that.
> >
> > So, ignoring the discussion of a single build system for a moment, how
> > can I, as a developer using the OS X + WK2 port, living mostly
> > in Xcode for editing and debugging, use ninja? I need the idiot's
> > guide :)
> >
> > (Note: I am an idiot, but not so much an idiot to realise that the
> > answer involves lots of work and probably updating some old GYP
> > files that you and Adam were testing with, etc etc. I'm just selfishly
> > thinking that cutting even 30s off each incremental rebuild would make
> > me so much happier that I'd be willing to put up with other
> > inconveniences.)
> >
> > Dean
> >
> > On 03/02/2013, at 4:54 PM, Eric Seidel  wrote:
> >
> >> +1
> >>
> >> Ninja is beyond-words amazing.  http://martine.github.com/ninja/  For
> >> better or worse, it is not designed to use human-editable build files,
> >> but rather to be used by a meta build system, like GYP or CMake.  So
> >> using ninja is really an orthogonal discussion to the "single build
> >> system" discussion for WebKit. :)
> >>
> >> Were the WebKit project to convert to using a single meta-build
> >> system, ninja would become an option many users might choose.  I'm
> >> told most Chromium hackers have GYP set to output ninja files these
> >> days, with the exception of some folks who still want the MSVC build
> >> environment. For WebKit ports already using CMake, they should
> >> definitely try ninja today!
> >>
> >>
> >> Anyway, my wish was not about arguing for a specific build solution.
> >> I'm instead noting that for the project to continue to move quickly,
> >> we need to stop needing to edit 8 build systems for every file
> >> move/addition.  Whether that's GYP or CMake or something else, I don't
> >> really care.  Adam and I tried GYP-for-WebKIt a while back.  But any
> >> of these solutions will require buy-in from Apple, as they will have
> >> to do the largest amount of work converting to use something other
> >> than XCode.
> >>
> >>
> >> On Sat, Feb 2, 2013 at 8:20 PM, Nico Weber  wrote:
> >>> On Sat, Feb 2, 2013 at 4:58 PM, Adam Barth  wrote:
>  Ninja has extremely fast incremental builds and can be generated by
>  GYP.  Here are some stats from a year ago:
> 
>  https://plus.google.com/101038813433650812235/posts/irc26fhRtPC
> 
>  Ninja has gotten even faster since then.  If you're interested in
>  trying it out, you can play around with incremental builds of the
>  Chromium port on Mac or Linux.
> >>>
> >>> You can also look at the build output from the chromium bots.
> >>>
> >>> Empty build in 1s:
> >>>
> http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/66807/steps/compile-webkit/logs/stdio
> >>> Build with a few files changed in 15s:
> >>>
> http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/66800/steps/compile-webkit/logs/stdio
> >>>
> >>> …and this is on fairly slow bots. On my SSD-equipped laptop, I can do
> >>> incremental rebuilds of all of chrome after touching one (cpp or mm)
> >>> file in 2-6s.
> >>>
> >
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Hajime Morrita]

On Fri, Feb 1, 2013 at 10:39 AM, Ryosuke Niwa  wrote:

> On Thu, Jan 31, 2013 at 5:20 PM, Hajime Morrita wrote:
>
>> The history aside, I think it makes sense to use the export macro
>> specifically for Mac WebCore because
>>
>> - As Eric mentioned, Currently only Mac and Win WebCore do WebCore/WebKit
>> separation.
>>   Other ports like GTK or Chromium build single "WebKit" library which
>> has both WebCore and WebKit API included.
>>   So we need to care about only Mac and Win for now.
>>
>> - Mac WebKit has relatively comprehensive feature set. It covers most of
>> possibly exported symbols.
>>
>> - The Windows toolchain allows us to use both export symbols list and
>> source-level annotation (the macro).
>>   Thus on Windows, we could use the Mac-centered export macro *and* an
>> export symbol list which covers Win-specific exports.
>>
>>   This means that there are unused exports on Win build, but I believe it
>> is very few considering that Mac/Win ports has
>>   similar feature set, which targets Safari on each platform. (This might
>> be wrong assumption though - On Mac, there are
>>   many other WebKit embedder other than Safari.)
>>
>> One exception is symbols exported for WebCoreTesting.
>> Fortunately, these symbols are exactly same across ports and we can use
>> another macro like
>> WEBCORE_TESTING_EXPORT for that.
>>
>
> Doesn't GTK+ port also require symbol exports for WebKit2? In particular,
> I thought all symbols used in Internals need to be exported there.
>

Ouch, I'm sorry for the unclear explanation.
This is what I meant say as "one exception" above. WebCoreTesting includes
Internals, which requires some exported symbols,
which could be (IMO) covered by WEBCORE_TESTING_EXPORT or some separate
macro.


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

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

[Hajime Morrita]

The history aside, I think it makes sense to use the export macro
specifically for Mac WebCore because

- As Eric mentioned, Currently only Mac and Win WebCore do WebCore/WebKit
separation.
  Other ports like GTK or Chromium build single "WebKit" library which has
both WebCore and WebKit API included.
  So we need to care about only Mac and Win for now.

- Mac WebKit has relatively comprehensive feature set. It covers most of
possibly exported symbols.

- The Windows toolchain allows us to use both export symbols list and
source-level annotation (the macro).
  Thus on Windows, we could use the Mac-centered export macro *and* an
export symbol list which covers Win-specific exports.

  This means that there are unused exports on Win build, but I believe it
is very few considering that Mac/Win ports has
  similar feature set, which targets Safari on each platform. (This might
be wrong assumption though - On Mac, there are
  many other WebKit embedder other than Safari.)

One exception is symbols exported for WebCoreTesting.
Fortunately, these symbols are exactly same across ports and we can use
another macro like
WEBCORE_TESTING_EXPORT for that.

--
morrita

On Fri, Feb 1, 2013 at 9:14 AM, Eric Seidel  wrote:

> I believe that it's a design mistake for WebCore to need to know
> anything about it's embedder, more than that there is a defined set of
> platform APIs and callbacks which it talks to (which should be the
> exact same for every embedder).
>
> (The export dependency dates back to the WebCore/WebKit separation,
> which in my recollection was done largely to be able to isolate LGPL
> code from the non-LGPL Mac WebKit layer.)
>
> But I believe it is a mistake that WebCore changes need to care about
> the possibility that different ports may export functions differently,
> or even worse, that different ports may need a different set of
> functions exported.
>
> I don't recommend using a more complicated export macro, but rather
> finding ways that WebCore doesn't need to care about diverging sets of
> exports.
>
> I believe most ports (with the exception of AppleWin/AppleMac) do not
> build WebCore as a separate dynamic library from WebKit, which makes
> exports a non-concern in the static case.
>
> In my perfect future world, WebCore would be split into many static
> libraries, and core-code -> WebKit exports would be a non-issue.  And
> of course, no embedder of core-code would ever expose core types, so
> no exports would ever need to be marked.
>
>
> On Thu, Jan 31, 2013 at 3:38 PM, Alexey Proskuryakov 
> wrote:
> >
> > 31.01.2013, в 15:15, Dirk Pranke  написал(а):
> >
> >>> I don't have concrete examples, and I don't know how big an effect on
> performance increasing the number of exports would have. It's something to
> keep an eye on, not a reason to avoid trying.
> >>
> >> I'm not parsing your reply properly -- avoid trying what? A common
> >> EXPORT macro that is set as appropriate by each port?
> >
> > Yes, you are parsing it correctly :)
> >
> > - WBR, Alexey Proskuryakov
> >
> >
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Hajime Morrita]

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

My personal feeling is that we could build a simple meta build system which
specifically targetsMac WebKit and XCode.

It could be just a little more than a templating system which generates the
list of files plus their UUIDs. The tool doesn't need to be so general like
CMake/GYP. Many tricky configuration things could be in the hard-coded
boilerplate. It could just focus on generating file list and UUIDs. It's
something like project.pbxproj.in and its preprocessor.

It won't be a direct step toward the unified build system. But we'll figure
out the next step once the build is represented by a simple plain text.

--
morrita


On Thu, Jan 31, 2013 at 5:49 PM, Patrick Gansterer wrote:

> Hi,
>
> Am 31.01.2013 um 09:25 schrieb Mark Rowe:
> >> CMake was originally considered a non-starter for chromium since the
> >> XCode and VS projects it produced didn't look or feel like native
> >> projects. However, we've since switched to ninja for most things so
> >> I'm less sure how important this is now. I've never been a huge fan of
> >> the CMake syntax but I haven't used it enough to really have an
> >> informed opinion.
> >
> > Generating well-structured Xcode projects is still something that is
> important for any meta build system that we would consider adopting for the
> Mac. It would be substantially more challenging for us to support an
> alternative system for building our production builds. If there are
> substantial advantages to using ninja for engineering builds then we may
> wish to support both to get the best behavior in each environment.
> >
> > The non-natively structured Xcode projects is one thing that turned me
> off CMake when I looked at it in the past. I’m not sure if this has
> improved since then. If not, then I don’t think CMake is worth spending
> much time on.
>
> If you want to commit the generated projects CMake isn't an option anyway,
> since it uses absolute paths and also requires a cmake binary on the
> machine used for compiling (to support all CMake features across all
> generators). This tight integration is usually a big win, since the
> CMakeLists.txt files are part of the build system they can be changed
> directly in the IDE and update the project without invoking external tools.
>
> Only for my personal interest: What do you mean exactly with non-natively
> structured Xcode projects? CMake aims to support a native IDE feel as far
> as possible. Would be great if you explain that to me (off-list) to get
> CMake improved for XCode?
>
> >> Regarding "(b) The generated project invokes only tools that are part
> >> of the default Mac OS X install": invoking tools that are checked into
> >> the WK repo is also possible, right, since we invoke scripts now? So,
> >> hypothetically, could we check in a copy of the ninja binary and build
> >> with that?
> >
> > Checking in binaries isn’t an option for us, and isn’t a particularly
> scalable approach anyway given the number of platforms that WebKit can
> build on. If we require an external tool as a dependency to build WebKit
> from source then we’d need to check in the source for the tool and build it
> prior to building WebKit proper. This obviously introduces more complexity
> so it would be preferable to keep the dependencies to a minimum.
>
> Maybe you can check in the ninja source and compile it during build. It
> only requires python (and hopefully installed build tools) to get built.
>
> -- Patrick
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Hajime Morrita]

On Thu, Jan 31, 2013 at 5:49 PM, Patrick Gansterer wrote:

> Hi,
>
> Am 31.01.2013 um 09:25 schrieb Mark Rowe:
> >> CMake was originally considered a non-starter for chromium since the
> >> XCode and VS projects it produced didn't look or feel like native
> >> projects. However, we've since switched to ninja for most things so
> >> I'm less sure how important this is now. I've never been a huge fan of
> >> the CMake syntax but I haven't used it enough to really have an
> >> informed opinion.
> >
> > Generating well-structured Xcode projects is still something that is
> important for any meta build system that we would consider adopting for the
> Mac. It would be substantially more challenging for us to support an
> alternative system for building our production builds. If there are
> substantial advantages to using ninja for engineering builds then we may
> wish to support both to get the best behavior in each environment.
> >
> > The non-natively structured Xcode projects is one thing that turned me
> off CMake when I looked at it in the past. I’m not sure if this has
> improved since then. If not, then I don’t think CMake is worth spending
> much time on.
>
> If you want to commit the generated projects CMake isn't an option anyway,
> since it uses absolute paths and also requires a cmake binary on the
> machine used for compiling (to support all CMake features across all
> generators). This tight integration is usually a big win, since the
> CMakeLists.txt files are part of the build system they can be changed
> directly in the IDE and update the project without invoking external tools.
>
> Only for my personal interest: What do you mean exactly with non-natively
> structured Xcode projects? CMake aims to support a native IDE feel as far
> as possible. Would be great if you explain that to me (off-list) to get
> CMake improved for XCode?
>
> >> Regarding "(b) The generated project invokes only tools that are part
> >> of the default Mac OS X install": invoking tools that are checked into
> >> the WK repo is also possible, right, since we invoke scripts now? So,
> >> hypothetically, could we check in a copy of the ninja binary and build
> >> with that?
> >
>
> Checking in binaries isn’t an option for us, and isn’t a particularly
> scalable approach anyway given the number of platforms that WebKit can
> build on. If we require an external tool as a dependency to build WebKit
> from source then we’d need to check in the source for the tool and build it
> prior to building WebKit proper. This obviously introduces more complexity
> so it would be preferable to keep the dependencies to a minimum.
>
> Maybe you can check in the ninja source and compile it during build. It
> only requires python (and hopefully installed build tools) to get built.


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

My personal feeling is that we could build a simple meta build system which
specifically targetsMac WebKit and XCode.

It could be just a little more than a templating system which generates the
list of files plus their UUIDs. The tool doesn't need to be so general like
CMake/GYP. Many tricky configuration things could be in the hard-coded
boilerplate. It could just focus on generating file list and UUIDs. It's
something like project.pbxproj.in and its preprocessor.

It won't be a direct step toward the unified build system. But we'll figure
out the next step once the build is represented by a simple plain text.

--
morrita


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

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

[Hajime Morrita]

(From the right address)

I did it for WTF and JSC with kevino@.
https://bugs.webkit.org/show_bug.cgi?id=72855
I hope I had had time to extend the work to WebCore, which was my original
goal :-/

I did it through an automation but the tool was so slow and hacky that it
was not capable for large WebCore codebase.

Seeing that the number of exported symbol is about 2700, manual work with
regular expression will also work
if it is OK to do the work incrementally... and if you are patient enough
:-)

--
morrita



On Thu, Jan 31, 2013 at 4:39 PM, Ryosuke Niwa wrote:

> On Wed, Jan 30, 2013 at 11:33 PM, Jochen Eisinger wrote:
>
>> On Thu, Jan 31, 2013 at 1:15 AM, Maciej Stachowiak  wrote:
>>
>>> On Jan 30, 2013, at 3:24 PM, Dirk Pranke  wrote:
>>>
>>> > On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo  wrote:
>>> >> Thanks for sharing this.
>>> >>
>>> >> On Jan 30, 2013, at 1:28 PM, Eric Seidel  wrote:
>>> >>
>>> >> I wish we only had one build system (it were easy to add/remove/move
>>> files).
>>> >>
>>> >> I believe changes like http://trac.webkit.org/changeset/74849 are an
>>> >> unhealthy sign for the project.  Adam is not the only person who has
>>> chosen
>>> >> to empty files instead of removing them.  The pain of updating 8 build
>>> >> system is so great, we jump through hoops to avoid it.  Which means
>>> it took
>>> >> us months to move JavaScriptCore/wtf to WTF, and will take us years
>>> to kill
>>> >> WebCore/platform.
>>> >>
>>> >>
>>> >> +1
>>> >>
>>> >> This is a hard problem.  It is a problem worth solving.
>>> >>
>>> >> Do you have more thoughts on this, particularly since you know quite
>>> well
>>> >> how both Xcode and gyp work?
>>> >>
>>> >> I suspect this is one of those things that it would be hard to achieve
>>> >> consensus on since there are so many stakeholders.  But it may be
>>> fruitful
>>> >> to have a "what if" discussion about what this might look like.
>>> >>
>>> >
>>> > I think we can solve this problem if we agree that we want to. I think
>>> > we haven't in the past mostly because we couldn't reach a consensus
>>> > that it was worth solving enough to really try.
>>> >
>>> > I would love to see this fixed and would be glad to work on it. I
>>> > think we should at least pursue this far enough to fully understand
>>> > what our options are and what the costs and tradeoffs might be; does
>>> > anyone disagree, and is anyone else willing to help pitch in?
>>> >
>>> > I think there are several possible ways we could solve this. One would
>>> > be to switch to a common meta-build system. My understanding is that
>>> > Apple's internal production build processes impose certain constraints
>>> > here that I don't fully understand, but I know we've discussed the
>>> > possibility of checking in generated project files as a workaround.
>>> > Maybe there are other options as well to those constraints? I would
>>> > love to discuss this further w/ someone from Apple ...
>>>
>>> It's far simplest for us if:
>>> (a) There is an Xcode project (or a Makefile) that builds the Mac port
>>> checked in to source control.
>>> (b) The generated project invokes only tools that are part of the
>>> default Mac OS X install.
>>>
>>
>> Another desirable property would be to move to a more automatic way of
>> handling exported symbols: Currently each port that depends on this feature
>> has its own .exp file or similar. I think if we could move to something
>> that would allow for changing WebCore API without having to touch all those
>> files, e.g. by consistently using WEBCORE_EXPORT macros would be a big win
>>
>
> morrita already did this for WTF, and it works great for us. What's
> blocking us from doing the same for WebCore?
>
> - R. Niwa
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Feature announcement: Custom Elements

[Hajime Morrita]

Hi Maciej, Thanks for your attention!

> For reference: will the feature flag be comprehensive, or will parts of
the implementation/scaffolding be outside the ifdef?

It should be comprehensive. So it will.

Although some trivial inline stubs, like just returning null or false, or
even doing nothing, will be outside the flag
for minimizing if/def disturbance, they'll be optimized out by compilers.

Also, some kind of refactoring might precede to make new features fit in
the code. Such refactoring will be aimed to achieve clear separation of new
additions by, for example, introducing better encapsulation. (Please note
that this is just a general direction of the change. I have no concrete
refactoring plan in my mind at this time.)

As an example, here is the first bit of the change:
https://bugs.webkit.org/attachment.cgi?id=185411&action=review

I expect most of the code from this feature to grow under these
CustomElementSomething and accompany classes.

Hope this answers your question.
--
morrita


On Wed, Jan 30, 2013 at 4:52 PM, Maciej Stachowiak  wrote:

>
> On Jan 29, 2013, at 6:22 PM, Hajime Morrita  wrote:
>
> Hi folks,
>
> I'm going to implement "Custom Elements" standard behind
> ENABLE(CUSTOM_ELEMENTS) flag.
> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html
>
>
> For reference: will the feature flag be comprehensive, or will parts of
> the implementation/scaffolding be outside the ifdef?
>
>  - Maciej
>
>
> Here is the tracking bug for the feature:
> https://bugs.webkit.org/show_bug.cgi?id=99688
>
> Note that Mozilla is also working on implementing this.
> https://bugzilla.mozilla.org/show_bug.cgi?id=783129
>
> Let me know if you have any questions or comments.
>
> Bests,
> --
> morrita
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Feature announcement: Custom Elements

[Hajime Morrita]

Hi folks,

I'm going to implement "Custom Elements" standard behind
ENABLE(CUSTOM_ELEMENTS) flag.
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html

Here is the tracking bug for the feature:
https://bugs.webkit.org/show_bug.cgi?id=99688

Note that Mozilla is also working on implementing this.
https://bugzilla.mozilla.org/show_bug.cgi?id=783129

Let me know if you have any questions or comments.

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

Re: [webkit-dev] Implementing Complex webform Widgets using ShadowDom

[Hajime Morrita]

Hi Hema,

If you are talking about WebKit and HTML, it already does it for some of
its built-in HTML elements.

Some UI controls, which are modal and don't fit into the page layout, are
implemented using native UI controls. These modal controls shouldn't
constrained by WebKit rendering area like iframes. In such case, OS native
controls are suited. File chooser is a perfect example of this.

Some other controls like progress bars and spin buttons are implemented
using Shadow DOM. They aren't modal and need to be parts of the page layout.

The decision which of native-controls/shadow-dom should be used for
implementing HTML form controls is case by case and
in't that simple. You can see how  element is implemented. When you
try to implement any new control for HTML, it would be good to file a bug
and have further discussion there. See
http://www.webkit.org/coding/adding-features.html

If you are talking about Web-app or JS library development, webkit-dev
isn't a place for that. Sites like stackoverflow.com will work well. There
are also some good tutorials. For example:
http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom/

Hope this helps.

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

Re: [webkit-dev] Prefix naming scheme for DOM-exposed functions

[Hajime Morrita]

(sending from correct address)
Come late here. I basically support Darin's point.

Here is some addition:

As Maciej said, we don't need to do this for all API. We can do this by
opt-in basis, as an optimization.
Since we have [implementedAs] IDL attribute already, we can even start this
today once consensus on prefix naming is made (I'd vote for "binding"
prefix.)

On taking error check apart, another possible idea is to get more help from
our code generators.
For example, we could add "Check" C++ function which returns an
ExceptionCode, then we could let generated code call it appropriately.


// IDL will look like this:
[IfCheckFail=ReturnNull] readonly attribute Node firstChild;

// generated code will look like this.
ExceptionCode ec = impl->firstChildCheck();
if (ec)
   return jsNull();
return toJS(impl->firstCihld());

// implementation could be
Node* ContainerNode::firstChild() const {
  ASSERT(!firstChildCheck());
  return m_firstChild;
}


I expect that there are only a few major patterns for handling and
reporting errors.
So we can also tell such patterns to the generator.


// Another IDL example:
[ExceptionIfNull=InvalidStateErorr] readonly attribute Node startContainer
getter raises(DOMException);

// generated code will be something like...
RefPtr return = impl->startContainer();
if (!return) {
  throwException();
  return jsNull();
}

return toJS(return);


This "IDL annotations plus optional C++ helpers" approach isn't as clean
(or simple) as uniform prefixing.
But it could result less hand-written C++ code and achieve same performance
benefit as original proposal.
Its opt-in nature will also help us try these ideas incrementally.

On the other hand, this could possibly result more complex, hard to
understand code backed by half-baked magic, if we do this badly.
I don't think this becomes that complex though.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Github vs. git.webkit.org

[Hajime Morrita]

It looks github supports mirroring by pulling a repo from official location.
http://stackoverflow.com/questions/11370239/creating-an-official-github-mirror

So we might be able to rename the existing one and ask github to pull our
git.webkit.org repository into github/WebKit/webkit.
Apparently Apache takes that way: https://github.com/apache
The "mirroring" icon indicates kind of official-ness.

I don't know how long their mirroring delay is, though.



On Sat, Dec 1, 2012 at 12:07 AM, Tor Arne Vestbø
wrote:

> On 11/28/12 16:55 , Adam Barth wrote:
>
>> My sense is that the WebKit community would prefer that the hashes in
>> GitHub match the hashes in git.webkit.org so that folks can more
>> easily move branches between the two.  For my part, I've switched over
>> to using GitHub exclusive of git.webkit.org, so the the difference in
>> hashes aren't an issue for me, but I can understand why they'd be
>> problematic for other people.
>>
>
> Yepp, agreed. Let's switch it over.
>
>
>  After the force-push, would you still be able to push updates
>> automatically?  If so, you can switch the hashes whenever is
>> convenient for you.  (It might be nice to announce the date/time on
>> this list so that folks aren't taken by surprise.)
>>
>
> The mirror is also pushed to 
> http://gitorious.org/webkit/**webkit,
> which I was planning to keep as is for now, so that would mean setting up
> an extra mirroring for the non-author-rewritten history :/ Also, the server
> I run this on has a somewhat uncertain future. With that in mind it's
> probably easier to just push directly from the same import that's pushed to
> git.webkit.org, and make the GitHub mirror an official mirror?
>
> tor arne
>
> __**_
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/**mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Is UseV8.cmake still used?

[Hajime Morrita]

IIRC, Android (non-Chrome) uses V8. I'm not sure whether PLATFORM(CHROMIUM)
is on there.


On Sun, Nov 11, 2012 at 3:59 PM, Kentaro Hara  wrote:

> EFL and other ports used to have an option to build with V8, but it
> looks like the option is no longer supported. For example, UseV8.cmake
> is already out of sync with existing V8 binding files.
>
> - Would it be OK to remove UseV8.cmake?
>
> - Would it be OK to remove #if PLATFORM(CHROMIUM) from all V8 binding
> files?
>
> If anyone has a plan to support the option in the near future, I'll
> keep them as is.
>
> --
> Kentaro Hara, Tokyo, Japan
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] List of IRC nicknames & pictures?

[Hajime Morrita]

(From right address...)


On Sun, Nov 4, 2012 at 8:14 PM, Ryosuke Niwa  wrote:

> On Sun, Nov 4, 2012 at 2:45 AM, Peter Beverloo  wrote:
>
>> IRC nicknames are available in committers.py, as the third argument of
>> the Contributor, Committer and Reviewer entries:
>>
>> http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/config/committers.py
>>
>
> I am certainly aware of that. You can even ask sheriffbot with "whois"
> command.
>
> I'm not aware of any picture database.  I guess we could include them on
>> the WebKit Team wiki page,
>>
>
> I don't think having people upload images to wiki is a scalable solution.
>
> How about ohloh? https://www.ohloh.net/p/WebKit/contributors shows
> gravatar.com pictures associated with commits.
>

Propbably we could have an optional link to gravatar icon and some other
informal data in committers.py then we can auto-generate pretty-looking
alternative to http://trac.webkit.org/wiki/WebKit%20Team.
Sounds like a good weekend project :-)


> but I'm not convinced the benefit would be worth the effort of adding that
>> much images.  If you use Gmail as your e-mail client, it'll somehow figure
>> out these images anyway.
>>
>
> I guess people don't mind even if I can't remember who they are?  And no,
> Gmail isn't a solution for this either because very few people ever post
> things on webkit-dev, and many contributors don't use Gmail.
>
> - R. Niwa
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] On returning mutable pointers from const methods

[Hajime Morrita]

We could have both const and non-const versions. For document(), we will
certainly need both.

I think these APIs can become less useful because the strict const-ness is
yet to be deployed widely. We can apply the rule for fresh classes line new
Web APIs since these rule worry little about older, less-const code. We'll
need certain level of compromise for existing code. This means we cannot
automate these check but it looks a reasonable starting point.

--
morrita


On Fri, Oct 26, 2012 at 12:53 PM, Elliott Sprehn wrote:

> This requires weird contortions in the DOM and Render tree and removes
> nice guarantees.
>
> For example Node.h has:
>
> TreeScope* treeScope() const;
> Document* document() const;
> Node* childNode(unsigned index) const;
>
> Returning a const Document* or Node* from childNode makes the DOM
> API's suddenly less useful, and marking them as non-const is
> confusing. These methods shouldn't be making mutations and the
> compiler should enforce that (or at least try to), and the const is also
> good
> documentation.
>
> On Thu, Oct 25, 2012 at 1:02 PM, Peter Kasting 
> wrote:
> > On Thu, Oct 25, 2012 at 3:48 AM, Andreas Kling  wrote:
> >>
> >> So, I propose that we allow only these two signature formats for raw
> >> pointers:
> >>
> >> - const Foo* foo() const;
> >> - Foo* foo();
> >
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Pre-proposal: Adding a Coverity instance for WebKIt

[Hajime Morrita]

On Tue, Sep 18, 2012 at 8:46 AM, Eric Seidel  wrote:

> On Mon, Sep 17, 2012 at 6:35 PM, Benjamin Poulain 
> wrote:
> > On Mon, Sep 17, 2012 at 4:11 PM, James Hawkins 
> > wrote:
> >>
> >> A few details:
> >> * Google will front the cost of the license (non-zero...very far from
> >> zero) and the infrastructure.
> >> * I'd leave it up to the WebKit leadership to decide who has access
> (most
> >> likely limited to WebKit committers for security purposes).
> >>
> >> The biggest rationale is to provide a strong defect signal for the
> entire
> >> WebKit community, which would directly impact the success of all
> >> WebKit-based projects.  Coverity has provided free licenses for
> unsponsored
> >> (by larger corporations anyway) open-source projects; this has resulted
> in
> >> significant improvements [2] to the code bases of these projects, one of
> >> which I was directly involved with years ago (Wine).
> >
> >
> > I am a little skeptical of Coverity because of bad patches that
> originated
> > for its report (sometimes even discussed on webkit-dev). I think we
> should
> > keep in mind the tool also make many mistakes and we should not blindly
> > follows it.
> >
> > Could this be integrated with the EWS like a kind of advanced "style
> check"?
>
> I think this is a great idea, and would be trivial if coverity could
> be convinced to run on a diff file, or if we could wrap it in a script
> to only report errors on the changed lines.  Either sounds very
>

And/Or are we going to allow inline annotations?
The practice Coverity suggested is to adding such annotations.
http://scan.coverity.com/best-practice.html

I personally think it's worth having inline annotations because it can also
help human code readers, so I'm curious what other folks think about that.


> doable.  The EWS infrastructure is already in place once such a script
> exists.


> > Reporting possible improvements before patches lands would be more useful
> > than a separate bot.
> >
> > Benjamin
> >
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo/webkit-dev
> >
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Multiple inheritance in the DOM

[Hajime Morrita]

If the only problem is to determine the type of JS wrappers, is it possible
to
make wrapSlow() a virtual method of some base class, instead of static
functions?

It need a tweak on the code generator. Also, it might need to avoid name
conflicts
by suffixing like wrapSlowForNode(), wrapSlowForRegion() etc.

This approach would make wrapSlow() a variation of QueryInterface(). But
considering that the functionality is limited and hard to abuse, it might
be better than having DOMInterface.



On Thu, Jul 26, 2012 at 9:53 AM, Alan Stearns  wrote:

> On 7/25/12 5:37 PM, "Sam Weinig"  wrote:
>
> >
> >On Jul 25, 2012, at 5:13 PM, Alan Stearns  wrote:
> >
> >> On 7/25/12 4:49 PM, "Kentaro Hara"  wrote:
> >>
> >>> A) Should we push back on the folks writing the CSS Regions
> >>> specification to avoid using multiple inheritance?  As far as I
> >> know,
> >>> this is the only instance of multiple inheritance in the platform.
> >>> Historically, EventTarget used multiple inheritance, but that's
> >>>been
> >>> fixed in DOM4 [4].
> >>>
> >>> If it is possible to avoid the multiple inheritance, that would be
> >>>best.
> >>
> >> From the WebIDL side, it's not strictly multiple inheritance. It's
> >>merely
> >> a supplemental interface that more than one object can implement. None
> >>of
> >> the members of the Region interface can clash with any of the members of
> >> the object that implements it.
> >>
> >> Right now Elements can become CSS Regions, but in the future other
> >>objects
> >> will be able to become CSS Regions. As far as I know, the correct way to
> >> specify this kind of relation is with WebIDL supplemental interfaces.
> >>I'd
> >> rather figure out the correct way to add this WebIDL functionality to
> >> WebKit now, than put something else into the spec and WebKit that we'll
> >> have to change later.
> >>
> >> Thanks,
> >>
> >> Alan
> >
> >What other objects do you envision implementing CSSRegion?  With the spec
> >written the way it is now, I see no reason to make anything virtual, or
> >even have a Region class.  Just implement it in Element.  If need to pull
> >things out for code reuse purposes, we can do that when it comes to that,
> >but right now, there doesn't seem to be a need to complicate things.
> >
> >-Sam
> >
>
> I have an upcoming proposal for a CSSPseudoElement object. You can make a
> pseudo-element like ::before or ::after into a CSS Region right now in
> WebKit. All that's lacking is a way to access those pseudo-elements from
> script.
>
> Thanks,
>
> Alan
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Using commit-queue doesn't mean you can use build failures

[Hajime Morrita]

(from the right address...)
Hi,

I don't think it is a reasonable expectation especially for non-chromium
developers.

It is possible for a change to break chromium-linux, chromium-win or
chromium-mac,
that means developers needs to have Linux, Mac and Windows machines to
ensure
the successful build since there is no EWS for these configurations.

More reasonable baseline would be getting all EWS builds green
and/or watching the tree until landed patch goes green. And in my
understanding, these are in fact our current norm.

Regards,
--
morrita


On Thu, Jul 19, 2012 at 3:59 PM, Ryosuke Niwa  wrote:

> Hi all,
>
> Using commit-queue doesn't pardon a committer from causing build failures.
>
> Notice that the commit queue only builds & runs tests on Chromium Linux
> port. Thus, any build failure that doesn't manifest itself on Chromium
> Linux port — namely any JSC-specific or Windows/Mac specific build
> failures — won't be caught.
>
> The current policy specifically says the committer is responsible for
> making sure his or her patch builds & passes tests:
> http://www.webkit.org/coding/contributing.html
>
> So please make sure your patch at least builds if you're landing a patch
> via commit queue.
>
> Best,
> Ryosuke Niwa
> Software Engineer
> Google Inc.
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] C++ unit tests for WebKit?

[Hajime Morrita]

(Resending from the right address)

FYI, Chromium port has some unit-like tests:
http://trac.webkit.org/browser/trunk/Source/WebKit/chromium/tests

Apparently it is not community's responsibility to maintain these. But it
might be useful for developing some low-level standalone/low-level stuff
like collections and utilities if you are developing on Chromium port.

My feeling is that the lack of unit test is mixture of philosophical
decisions and technical limitations.
As Adam mentioned, Layout Tests for Web Platform features fit former, and
untested low level stuff fits later.

If we have some low-level/primitive component for building larger web
platform features, such primitives are worth unit-testing IMHO.
And TestWebKitAPI (or cr-port test in some case) is good place for them.


On Thu, Jul 12, 2012 at 8:48 AM, Adam Barth  wrote:

> On Wed, Jul 11, 2012 at 4:31 PM, Hans Muller  wrote:
>
>> Thanks for the thoughtful reply.   It was exactly the "community's
>> conventions and customs" that I was trying to get a handle on.   Not to put
>> too fine a point on it, but I assume that adding unit tests to
>> TestWebKitAPI or writing tests that depend on APIs defined in Internals.idl
>> wouldn't be customary or conventional?
>>
>
> As the name implies, TestWebKitAPI is mostly about testing the WebKit API
> (meaning the API that WebKit exposes to folks who use it as a library).
>  Your feature doesn't seem to involve any WebKit API, so I would steer
> clear of TestWebKitAPI.
>
> We're still feeling out when it's appropriate to test something via
> Internals.  One good use of Internals is to set a WebCore::Setting directly
> rather than having to create API for N different ports.  There's a risk
> that Internals will become a dumping group for random things, and this is
> something we try to look out for when reviewing changes to Internals.idl.
>
>
>> I'd been thinking about doing the latter (Internals.idl), just because it
>> would enable testing some low level classes before everything we're working
>> on had been integrated top to bottom.  Doing so could just be a private
>> temporary change, since eventually it will be possible to exercise the code
>> via public APIs.
>>
>
> Obviously, you should feel free to do whatever is convenient in your own
> private branch.  For development on trunk, I would encourage you to try to
> get a basic version of your feature working end-to-end (so that it's
> testable via the web platform) and then to elaborate it incrementally.
>  That's not always possible, but it tends to be a good approach for
> generating test coverage.
>
> I'm happy to discuss this topic further in #webkit if that would be
> helpful to you.
>
> Adam
>
>
>
>> From: Adam Barth 
>> To: Hans Muller 
>> Cc: Benjamin Poulain , Konrad Piascik <
>> kpias...@rim.com>, webkit-dev 
>> Subject: Re: [webkit-dev] C++ unit tests for WebKit?
>>
>> Generally speaking, WebKit's testing philosophy is to test at API
>> boundaries, typically either a given port's WebKit API or the web platform
>> API.  The benefit of that approach is that it makes it easier for us to
>> refactor the internals of WebCore without being constrained by fragile
>> tests---only by API commitments.
>>
>> In the case of CSS Exclusions, it's likely valuable to think about how
>> you can test the feature via the web platform.  Developing a rich set of
>> tests that use web platform APIs has a number of follow-on benefits that
>> WebCore-internal testing doesn't, such as the ability to run the tests in
>> other browsers and to contribute them to the W3C as part of the standards
>> process.
>>
>> Of course, this sort of one-size-fits-all testing strategy works well in
>> come cases in less well in others.  I understand that other projects have
>> different testing strategies that have worked well for them, but I would
>> encourage you to try our the community's conventions and customs for a
>> while to get a feel for which ones work well and which ones ought to be
>> improved.
>>
>> Adam
>>
>>
>> On Wed, Jul 11, 2012 at 3:44 PM, Hans Muller  wrote:
>>
>>> It looks like Tools/TestWebKitAPI/Tests/WebCore just contains one small
>>> KURL test. I could certainly add more for the Exclusions shape classes,
>>> but I got that feeling that maybe you get about being the first to take a
>>> table at an empty restaurant.  Perhaps it's just that most of the C++
>>> classes in WebCore are too interdependent to merit unit testing?
>>>
>>> - Hans
>>>
>>>
>>> On 7/11/12 2:26 PM, "Benjamin Poulain"  wrote:
>>>
>>> >On Wed, Jul 11, 2012 at 2:23 PM, Hans Muller  wrote:
>>> >> Have the merits of C++ unit tests been debated before?  I noticed that
>>> >>a bug
>>> >> representing as much has been around since 2008
>>> >> (https://bugs.webkit.org/show_bug.cgi?id=21010).  The last comment
>>> >>(2009)
>>> >> concludes with: "I'd be interested to hear other's thoughts."
>>> >>Personally,
>>> >> I'd like to be able to include unit tests with worthy C++ classes,
>>> >>howev

Re: [webkit-dev] Can protocol handler be moved to the modules ?

[Hajime Morrita]

This change looks reasonable for me.

I hope the client interface to be extracted from ChromeClient to its own.
ChromeClient is like a zoo of ifdefs, which modularization effort has
aimed to improve.
(I don't think we need to split the implementations of ChromeClient:
they can implement both interfaces)

On Tue, Jul 10, 2012 at 2:26 PM, Gyuyoung Kim  wrote:
> Hello folks,
>
> I wonder whether protocol handler is able to be moved to the modules. I was 
> told that protocol handler belonges  Techniques for Loose Coupling>
>
> == Current Non-Modules Using Module-Related Techniques for Loose Coupling ==
> devicemotion
> deviceoritentation
> fileapi
> html
> notifications
> protocolhandler
> speechinput
> svg
> webgl
> websql
> workers
> xml
>
> 
>
> However, it seems to me protocol handler is now self-contained except for an 
> interface which supports port implementation. In intents case, it also has 
> similar interface in FrameLoaderClient.h.
>
> Is there any reason that protocol handler can't be moved to the modules ?
>
> I filed a bug for this and submitted a patch.
> https://bugs.webkit.org/show_bug.cgi?id=90766
>
> Cheers,
> Gyuyoung.
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Reg.use of WTF_CHANGES in FastMalloc.cpp...

[Hajime Morrita]

Hi,

The code was brought from a third party library and WebKit (WTF) needs
some changes to the original code. It looks such changes are marked by
WTF_CHANGES. For example, WTF shouldn't depend on gflags, which is
disabled by the WTF_CHANGES guard.

--
morrita

On Thu, Apr 12, 2012 at 6:01 PM, Arunprasad Rajkumar
 wrote:
> I don't understand the use of define  WTF_CHANGES in FastMalloc.cpp &
> TCSystemAlloc.cpp.
>
> Any body help me to understand that?
>
> Thanks in advance.
>
> --
> Arunprasad Rajkumar
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Documentation for WTF/JSC exports?

[Hajime Morrita]

On Thu, Mar 22, 2012 at 10:38 AM, Eric Seidel  wrote:
> Thank you.  Mark Rowe was kind enough to resolve
> https://bugs.webkit.org/show_bug.cgi?id=81838#c8 in
> http://trac.webkit.org/changeset/111634.
>
> I've found that some of the "Weak External Symbol" errors from
> http://pastebin.com/dVjV8UiR can be resolved by marking the functions
> in question as "inline", but that doesn't seem like the right fix.
>
> Some others like:
> ERROR: symbol double WTF::strtod<(WTF::AllowTrailingJunkTag)0,
> (WTF::AllowTrailingSpacesTag)0>(char const*, char**)

You may need
GCC_SYMBOLS_PRIVATE_EXTERN = YES;
on WTF.xcconfig. JavaScriptCore.xcconfig has it.

>
> Are for functions which are not even in headers:
> http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/dtoa.cpp#L651
>
> So it's unclear what's causing those.
>
> Thank you for your attempts at documentation. Perhaps that will make
> clear how these exports are supposed to work. :)
>
> -eric
>
> On Wed, Mar 21, 2012 at 6:21 PM, Hajime Morrita  wrote:
>> I'll write a draft so that ports' expert can fill missing pieces.
>> --
>> morrita
>>
>> On Thu, Mar 22, 2012 at 9:49 AM, Eric Seidel  wrote:
>>> Do we have any documentation for how the current symbol export system
>>> for WTF/JSC is supposed to work?
>>>
>>> I'm hitting errors when trying to move WTF files to their own libwtf.a, 
>>> such as:
>>> https://bugs.webkit.org/show_bug.cgi?id=81838
>>> and
>>> http://pastebin.com/dVjV8UiR
>>>
>>> But looking at 
>>> http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/ExportMacros.h
>>>
>>> It appears most of those macros are never used!  (Like
>>> WTF_EXPORT_CLASS, for example.)
>>>
>>> So when trying to resolve errors such as:
>>> https://bugs.webkit.org/show_bug.cgi?id=81838#c8
>>>
>>> The path is unclear.
>>>
>>> Perhaps there is a wiki somewhere on how this system is supposed to work?
>>>
>>> -eric
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>>
>> --
>> morrita
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Documentation for WTF/JSC exports?

[Hajime Morrita]

Done: https://trac.webkit.org/wiki/ExportingSymbols
It doesn't looks this helps your WTF move though.

On Thu, Mar 22, 2012 at 10:38 AM, Eric Seidel  wrote:
> Thank you.  Mark Rowe was kind enough to resolve
> https://bugs.webkit.org/show_bug.cgi?id=81838#c8 in
> http://trac.webkit.org/changeset/111634.
>
> I've found that some of the "Weak External Symbol" errors from
> http://pastebin.com/dVjV8UiR can be resolved by marking the functions
> in question as "inline", but that doesn't seem like the right fix.
>
> Some others like:
> ERROR: symbol double WTF::strtod<(WTF::AllowTrailingJunkTag)0,
> (WTF::AllowTrailingSpacesTag)0>(char const*, char**)
>
> Are for functions which are not even in headers:
> http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/dtoa.cpp#L651
>
> So it's unclear what's causing those.
>
> Thank you for your attempts at documentation. Perhaps that will make
> clear how these exports are supposed to work. :)
>
> -eric
>
> On Wed, Mar 21, 2012 at 6:21 PM, Hajime Morrita  wrote:
>> I'll write a draft so that ports' expert can fill missing pieces.
>> --
>> morrita
>>
>> On Thu, Mar 22, 2012 at 9:49 AM, Eric Seidel  wrote:
>>> Do we have any documentation for how the current symbol export system
>>> for WTF/JSC is supposed to work?
>>>
>>> I'm hitting errors when trying to move WTF files to their own libwtf.a, 
>>> such as:
>>> https://bugs.webkit.org/show_bug.cgi?id=81838
>>> and
>>> http://pastebin.com/dVjV8UiR
>>>
>>> But looking at 
>>> http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/ExportMacros.h
>>>
>>> It appears most of those macros are never used!  (Like
>>> WTF_EXPORT_CLASS, for example.)
>>>
>>> So when trying to resolve errors such as:
>>> https://bugs.webkit.org/show_bug.cgi?id=81838#c8
>>>
>>> The path is unclear.
>>>
>>> Perhaps there is a wiki somewhere on how this system is supposed to work?
>>>
>>> -eric
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>>
>> --
>> morrita
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Documentation for WTF/JSC exports?

[Hajime Morrita]

I'll write a draft so that ports' expert can fill missing pieces.
--
morrita

On Thu, Mar 22, 2012 at 9:49 AM, Eric Seidel  wrote:
> Do we have any documentation for how the current symbol export system
> for WTF/JSC is supposed to work?
>
> I'm hitting errors when trying to move WTF files to their own libwtf.a, such 
> as:
> https://bugs.webkit.org/show_bug.cgi?id=81838
> and
> http://pastebin.com/dVjV8UiR
>
> But looking at 
> http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/ExportMacros.h
>
> It appears most of those macros are never used!  (Like
> WTF_EXPORT_CLASS, for example.)
>
> So when trying to resolve errors such as:
> https://bugs.webkit.org/show_bug.cgi?id=81838#c8
>
> The path is unclear.
>
> Perhaps there is a wiki somewhere on how this system is supposed to work?
>
> -eric
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Using GitHub to Contribute to WebKit (Experimental)

[Hajime Morrita]

On Fri, Mar 16, 2012 at 6:50 PM, Konstantin Tokarev  wrote:
>
>
> 16.03.2012, 04:41, "Adam Barth" :
>> Hi webkit-dev,
>>
>> After reading last week's discussion about switching the project to
>> git, I wondered if it would be possible to get some of the benefits of
>> git-style development without forcing everyone to switch to git.
>>
>> One of the benefits of git-style development is the ability to review
>> a series of patches at once.  GitHub has some nice tools to reviewing
>> pull requests, so I wrote up a short wiki page describing how someone
>> might use GitHub to contribute to WebKit:
>>
>> https://trac.webkit.org/wiki/UsingGitHub
>>
>> I'm not sure we'll want to switch the whole project over to GitHub any
>> time soon, but it might be something that folks who like git might
>> want to experiment with.
>
> Don't you consider using Gerrit[1]? It's more effective review tool for git.

The hardest part would be finishing the setup and making it up and running.
Unlike the build slaves which can go down and lost sometimes,
The code review records need to be more permanent
since people want to read the conversation and see how decisions were made.

That's being said, I personally agree that Gerrit can be a great choice.
Starting from an experiment like Adam is suggesting to GitHub won't hurt,
if someone does setup the server.

--
morrita

>
> [1] http://code.google.com/p/gerrit/
>
> --
> Regards,
> Konstantin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] exporting symbols for building .so/.dll's

[Hajime Morrita]

I found some confusion here.

There are two kinds of symbols which need to be exported from WebCore.

- A. Symbols from WebCore to WebKit(API). This is basically what
WebCore.exp.in covers.
- B. Symbols from WebCore to Application. In principle, there should
be no such symbols.
  But in reality there is some. Symbols for Internals objects follow
this pattern.

Note that the number of B is significantly smaller than one of A.

It looks Alp's main concern is about B. But I implicitly assumed A.
Currently A matters only for Mac WK1 port (Webcore.exp.in).
Some other ports including GTK, WebKit2 needs B. (symbols.fiter,
WebKit_Cairo.def, etc.)
Mac WK1 also needs B. But it's in the same WebCore.exp.in list.

For A, it should be marked as WEBCORE_EXPORT_PRIVATE if we use inline
annotations.
For B, it should use WEBCORE_EXPORT.

For A, I think it's infeasible to replace it with inline annotations
because the .exp list and inline annotations are mutually exclusive.
So we need to make it happen at once. But it's not a simple job.
I think we need some incremental transition plan.
It might be someting like what Alp mentioned, that is,
to use nm or whatever to automate exp list generation, etc.

For B, it's relatively easy to turn the macro on because its number is small.
The symbols.filter file shows about 100 symbols, which would be
manually convertible.

What's tricky is that Chromium component build wants yet another kind
of symbols: The symbols is for unit testing.
Let me call it "C" otpion here.

C is different from either A or B. It touches deep WebCore internals
which people don't need to export unless they write unit tests, that
is current WebKit situation.

So,

- Some ports need A+B (ex. Mac WK1 Port)
- Some ports need   B (ex. GTK, Windows)
- Some ports need   B+C (Chromium)
  And my feeling is that Chromium is OK to have A if it's available.



Having that said, here is my proposal:

- Let's introduce WEBCORE_EXPORT for B.
  Chromium will use this, GTK and Windows also could use. (For GTK, I
expect this to have same definition as WEBKIT_API.)

- Let's NOT introduce WEBCORE_EXPORT_PRIVATE for now
  because it would be useless unless we don't get rid of
WebCore.exp.in, which won't easy.

- Let's introduce WEBCORE_EXPORT_TEST for C.
  Chromium will enable and use this for now.

- If WEBCORE_EXPORT and WEBCORE_EXPORT_TEST conflicts, WEBCORE_EXPORT win.
- If WEBCORE_EXPORT_PRIVATE and WEBCORE_EXPORT_TEST conflicts,
WEBCORE_EXPORT_TEST win.
- If WEBCORE_EXPORT and WEBCORE_EXPORT_PRIVATE conflicts (in the
future), WEBCORE_EXPORT win.

Then we can start from adding C for Chromium, which doesn't have any
export list before.
Chromium will also need B. Having B would be good news also for GTK
and Windows port
because these no longer need to touch their symbols file for each time
the Internals object needs one.
I'm happy to help this to happen. (... and I'd like to ask Ami to help ;-))

What do you think?

--
morrita

On Mon, Mar 12, 2012 at 9:16 AM, Ami Fischman  wrote:
> Responding to several emails below.
>
> Adam wrote:
>>
>> I'm not sure I understand your proposal fully.  Specifically, how would
>> these macros work for, say, the Chromium, Apple-Mac, and Apple-Win ports,
>> which export overlapping, but not identical, sets of symbols?
>
>
> I do not have a proposal to unify the export story across ports.  My
> "proposal" (such as it is) is limited to removing test code from the
> non-test webkit target (see the patch on the bug).
> AFAICT from this thread there is no consensus on unifying options that
> doesn't have as its first step "achieve consensus on the complete public API
> of each library layer", and I didn't get the sense that this is a realistic
> goal, at least for me at my current level of engagement.
>
> Adam also wrote:
>>
>> Relatedly, do you plan to
>> replace  with
>> EXPORT macros, or will we have both macros and an export list for an
>> extended period of time?
>
>
> The latter.  To put things in perspective, WebCore.exp.in is over 2000 lines
> long; my patch macro-annotates ~40 classes in WebCore (which is a far cry
> from, say, doubling the pain of WebCore.exp.in).
> I'm also emboldened in this respect by the coexistence of WEBKIT_EXPORT
> and Source/WebKit/mac/WebKit.exp.
>
> Alp wrote:
>>
>> Doesn't the list of exports change massively based on the level of
>> inlining and compiler optimisation? Which configuration is the target to aim
>> for, and which compiler vendor?
>>
>> Doesn't the list also change between releases of the same compiler?
>
>
> AFAICT the answers to your questions are all "no", for the limited scope of
> my change (some indication of this is that I only tested my patch on
> chromium/linux, but it's now green on all EWS bots after only needing to add
> #include's to get the definition of the export macro, not due to having to
> add extra annotations for some ports).
> As with the existing JSC_EXPORT 

Re: [webkit-dev] exporting symbols for building .so/.dll's

[Hajime Morrita]

(From the right address again...)

On Sun, Mar 11, 2012 at 9:34 AM, Alp Toker  wrote:
> On 09/03/2012 03:52, Ami Fischman wrote:
>
> Hi webkittens,
>
> The over-all question: how should webkit libraries declare which symbols
> they export?
> The trigger for the question: as described in bug 80062, the chromium
> shared-library-based build links test code into the (non-test) libwebkit.so
> target, which is terrible.
>
> The details:
> I took a crack at fixing the above bug (see patch in the bug) by pulling the
> test files out of the non-test build target, and sprinkling various
> {WTF,WEBKIT}_EXPORT{,DATA} macros around declarations that need them (as
> discovered by build-time and run-time failures).  This style of export
> declaration is what the webkit codebase does in various places
> (WTF, Platform, WebCore, and WebKit, AFAICT), and incidentally also what
> the chromium project uses for its sub-components.
> But I'm told other ports use different mechanisms such as .exp.in files for
> apple/mac (and maybe others for other ports? IDK).
>
> Is there consensus on the list for what the Right Thing To Do(tm) is?
> ISTM my options are:
> 1) Add EXPORT declarations as in the patch on the bug.
> 2) Drop the patch from the bug and replace it with chromium-specific
> .exp.in-style files, one per layer from which I need to export (WebCore,
> WTF, WebKit).  And build the build-time machinery to use them.  I don't
> really know what's involved here and would appreciate any pointers/hints
> people had if this is the way to go.
> 3) Something else (preferably unifying other ports' approaches).
>
> Help me webkit-dev, you're my only hope (for consensus).
>
>
> I think the export macros would only ever have made sense if they were put
> there explicitly to guide refactoring of the classes into a library /
> interface structure. And this isn't the case.
>
> At present I don't see an active effort towards that, or much interest in
> defining the public interfaces in each 'module' more strictly. They're
> intentionally fluid.
>
> Having said that, the macros are /vaguely/ useful to see what could be made
> private or hidden in future shuffling of the code in wtf, for example, but
> that's about it.
>
> The very fact that the export macros have to be updated with a tool every
> time a library higher in the link chain uses or doesn't use a public entry
> point, and that the set of imported functions or variables varies between
> ports indicates that this is not going to have wide adoption.
>

This is same for port specific export lists.
To keep the tree green, the community needs to maintain the list
regardless it is externalized from or embedded in the source.
And maintaining the set of export lists has larger pain than
maintaining a macro-based annotation.
Thus keeping it isolated won't help us much.

>, and that the set of imported functions or variables varies between
> ports indicates that this is not going to have wide adoption.

As mrobinson@ mentioned, there is a set of the least common denominator.
My guess is that the number of symbols which is different between
ports will be less than a half of the total.
If we accept such overhead, it could be a preferable option.

>
> If we follow this to the logical conclusion, no unification of granular
> export lists is realistic with the current WebKit porting layer. If the
> strategy were adapted to define exported functionality at class granularity,
> it might just be feasible, but again that is a contract that is begging to
> be broken, and besides, most toolchains lack export-by-class so it's a moot
> point.
>

At least recent gcc+ld and link.exe support such a class level annotation.
For GNU chain, the lack of support seems like an old story:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9283

My feeling is that the macro annotation is never for declaring a "public API".
It's just a pretty convenient replacement of the port specific export
lists, with small overhead from possible unwanted exports.
It's different from WebKit API which each port is providing.
There is no commitment for compatibility, as the "_PRIVATE" suffix indicates.

To clarify: I think that there should be WEBCORE_EXPORT_PRIVATE but no
WEBCORE_EXORT.
This is unlike JSC, which has both JS_EXPORT and JS_EXPORT_PRIVATE.
(I prefer some shorter name btw... but it's a different topic.)

> So the ultimate course of action is then to revert the macros and leave
> everyone to do what they think best in terms of export lists, then tying
> together those solutions where there's overlap.
>

So, as I wrote above, this course seems based on a wrong assumption:
The annotation as a public API.
No, it won't. It could be fluid. it would be just an internal tool
which only WebKit port implementations can rely on.

Does this make sense?

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

Re: [webkit-dev] exporting symbols for building .so/.dll's

[Hajime Morrita]

(From the right address...)

Hi Ami,

I don't think there is a consensus about that. Here is my
understanding of the current status of the export symbol management:

At first, each port has different way to split libraries. For example,

- A) Mac port (WebKit1) splits WebKit into three frameworks: WebCore,
JavaScriptCore and WebKit.
 (The last one is for Objective-C API which wraps WebCore.)
- B) Some others split it into JavaScriptCore and WebCore+WebKit.
- C) Chromium chooses yet another variation: making a single library
for whole WebKit.

This difference is one of the reasons why the way to export symbols is
different among ports.

For ports on approach "C", it doesn't matter which WebCore/JSC API is
used from WebKit API layer because they are built in the same library.
For ports on approach "B", only the symbols exported from JSC matter.
The dependency from WebKit API to WebCore doesn't.
For ports on approach "A", symbols exported both from JSC and WebCore
matter because these two have their own libraries. APIs of these
libraries should be exported to be used by WebKit API library.

Also, there are port specific WebKit APIs (like WebFrame and WebString
of Chromium.) which have their own ways to export symbols. But in
general, people other than the port maintainers don't need to care
about that because there are few chances to change such APIs.

---

I'd try to clarify some more detail:

For JSC API, which "A" and "B" folks care about, there are two ways to
export it.

- For Windows port, there is JavaScriptCore.def.
- For Mac (and WX?) port, there are macro-based annotations like
JS_EXPORT, WTF_EXPORT_PRIVATE.

I'm in the way to eliminate JavaScriptCore.def by replacing it with
these annotations, but the migration isn't finished yet.
(http://wkb.ug/76257)

For WebCore API, we only need to care about WebCore.exp.in because Mac
port is the only one which follows "A" pattern. (I remember Windows
port used to use this pattern. But it looks no longer the case. Maybe
they changed the way when they switched to WebKit2. But my memory
might be just wrong...)

---

Having that long said, back to the original question:

> Is there consensus on the list for what the Right Thing To Do(tm) is?
> ISTM my options are:
> 1) Add EXPORT declarations as in the patch on the bug.
> 2) Drop the patch from the bug and replace it with chromium-specific
> .exp.in-style files, one per layer from which I need to export (WebCore,
> WTF, WebKit).  And build the build-time machinery to use them.  I don't
> really know what's involved here and would appreciate any pointers/hints
> people had if this is the way to go.
> 3) Something else (preferably unifying other ports' approaches).

- If the API is under JavaScriptCore/ (or WTF/), I'd recommend to use
JS_EXPORT and WTF_EXPORT_PRIVATE because we are under transition to
this path.
- If the API is under WebKit/chromium/, we can just use WEBKIT_EXPORT as before.
- If the API is under WebCore/, there is no consensus except we
already have WebCore.exp.in.

My personal preference is to introduce WebCore version of export
macros like WK_EXPORT_PRIVATE. In this way, we could use it to get rid
of WebCore.exp.in in the future.

Another possibility is to ride existing WebCore.exp.in somehow. Yet
another approach could be just giving up to have the unit test as a
separate binary and build it into the library for non-prod
configuration. The last one seems exactly what you are trying to avoid
though... One clear thing is that maintaining yet another exp file
will be bad news for almost everyone ;-)

Anyway, I'd like to hear thoughts from other folks.

Bests,
--
morrita

> ___
> webkit-dev mailing list

On Fri, Mar 9, 2012 at 12:52 PM, Ami Fischman  wrote:
> Hi webkittens,
>
> The over-all question: how should webkit libraries declare which symbols
> they export?
> The trigger for the question: as described in bug 80062, the chromium
> shared-library-based build links test code into the (non-test) libwebkit.so
> target, which is terrible.
>
> The details:
> I took a crack at fixing the above bug (see patch in the bug) by pulling the
> test files out of the non-test build target, and sprinkling various
> {WTF,WEBKIT}_EXPORT{,DATA} macros around declarations that need them (as
> discovered by build-time and run-time failures).  This style of export
> declaration is what the webkit codebase does in various places
> (WTF, Platform, WebCore, and WebKit, AFAICT), and incidentally also what
> the chromium project uses for its sub-components.
> But I'm told other ports use different mechanisms such as .exp.in files for
> apple/mac (and maybe others for other ports? IDK).
>
> Is there consensus on the list for what the Right Thing To Do(tm) is?
> ISTM my options are:
> 1) Add EXPORT declarations as in the patch on the bug.
> 2) Drop the patch from the bug and replace it with chromium-specific
> .exp.in-style files, one per layer from which I need to export (WebCo

Re: [webkit-dev] Adding -webkit-image-set CSS function

[Hajime Morrita]

(Resending from the right address...)

Hi Beth,

Thanks for letting us know about this! The feature sounds gerat for
anyone trying to make their pages more responsive.

Are you going to add any compilation flags? Also, if there is a
Bugzilla entry to track this, I'd like to know that.

When announcing new feature, it would be appreciated if you mention
these two points:
http://trac.webkit.org/wiki/AddingFeatures

Thanks,
--
morrita


On Fri, Mar 2, 2012 at 9:56 AM, Hajime Morrita  wrote:
> Hi Beth,
>
> Thanks for letting us know about this! The feature sounds gerat for
> anyone trying to make their pages more responsive.
>
> Are you going to add any compilation flags? Also, if there is a
> Bugzilla entry to track this, I'd like to know that.
>
> When announcing new feature, it would be appreciated if you mention
> these two points:
> http://trac.webkit.org/wiki/AddingFeatures
>
> Thanks,
> --
> morrita
>
> On Fri, Mar 2, 2012 at 8:06 AM, Beth Dakin  wrote:
>> Hi all!
>>
>> Ted O'Connor recently proposed a new CSS function for the Images module to
>> the CSS working group called image-set. The idea behind the feature is to
>> allow authors to provide multiple variants of the same image at differing
>> resolutions, and to allow the User Agent to choose the resource that is most
>> appropriate at the time. We think this will be a great way to allow authors
>> to specify high resolution resources for iPhone's retina display, and we
>> imagine User Agents being able to choose different resolution resources when
>> content is scaled or zoomed. There is some consensus on the list that a
>> feature like this would be a good addition to CSS Images Level 4. Discussion
>> is still ongoing about the exact syntax of the property, but we'd like to
>> add an experimental implementation to WebKit; after all, such
>> implementations often help guide features like this along.
>>
>> -Beth
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
>
> --
> morrita
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] build-webkit --maximal?

[Hajime Morrita]

Hi Ashod,

On Sat, Feb 25, 2012 at 5:38 PM, Ashod Nakashian
 wrote:
> Webkit-dev,
>
> We have --minimal to disable all optional features, but what about enabling
> everything?
>
> The use-case I have in mind is build sanity checking, where one might need
> to make sure no change broke code under a feature flag. Or may be that's
> something done by the build server or some other way I'm ignorant of?

For some features, each port needs to provide its port-dependent part
to make them work. And filling such gaps isn't a trivial work.

I guess Mac port plus Chromium port provide pretty good coverage
though. If you have a Mac-based box, you can build both on the same
machine. You can "build-webkit" for  building Mac port and
"build-webkit --chromium" followed by "update-webkit-chromium" for
building Chromium port.

Also, a large part of build breakages comes from port specific bits
which need certain setup to build. So hypothetical "--maximum" flag
won't rescue anyway. That's why we have EWS bots on the Bugzilla.
http://markmail.org/thread/hn5c2lqel5yvgslm

Bests,
--
morrita

for Apple
>
> If not, I'm suggesting adding such a flag (perhaps called something else)
> that may be used to enable all flags (valid on the given platform).
>
> -Ash
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Should we move methods from layoutTestController/etc... to internals?

[Hajime Morrita]

On Wed, Feb 22, 2012 at 10:48 AM, Maciej Stachowiak  wrote:
>
> On Feb 21, 2012, at 5:40 PM, Hajime Morrita wrote:
>
>> Hi, Thanks for starting this discussion!
>>
>> To summarize, there is a rough consensus which is like:
>>
>> * A. LayoutTestController (LTC) is for control test harness.
>> dumpAsText() and waitUntilDone() is great example of this.
>>
>> * B. EventSender and some other stuff are for emulating external
>> events like user input.
>> keyDown() is good example.
>>
>> * C. Internals is for inspecting WebCore internal state which isn't
>> available from WebKit API.
>> Inspecting spellcheck markers is one typical example.
>>
>> But I found that there are some test-specific APIs which don't fit
>> well in any of listed categories:
>>
>> * D. Changing Settings and RuntimeFeatures values.
>> Inspecting flags in these objects is a good fit for Internals. But how
>> about changing these values? I feel that it's no longer "inspecting".
>> On the other hand, we know that adding new WebKit and LTC API for each
>> these flags is certainly tedious work especially the flag is just for
>> disabling/enabling half-baked features. Currently we have several flag
>> setters on Internals object but I worry a bit this as a start of
>> abusing Internals.
>>
>> My feeling is that it's OK to use Internals family assuming that
>> getting/setting flags are "trivial" enough so that we don't need to
>> worry about unexpected side-effects. We already have InternalsSettings
>> for this purpose.
>>
>> * E. Invoking some WebCore API which implements "portable" WebKit API.
>> This is one step forward from D. There are some WebKit APIs which just
>> call corresponding WebCore methods. A good example of WebCore side is
>> WebCore::Page::setDeviceScaleFactor(): There is a discussion to
>> whether we should add a wrapper API for this to Internals:
>> http://wkb.ug/74014.
>>
>> This API is less trivial than changing settings since this isn't just
>> a parameter setting but has a side effect. On the other hand, some API
>> like this has no platform-specific part. WebKit API just calls this.
>> It could be felt as a waste of abstraction if we add LTC API for that
>> - it will just stack a few more call frames.
>>
>> I think we could cover this usecase by some Internals-like object. But
>> it should never be Internals itself and ideally a wrapper of WebCore
>> object. For example, we could have something like PageWrapper for
>> WebCore::Page which could be implemented in the same way as Internals.
>>
>> Or, we could employ the controller-client pattern to have IDL
>> generated class in shared WebCoreTestSupport and let each DRT to
>> implement the client. This could eliminate the need for hand-written
>> bindings even though we need to have some per-port stuff.
>>
>> * F. Purely for testing, but "portable" mechanism.
>> Mocking some clients are primary example of this. Mock objects are
>> rarely platform specific and implementing it in each platform is
>> nothing more than coding practice IMHO. I understand that there are
>> some controversy around mock itself. But we have some features which
>> are hard to test in automated manner without mock.
>>
>> For this, we could do same as E.
>>
>> I think LTC isn't good place for neither D, E or F. But Internals also isn't.
>> What do you think?
>
> For D, E and F, I think the methods should be split up into object by purpose 
> rather than by how they'd be implemented. I agree that these methods 
> shouldn't be piled onto a single LayoutTestController object.

That's right.

>
> One concern I have about settings: poking through the WebKit API layer to set 
> settings directly in WebCore may not necessarily work as expected in all 
> WebKit ports, or at least it will violate implementation invariants. For 
> example, in WebKit2 (currently using the WebKitTestRunner tool which is 
> separate from DumpRenderTree at present), both the WebProcess and the UI 
> process need to know about settings. This makes me think that settings (at 
> least ones surfaced at the API level) should actually go through the WebKit 
> API rather than poking directly into WebCore via the internals object.
>

Good point. I wasn't aware of this.

In my understanding, the problem here is that these states can be
out-of-sync. Considering so, we can move a part of Settings parameters
to RuntimeFeatures, which doesn't need to be updated dynamically. I
guess there is a certain numer of flags in Settings which are't
changed from the default outside the test.

Thanks for pointing this out.

Bests,
--
morrita

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

Re: [webkit-dev] Should we move methods from layoutTestController/etc... to internals?

[Hajime Morrita]

Hi, Thanks for starting this discussion!

To summarize, there is a rough consensus which is like:

* A. LayoutTestController (LTC) is for control test harness.
dumpAsText() and waitUntilDone() is great example of this.

* B. EventSender and some other stuff are for emulating external
events like user input.
keyDown() is good example.

* C. Internals is for inspecting WebCore internal state which isn't
available from WebKit API.
Inspecting spellcheck markers is one typical example.

But I found that there are some test-specific APIs which don't fit
well in any of listed categories:

* D. Changing Settings and RuntimeFeatures values.
Inspecting flags in these objects is a good fit for Internals. But how
about changing these values? I feel that it's no longer "inspecting".
On the other hand, we know that adding new WebKit and LTC API for each
these flags is certainly tedious work especially the flag is just for
disabling/enabling half-baked features. Currently we have several flag
setters on Internals object but I worry a bit this as a start of
abusing Internals.

My feeling is that it's OK to use Internals family assuming that
getting/setting flags are "trivial" enough so that we don't need to
worry about unexpected side-effects. We already have InternalsSettings
for this purpose.

* E. Invoking some WebCore API which implements "portable" WebKit API.
This is one step forward from D. There are some WebKit APIs which just
call corresponding WebCore methods. A good example of WebCore side is
WebCore::Page::setDeviceScaleFactor(): There is a discussion to
whether we should add a wrapper API for this to Internals:
http://wkb.ug/74014.

This API is less trivial than changing settings since this isn't just
a parameter setting but has a side effect. On the other hand, some API
like this has no platform-specific part. WebKit API just calls this.
It could be felt as a waste of abstraction if we add LTC API for that
- it will just stack a few more call frames.

I think we could cover this usecase by some Internals-like object. But
it should never be Internals itself and ideally a wrapper of WebCore
object. For example, we could have something like PageWrapper for
WebCore::Page which could be implemented in the same way as Internals.

Or, we could employ the controller-client pattern to have IDL
generated class in shared WebCoreTestSupport and let each DRT to
implement the client. This could eliminate the need for hand-written
bindings even though we need to have some per-port stuff.

* F. Purely for testing, but "portable" mechanism.
Mocking some clients are primary example of this. Mock objects are
rarely platform specific and implementing it in each platform is
nothing more than coding practice IMHO. I understand that there are
some controversy around mock itself. But we have some features which
are hard to test in automated manner without mock.

For this, we could do same as E.

I think LTC isn't good place for neither D, E or F. But Internals also isn't.
What do you think?

--
morrita

On Wed, Feb 22, 2012 at 8:43 AM, Dimitri Glazkov  wrote:
> On Tue, Feb 21, 2012 at 3:39 PM, Ryosuke Niwa  wrote:
>> On Tue, Feb 21, 2012 at 3:14 PM, Maciej Stachowiak  wrote:
>>>
>>> On Feb 21, 2012, at 1:21 PM, Ryosuke Niwa wrote:
>>>
>>> > I'd prefer getting rid of the entire interface when possible. We're
>>> > obviously removing layoutTestController, textInputController, etc... at 
>>> > the
>>> > moment though.
>>>
>>> I think it's helpful to organize the methods by functional area instead of
>>> dumping them all onto one giant interface. layoutTestController for example
>>> has far too many methods, in my opinion. We would not design a public API
>>> where every method is on one global interface, and our testing API should
>>> not look that way either. I would like to see our test API split up more,
>>> rather than combined into a single interface.
>>
>>
>> Yeah, that'll be nice. Maybe morrita and dglazkov have an idea on how to do
>> this nicely?
>
> I kind of like this plan: https://bugs.webkit.org/show_bug.cgi?id=76423
>
> :DG<
>
>>
>>> I'm also confused about your examples of interfaces you are "obviously"
>>> removing. Did you mean "obviously not removing"?
>>
>>
>> Sorry. Yes, it should read "obviously NOT removing".
>>
>> - Ryosuke
>>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] When should we turn on new features?

[Hajime Morrita]

On Tue, Feb 14, 2012 at 11:09 AM, Maciej Stachowiak  wrote:
>
> I think we're talking about a couple of different things now:
>
> 1) Table of what the WebKit community as a whole (instead of individual point 
> maintainers) thinks should be enabled in stable releases. This would be input 
> to port maintainers looking to make a release.
>
> 2) Documenting what enable flags are actually on for given ports as shipped. 
> Probably hard to gather this info, but might be useful input for the WebKit 
> community.
>
> 3) Changing build systems to enable compiling "nightly" and "stable" versions 
> from the same tree, so both modes are documented in trunk. Requires some 
> coding for various build systems.
>
> I like (2) and (3), but I don't think they replace the usefulness of (1). I 
> think the mention of "the feature-table page" is blending (2) and (1), which 
> would serve different purposes.

You are right. And talking about (1) is fine for this discussion to be focused.
I went off the point.

Regards,
--
morrita

>
> Regards,
> Maciej
>
>
> On Feb 13, 2012, at 4:21 PM, Hajime Morrita wrote:
>
>> (Re-sending from the right address...)
>>
>> I'd +1 Adam's point.
>>
>> It would be great if we can do something like "webkit-build --gtk
>> --stable", "webkit-build --chromium --canary" or "webkit-build
>> --nightly" where the script read the central configuration file and
>> find an appropriate configuration. In this way, there would be no
>> duplication we should maintain.
>>
>> Even though some ports currently don't support switches through
>> build-webkit, we can gradually switch over to the central list-based
>> configuration settings by, for example, generating features.gypi,
>> FeatureDefines.xcconfig or a set of flags for autoconf.
>>
>> Also the feature-table page could be generated from the list. We can
>> even start from simply generating an HTML from the machine-readable
>> configuration file, then integrate it to each build system.
>>
>> Although it might be overkill, I personally prefer this kind of "don't
>> repeat youself" direction.
>> --
>> morrita
>>
>> On Tue, Feb 14, 2012 at 8:11 AM, Maciej Stachowiak  wrote:
>>>
>>> On Feb 13, 2012, at 1:21 PM, Ryosuke Niwa wrote:
>>>
>>> On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak  wrote:
>>>>
>>>> I think you raise a good point. Another point worth mentioning is that
>>>> sometimes a feature can be complete and useful in one port, but half-baked
>>>> in another (for example, fullscreen API was shipped in Safari and at the
>>>> same time present but non-functional in Chrome).
>>>>
>>>> I think in the past, port owners have made clear that they want to own the
>>>> final decisions on what features are enabled in their ports.
>>>>
>>>> But we as a community could do better, by having a shared recommendation
>>>> of what features we think should be enabled in shipping releases. In some
>>>> cases, this may not match the settings on trunk, as some features may be
>>>> desirable to enable for experimental builds, but not in shipping product.
>>>> For features that we recommended disabling, ideally we'd identify a reason.
>>>> And in some cases, those might be port-specific issues.
>>>
>>>
>>> Right. Even just having a list of new features with flag(s) to
>>> enable/disable and the status (e.g. list of outstanding bugs) on wiki page
>>> will be helpful.
>>>
>>> For example, vertical writing mode doesn't work on Windows, Chromium, etc...
>>> but port owners may not necessarily realize that the feature is enabled by
>>> default and each port needs to modify the code that draws text.
>>>
>>>
>>> I personally think such a page would be a good idea. I'd love to hear input
>>> from more folks on whether this is a good idea and what the right approach
>>> is.
>>>
>>> Cheers,
>>> Maciej
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] When should we turn on new features?

[Hajime Morrita]

(Re-sending from the right address...)

I'd +1 Adam's point.

It would be great if we can do something like "webkit-build --gtk
--stable", "webkit-build --chromium --canary" or "webkit-build
--nightly" where the script read the central configuration file and
find an appropriate configuration. In this way, there would be no
duplication we should maintain.

Even though some ports currently don't support switches through
build-webkit, we can gradually switch over to the central list-based
configuration settings by, for example, generating features.gypi,
FeatureDefines.xcconfig or a set of flags for autoconf.

Also the feature-table page could be generated from the list. We can
even start from simply generating an HTML from the machine-readable
configuration file, then integrate it to each build system.

Although it might be overkill, I personally prefer this kind of "don't
repeat youself" direction.
--
morrita

On Tue, Feb 14, 2012 at 8:11 AM, Maciej Stachowiak  wrote:
>
> On Feb 13, 2012, at 1:21 PM, Ryosuke Niwa wrote:
>
> On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak  wrote:
>>
>> I think you raise a good point. Another point worth mentioning is that
>> sometimes a feature can be complete and useful in one port, but half-baked
>> in another (for example, fullscreen API was shipped in Safari and at the
>> same time present but non-functional in Chrome).
>>
>> I think in the past, port owners have made clear that they want to own the
>> final decisions on what features are enabled in their ports.
>>
>> But we as a community could do better, by having a shared recommendation
>> of what features we think should be enabled in shipping releases. In some
>> cases, this may not match the settings on trunk, as some features may be
>> desirable to enable for experimental builds, but not in shipping product.
>> For features that we recommended disabling, ideally we'd identify a reason.
>> And in some cases, those might be port-specific issues.
>
>
> Right. Even just having a list of new features with flag(s) to
> enable/disable and the status (e.g. list of outstanding bugs) on wiki page
> will be helpful.
>
> For example, vertical writing mode doesn't work on Windows, Chromium, etc...
> but port owners may not necessarily realize that the feature is enabled by
> default and each port needs to modify the code that draws text.
>
>
> I personally think such a page would be a good idea. I'd love to hear input
> from more folks on whether this is a good idea and what the right approach
> is.
>
> Cheers,
> Maciej
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding the Vibration API to WebCore

[Hajime Morrita]

Hi,

The first patch for this feature is almost ready:
https://bugs.webkit.org/show_bug.cgi?id=72010 But I found that there
is not so positive atmosphere here.

Considering the feature is small and isolated enough and This API can
be taken as a sort of Cookie for LocalStorage in the context of
Gamepad API comparison, I personally feel that this change is OK to
land.

Please let this thread know if there are any concern or objection,
otherwise I'll r+ this in this week. Also, if the author of original
proposal has any discussion around the points that Adam and Simon
raised, it would be helpful to drop it here for supporting this to
happen.

Thanks,
--
morrita





On Fri, Nov 11, 2011 at 7:37 AM, Simon Fraser  wrote:
> On Nov 10, 2011, at 5:57 AM, 권기홍 wrote:
>
>> Hi webkit-dev.
>>
>> I want to let you know that I plan to add the Vibration API to WebKit.
>> (http://dev.w3.org/2009/dap/vibration/)
>> This support will be behind the ENABLE_VIBRATION feature define.
>> see : https://bugs.webkit.org/show_bug.cgi?id=72010
>>
>> Spec is not mature because it's recently added.
>> But Mozila is already implemented this.
>>
>> I'm going to support this until finishing both the spec and patch.
>> If you have any comment, please let me know.
>
> For game pads that have vibration feedback, there's obviously a tie-in with 
> the joystick API here:
> 
>
> Simon
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Asking for review by pinging bugs---another approach

[Hajime Morrita]

Does it make sense for webkit-patch post/upload to support "--ping" to
acknowledge a set of reviewers using a specific form of comment? As a
reviewer, some kind of specific pattern would be helpful to filter
such ping mails which contain, for example, "ping:morrita@".

Maybe this can be taken as a step backward to the "by name" review
request which we had declined. But at least for me, such kind of
filterable mail would be gret tool to pick bugs for review.  Even
though this won't help some high-traffic reviewers, it won't hurt at
least. I've been overwhelmed by the stream of Bugzilla mail coming...

What do you think?

--
morrita


On Thu, Jan 5, 2012 at 5:03 PM, Andreas Kling  wrote:
> On Thu, Jan 5, 2012 at 7:49 AM, Adam Barth  wrote:
>>
>> Not to pick on anyone in particular, but when reading bugmail I
>> occasionally see messages like "pinging for review."  I review a lot
>> of patches, but I don't find these messages particularly helpful
>> because I don't know whether I'm supposed to review the patch.
>>
>> Another approach that might work better for you is to address your
>> comment at someone in particular.  For example, if the message says
>> "Adam, can you please review this patch?", then there's a pretty good
>> chance I'll click through and try to answer your question.
>>
>> If you're unsure who to ask for review, one approach is to look at the
>> svn log for the files you're changing and see who has written/reviewed
>> patches for those files recently.  You can also ask folks who've been
>> around the project for a while to suggest someone.
>
>
> True that.
>
> You can also find reviewers for a particular area here on the WebKit Team
> wiki page: http://trac.webkit.org/wiki/WebKit%20Team (and I encourage people
> to keep their entry up-to-date.)
>
> -Kling
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Incremental steps towards moving WebCore/platform out of WebCore

[Hajime Morrita]

One concern is that "Platform" is too generic to put in global
namespace and it might conflict existing symbols from platform SDK or
something. But because we already have generic names like ASSERT() and
it works, this concern is just a theoretical thing.

So if it works with existing platforms, I think it's fine.

--
morrita

On Thu, Dec 15, 2011 at 4:02 PM, Jarred Nicholls  wrote:
> On Thu, Dec 15, 2011 at 1:55 AM, Adam Barth  wrote:
>>
>> I was working backwards from what's going to be needed to move
>> WebCore/platform out of WebCore, and it occurred to me that we'll
>> probably want a separate namespace for the code once it's outside of
>> WebCore, just like WTF has a separate namespace from JSC.
>>
>> It seems like introducing the new namespace before the move would be
>> beneficial because it would help us sort out whatever layering
>> violations we have today (as they'd become apparent because of the
>> explicit mention of the WebCore namespace).
>>
>> What would be an appropriate name for the namespace?  My first
>> instinct is "Platform" to match the name of the new directory, but I'm
>> open to suggestions.
>
>
> I think Platform is good.  When explaining it to an outsider, I refer to it
> as the Client Interface or Port Interface.  If Platform doesn't resonate
> well with everyone then maybe something around that verbiage would fit.  But
> honestly I can't think of anything better than Platform.
>
>>
>>
>> Adam
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Replacing symbol files with source level annotations

[Hajime Morrita]

Hi folks,

I'm working on replacing the symbol lists with source-level annotations.
And I'd like to ask for your help and review the work.

The first target is JavaScriptCore.exp since JSC is smaller than
WebCore thus easier to attack, and the Mac port maintains the most
comprehensive symbol list.

My plan is to use an automation tool for rewriting the code.
The tool inserts JSC_EXPORT_PRIVATE and its variants for functions and variables
whose symbols are specified in JavaScriptCore.exp.

Here is the current result:

 * The tool: https://github.com/omo/ListExportables
   README.txt explains how to run it.Note that it's for Mac OS and Mac port.

 * A snapshot diff of the generated rewrite:
   https://bugs.webkit.org/show_bug.cgi?id=72855

 * To make the rewrite build-able, we need to land a few changes:
   * https://bugs.webkit.org/show_bug.cgi?id=72862
   * https://bugs.webkit.org/show_bug.cgi?id=72853
   * https://bugs.webkit.org/show_bug.cgi?id=72858

After applying these changes, rewritten code can be built on Mac Snow
Leopard without the export list. I guess it's also buidable for other
versions of Mac with no ... or few modifications.

The advantages of this automate rewrite are:

 * We can write whole JSC code at once. So the result is verifiable
   before landing it.

 * We can land it anytime. For example, I can run the script and land
   the result at the weekend midnight. This would minimize the impact
   of landing.

 * There are fewer chances to over-export and miss-export symbols
   because the rewrite locations are based on the exp file.

I'd like to ask, especially for some Mac build expert ...

 * Please try the rewrite result. You can run the tool by yourself,
   or I can generate the result for specific revision of WebKit for you.

 * Please review blocking problems: http://webkit.org/b/72862,
http://webkit.org/b/72853, http://webkit.org/b/72858
   I think these are trivial and is no harm to land this even without
the rewrite.

 * Once the idea looks OK for you, rubberstamp the rewrite result ;-)

Once this rewrite is in the tree. it would be easy to attack other
ports like GTK and Windows.
There are some remaining tasks for using this tool against WebCore.
But I think JSC is a good starting point.

Here is the master bug: https://bugs.webkit.org/show_bug.cgi?id=67852

Any advice, feedbacks and reviews are welcome!
I hope our frequent build breakers to retire.

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

Re: [webkit-dev] Simplifying "hub" classes (was Cleaning up directories in WebCore)

[Hajime Morrita]

One traditional pattern is to split a big class into  a set small
classes plus a "hub" class
like how Adam has done for original Frame.
In that pattern, small classes has a reference to the hub class and
know its API.
I hope these small classes know just a small part of its hub class via
interface (abstract class.)
In that way, such classes can be unit-tested independently without
instantiating the hub class,
whose instantiation is typically a difficult job.

Personally, I feel that we don't need category-like mixin mechanism
for existing hub classes.
Since we have just a few or dozen of instances of these classes and
the size overhead from extra pointers
is negligible. It isn't case for the node family though.

--
morrita

On Sun, Nov 20, 2011 at 2:23 AM, Adam Roben  wrote:
> On Nov 18, 2011, at 5:55 PM, Adam Barth wrote:
>
>> Really, SQL_DATABASE just wants to store some state per
>> ScriptExecutionContext.  It seems like there should be a way to do
>> that without making a mess of ScriptExecutionContext.
>>
>> IMHO, we want something like the C++ equivalent of Objective-C
>> categories.  I'm not sure how best to achieve that.
>
> Note that ObjC categories don't allow you to add extra state (i.e., ivars) to 
> classes. They only allow you to add extra methods.
>
> -Adam
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



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

Re: [webkit-dev] Change to style guideline: should use type& instead of type* for out arguments

[Hajime Morrita]

At least we already have some of such mehods like:
void Range::getBorderAndTextQuads(Vector&) const;
void VisiblePosition::getInlineBoxAndOffset(InlineBox*& inlineBox, int&
caretOffset) const;
void Posiiton::getInlineBoxAndOffset(EAffinity, InlineBox*&, int&
caretOffset) const;
void FrameView::getTickmarks(Vector&) const;
bool Editor::getCompositionSelection(unsigned& selectionStart, unsigned&
selectionEnd) const;


On Wed, Oct 5, 2011 at 10:14 AM, Eric Seidel  wrote:

> Interesting.  I thought historical policy was universally against the
> word "get" in function names.  I guess you're suggesting that "get"
> should only be applied to function names which have an out-argument?
>

I once heard such a feed back on some review.
And at least we already have some of such mehods like:
void Range::getBorderAndTextQuads(Vector&) const;
void VisiblePosition::getInlineBoxAndOffset(InlineBox*& inlineBox, int&
caretOffset) const;
void Posiiton::getInlineBoxAndOffset(EAffinity, InlineBox*&, int&
caretOffset) const;
void FrameView::getTickmarks(Vector&) const;
bool Editor::getCompositionSelection(unsigned& selectionStart, unsigned&
selectionEnd) const;
...and more:
http://codesearch.google.com/codesearch#search/&exact_package=chromium&q=WebCore%20get.%2B%20file:h$

Personally prefer the get prefix for function with out-params
since it's hard to feel it like an attribute/member variable.
This is never a strong claim though.

Regards,
--
morrita


>
> -eric
>
> On Tue, Oct 4, 2011 at 6:00 PM, Darin Adler  wrote:
> > On Oct 4, 2011, at 2:06 PM, Ryosuke Niwa wrote:
> >
> >> It came to my attention that some people are using raw pointers to pass
> out-arguments (e.g. bug 69366). In my understanding, we use pass by
> reference for out arguments when they have to be modified in callees.
> >>
> >> If there's no objection, I'm going to file a bug & upload a patch to
> state this explicitly in the style guideline.
> >
> > If it’s not already in there, I think you might also want to mention the
> related rule that encourages the use of the word “get” at the starts of the
> names of these functions with out arguments.
> >
> >-- Darin
> >
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



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

[webkit-dev] Spellcheck code cleanup

[Hajime Morrita]

Hi folks,

My team is planning to simplify spellchecking code in WebCore by
migrating old code path to new code path.
I'd like to hear your advice before moving forward.

Background:
Currently WebCore has two separate logics for spellchecking.
The first version relies on TextCheckerClient::checkTextOfParagraph(),
which is available Snow Leopard or later.
We call it "unified" version since the code path is guarded by
USE(UNIFIED_TEXT_CHECKING).
Another version only uses simpler (but less powerful) API like
TextCheckerClient::checkSpellingOfString().
We call it "legacy" version.

Although both "unified" and "legacy" version have almost same role,
their code paths are completely different and are mutual exclusive.
"Unified" version is inside #if block and "legacy" is in #else.
This makes it hard to change editing code
because we need to take care of both but we cannot check both at once.

Our goal is to make the code simpler by removing "legacy" path and
replacing it with "unified" path.
It should be possible by implementing checkTextOfParagraph()
equivalent with other TextCheckerClient API.

Here is a tracking bug for this: https://bugs.webkit.org/show_bug.cgi?id=65849
I uploaded prototype version of the change.

Theoretically, this can be a harmless one-shot change.
But we're worrying about unexpected side effect thus we'd like to do
it in small steps.
Here is a rough plan:

Step 1: Add Setting::isUnifiedTextCheckerEnabled(), which is true only
for platform who has checkTextOfParagraph().
Step 2: Implement Editor::checkTextOfParagraph() which wraps
TextCheckerClient::checkTextOfParagraph()
and replace TextCheckerClient::checkTextOfParagraph() call
with Editor's indirection.
Step 3: Replace compile-time flag "#if USE(UNIFIED_TEXT_CHECKING)"
with the runtime-flag check using isUnifiedTextCheckerEnabled().
 This is only for files under editing/.
Step 4: Implement TextCheckerClient::checkTextOfParagraph() equivalent
in Editor::checkTextOfParagraph(),
 which is used with platforms which don't have
TextCheckerClient::checkTextOfParagraph().
Step 5: Flip isUnifiedTextCheckerEnabled() to true on Chromium (maybe
behind the experimental flag.)
Then see how it works.
Step 6: Stabilize (Hopes there is no need to do it ;-))
Step 7: Once step 6 goes well, flip isUnifiedTextCheckerEnabled() for
all platforms,
 maybe behind the compilation flags like
ENABLE_EDITOR_UNIFIED_TEXT_CHECKING.
Step 8: Remove "legacy" code path and the runtime flag.

Possible side effects in my mind are:

A: Temporal code size growth
Since we enable both legacy and unified code path, it can impact the code size.
But in practice, the grows is around a few hundred lines of code and
there is no template heavy class.
Thus the impact seems negligible.

B: Performance impact.
This change can affect performance since the "unified" version
requires larger text chunks to check spelling
when the grammar checker is enabled.
This affect only Leopard since it is the only platform that has
grammar checker but doesn't have unified checker.
And in my understanding, Safari disables grammar checker by default.
So this looks to affect only
small number of people who 1.use Leopard 2.enable grammar checking
3.use latest WebKit.
And the spellchecking only happens by typing, and there is no batch spellcheck.
Thus it would be little recognizable difference in real use.

>From my personal viewpoint, Step 1-5 looks fine, but 6-8 may be controversial.
How do you think? Any feedback is appreciated.

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