Re: [webkit-dev] WebKit2 SharedSecondaryProcess model

[Balazs Kelemen]

(Sorry for flooding the list but I need to repeat my reply to put it in
the right thread.)

Seems like I misunderstood the concept. I assumed that the shared
process model means that there could be multiply UI process instances
that uses the same web process, virtually when the second MiniBrowser is
launched it connects to the existing web process. By taking a deeper
look into the WebContext and WebProcessProxy classes, I have realized
that the shared process model is about using one web process for
multiply views (what is cool) and not for multiply processes (what would
be more cool from my point of view :) ).
What do you think about my idea? Primarily on embedded devices it
would be great to use the web engine as a server process because it
could save a lot of memory. I think the current design is not too far
for supporting that. Mainly we should find a correct way of connecting
the new UI process to the existing web process, and the Connection
should be per page instead of per process (or we should rework the
WebProcess to not be a singleton?).
Please provide some feedback on this because it is important for our
project to know which way should we go on with WebKit2. Thank you!

Balazs Kelemen

On 08/30/2010 08:22 PM, Sam Weinig wrote:
> Hi Balazs,
>
> Does it not work currently?  If not, can you please file bugs on what
> is not working. We plan on making the shared process model the default
> model for the API, but  it will probably have the caveat that it will
> not support InjectedBundles.
>
> -Sam
>
> On Mon, Aug 30, 2010 at 6:08 AM, Balazs Kelemen  > wrote:
>
>   Hi all!
>
> I am wondering about do you plan for the mac and win to support the
> shared web process model?
> Actually, I have played around with that for Qt. I have a working,
> proof
> of concept implementation. The visited links and the back-forward list
> features are broken, but apart from that the browsers are working with
> the shared web process. I had to rework common parts of the code for
> achieving that, and I would like to contribute it in small parts. I
> think if we want to support that model in the future than we should
> start to implement it as soon as possible to assure that our
> design fits
> the needs of that.
>
> Cheers!
> Balazs Kelemen
> ___
> 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] Problems to build WebKit on Windows

[Diego Gonzalez]

Thanks a lot. It solve my problem.

Regards,
Diego

On Tue, Aug 31, 2010 at 6:24 PM, Chris Hatko  wrote:

> I presume this is a release build ... I ran into this problem myself.
> You can switch to 64Bit OS or turn off "whole program optimization"
> /GL and corresponding linker flag.
>
> Chris
>
> On Tue, Aug 31, 2010 at 5:20 PM, Diego Gonzalez
>  wrote:
> > Hi,
> >
> > Thanks for the feedback!
> >
> > On Tue, Aug 31, 2010 at 12:01 PM, Ilya Tikhonovsky 
> > wrote:
> >>
> >> It is the problem with VC project properties.
> >> The build script just remove all the properties
> >> from WebKitLibraries/win/tools/vsprops/ by mistake.
> >> This problem happens if you use git.
> >> I've created a bug about
> >> that. https://bugs.webkit.org/show_bug.cgi?id=44050
> >> The dirty hack for this is just create .svn file
> >> in WebKitLibraries/win/tools/vsprops/ folder and restore the files from
> the
> >> repository.
> >
> > My problem was related to git and your trick solve my build failures.
> Thanks
> > a lot
> >
> > My problem now is to link the WebKit lib:
> >
> > 11>Compiling resources...
> > 11>Performing Pre-Link Event...
> > 11>1 file(s) copied.
> > 11>1 file(s) copied.
> > 11>Linking...
> > 11>fatal error C1083: Cannot open compiler intermediate file:
> > 'C:\cygwin\home\rodribel\webkit\WebKitBuild\lib\WebKitLib.lib': Not
> enough
> > space
> > 11>LINK : fatal error LNK1257: code generation failed
> >
> > Do you (or anyone) knows about why this linking is exceeding the space?
> >
> >
> > Regards,
> > Diego
> >
> >>
> >> Regards,
> >> Tim.
> >>
> >>
> >> On Tue, Aug 31, 2010 at 6:16 PM, Diego Gonzalez
> >>  wrote:
> >>>
> >>> Hi folks,
> >>>
> >>> I have some problems to build WebKit ToT on my Window Env.
> >>> I'm using Visual C++ express 2005.
> >>>
> >>> I've followed the steps win: http://webkit.org/building/tools.html
> >>> After it I ran update-webkit and build-wekit script
> >>>
> >>> I got this build output: http://pastebin.com/x99zta73
> >>>
> >>> Some  build errors like:
> >>>
> >>> InspectorStorageAgent.cpp
> >>> ..\inspector\InspectorStorageAgent.cpp(64) : error C2039:
> >>> 'sqlTransactionFailed' : is not a member of
> 'WebCore::InspectorFrontend'
> >>>
> >>>
> C:\cygwin\home\rodribel\webkit\WebKitBuild\obj\WebCore\DerivedSources\InspectorFrontend.h(17)
> >>> : see declaration of 'WebCore::InspectorFrontend'
> >>> ..\inspector\InspectorStorageAgent.cpp(98) : error C2039:
> >>> 'sqlTransactionSucceeded' : is not a member of
> 'WebCore::InspectorFrontend'
> >>>
> >>>
> C:\cygwin\home\rodribel\webkit\WebKitBuild\obj\WebCore\DerivedSources\InspectorFrontend.h(17)
> >>> : see declaration of 'WebCore::InspectorFrontend'
> >>>
> >>> and
> >>>
> >>> SVGCSSStyleSelector.cpp
> >>>
> >>>
> c:\cygwin\home\rodribel\webkit\webcore\css\CSSPrimitiveValueMappings.h(2217)
> >>> : error C2065: 'CSSValueButt' : undeclared identifier
> >>>
> >>>
> c:\cygwin\home\rodribel\webkit\webcore\css\CSSPrimitiveValueMappings.h(2231)
> >>> : error C2051: case expression not constant
> >>>
> >>>
> c:\cygwin\home\rodribel\webkit\webcore\css\CSSPrimitiveValueMappings.h(2249)
> >>> : error C2065: 'CSSValueMiter' : undeclared identifier
> >>>
> >>>
> c:\cygwin\home\rodribel\webkit\webcore\css\CSSPrimitiveValueMappings.h(2255)
> >>> : error C2065: 'CSSValueBevel' : undeclared identifier
> >>>
> >>>
> c:\cygwin\home\rodribel\webkit\webcore\css\CSSPrimitiveValueMappings.h(2263)
> >>> : error C2051: case expression not constant
> >>>
> >>>
> c:\cygwin\home\rodribel\webkit\webcore\css\CSSPrimitiveValueMappings.h(2267)
> >>> : error C2051: case expression not constant
> >>>
> >>>
> c:\cygwin\home\rodribel\webkit\webcore\css\CSSPrimitiveValueMappings.h(2281)
> >>> : error C2065: 'CSSValueNonzero' : undeclared identifier
> >>>
> >>>
> c:\cygwin\home\rodribel\webkit\webcore\css\CSSPrimitiveValueMappings.h(2284)
> >>> : error C2065: 'CSSValueEvenodd' : undeclared identifier
> >>>
> >>> seems to be related with features disabled (e.g. database, svg) but
> these
> >>> featrues were not disabled for the build. As I do not have experience
> >>> with these Windows build tools, I wonder if someone could give me some
> >>> directions to get this build ok.
> >>>
> >>> Thanks,
> >>> Diego
> >>>
> >>> ___
> >>> 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] Color Management

[Igor Trindade Oliveira]

Hi,

Continuing color management discussion,  it would be great  to get
advice for some of the questions I have before starting coding up.

There are already some libraries to parser and convert icc profiles.
One of them is little cms[1] and it's being used by many applications,
specially because it is simple and works with specifications version 2
and 4.

However, after looking at how WebKit deals with externals
dependencies, I had the impression that they are tried to be avoided
as much as possible, and due to that, some tools end up being written
from scratch(like SVG, MathML, image decoders, and other parsers).

Now we have two possible paths:

a) use an external dependency(littlecms for example);

b) write from scratch all the ICC Profile specification;

What do you guys think what the best approach?

[1] http://www.littlecms.com/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Color Management

[Alexey Proskuryakov]

01.09.2010, в 08:31, Igor Trindade Oliveira написал(а):

> a) use an external dependency(littlecms for example);
> 
> b) write from scratch all the ICC Profile specification;
> 
> What do you guys think what the best approach?


I think that the first question to answer is why a CMS implementation is needed 
in WebKit at all. It's normally the job of a drawing library to perform the 
conversion behind the scenes.

For example, one can specify a color space when drawing with CoreGraphics (as 
used by Mac and Windows Safari). If some platforms don't have such support, 
deciding what to do with colors should be left to platform-specific code in 
WebKit anyway.

This is what already happens with images that have color profiles embedded, for 
example.

- WBR, Alexey Proskuryakov

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

Re: [webkit-dev] Color Management

[Igor Trindade Oliveira]

2010/9/1 Alexey Proskuryakov :
>
> 01.09.2010, в 08:31, Igor Trindade Oliveira написал(а):
>
>> a) use an external dependency(littlecms for example);
>>
>> b) write from scratch all the ICC Profile specification;
>>
>> What do you guys think what the best approach?
>
>
> I think that the first question to answer is why a CMS implementation is 
> needed in WebKit at all. It's normally the job of a drawing library to 
> perform the conversion behind the scenes.
>
> For example, one can specify a color space when drawing with CoreGraphics (as 
> used by Mac and Windows Safari). If some platforms don't have such support, 
> deciding what to do with colors should be left to platform-specific code in 
> WebKit anyway.
>
> This is what already happens with images that have color profiles embedded, 
> for example.
>
> - WBR, Alexey Proskuryakov
>
>

Hi,

in Qt and Cairo Graphics side does not exist internally any color
management system normally the application that needs it uses a
external dependency like littlecms, this approach is used by Krita[1]
for example. So if the graphics api does not have any support to color
management the fallback could be done to WebKit CMS.

Other use case could be used by icc support in css3. In the last
draft, css3 drops color-profile property due to a lack of
implementation [2][3].


[1] www.koffice.org/krita/
[2] http://oyranos-cms.blogspot.com/2010/06/css3-and-icc-colour-profiles.html
[3] http://www.w3.org/TR/css3-color/#dropped
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Complex and Vector3 classes in WTF?

[Chris Marrin]

On Aug 31, 2010, at 6:59 PM, Kenneth Russell wrote:

> On Tue, Aug 31, 2010 at 6:42 PM, Maciej Stachowiak  wrote:
>> 
>> On Aug 31, 2010, at 5:29 PM, Chris Marrin wrote:
>> 
>>> 
>>> On Aug 31, 2010, at 5:25 PM, Kenneth Russell wrote:
>>> 
>> ...Yes, I did the Google search and you're right that the term is not in 
>> common usage (although I still maintain it's a completely reasonable 
>> term). The reason I think it's meaningful is because it really is a 
>> matrix of sorts, but a specialized one that handles only affine 
>> transformations. We could call it AffineTransform, but then why not call 
>> our 4x4 matrix HomogeneousTransform? I'd just like to be consistent.
> 
> HomogenousTransform is fine. I would also be fond of 
> PerspectiveProjection.
 
 PerspectiveProjection is not a good name for a 4x4 matrix class. Such
 a matrix might be used to represent an orthographic projection.
 
> I think TransformMatrix is not a good name. It immediately raises the 
> question, "what kind of transform". I also think Matrix does not need to 
> be in the name. That is to some extent an implementation detail, from the 
> mathematical perspective. It's more important to identify the type of 
> transformation.
 
 I'm concerned about the route of adding a class for each kind of
 transformation. It will lead to a proliferation of confusingly named
 types and excess type conversion, or re-identification of the type of
 transformation, when composing transformations. At least in the 3D
 realm, all that is desired is one simple 4x4 matrix class. Additional
 classes to represent e.g. 4x3 matrices add unnecessary complexity.
>> 
>> I don't think we need a huge number, but the 2D affine transform case is 
>> clearly special - it's too expensive to use a 4x4 matrix for this.
> 
> Agreed.
> 
>>> 
>>> I agree. So, in order to appease Maciej :-) what if we keep AffineTransform 
>>> as is, and change TransformationMatrix to Matrix (or Matrix4 if Matrix is 
>>> too generic)?
>> 
>> Is HomogenousTransform an inaccurate representation of what it does?
>> 
>> The class has methods such as mapPoint, projectPoint, scale, rotate3d, 
>> applyPerspective, etc. It is clearly oriented around being some sort of 
>> transform, not a generic 4x4 matrix. Is it ever used to represent something 
>> that is not a transform at all? Would you use this class for something 
>> totally unrelated to transforms, for example if you wanted to solve a system 
>> of linear equations via gaussian elimination? My expectation is that you 
>> would not.
> 
> I would certainly not preclude this possibility. If you look at the
> implementation of TransformationMatrix, it actually does matrix
> decomposition to extract components like rotation and perspective of a
> given transform. I could easily see the need to expose the underlying
> operations, or other operations like LU decomposition, in the public

But I agree with Maciej that all of the public API is transformation oriented. 
Even things like inverse() and transpose() have application in doing 
transforms. I think it would be a stretch to use this 4x4 matrix for general 
purposes. A general matrix class usually has to deal with different dimensions, 
for instance.

But I am loath to call it HomogeneousTransform, given the fact that Maciej and 
I have spelled it differently (both are accepted spellings) and it will be 
really hard for people to get used to spelling such an uncommon word.

If you look at the "Uses" section of 
http://en.wikipedia.org/wiki/Transformation_matrix you'll see that they 
consider the term improper as well. And they have a good point. Since they 
recommend the term "general transformation matrix" to distinguish it from the 
more restricted "affine transformation", then simply calling it Transform seems 
appropriate.

-
~Chris
cmar...@apple.com




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

Re: [webkit-dev] Complex and Vector3 classes in WTF?

[Kenneth Russell]

On Wed, Sep 1, 2010 at 11:43 AM, Chris Marrin  wrote:
>
> On Aug 31, 2010, at 6:59 PM, Kenneth Russell wrote:
>
>> On Tue, Aug 31, 2010 at 6:42 PM, Maciej Stachowiak  wrote:
>>>
>>> On Aug 31, 2010, at 5:29 PM, Chris Marrin wrote:
>>>

 On Aug 31, 2010, at 5:25 PM, Kenneth Russell wrote:

>>> ...Yes, I did the Google search and you're right that the term is not 
>>> in common usage (although I still maintain it's a completely reasonable 
>>> term). The reason I think it's meaningful is because it really is a 
>>> matrix of sorts, but a specialized one that handles only affine 
>>> transformations. We could call it AffineTransform, but then why not 
>>> call our 4x4 matrix HomogeneousTransform? I'd just like to be 
>>> consistent.
>>
>> HomogenousTransform is fine. I would also be fond of 
>> PerspectiveProjection.
>
> PerspectiveProjection is not a good name for a 4x4 matrix class. Such
> a matrix might be used to represent an orthographic projection.
>
>> I think TransformMatrix is not a good name. It immediately raises the 
>> question, "what kind of transform". I also think Matrix does not need to 
>> be in the name. That is to some extent an implementation detail, from 
>> the mathematical perspective. It's more important to identify the type 
>> of transformation.
>
> I'm concerned about the route of adding a class for each kind of
> transformation. It will lead to a proliferation of confusingly named
> types and excess type conversion, or re-identification of the type of
> transformation, when composing transformations. At least in the 3D
> realm, all that is desired is one simple 4x4 matrix class. Additional
> classes to represent e.g. 4x3 matrices add unnecessary complexity.
>>>
>>> I don't think we need a huge number, but the 2D affine transform case is 
>>> clearly special - it's too expensive to use a 4x4 matrix for this.
>>
>> Agreed.
>>

 I agree. So, in order to appease Maciej :-) what if we keep 
 AffineTransform as is, and change TransformationMatrix to Matrix (or 
 Matrix4 if Matrix is too generic)?
>>>
>>> Is HomogenousTransform an inaccurate representation of what it does?
>>>
>>> The class has methods such as mapPoint, projectPoint, scale, rotate3d, 
>>> applyPerspective, etc. It is clearly oriented around being some sort of 
>>> transform, not a generic 4x4 matrix. Is it ever used to represent something 
>>> that is not a transform at all? Would you use this class for something 
>>> totally unrelated to transforms, for example if you wanted to solve a 
>>> system of linear equations via gaussian elimination? My expectation is that 
>>> you would not.
>>
>> I would certainly not preclude this possibility. If you look at the
>> implementation of TransformationMatrix, it actually does matrix
>> decomposition to extract components like rotation and perspective of a
>> given transform. I could easily see the need to expose the underlying
>> operations, or other operations like LU decomposition, in the public
>
> But I agree with Maciej that all of the public API is transformation 
> oriented. Even things like inverse() and transpose() have application in 
> doing transforms. I think it would be a stretch to use this 4x4 matrix for 
> general purposes. A general matrix class usually has to deal with different 
> dimensions, for instance.
>
> But I am loath to call it HomogeneousTransform, given the fact that Maciej 
> and I have spelled it differently (both are accepted spellings) and it will 
> be really hard for people to get used to spelling such an uncommon word.
>
> If you look at the "Uses" section of 
> http://en.wikipedia.org/wiki/Transformation_matrix you'll see that they 
> consider the term improper as well. And they have a good point. Since they 
> recommend the term "general transformation matrix" to distinguish it from the 
> more restricted "affine transformation", then simply calling it Transform 
> seems appropriate.

It's fine, though I'd prefer Matrix4.

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

Re: [webkit-dev] Complex and Vector3 classes in WTF?

[Maciej Stachowiak]

On Sep 1, 2010, at 11:43 AM, Chris Marrin wrote:

> 
> But I agree with Maciej that all of the public API is transformation 
> oriented. Even things like inverse() and transpose() have application in 
> doing transforms. I think it would be a stretch to use this 4x4 matrix for 
> general purposes. A general matrix class usually has to deal with different 
> dimensions, for instance.
> 
> But I am loath to call it HomogeneousTransform, given the fact that Maciej 
> and I have spelled it differently (both are accepted spellings) and it will 
> be really hard for people to get used to spelling such an uncommon word.
> 
> If you look at the "Uses" section of 
> http://en.wikipedia.org/wiki/Transformation_matrix you'll see that they 
> consider the term improper as well. And they have a good point. Since they 
> recommend the term "general transformation matrix" to distinguish it from the 
> more restricted "affine transformation", then simply calling it Transform 
> seems appropriate.

Transform sounds ok to me, actually, even though it is a little broad.

Regards,
Maciej

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

Re: [webkit-dev] Complex and Vector3 classes in WTF?

[Chris Marrin]

On Sep 1, 2010, at 12:29 PM, Maciej Stachowiak wrote:

> 
> On Sep 1, 2010, at 11:43 AM, Chris Marrin wrote:
> 
>> 
>> But I agree with Maciej that all of the public API is transformation 
>> oriented. Even things like inverse() and transpose() have application in 
>> doing transforms. I think it would be a stretch to use this 4x4 matrix for 
>> general purposes. A general matrix class usually has to deal with different 
>> dimensions, for instance.
>> 
>> But I am loath to call it HomogeneousTransform, given the fact that Maciej 
>> and I have spelled it differently (both are accepted spellings) and it will 
>> be really hard for people to get used to spelling such an uncommon word.
>> 
>> If you look at the "Uses" section of 
>> http://en.wikipedia.org/wiki/Transformation_matrix you'll see that they 
>> consider the term improper as well. And they have a good point. Since they 
>> recommend the term "general transformation matrix" to distinguish it from 
>> the more restricted "affine transformation", then simply calling it 
>> Transform seems appropriate.
> 
> Transform sounds ok to me, actually, even though it is a little broad.

Filed as https://bugs.webkit.org/show_bug.cgi?id=45051. I also opened 
https://bugs.webkit.org/show_bug.cgi?id=45052 for the work to change Transform 
back to floats. I'm not sure we've fully committed to do this, but I wanted it 
recorded in the bug list. We can invalidate it if we don't end up doing it.

-
~Chris
cmar...@apple.com




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

Re: [webkit-dev] Color Management

[David Hyatt]

On Sep 1, 2010, at 9:52 AM, Igor Trindade Oliveira wrote:

> 2010/9/1 Alexey Proskuryakov :
>> 
>> 01.09.2010, в 08:31, Igor Trindade Oliveira написал(а):
>> 
>>> a) use an external dependency(littlecms for example);
>>> 
>>> b) write from scratch all the ICC Profile specification;
>>> 
>>> What do you guys think what the best approach?
>> 
>> 
>> I think that the first question to answer is why a CMS implementation is 
>> needed in WebKit at all. It's normally the job of a drawing library to 
>> perform the conversion behind the scenes.
>> 
>> For example, one can specify a color space when drawing with CoreGraphics 
>> (as used by Mac and Windows Safari). If some platforms don't have such 
>> support, deciding what to do with colors should be left to platform-specific 
>> code in WebKit anyway.
>> 
>> This is what already happens with images that have color profiles embedded, 
>> for example.
>> 
>> - WBR, Alexey Proskuryakov
>> 
>> 
> 
> Hi,
> 
> in Qt and Cairo Graphics side does not exist internally any color
> management system normally the application that needs it uses a
> external dependency like littlecms, this approach is used by Krita[1]
> for example. So if the graphics api does not have any support to color
> management the fallback could be done to WebKit CMS.
> 
> Other use case could be used by icc support in css3. In the last
> draft, css3 drops color-profile property due to a lack of
> implementation [2][3].


It seems like this support would just be behind the GraphicsContext abstraction 
(which is already colorspace-aware).  I don't see why you'd need code above 
GraphicsContext.  Even color-profile in CSS should ultimately just pass the 
contents of the color profile to GraphicsContext.

For example CoreGraphics supports CGColorSpaceCreateWithICCProfile, so I'd just 
expect GraphicsContext to take the ICC profile data and let the platform decide 
what to do with it.

dave
(hy...@apple.com)


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

Re: [webkit-dev] Complex and Vector3 classes in WTF?

[Simon Fraser]

On Sep 1, 2010, at 1:04 PM, Chris Marrin wrote:

> On Sep 1, 2010, at 12:29 PM, Maciej Stachowiak wrote:
> 
>> On Sep 1, 2010, at 11:43 AM, Chris Marrin wrote:
>> 
>>> 
>>> But I agree with Maciej that all of the public API is transformation 
>>> oriented. Even things like inverse() and transpose() have application in 
>>> doing transforms. I think it would be a stretch to use this 4x4 matrix for 
>>> general purposes. A general matrix class usually has to deal with different 
>>> dimensions, for instance.
>>> 
>>> But I am loath to call it HomogeneousTransform, given the fact that Maciej 
>>> and I have spelled it differently (both are accepted spellings) and it will 
>>> be really hard for people to get used to spelling such an uncommon word.
>>> 
>>> If you look at the "Uses" section of 
>>> http://en.wikipedia.org/wiki/Transformation_matrix you'll see that they 
>>> consider the term improper as well. And they have a good point. Since they 
>>> recommend the term "general transformation matrix" to distinguish it from 
>>> the more restricted "affine transformation", then simply calling it 
>>> Transform seems appropriate.
>> 
>> Transform sounds ok to me, actually, even though it is a little broad.
> 
> Filed as https://bugs.webkit.org/show_bug.cgi?id=45051. I also opened 
> https://bugs.webkit.org/show_bug.cgi?id=45052 for the work to change 
> Transform back to floats. I'm not sure we've fully committed to do this, but 
> I wanted it recorded in the bug list. We can invalidate it if we don't end up 
> doing it.

SVG already has SVGTransform, the interface for one of the component 
transformations within an SVGTransformList, which has an SVGMatrix property, 
which represents the matrix.

I think Transform is going to get too easily confused with existing transform 
terminology related to CSS and SVG transforms, and maybe XSLT too.

Simon

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

Re: [webkit-dev] Complex and Vector3 classes in WTF?

[Chris Marrin]

On Sep 1, 2010, at 1:48 PM, Simon Fraser wrote:

> On Sep 1, 2010, at 1:04 PM, Chris Marrin wrote:
> 
>> On Sep 1, 2010, at 12:29 PM, Maciej Stachowiak wrote:
>> 
>>> On Sep 1, 2010, at 11:43 AM, Chris Marrin wrote:
>>> 
 
 But I agree with Maciej that all of the public API is transformation 
 oriented. Even things like inverse() and transpose() have application in 
 doing transforms. I think it would be a stretch to use this 4x4 matrix for 
 general purposes. A general matrix class usually has to deal with 
 different dimensions, for instance.
 
 But I am loath to call it HomogeneousTransform, given the fact that Maciej 
 and I have spelled it differently (both are accepted spellings) and it 
 will be really hard for people to get used to spelling such an uncommon 
 word.
 
 If you look at the "Uses" section of 
 http://en.wikipedia.org/wiki/Transformation_matrix you'll see that they 
 consider the term improper as well. And they have a good point. Since they 
 recommend the term "general transformation matrix" to distinguish it from 
 the more restricted "affine transformation", then simply calling it 
 Transform seems appropriate.
>>> 
>>> Transform sounds ok to me, actually, even though it is a little broad.
>> 
>> Filed as https://bugs.webkit.org/show_bug.cgi?id=45051. I also opened 
>> https://bugs.webkit.org/show_bug.cgi?id=45052 for the work to change 
>> Transform back to floats. I'm not sure we've fully committed to do this, but 
>> I wanted it recorded in the bug list. We can invalidate it if we don't end 
>> up doing it.
> 
> SVG already has SVGTransform, the interface for one of the component 
> transformations within an SVGTransformList, which has an SVGMatrix property, 
> which represents the matrix.
> 
> I think Transform is going to get too easily confused with existing transform 
> terminology related to CSS and SVG transforms, and maybe XSLT too.

Alternative?

-
~Chris
cmar...@apple.com




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

Re: [webkit-dev] Complex and Vector3 classes in WTF?

[Chris Marrin]

On Sep 1, 2010, at 1:48 PM, Simon Fraser wrote:

> On Sep 1, 2010, at 1:04 PM, Chris Marrin wrote:
> 
>> On Sep 1, 2010, at 12:29 PM, Maciej Stachowiak wrote:
>> 
>>> On Sep 1, 2010, at 11:43 AM, Chris Marrin wrote:
>>> 
 
 But I agree with Maciej that all of the public API is transformation 
 oriented. Even things like inverse() and transpose() have application in 
 doing transforms. I think it would be a stretch to use this 4x4 matrix for 
 general purposes. A general matrix class usually has to deal with 
 different dimensions, for instance.
 
 But I am loath to call it HomogeneousTransform, given the fact that Maciej 
 and I have spelled it differently (both are accepted spellings) and it 
 will be really hard for people to get used to spelling such an uncommon 
 word.
 
 If you look at the "Uses" section of 
 http://en.wikipedia.org/wiki/Transformation_matrix you'll see that they 
 consider the term improper as well. And they have a good point. Since they 
 recommend the term "general transformation matrix" to distinguish it from 
 the more restricted "affine transformation", then simply calling it 
 Transform seems appropriate.
>>> 
>>> Transform sounds ok to me, actually, even though it is a little broad.
>> 
>> Filed as https://bugs.webkit.org/show_bug.cgi?id=45051. I also opened 
>> https://bugs.webkit.org/show_bug.cgi?id=45052 for the work to change 
>> Transform back to floats. I'm not sure we've fully committed to do this, but 
>> I wanted it recorded in the bug list. We can invalidate it if we don't end 
>> up doing it.
> 
> SVG already has SVGTransform, the interface for one of the component 
> transformations within an SVGTransformList, which has an SVGMatrix property, 
> which represents the matrix.
> 
> I think Transform is going to get too easily confused with existing transform 
> terminology related to CSS and SVG transforms, and maybe XSLT too.

It's true that we have many Transform concepts. But this Transform class is at 
the bottom of the CSS and SVG transformation logic, so doesn't it make sense 
that it is the simplest name?

-
~Chris
cmar...@apple.com




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

[webkit-dev] FrameLoader forwarding calls to FrameLoaderClient

[Nate Chapin]

In looking at ways to decrease the agony associated with FrameLoader,
I've noticed that there are a whole of 1-line functions on FrameLoader
that just call a similarly named function on FrameLoaderClient without
accessing any member variables other than m_client.

On the one hand, removing these forwarding functions could move a lot
of noise out of FrameLoader.  On the other hand, doing so would add
another dereference at the callsite and increase the number of places
we have to include FrameLoaderClient.h.

I'm just curious whether this was a conscious design decision
(especially since there are also a bunch of functions on
FrameLoaderClient that are called directly, rather than having a
corresponding function on FrameLoader).  Does anyone have insight into
the history of this abstraction or strong feelings on it?

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

[webkit-dev] Arena is crufty?

[Chris Marrin]

Ken's PODRedBlackTree patch has made me go back and take a closer look at 
WebKit's Arena "class". Turns out it's not a class at all, just some structs 
and macros. That seems very un-WebKit-like to me. Ken's patch also has a 
PODArena class, which uses Arena in its implementation. Sam suggests that 
PODRedBlackTree should really go into WTF, which means PODArena and Arena would 
need to go there as well.

It seems like Arena really needs to be brought into the 21st century and made a 
proper class. Maybe now is the right time to:

1) Make Arena a class

2) Integrate Ken's PODArena functionality into this new Arena class (or maybe 
just make Ken's PODArena the new Arena class).

3) Move the new Arena class to WTF

4) Put PODRedBlackTree in WTF

It looks like RenderArena is currently the only client of Arena.h, so this 
change shouldn't be too hard. Of course, looking at RenderArena, it's a little 
odd, too. It is not renderer specific at all. It's just an Arena that recycles 
freed objects. Maybe we should move that functionality into the new Arena 
class. But RenderArena is used all over the place, so maybe that's going one 
step too far down this road?

-
~Chris
cmar...@apple.com




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

Re: [webkit-dev] FrameLoader forwarding calls to FrameLoaderClient

[Darin Adler]

Originally, I think Maciej and I intended the frame loader client to be private 
to frame loader, and all calls were intended to flow through the frame loader. 
The same for other clients elsewhere in WebKit. It would be good to be 
consistent one way or the other, I guess. Not a very momentous decision.

-- Darin

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

Re: [webkit-dev] Arena is crufty?

[James Robinson]

On Wed, Sep 1, 2010 at 4:20 PM, Chris Marrin  wrote:

>
> Ken's PODRedBlackTree patch has made me go back and take a closer look at
> WebKit's Arena "class". Turns out it's not a class at all, just some structs
> and macros. That seems very un-WebKit-like to me. Ken's patch also has a
> PODArena class, which uses Arena in its implementation. Sam suggests that
> PODRedBlackTree should really go into WTF, which means PODArena and Arena
> would need to go there as well.
>
> It seems like Arena really needs to be brought into the 21st century and
> made a proper class. Maybe now is the right time to:
>
> 1) Make Arena a class
>
> 2) Integrate Ken's PODArena functionality into this new Arena class (or
> maybe just make Ken's PODArena the new Arena class).
>
> 3) Move the new Arena class to WTF
>
> 4) Put PODRedBlackTree in WTF
>
> It looks like RenderArena is currently the only client of Arena.h, so this
> change shouldn't be too hard. Of course, looking at RenderArena, it's a
> little odd, too. It is not renderer specific at all. It's just an Arena that
> recycles freed objects. Maybe we should move that functionality into the new
> Arena class. But RenderArena is used all over the place, so maybe that's
> going one step too far down this road?
>

I'm pretty sure we want to delete RenderArena (since
the minuscule-to-negative performance gain is not worth the extra
complexity) at some point anyway.  If that is still the case, then maybe it
makes more sense to have PODArena be the only arena class in WebKit.

I'm not sure we have to move PODArena / PODRedBlackTree to WTF right away,
but it can't hurt.  My gut feeling is that historically most classes that
think they want Arenas actually do not need the extra complexity and we
shouldn't encourage more users of arena classes without some discussion.  I
actually prefer having PODArena be an implementation detail of
PODRedBlackTree and not exposed as a general utility until we have a clear
need for something else to use it.

- James



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

Re: [webkit-dev] Arena is crufty?

[Maciej Stachowiak]

On Sep 1, 2010, at 4:20 PM, Chris Marrin wrote:

> 
> Ken's PODRedBlackTree patch has made me go back and take a closer look at 
> WebKit's Arena "class". Turns out it's not a class at all, just some structs 
> and macros. That seems very un-WebKit-like to me. Ken's patch also has a 
> PODArena class, which uses Arena in its implementation. Sam suggests that 
> PODRedBlackTree should really go into WTF, which means PODArena and Arena 
> would need to go there as well.
> 
> It seems like Arena really needs to be brought into the 21st century and made 
> a proper class. Maybe now is the right time to:
> 
> 1) Make Arena a class
> 
> 2) Integrate Ken's PODArena functionality into this new Arena class (or maybe 
> just make Ken's PODArena the new Arena class).
> 
> 3) Move the new Arena class to WTF
> 
> 4) Put PODRedBlackTree in WTF
> 
> It looks like RenderArena is currently the only client of Arena.h, so this 
> change shouldn't be too hard. Of course, looking at RenderArena, it's a 
> little odd, too. It is not renderer specific at all. It's just an Arena that 
> recycles freed objects. Maybe we should move that functionality into the new 
> Arena class. But RenderArena is used all over the place, so maybe that's 
> going one step too far down this road?

Arena was imported from Mozilla and could certainly benefit from modernization. 
For the rendering use case though, it is essential to handle non-POD types 
correctly.

Regards,
Maciej

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

Re: [webkit-dev] Arena is crufty?

[Kenneth Russell]

On Wed, Sep 1, 2010 at 4:36 PM, James Robinson  wrote:
> On Wed, Sep 1, 2010 at 4:20 PM, Chris Marrin  wrote:
>>
>> Ken's PODRedBlackTree patch has made me go back and take a closer look at
>> WebKit's Arena "class". Turns out it's not a class at all, just some structs
>> and macros. That seems very un-WebKit-like to me. Ken's patch also has a
>> PODArena class, which uses Arena in its implementation. Sam suggests that
>> PODRedBlackTree should really go into WTF, which means PODArena and Arena
>> would need to go there as well.
>>
>> It seems like Arena really needs to be brought into the 21st century and
>> made a proper class. Maybe now is the right time to:
>>
>> 1) Make Arena a class
>>
>> 2) Integrate Ken's PODArena functionality into this new Arena class (or
>> maybe just make Ken's PODArena the new Arena class).
>>
>> 3) Move the new Arena class to WTF
>>
>> 4) Put PODRedBlackTree in WTF
>>
>> It looks like RenderArena is currently the only client of Arena.h, so this
>> change shouldn't be too hard. Of course, looking at RenderArena, it's a
>> little odd, too. It is not renderer specific at all. It's just an Arena that
>> recycles freed objects. Maybe we should move that functionality into the new
>> Arena class. But RenderArena is used all over the place, so maybe that's
>> going one step too far down this road?
>
> I'm pretty sure we want to delete RenderArena (since
> the minuscule-to-negative performance gain is not worth the extra
> complexity) at some point anyway.  If that is still the case, then maybe it
> makes more sense to have PODArena be the only arena class in WebKit.
> I'm not sure we have to move PODArena / PODRedBlackTree to WTF right away,
> but it can't hurt.  My gut feeling is that historically most classes that
> think they want Arenas actually do not need the extra complexity and we
> shouldn't encourage more users of arena classes without some discussion.  I
> actually prefer having PODArena be an implementation detail of
> PODRedBlackTree and not exposed as a general utility until we have a clear
> need for something else to use it.

There is more code coming, outside of the red/black tree, which uses
PODArena to allocate (lots) of small temporary objects and then throw
them all away at the end. I definitely do not want to have to add
bookkeeping for these temporary objects, which would be required if
the PODArena weren't available.

PODArena is not designed to be a replacement for the ArenaPool
functionality; it's just a consumer. I'd rather start to land the code
in this place before doing major restructurings.

-Ken

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

Re: [webkit-dev] Script programming language: Perl, Python, or Ruby?

[TAMURA, Kent]

Thanks.
So porting PrettyPatch to Python will make good benefit and should have no
drawbacks.  I should go ahead.

On Wed, Sep 1, 2010 at 09:21, William Siegrist  wrote:


On Aug 31, 2010, at 4:43 PM, TAMURA, Kent wrote:



>   Can we run python scripts on bugs.webkit.org server?



Yes.



-Bill





--
TAMURA Kent
Software Engineer, Google




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

Re: [webkit-dev] Arena is crufty?

[Chris Marrin]

On Sep 1, 2010, at 4:39 PM, Maciej Stachowiak wrote:

> 
> On Sep 1, 2010, at 4:20 PM, Chris Marrin wrote:
> 
>> 
>> Ken's PODRedBlackTree patch has made me go back and take a closer look at 
>> WebKit's Arena "class". Turns out it's not a class at all, just some structs 
>> and macros. That seems very un-WebKit-like to me. Ken's patch also has a 
>> PODArena class, which uses Arena in its implementation. Sam suggests that 
>> PODRedBlackTree should really go into WTF, which means PODArena and Arena 
>> would need to go there as well.
>> 
>> It seems like Arena really needs to be brought into the 21st century and 
>> made a proper class. Maybe now is the right time to:
>> 
>> 1) Make Arena a class
>> 
>> 2) Integrate Ken's PODArena functionality into this new Arena class (or 
>> maybe just make Ken's PODArena the new Arena class).
>> 
>> 3) Move the new Arena class to WTF
>> 
>> 4) Put PODRedBlackTree in WTF
>> 
>> It looks like RenderArena is currently the only client of Arena.h, so this 
>> change shouldn't be too hard. Of course, looking at RenderArena, it's a 
>> little odd, too. It is not renderer specific at all. It's just an Arena that 
>> recycles freed objects. Maybe we should move that functionality into the new 
>> Arena class. But RenderArena is used all over the place, so maybe that's 
>> going one step too far down this road?
> 
> Arena was imported from Mozilla and could certainly benefit from 
> modernization. For the rendering use case though, it is essential to handle 
> non-POD types correctly.

But RenderArena doesn't deal with types at all, does it? It just allocs and 
free's void*'s. It's not even a template class. So maybe we should have an 
Arena class which deals with void*'s and a PODArena template class which lets 
you type arena objects? RenderArena would use the Arena class.

-
~Chris
cmar...@apple.com




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

Re: [webkit-dev] Arena is crufty?

[Kenneth Russell]

On Wed, Sep 1, 2010 at 5:08 PM, Chris Marrin  wrote:
>
> On Sep 1, 2010, at 4:39 PM, Maciej Stachowiak wrote:
>
>>
>> On Sep 1, 2010, at 4:20 PM, Chris Marrin wrote:
>>
>>>
>>> Ken's PODRedBlackTree patch has made me go back and take a closer look at 
>>> WebKit's Arena "class". Turns out it's not a class at all, just some 
>>> structs and macros. That seems very un-WebKit-like to me. Ken's patch also 
>>> has a PODArena class, which uses Arena in its implementation. Sam suggests 
>>> that PODRedBlackTree should really go into WTF, which means PODArena and 
>>> Arena would need to go there as well.
>>>
>>> It seems like Arena really needs to be brought into the 21st century and 
>>> made a proper class. Maybe now is the right time to:
>>>
>>> 1) Make Arena a class
>>>
>>> 2) Integrate Ken's PODArena functionality into this new Arena class (or 
>>> maybe just make Ken's PODArena the new Arena class).
>>>
>>> 3) Move the new Arena class to WTF
>>>
>>> 4) Put PODRedBlackTree in WTF
>>>
>>> It looks like RenderArena is currently the only client of Arena.h, so this 
>>> change shouldn't be too hard. Of course, looking at RenderArena, it's a 
>>> little odd, too. It is not renderer specific at all. It's just an Arena 
>>> that recycles freed objects. Maybe we should move that functionality into 
>>> the new Arena class. But RenderArena is used all over the place, so maybe 
>>> that's going one step too far down this road?
>>
>> Arena was imported from Mozilla and could certainly benefit from 
>> modernization. For the rendering use case though, it is essential to handle 
>> non-POD types correctly.
>
> But RenderArena doesn't deal with types at all, does it? It just allocs and 
> free's void*'s. It's not even a template class. So maybe we should have an 
> Arena class which deals with void*'s and a PODArena template class which lets 
> you type arena objects? RenderArena would use the Arena class.

RenderArena is used by classes which want to override operator new and
delete in order to be allocated in an arena.

PODArena is designed to be non-intrusive with respect to the POD data
types that are allocated in it; overloaded operator new and delete do
not need to be provided.

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

Re: [webkit-dev] Arena is crufty?

[Chris Marrin]

On Sep 1, 2010, at 5:12 PM, Kenneth Russell wrote:

> On Wed, Sep 1, 2010 at 5:08 PM, Chris Marrin  wrote:
>> 
>> On Sep 1, 2010, at 4:39 PM, Maciej Stachowiak wrote:
>> 
>>> 
>>> On Sep 1, 2010, at 4:20 PM, Chris Marrin wrote:
>>> 
 
 Ken's PODRedBlackTree patch has made me go back and take a closer look at 
 WebKit's Arena "class". Turns out it's not a class at all, just some 
 structs and macros. That seems very un-WebKit-like to me. Ken's patch also 
 has a PODArena class, which uses Arena in its implementation. Sam suggests 
 that PODRedBlackTree should really go into WTF, which means PODArena and 
 Arena would need to go there as well.
 
 It seems like Arena really needs to be brought into the 21st century and 
 made a proper class. Maybe now is the right time to:
 
 1) Make Arena a class
 
 2) Integrate Ken's PODArena functionality into this new Arena class (or 
 maybe just make Ken's PODArena the new Arena class).
 
 3) Move the new Arena class to WTF
 
 4) Put PODRedBlackTree in WTF
 
 It looks like RenderArena is currently the only client of Arena.h, so this 
 change shouldn't be too hard. Of course, looking at RenderArena, it's a 
 little odd, too. It is not renderer specific at all. It's just an Arena 
 that recycles freed objects. Maybe we should move that functionality into 
 the new Arena class. But RenderArena is used all over the place, so maybe 
 that's going one step too far down this road?
>>> 
>>> Arena was imported from Mozilla and could certainly benefit from 
>>> modernization. For the rendering use case though, it is essential to handle 
>>> non-POD types correctly.
>> 
>> But RenderArena doesn't deal with types at all, does it? It just allocs and 
>> free's void*'s. It's not even a template class. So maybe we should have an 
>> Arena class which deals with void*'s and a PODArena template class which 
>> lets you type arena objects? RenderArena would use the Arena class.
> 
> RenderArena is used by classes which want to override operator new and
> delete in order to be allocated in an arena.
> 
> PODArena is designed to be non-intrusive with respect to the POD data
> types that are allocated in it; overloaded operator new and delete do
> not need to be provided.

Right, so I think we should have (in WTF) an Arena class which simply does 
arena based alloc and free of void*'s, and a PODArena template class which does 
what your PODArena does today, using the Arena class as its implementation. 
Then RenderArena should be changed to use Arena. This is minimal change and 
doesn't change the functionality of any end-user classes.

-
~Chris
cmar...@apple.com




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

Re: [webkit-dev] Arena is crufty?

[David Hyatt]

We should just kill Arena and remove it and RenderArena both.

dave

On Sep 1, 2010, at 4:20 PM, Chris Marrin wrote:

> 
> Ken's PODRedBlackTree patch has made me go back and take a closer look at 
> WebKit's Arena "class". Turns out it's not a class at all, just some structs 
> and macros. That seems very un-WebKit-like to me. Ken's patch also has a 
> PODArena class, which uses Arena in its implementation. Sam suggests that 
> PODRedBlackTree should really go into WTF, which means PODArena and Arena 
> would need to go there as well.
> 
> It seems like Arena really needs to be brought into the 21st century and made 
> a proper class. Maybe now is the right time to:
> 
> 1) Make Arena a class
> 
> 2) Integrate Ken's PODArena functionality into this new Arena class (or maybe 
> just make Ken's PODArena the new Arena class).
> 
> 3) Move the new Arena class to WTF
> 
> 4) Put PODRedBlackTree in WTF
> 
> It looks like RenderArena is currently the only client of Arena.h, so this 
> change shouldn't be too hard. Of course, looking at RenderArena, it's a 
> little odd, too. It is not renderer specific at all. It's just an Arena that 
> recycles freed objects. Maybe we should move that functionality into the new 
> Arena class. But RenderArena is used all over the place, so maybe that's 
> going one step too far down this road?
> 
> -
> ~Chris
> cmar...@apple.com
> 
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] Arena is crufty?

[Maciej Stachowiak]

On Sep 1, 2010, at 7:04 PM, David Hyatt wrote:

> We should just kill Arena and remove it and RenderArena both.

Wasn't it still a measurable slowdown last time we tried that?

 - Maciej

> 
> On Sep 1, 2010, at 4:20 PM, Chris Marrin wrote:
> 
>> 
>> Ken's PODRedBlackTree patch has made me go back and take a closer look at 
>> WebKit's Arena "class". Turns out it's not a class at all, just some structs 
>> and macros. That seems very un-WebKit-like to me. Ken's patch also has a 
>> PODArena class, which uses Arena in its implementation. Sam suggests that 
>> PODRedBlackTree should really go into WTF, which means PODArena and Arena 
>> would need to go there as well.
>> 
>> It seems like Arena really needs to be brought into the 21st century and 
>> made a proper class. Maybe now is the right time to:
>> 
>> 1) Make Arena a class
>> 
>> 2) Integrate Ken's PODArena functionality into this new Arena class (or 
>> maybe just make Ken's PODArena the new Arena class).
>> 
>> 3) Move the new Arena class to WTF
>> 
>> 4) Put PODRedBlackTree in WTF
>> 
>> It looks like RenderArena is currently the only client of Arena.h, so this 
>> change shouldn't be too hard. Of course, looking at RenderArena, it's a 
>> little odd, too. It is not renderer specific at all. It's just an Arena that 
>> recycles freed objects. Maybe we should move that functionality into the new 
>> Arena class. But RenderArena is used all over the place, so maybe that's 
>> going one step too far down this road?



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

Re: [webkit-dev] Arena is crufty?

[David Hyatt]

On Sep 1, 2010, at 7:07 PM, Maciej Stachowiak wrote:

> 
> On Sep 1, 2010, at 7:04 PM, David Hyatt wrote:
> 
>> We should just kill Arena and remove it and RenderArena both.
> 
> Wasn't it still a measurable slowdown last time we tried that?
> 

Not enough to matter.  We could easily make up the difference.

dave
(hy...@apple.com)


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

Re: [webkit-dev] Arena is crufty?

[David Hyatt]

Please let's not add another client of Arena though.  That will just make it 
harder to remove, and I highly doubt you're getting any real performance gain 
from using it.

dave

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

Re: [webkit-dev] Arena is crufty?

[Kenneth Russell]

I would be happy to not add another Arena client, but the primary
reason I need an arena is not just for performance but to avoid having
to keep track of all of the objects I need to delete.

Is there any consensus yet on how to proceed with
https://bugs.webkit.org/show_bug.cgi?id=45059 ? I'm concerned about
taking on large-scale restructuring with potential performance impact
as a prerequisite for my landing any initial code. I could revert my
PODArena class to use its own memory allocation rather than that in
Arena.h.

-Ken

On Wed, Sep 1, 2010 at 7:12 PM, David Hyatt  wrote:
> Please let's not add another client of Arena though.  That will just make it 
> harder to remove, and I highly doubt you're getting any real performance gain 
> from using it.
>
> dave
>
> ___
> 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] Script programming language: Perl, Python, or Ruby?

[Sam Weinig]

Sorry, I seemed to have missed this thread.  Please do not rewrite scripts
just to rewrite them in a language you like. WebKit's dependency on Ruby is
here to stay. Just because python is common at Google does not make it
universal.

-Sam

On Wed, Sep 1, 2010 at 4:48 PM, TAMURA, Kent  wrote:

> Thanks.
> So porting PrettyPatch to Python will make good benefit and should have no
> drawbacks.  I should go ahead.
>
>
> On Wed, Sep 1, 2010 at 09:21, William Siegrist wrote:
>
>> On Aug 31, 2010, at 4:43 PM, TAMURA, Kent wrote:
>>
>> >   Can we run python scripts on bugs.webkit.org server?
>>
>> Yes.
>>
>> -Bill
>>
>>
>
>
> --
> TAMURA Kent
> Software Engineer, Google
>
>
>
>
> ___
> 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] Script programming language: Perl, Python, or Ruby?

[Eric Seidel]

Here are the list of files in the project which use ruby:

Scripts/check-for-inappropriate-files-in-framework:#!/usr/bin/env ruby
Scripts/check-for-webkit-framework-include-consistency:#!/usr/bin/env ruby
Scripts/clean-header-guards:#!/usr/bin/ruby
Scripts/roll-over-ChangeLogs:#!/usr/bin/env ruby
iExploder/htdocs/iexploder.cgi:#!/usr/bin/ruby
iExploder/htdocs/iexploder.rb:# These if statements are so
that mod_ruby doesn't have to reload the files
iExploder/htdocs/webserver.rb:#!/usr/bin/ruby
iExploder/tools/lasthit.rb:#!/usr/bin/ruby
iExploder/tools/osx_last_crash.rb:#!/usr/bin/ruby
iExploder/tools/showtest.rb:#!/usr/bin/ruby

-eric

On Wed, Sep 1, 2010 at 7:40 PM, Sam Weinig  wrote:
> Sorry, I seemed to have missed this thread.  Please do not rewrite scripts
> just to rewrite them in a language you like. WebKit's dependency on Ruby is
> here to stay. Just because python is common at Google does not make it
> universal.
> -Sam
>
> On Wed, Sep 1, 2010 at 4:48 PM, TAMURA, Kent  wrote:
>>
>> Thanks.
>> So porting PrettyPatch to Python will make good benefit and should have no
>> drawbacks.  I should go ahead.
>>
>> On Wed, Sep 1, 2010 at 09:21, William Siegrist 
>> wrote:
>>>
>>> On Aug 31, 2010, at 4:43 PM, TAMURA, Kent wrote:
>>>
>>> >   Can we run python scripts on bugs.webkit.org server?
>>>
>>> Yes.
>>>
>>> -Bill
>>>
>>
>>
>>
>> --
>> TAMURA Kent
>> Software Engineer, Google
>>
>>
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Script programming language: Perl, Python, or Ruby?

[Ryosuke Niwa]

Hi,

On Tue, Aug 31, 2010 at 7:56 AM, TAMURA, Kent  wrote:

> Do we have any recommendation of programming language for scripts such as
> WebKitTools/Scripts?
> It seems new scripts are written by Python and Ruby code is very rare.
>
> Is it reasonable to port a Ruby script to Python?
> I tried to port PrettyPatch.rb to Python in
> https://bugs.webkit.org/show_bug.cgi?id=43617 in order to remove Ruby
> dependency for many developers and buildbots.  However bdash objected it.
>

Why Ruby to Python?  There are also Perl scripts in WebKitTools/Scripts.
 Could you explain the benefits of converting Ruby scripts to Python?

I agree that having to install Ruby, Python, and Perl is a burden for many
Windows developers but most of us use Mac / Linux for WebKit development
anyways.

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

Re: [webkit-dev] Script programming language: Perl, Python, or Ruby?

[Dirk Pranke]

Hi Sam,

Did you see the reply I sent on this thread? There are actually decent
reasons to rewrite the code into Python, to simplify and speed up the
new-run-webkit-tests implementation. Given that, do you still object
to the patch landing (since the work has already been done)?

-- Dirk

On Wed, Sep 1, 2010 at 7:40 PM, Sam Weinig  wrote:
> Sorry, I seemed to have missed this thread.  Please do not rewrite scripts
> just to rewrite them in a language you like. WebKit's dependency on Ruby is
> here to stay. Just because python is common at Google does not make it
> universal.
> -Sam
>
> On Wed, Sep 1, 2010 at 4:48 PM, TAMURA, Kent  wrote:
>>
>> Thanks.
>> So porting PrettyPatch to Python will make good benefit and should have no
>> drawbacks.  I should go ahead.
>>
>> On Wed, Sep 1, 2010 at 09:21, William Siegrist 
>> wrote:
>>>
>>> On Aug 31, 2010, at 4:43 PM, TAMURA, Kent wrote:
>>>
>>> >   Can we run python scripts on bugs.webkit.org server?
>>>
>>> Yes.
>>>
>>> -Bill
>>>
>>
>>
>>
>> --
>> TAMURA Kent
>> Software Engineer, Google
>>
>>
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Script programming language: Perl, Python, or Ruby?

[David Levin]

>From reading this thread and the bug, it sounds like there is one key issue
installing something new on build machines.

As discussed before in regards to python, there was a desire not to go above
a certain version so that the tiger build machine could run a script. That
seemed reasonable to me.

Similarly there is a desire in this case to avoid Ruby because it means
installing something new on other build machines. This also seems reasonable
to me.

There are other issues that seem tangential which are being brought up and
only confuse the subject for me:

   - Speed -- without numbers this is meaningless to me.
   - A hang that might be reduced -- since it will remain, it sounds like
   there is a deeper issue to fix.
   - People like python -- me too, but perhaps not a deciding factor.

It probably didn't help that the subject of the email focuses on languages
in a highlander smack down style as if there can be only one.

Focusing again, given the build machine issue:

   - Is it best to have a separate script that is similar to PrettyPatch
   solve the issue?
   - Or replace the script?
   - Or can the dependency on PrettyPatch be controlled via a commandline
   option and just turned off on build machines?
   - Or have folks explain why they don't want to install more on their
   build machine?


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

Re: [webkit-dev] Script programming language: Perl, Python, or Ruby?

[Maciej Stachowiak]

On Sep 1, 2010, at 9:28 PM, Dirk Pranke wrote:

> Hi Sam,
> 
> Did you see the reply I sent on this thread? There are actually decent
> reasons to rewrite the code into Python, to simplify and speed up the
> new-run-webkit-tests implementation. Given that, do you still object
> to the patch landing (since the work has already been done)?

If there is a practical improvement that is best achieved by rewriting the tool 
in another language, then by all means let's do it. And I would also prefer to 
see fewer different languages used for scripts, since it is hard to be good at 
all of them. (I know Perl a lot better than Python or Ruby, but I would not 
recommend it for new tools.) I do agree with Sam that language rewrites just to 
use a new language are not so great.

I am mildly skeptical that using PrettyPatch as a library is a major 
performance win, since in the common case of running tests there are few 
failures so it should not need to be invoked many times. (If it is invoked even 
for tests that didn't fail, then a much better performance improvement would be 
to not do that.) My skepticism would be 100% cured by a measurement of the 
actual performance improvement.

I also note that the "make new-run-webkit-tests faster" motivation was not 
cited at all in the bug, just a "reduce dependencies" motivation, which doesn't 
seem well-aligned with where we are currently. If this was our only Ruby script 
I might feel differently.

I think for new tools, we should definitely encourage a particular language, 
not just make it a free-for-all. And Python seems like the most plausible 
candidate going forward (Perl is too crufty and Ruby is less popular without 
being clearly better). OTOH it seems like some third-party tools such as 
bugzilla or iexploder will continue to use Perl or Ruby respectively since it 
would be unwise to work them just to change the language.

Regards,
Maciej

> 
> -- Dirk
> 
> On Wed, Sep 1, 2010 at 7:40 PM, Sam Weinig  wrote:
>> Sorry, I seemed to have missed this thread.  Please do not rewrite scripts
>> just to rewrite them in a language you like. WebKit's dependency on Ruby is
>> here to stay. Just because python is common at Google does not make it
>> universal.
>> -Sam
>> 
>> On Wed, Sep 1, 2010 at 4:48 PM, TAMURA, Kent  wrote:
>>> 
>>> Thanks.
>>> So porting PrettyPatch to Python will make good benefit and should have no
>>> drawbacks.  I should go ahead.
>>> 
>>> On Wed, Sep 1, 2010 at 09:21, William Siegrist 
>>> wrote:
 
 On Aug 31, 2010, at 4:43 PM, TAMURA, Kent wrote:
 
>   Can we run python scripts on bugs.webkit.org server?
 
 Yes.
 
 -Bill
 
>>> 
>>> 
>>> 
>>> --
>>> TAMURA Kent
>>> Software Engineer, Google
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>> 
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> 
>> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] Script programming language: Perl, Python, or Ruby?

[Maciej Stachowiak]

On Sep 1, 2010, at 10:46 PM, David Levin wrote:

> From reading this thread and the bug, it sounds like there is one key issue 
> installing something new on build machines.
> 
> As discussed before in regards to python, there was a desire not to go above 
> a certain version so that the tiger build machine could run a script. That 
> seemed reasonable to me.
> 
> Similarly there is a desire in this case to avoid Ruby because it means 
> installing something new on other build machines. This also seems reasonable 
> to me.

Hmm, I thought Ruby was a very longstanding dependency for the layout tests but 
it looks like it was a little over a year ago:

2009-04-24  Eric Seidel  

Reviewed by Adam Roben.

Add PrettyPatch support to run-webkit-tests

* Scripts/run-webkit-tests:

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

Re: [webkit-dev] Script programming language: Perl, Python, or Ruby?

[Ryosuke Niwa]

Oh, I didn't see your second post either.  Sounds like porting everything
into Python would speed up new-run-webkit-tests?  Then I'm all for it.  I
think other folks would be equally convinced as well if you could kindly
measure the time difference between Ruby + Python + shell script
implementation vs Python implementation.

- Ryosuke

On Wed, Sep 1, 2010 at 9:28 PM, Dirk Pranke  wrote:

> Hi Sam,
>
> Did you see the reply I sent on this thread? There are actually decent
> reasons to rewrite the code into Python, to simplify and speed up the
> new-run-webkit-tests implementation. Given that, do you still object
> to the patch landing (since the work has already been done)?
>
> -- Dirk
>
> On Wed, Sep 1, 2010 at 7:40 PM, Sam Weinig  wrote:
> > Sorry, I seemed to have missed this thread.  Please do not rewrite
> scripts
> > just to rewrite them in a language you like. WebKit's dependency on Ruby
> is
> > here to stay. Just because python is common at Google does not make it
> > universal.
> > -Sam
> >
> > On Wed, Sep 1, 2010 at 4:48 PM, TAMURA, Kent  wrote:
> >>
> >> Thanks.
> >> So porting PrettyPatch to Python will make good benefit and should have
> no
> >> drawbacks.  I should go ahead.
> >>
> >> On Wed, Sep 1, 2010 at 09:21, William Siegrist 
> >> wrote:
> >>>
> >>> On Aug 31, 2010, at 4:43 PM, TAMURA, Kent wrote:
> >>>
> >>> >   Can we run python scripts on bugs.webkit.org server?
> >>>
> >>> Yes.
> >>>
> >>> -Bill
> >>>
> >>
> >>
> >>
> >> --
> >> TAMURA Kent
> >> Software Engineer, Google
> >>
> >>
> >>
> >>
> >> ___
> >> webkit-dev mailing list
> >> webkit-dev@lists.webkit.org
> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >>
> >
> >
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Script programming language: Perl, Python, or Ruby?

[Dirk Pranke]

I suspect that Maciej is right and whatever speedup we would see would
be inconsequential. It's still a slightly cleaner design to not have
to shell out to Ruby from Python, jumping from one scripting language
to another. The deadlocking issue is a serious issue, blocking us from
increasing our usage of new-run-webkit-tests, but simply porting
PrettyPatch isn't going to fix it (for the record, I am actively
working on fixing the deadlocking issue).

But until we can put a stake into old-run-webkit-tests, we can't
delete the ruby version anyway (well, I guess we could shell out from
Perl to Python, but that would be only slightly less goofy).

-- Dirk

On Wed, Sep 1, 2010 at 11:30 PM, Ryosuke Niwa  wrote:
> Oh, I didn't see your second post either.  Sounds like porting everything
> into Python would speed up new-run-webkit-tests?  Then I'm all for it.  I
> think other folks would be equally convinced as well if you could kindly
> measure the time difference between Ruby + Python + shell script
> implementation vs Python implementation.
> - Ryosuke
>
> On Wed, Sep 1, 2010 at 9:28 PM, Dirk Pranke  wrote:
>>
>> Hi Sam,
>>
>> Did you see the reply I sent on this thread? There are actually decent
>> reasons to rewrite the code into Python, to simplify and speed up the
>> new-run-webkit-tests implementation. Given that, do you still object
>> to the patch landing (since the work has already been done)?
>>
>> -- Dirk
>>
>> On Wed, Sep 1, 2010 at 7:40 PM, Sam Weinig  wrote:
>> > Sorry, I seemed to have missed this thread.  Please do not rewrite
>> > scripts
>> > just to rewrite them in a language you like. WebKit's dependency on Ruby
>> > is
>> > here to stay. Just because python is common at Google does not make it
>> > universal.
>> > -Sam
>> >
>> > On Wed, Sep 1, 2010 at 4:48 PM, TAMURA, Kent  wrote:
>> >>
>> >> Thanks.
>> >> So porting PrettyPatch to Python will make good benefit and should have
>> >> no
>> >> drawbacks.  I should go ahead.
>> >>
>> >> On Wed, Sep 1, 2010 at 09:21, William Siegrist 
>> >> wrote:
>> >>>
>> >>> On Aug 31, 2010, at 4:43 PM, TAMURA, Kent wrote:
>> >>>
>> >>> >   Can we run python scripts on bugs.webkit.org server?
>> >>>
>> >>> Yes.
>> >>>
>> >>> -Bill
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> TAMURA Kent
>> >> Software Engineer, Google
>> >>
>> >>
>> >>
>> >>
>> >> ___
>> >> webkit-dev mailing list
>> >> webkit-dev@lists.webkit.org
>> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >>
>> >
>> >
>> > ___
>> > webkit-dev mailing list
>> > webkit-dev@lists.webkit.org
>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >
>> >
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev