[webkit-dev] YARR example
Hello! I need info how to use YARR to replace all matches of a given regular expression in a string with another string. For example in Java this is achieved by String.replaceAll method. I will appreciate if someone leads me to the solution, thanks! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] YARR example
Ognian, YARR is the regular expression engine for the JavaScriptCore part of webkit. It can find the matches, but you would need to write other C++ code to do the replacement. The String.replace() method will do what you want in JavaScript. - Michael On Jan 3, 2013, at 4:16 AM, Ognian Milanov ogi.andr...@gmail.com wrote: Hello! I need info how to use YARR to replace all matches of a given regular expression in a string with another string. For example in Java this is achieved by String.replaceAll method. I will appreciate if someone leads me to the solution, thanks! ___ 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] Int/FloatPoint and Int/FloatSize
Personally I like the idea of removing the subtraction operator (point minus point returns size) and make it explicit. *** However ***, if we change the data type of objects from Size to Point, we have to be careful to check whether they are ever mapped by transforms. In particular, Points use a homogeneous coordinate of w=1, while Size (and conceptual vectors) use homogeneous coordinates of w=0. Some more thinking out loud - Pros of making a separate vector class: - avoids the mismatch in Size or Point APIs - avoids the mismatch in homogeneous coordinate w usage - would allow us more compile-time safety in usage of math objects, i.e. doing an operation that doesn't make sense could cause a type-mismatch error. Cons of making a separate vector class: - offsets are sometimes treated as relative point locations, and other times treated as vectors that can be added to points. Deciding when to use which one could become just as confusing as using Point vs Size is right now. On Thu, Jan 3, 2013 at 10:00 AM, Levi Weintraub le...@google.com wrote: Hi Steve, When converting the old tx/ty paint offsets to use IntPoint and IntSize (later LayoutPoint/Size) we had some discussion around this. Darin Adler wrote some good advice here: https://bugs.webkit.org/show_bug.cgi?id=61562#c2 -- quoting: It’s hard to tell points and sizes apart when we have nested coordinate systems. The distance from the top left to a rect is a “size”, yet it’s expressed as an origin point. I think that whenever we can’t decide, we should use IntPoint, and we should use IntSize only when it’s clearly the size of something, not just a distance (a point described relative to another point). Cheers, -Levi On Wed, Jan 2, 2013 at 11:21 PM, Steve Block stevebl...@chromium.orgwrote: Hi webkit, I was hoping that somebody could clarify the policy regarding the correct use of Int/FloatPoint vs Int/FloatSize. It seems that xxxPoint is consistently used to represent a position, which makes sense. However, when representing the position of one point relative to another, both xxxPoint and xxxSize are used, which seems inconsistent. I'd expect that xxxPoint should be used for this case of a relative position, since its x(), y() and length() methods make more sense than the width() and height() methods of xxxSize. However, the operators [1] for subtracting one xxxPoint from another encourage the use of xxxSize. I recognize that in some situations, you need really do want to represent the difference between two points as an area or size, but this seems the less common case, and it might be better to make it more explicit [2]. My questions are ... - What (if any) is the correct policy? - Would people welcome changes to encourage that policy? Thanks, Steve [1] eg 'inline FloatSize operator-(const FloatPoint, const FloatPoint)' [2] Perhaps something like 'static FloatSize FloatSize::fromCornerPoints(const FloatPoint, const FloatPoint)'. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Int/FloatPoint and Int/FloatSize
On Thu, Jan 3, 2013 at 11:36 AM, Shawn Singh shawnsi...@chromium.orgwrote: Cons of making a separate vector class: - offsets are sometimes treated as relative point locations, and other times treated as vectors that can be added to points. Deciding when to use which one could become just as confusing as using Point vs Size is right now. Yeah, this is a real danger. It's sort of mitigated if you have no way to add/subtract two points, only a point and a vector, because that kind of forces you to always use your vector class for offsets, otherwise you can't do much with them. However, you do still end up needing things like PointAtOffsetFromOrigin(const vector) that basically just convert a vector directly to a point, so there is still the possibility for confusion. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Int/FloatPoint and Int/FloatSize
On Thu, Jan 3, 2013 at 3:14 PM, Peter Kasting pkast...@google.com wrote: On Thu, Jan 3, 2013 at 11:36 AM, Shawn Singh shawnsi...@chromium.orgwrote: Cons of making a separate vector class: - offsets are sometimes treated as relative point locations, and other times treated as vectors that can be added to points. Deciding when to use which one could become just as confusing as using Point vs Size is right now. Yeah, this is a real danger. It's sort of mitigated if you have no way to add/subtract two points, only a point and a vector, because that kind of forces you to always use your vector class for offsets, otherwise you can't do much with them. However, you do still end up needing things like PointAtOffsetFromOrigin(const vector) that basically just convert a vector directly to a point, so there is still the possibility for confusion. PK The homogenous coordinate issue is the primary reason why it matters whether you are using (x,y) to represent a point or a direction. We seem to be begging for bugs by failing to clearly distinguish between the two cases. Not everyone learns this stuff, so here the summary. Say you have a transformation T(..) that transforms points, and it's using homogeneous coordinates. It is desirable to have T(a-b) == T(a) - T(b). To do so requires storing a-b, which is really a direction or offset, with a zero homogeneous coordinate. I would support adding offset and enforcing the mathematical definitions through parameter and return types, which is basically what Peter is suggesting. I think it makes the code much more self-documenting and will reduce the chance of bugs. Cheers, Stephen.Stephen Chenney | Software Engineer | schen...@google.com | 404-314-1809 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Add webkitFillRule to canvas
On Wed, 2 Jan 2013, James Ascroft-Leigh wrote: There has been a proposal that a new property is added to the canvas 2D drawing context called fillRule with values nonzero (default) and evenodd. This is compatible with the mozFillRule already implemented in Mozilla Firefox and would be on track to become a web standard. If you are interested in knowing more I suggest you start with the bug I raised and take a look at the patch. https://bugs.webkit.org/show_bug.cgi?id=105508 This is now in the spec. http://whatwg.org/html/#dom-context-2d-fillrule -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Int/FloatPoint and Int/FloatSize
Thanks all for the detailed replies. I wasn't aware of the distinction made between points and vectors for the purposes transforms. However, if I understand things correctly, introducing a vector type could be considered separately from the issue I initially raised. It seems that everyone is agreed that xxxSize should be used only when you really want to represent a size. A good first step would be trying to enforce this, such that all points and vectors are represented with xxxPoint. As Shawn points out, when doing this, we need to make sure that we continue to use the correct homogeneous coordinate for transforms. Removing the existing subtraction operator (xxxPoint minus xxxPoint returns xxxSize) might be a good place to start. Introducing the concept of a vector could then be done in a second phase. WDYT? Steve ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Int/FloatPoint and Int/FloatSize
On Jan 3, 2013, at 7:43 PM, Steve Block wrote: Thanks all for the detailed replies. I wasn't aware of the distinction made between points and vectors for the purposes transforms. However, if I understand things correctly, introducing a vector type could be considered separately from the issue I initially raised. It seems that everyone is agreed that xxxSize should be used only when you really want to represent a size. A good first step would be trying to enforce this, such that all points and vectors are represented with xxxPoint. As Shawn points out, when doing this, we need to make sure that we continue to use the correct homogeneous coordinate for transforms. Removing the existing subtraction operator (xxxPoint minus xxxPoint returns xxxSize) might be a good place to start. I find point - point = size quite useful in general, and it seems to make logical sense. Introducing the concept of a vector could then be done in a second phase. What would you call this type, avoiding confusion with Vector? Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Int/FloatPoint and Int/FloatSize
On 4 January 2013 16:15, Simon Fraser simon.fra...@apple.com wrote: Introducing the concept of a vector could then be done in a second phase. What would you call this type, avoiding confusion with Vector? Rename that to DynamicallyResizableRandomlyAccessibleT, because, you know, Euclid got there first :P ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Int/FloatPoint and Int/FloatSize
I find point - point = size quite useful in general, and it seems to make logical sense. I agree that it makes logical sense, but I think that 'point - point = point' also makes sense, and is perhaps more frequently the right choice. What would you call this type, avoiding confusion with Vector? I guess 'Offset' is an obvious candidate, but that is probably already too overloaded. Perhaps RelativePosition or RelativePoint? On 4 January 2013 16:15, Simon Fraser simon.fra...@apple.com wrote: On Jan 3, 2013, at 7:43 PM, Steve Block wrote: Thanks all for the detailed replies. I wasn't aware of the distinction made between points and vectors for the purposes transforms. However, if I understand things correctly, introducing a vector type could be considered separately from the issue I initially raised. It seems that everyone is agreed that xxxSize should be used only when you really want to represent a size. A good first step would be trying to enforce this, such that all points and vectors are represented with xxxPoint. As Shawn points out, when doing this, we need to make sure that we continue to use the correct homogeneous coordinate for transforms. Removing the existing subtraction operator (xxxPoint minus xxxPoint returns xxxSize) might be a good place to start. I find point - point = size quite useful in general, and it seems to make logical sense. Introducing the concept of a vector could then be done in a second phase. What would you call this type, avoiding confusion with Vector? Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
