Re: [webkit-dev] Problems to build WebKit on Windows
Thanks a lot. It solve my problem. Regards, Diego On Tue, Aug 31, 2010 at 6:24 PM, Chris Hatko cha...@gmail.com 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 diego.gonza...@openbossa.org wrote: Hi, Thanks for the feedback! On Tue, Aug 31, 2010 at 12:01 PM, Ilya Tikhonovsky loi...@chromium.org 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: 11Compiling resources... 11Performing Pre-Link Event... 111 file(s) copied. 111 file(s) copied. 11Linking... 11fatal error C1083: Cannot open compiler intermediate file: 'C:\cygwin\home\rodribel\webkit\WebKitBuild\lib\WebKitLib.lib': Not enough space 11LINK : 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 diego.gonza...@openbossa.org 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
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
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
2010/9/1 Alexey Proskuryakov a...@webkit.org: 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?
On Aug 31, 2010, at 6:59 PM, Kenneth Russell wrote: On Tue, Aug 31, 2010 at 6:42 PM, Maciej Stachowiak m...@apple.com 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?
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] Color Management
On Sep 1, 2010, at 9:52 AM, Igor Trindade Oliveira wrote: 2010/9/1 Alexey Proskuryakov a...@webkit.org: 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?
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
[webkit-dev] Arena is crufty?
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] Arena is crufty?
On Wed, Sep 1, 2010 at 4:20 PM, Chris Marrin cmar...@apple.com 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?
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] Script programming language: Perl, Python, or Ruby?
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 wsiegr...@apple.com 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?
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?
On Wed, Sep 1, 2010 at 5:08 PM, Chris Marrin cmar...@apple.com 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?
On Sep 1, 2010, at 5:12 PM, Kenneth Russell wrote: On Wed, Sep 1, 2010 at 5:08 PM, Chris Marrin cmar...@apple.com 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?
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?
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?
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?
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?
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 hy...@apple.com 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?
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 tk...@chromium.org 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 wsiegr...@apple.comwrote: 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?
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 sam.wei...@gmail.com 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 tk...@chromium.org 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 wsiegr...@apple.com 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?
Hi, On Tue, Aug 31, 2010 at 7:56 AM, TAMURA, Kent tk...@chromium.org 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?
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 sam.wei...@gmail.com 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 tk...@chromium.org 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 wsiegr...@apple.com 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?
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
