[webkit-dev] RenderStyleConstants.h - enum naming conventions?
I'm implementing a patch for [1], namely to support the CSS3 line-break
property.
[1] https://bugs.webkit.org/show_bug.cgi?id=89235
There is an older -{khtml,webkit}-line-break enum EKHTMLLineBreak defined
in RenderStyleConstants.h. I see that some enums use a 'E' prefix, while
others do not, e.g.,
enum ELineClampType { LineClampLineCount, LineClampPercentage };
vs
enum LineAlign { LineAlignNone, LineAlignEdges };
plus, there appears to be a different convention for enum member names,
e.g.,
enum EKHTMLLineBreak { LBNORMAL, AFTER_WHITE_SPACE };
Would it be better to have:
enum LineBreak { LineBreakNormal, LineBreakAfterWhiteSpace };
or, with the new keywords from CSS3 Text line-break, write this as:
enum LineBreak { LineBreakAuto, LineBreakLoose, LineBreakNormal,
LineBreakStrict, LineBreakAfterWhiteSpace };
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] RenderStyleConstants.h - enum naming conventions?
E is an old style from KHTML.
We should update our style guide to say more than it does. :)
Enum members should user InterCaps with an initial capital letter.
[names-enum-members]
On Thu, Aug 23, 2012 at 11:53 PM, Glenn Adams gl...@skynav.com wrote:
I'm implementing a patch for [1], namely to support the CSS3 line-break
property.
[1] https://bugs.webkit.org/show_bug.cgi?id=89235
There is an older -{khtml,webkit}-line-break enum EKHTMLLineBreak defined in
RenderStyleConstants.h. I see that some enums use a 'E' prefix, while others
do not, e.g.,
enum ELineClampType { LineClampLineCount, LineClampPercentage };
vs
enum LineAlign { LineAlignNone, LineAlignEdges };
plus, there appears to be a different convention for enum member names,
e.g.,
enum EKHTMLLineBreak { LBNORMAL, AFTER_WHITE_SPACE };
Would it be better to have:
enum LineBreak { LineBreakNormal, LineBreakAfterWhiteSpace };
or, with the new keywords from CSS3 Text line-break, write this as:
enum LineBreak { LineBreakAuto, LineBreakLoose, LineBreakNormal,
LineBreakStrict, LineBreakAfterWhiteSpace };
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] RenderStyleConstants.h - enum naming conventions?
Sorry, I was unclear. I haven't seen someone create a new enum using
E in years. LineBreakType or similar would be better than
ELineBreakType.
On Thu, Aug 23, 2012 at 11:57 PM, Eric Seidel e...@webkit.org wrote:
E is an old style from KHTML.
We should update our style guide to say more than it does. :)
Enum members should user InterCaps with an initial capital letter.
[names-enum-members]
On Thu, Aug 23, 2012 at 11:53 PM, Glenn Adams gl...@skynav.com wrote:
I'm implementing a patch for [1], namely to support the CSS3 line-break
property.
[1] https://bugs.webkit.org/show_bug.cgi?id=89235
There is an older -{khtml,webkit}-line-break enum EKHTMLLineBreak defined in
RenderStyleConstants.h. I see that some enums use a 'E' prefix, while others
do not, e.g.,
enum ELineClampType { LineClampLineCount, LineClampPercentage };
vs
enum LineAlign { LineAlignNone, LineAlignEdges };
plus, there appears to be a different convention for enum member names,
e.g.,
enum EKHTMLLineBreak { LBNORMAL, AFTER_WHITE_SPACE };
Would it be better to have:
enum LineBreak { LineBreakNormal, LineBreakAfterWhiteSpace };
or, with the new keywords from CSS3 Text line-break, write this as:
enum LineBreak { LineBreakAuto, LineBreakLoose, LineBreakNormal,
LineBreakStrict, LineBreakAfterWhiteSpace };
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] RenderStyleConstants.h - enum naming conventions?
On Fri, Aug 24, 2012 at 3:06 PM, Glenn Adams gl...@skynav.com wrote: [or if there is a name conflict on LineBreak, then will use LineBreakType] (whether the suffice 'Type' is included also seems somewhat irregular) s/suffice/suffix/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Subpixel layout - requesting help for big rebaseline
Hi Dirk, On 08/22/2012 10:49 PM, Dirk Pranke wrote: The Chromium canaries now exit after 5000 failures or 1000 crashes/timeouts. Can the failure limit be increased to 1 for example? Levi/Emil were saying the rebaseline touches about 8000 cases. Otherwise we'd have to go through a more complicated process like Zan explains. Dominik ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Subpixel layout - requesting help for big rebaseline
On Fri, Aug 24, 2012 at 4:35 AM, Dominik Röttsches dominik.rottsc...@intel.com wrote: Hi Dirk, On 08/22/2012 10:49 PM, Dirk Pranke wrote: The Chromium canaries now exit after 5000 failures or 1000 crashes/timeouts. Can the failure limit be increased to 1 for example? Levi/Emil were saying the rebaseline touches about 8000 cases. Otherwise we'd have to go through a more complicated process like Zan explains. Despite the testing exiting after a certain number of failures, the newly-registered failures would still be possible to rebaseline. So technically you could do three or four rebaseline cycles and get the bots back into a normal state. Dominik __**_ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/**mailman/listinfo/webkit-devhttp://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Subpixel layout - requesting help for big rebaseline
You can mark the failing tests as failing tests or skip them in TestExpectations/Skipped with the change. And then you can rebase and unskip them without disturbing the bot. Dominik Röttsches írta: Hi Dirk, On 08/22/2012 10:49 PM, Dirk Pranke wrote: The Chromium canaries now exit after 5000 failures or 1000 crashes/timeouts. Can the failure limit be increased to 1 for example? Levi/Emil were saying the rebaseline touches about 8000 cases. Otherwise we'd have to go through a more complicated process like Zan explains. Dominik ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Subpixel layout - requesting help for big rebaseline
On Fri, Aug 24, 2012 at 4:42 AM, Žan Doberšek zandober...@gmail.com wrote: On Fri, Aug 24, 2012 at 4:35 AM, Dominik Röttsches dominik.rottsc...@intel.com wrote: Hi Dirk, On 08/22/2012 10:49 PM, Dirk Pranke wrote: The Chromium canaries now exit after 5000 failures or 1000 crashes/timeouts. Can the failure limit be increased to 1 for example? Levi/Emil were saying the rebaseline touches about 8000 cases. Otherwise we'd have to go through a more complicated process like Zan explains. Despite the testing exiting after a certain number of failures, the newly-registered failures would still be possible to rebaseline. So technically you could do three or four rebaseline cycles and get the bots back into a normal state. Both of these are fine solutions. I don't think we need to do the more complicated approach. As long as the gardener on duty is informed and ready. Again, it's a huge simplification that Emil and Levi have already audited the new results since the gardener can just bulk rebaseline them. Dominik __**_ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/**mailman/listinfo/webkit-devhttp://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] [WK2] WebContext destructor is never triggered on normal exit
Hi, I've found WebContext destructor is never triggered on normal exit in WK2. This happens because only IPC message from WebProcess could terminate it but won't do that in this case. One possibility for doing this is to create a flow of termination from UIProcess on exit. But, before starting investigation, I would like to ask your opinion. kangil ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Initializing String and AtomicString with literals
Dear webkit-dev, Some recent changes improved the way we can use string classes with literals. There are 3 new constructors for initializing a string from a literal: -String(ASCIILIteral): http://trac.webkit.org/browser/trunk/Source/WTF/wtf/text/WTFString.h#L139 -String(const char[], ConstructFromLiteralTag) -AtomicString(const char[], ConstructFromLiteralTag) The differences with the regular char* constructor are: -no memory is allocated for the bytes of the string. -the characters are not copied to the heap -String(const char[], ConstructFromLiteralTag) does not even access the bytes of the string. Those constructors are faster and use less memory in some cases. I converted some of the generated code to use the new constructors. In the future, please consider using ASCIILiteral() whenever constructing a String, and ConstructFromLiteral for a AtomicString. cheers, Benjamin PS: I started a Wiki page about the efficient use of the string classes: http://trac.webkit.org/wiki/EfficientStrings ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Initializing String and AtomicString with literals
Thanks! The wiki page is very helpful. I wonder if we should organize a hack-a-thon to deploy this pattern throughout WebKit. Is there a way the compiler could give us a list of all the code location we should update? Adam On Fri, Aug 24, 2012 at 8:00 PM, Benjamin Poulain benja...@webkit.org wrote: Dear webkit-dev, Some recent changes improved the way we can use string classes with literals. There are 3 new constructors for initializing a string from a literal: -String(ASCIILIteral): http://trac.webkit.org/browser/trunk/Source/WTF/wtf/text/WTFString.h#L139 -String(const char[], ConstructFromLiteralTag) -AtomicString(const char[], ConstructFromLiteralTag) The differences with the regular char* constructor are: -no memory is allocated for the bytes of the string. -the characters are not copied to the heap -String(const char[], ConstructFromLiteralTag) does not even access the bytes of the string. Those constructors are faster and use less memory in some cases. I converted some of the generated code to use the new constructors. In the future, please consider using ASCIILiteral() whenever constructing a String, and ConstructFromLiteral for a AtomicString. cheers, Benjamin PS: I started a Wiki page about the efficient use of the string classes: http://trac.webkit.org/wiki/EfficientStrings ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Initializing String and AtomicString with literals
What's the difference between the ASCIILiteral and ConstructFromLiteral versions? - Maciej On Aug 24, 2012, at 8:00 PM, Benjamin Poulain benja...@webkit.org wrote: Dear webkit-dev, Some recent changes improved the way we can use string classes with literals. There are 3 new constructors for initializing a string from a literal: -String(ASCIILIteral): http://trac.webkit.org/browser/trunk/Source/WTF/wtf/text/WTFString.h#L139 -String(const char[], ConstructFromLiteralTag) -AtomicString(const char[], ConstructFromLiteralTag) The differences with the regular char* constructor are: -no memory is allocated for the bytes of the string. -the characters are not copied to the heap -String(const char[], ConstructFromLiteralTag) does not even access the bytes of the string. Those constructors are faster and use less memory in some cases. I converted some of the generated code to use the new constructors. In the future, please consider using ASCIILiteral() whenever constructing a String, and ConstructFromLiteral for a AtomicString. cheers, Benjamin PS: I started a Wiki page about the efficient use of the string classes: http://trac.webkit.org/wiki/EfficientStrings ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Initializing String and AtomicString with literals
The wiki page says: [[[ The difference between the version is if the length of the string is included or not. Having the size given in the constructor makes the constructor faster. Having the size also makes the code bigger, which is a problem when the code is executed infrequently. ]]] That description isn't 100% clear to me, but my reading of it is that the ConstructFromLiteral version has the length of the string embedded at the call site and therefore makes the code faster by increases the code size. Adam On Fri, Aug 24, 2012 at 10:13 PM, Maciej Stachowiak m...@apple.com wrote: What's the difference between the ASCIILiteral and ConstructFromLiteral versions? - Maciej On Aug 24, 2012, at 8:00 PM, Benjamin Poulain benja...@webkit.org wrote: Dear webkit-dev, Some recent changes improved the way we can use string classes with literals. There are 3 new constructors for initializing a string from a literal: -String(ASCIILIteral): http://trac.webkit.org/browser/trunk/Source/WTF/wtf/text/WTFString.h#L139 -String(const char[], ConstructFromLiteralTag) -AtomicString(const char[], ConstructFromLiteralTag) The differences with the regular char* constructor are: -no memory is allocated for the bytes of the string. -the characters are not copied to the heap -String(const char[], ConstructFromLiteralTag) does not even access the bytes of the string. Those constructors are faster and use less memory in some cases. I converted some of the generated code to use the new constructors. In the future, please consider using ASCIILiteral() whenever constructing a String, and ConstructFromLiteral for a AtomicString. cheers, Benjamin PS: I started a Wiki page about the efficient use of the string classes: http://trac.webkit.org/wiki/EfficientStrings ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
