Re: [webkit-dev] WebCore/platform standalone library

[Alex Christensen]

If PAL were a shared library in a CMake build, then it wouldn’t build 
successfully if there were layering violations.  I think we should do something 
like that to enforce good design, even if the Mac Xcode projects treat it as a 
static library or even just a part of WebCore.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [webkit-reviewers] usage of auto

[Geoffrey Garen]

>> My take-away from this discussion so far is that there is actually very 
>> little consensus on usage of auto, which means there’s probably very little 
>> room for actual style guideline rules.
>> 
>> I think there are two very limited rules that are probably not objectionable 
>> to anybody.
>> 
>> 1 - If you are using auto for a raw pointer type, you should use auto*
>> 2 - If you are using auto in a range-based for loop for values that aren’t 
>> pointers, you should use (const) auto&
> 
> In some cases you need a copy for the code to be correct. I understand why & 
> is often better for performance but there is a significant and dangerous 
> behavioral difference.
> 
> I agree with encouraging people to use auto& because it's usually ok, but I 
> disagree with mandating it because it's sometimes wrong. 

Seems like we could still have a style guideline in favor of these styles.

Style guidelines are always recommendations, which are of course not followed 
if they produce incorrect code. For example, it is S_OK to violate our camel 
case guidelines when interfacing with COM APIs.

I think Darin would also suggest:

1.5 - If you are using auto in a range-based for loop for values that are 
scalars, you should use auto.

Geoff___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [webkit-reviewers] usage of auto

[Geoffrey Garen]

>> e.g. I think this is great:
>> auto ptr = std::make_unique(bar);
>> Proposed rule: if the type is obvious because it's on the line, then auto is 
>> good.
>> Similarly:
>> auto i = static_cast(j);
>> auto foo = make_foo();
>> auto bar = something.get_bar(); // Sometimes, "bar" is obvious.
> I'm not sure I agree with this style. There are times where the type of an 
> auto variable is obvious-enough, but it's almost never more obvious than 
> actually writing out the types.

In the first case, static_cast, the type is written out on the same line. 
Same goes for other casts, make_unique, and so on. Would you accept auto in 
those cases? If not, what benefit do you get from seeing the type twice on one 
line?

I think the second and third cases are somewhat rare in WebKit, and I might 
agree against using auto. For example:

RefPtr thing;
auto* context = something.context();
context->setThing(thing.get()); // I need to research why context->thing is 
allowed to be a raw pointer, but I don’t know what context is.

Geoff___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] usage of auto

[Darin Adler]

We probably need to step away from mandating style for a while until we have 
more consensus.

I’m sad that we are so far away from that right now. I’ve found greatly 
increased use of auto during coding and refactoring that I am doing feels like 
it’s improving clarity quite at bit. From the point of view of project norms 
I’m a little disappointed that so many people see it so dramatically 
differently!

> On Jan 12, 2017, at 9:24 AM, Filip Pizlo  wrote:
> 
>> On Jan 12, 2017, at 08:54, Brady Eidson > > wrote:
>> 
>>> My take-away from this discussion so far is that there is actually very 
>>> little consensus on usage of auto, which means there’s probably very little 
>>> room for actual style guideline rules.
>>> 
>>> I think there are two very limited rules that are probably not 
>>> objectionable to anybody.
>>> 
>>> 1 - If you are using auto for a raw pointer type, you should use auto*
>>> 2 - If you are using auto in a range-based for loop for values that aren’t 
>>> pointers, you should use (const) auto&
> 
> In some cases you need a copy for the code to be correct. I understand why & 
> is often better for performance but there is a significant and dangerous 
> behavioral difference.
> 
> I agree with encouraging people to use auto& because it's usually ok, but I 
> disagree with mandating it because it's sometimes wrong. 


Lets talk about that specific point for a moment. Consider these two cases:

1) Iterating over a collection that is not being modified and operating on the 
objects inside the collection in a straightforward way. This idiom is 
incredibly common. Iterating over an entire collection is a pattern that occurs 
constantly in WebKit code, and we lean more toward the for loop than using 
lambdas for that kind of operation. In these cases, copying the items as we 
iterate is not valuable, often bad for efficiency, and a very easy mistake to 
make because of how auto works. I have fixed at least 20 examples, maybe as 
many as 100, of copying a RefPtr by using a for loop and so churning the 
reference count for no benefit. Using “auto” creates this problem in the first 
place, since it makes the copy of the RefPtr subtle, missed by many 
programmers. And “auto&” is a pretty good solution, I think better than writing 
RefPtr&. To me “auto&” is the way to say “operate on the members of this 
collection in place”, without the distraction of stating anything else about 
the iteration, such as the type of the iterator, for example, which you would 
see if the begin/end was written out without the use of a modern for loop or 
auto. The biggest downside of “auto&” as a solution is that the incorrect 
“auto” and the correct “auto&” are so subtly different that it’s easy to fail 
to spot incorrect code. The future version of C++ where you can do a 
non-copying for loop omitting any mention of the type will be even better, 
because “no type at all” is not easily confusable with the incorrect “auto”. In 
that new feature, the type is “auto&&” where not specified. I look forward to 
when we can use that feature.

2) The occasional for loops where copying each item in the collection is part 
of what we want to do. There are multiple options here. We could name the type 
in the for loop and count on people’s understanding that means copying. Or if 
we want to be more explicit, we could have the for loop use “auto&” and write 
the copying out explicitly as a separate statement. That would also work for 
moving. Less terse than doing the copying as a side effect of how the for loop 
itself is written, but perhaps much clearer because of how explicit it is. 
Since this is a tiny fraction of for loops I haven’t had to consider this style 
question often.

I personally don’t like using auto& when iterating a collection that contains a 
scalar such as an int or bool with a short name. But there is a change using 
auto& when iterating a collection containing a complex type that we want to 
copy might be a good style idea. Maybe even a good enough idea that  we some 
day would want to mandate it!

— Darin___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [webkit-reviewers] usage of auto

[Konstantin Tokarev]

12.01.2017, 19:54, "Brady Eidson" :
> My take-away from this discussion so far is that there is actually very 
> little consensus on usage of auto, which means there’s probably very little 
> room for actual style guideline rules.
>
> I think there are two very limited rules that are probably not objectionable 
> to anybody.
>
> 1 - If you are using auto for a raw pointer type, you should use auto*

This rule seems to be very useful if we can enforce that * is never acidentally 
dropped.

> 2 - If you are using auto in a range-based for loop for values that aren’t 
> pointers, you should use (const) auto&
>
> If there’s no objections to these rules, I think it’s valuable to have them 
> in the style guidelines at the very least.
>
> Thanks,
> ~Brady
>
>> On Jan 11, 2017, at 10:27 PM, saam barati  wrote:
>>
>> On Jan 11, 2017, at 11:15 AM, JF Bastien  wrote:
>>
>>> Would it be helpful to focus on small well-defined cases where auto makes 
>>> sense, and progressively grow that list as we see fit?
>>>
>>> e.g. I think this is great:
 auto ptr = std::make_unique(bar);
>>> Proposed rule: if the type is obvious because it's on the line, then auto 
>>> is good.
>>> Similarly:
 auto i = static_cast(j);
 auto foo = make_foo();
 auto bar = something.get_bar(); // Sometimes, "bar" is obvious.
>> I'm not sure I agree with this style. There are times where the type of an 
>> auto variable is obvious-enough, but it's almost never more obvious than 
>> actually writing out the types. Writing out types, for my brain at least, 
>> almost always makes the code easier to understand. The most obvious place 
>> where I prefer auto over explicit types is when something has a lot of 
>> template bloat.
>>
>> I feel like the places where auto makes the code better are limited, but 
>> places where auto makes the code more confusing, or requires me to spend 
>> more time figuring it out, are widespread. (Again, this is how my brain 
>> reads code.)
>>
>> Also, I completely agree with Geoff that I use types to grep around the 
>> source code and to figure out what data structures are being used. If we 
>> used auto more inside JSC it would hurt my workflow for reading and 
>> understanding new code.
>>
>> - Saam
>>
>>> Range-based loops are a bit tricky. IMO containers with "simple" types are 
>>> good candidates for either:
 for (const auto& v : cont) { /* don't change v */ }
 for auto& v : cont) { /* change v */ }
>>> But what's "simple"? I'd say all numeric, pointer, and string types at 
>>> least. It gets tricky for more complex types, and I'd often rather have the 
>>> type in the loop. Here's more discussion on this, including a 
>>> recommendation to use auto&& on range-based loops! I think this gets 
>>> confusing, and I'm not a huge fan of r-value references everywhere.
>>>
>>> Here's another I like, which Yusuke pointed out a while ago (in ES6 
>>> Module's implementation?):
 struct Foo {
   typedef Something Bar;
   // ...
   Bar doIt();
 };
 auto Foo::doIt() -> Bar
 {
   // ...
 }
>>> Why? Because Bar is scoped to Foo! It looks odd the first time, but I think 
>>> this is idiomatic "modern" C++.
>>>
>>> I also like creating unnamed types, though I know this isn't everyone's 
>>> liking:
 auto ohMy()
 {
   struct { int a; float b; } result;
   // ...
   return result;
 }
 void yeah()
 {
   auto myMy = ohMy();
   dataLogLn(myMy.a, myMy.b);
 }
>>> I initially had that with consumeLoad, which returns a T as well as a 
>>> ConsumeDependency. I couldn't care less about the container for T and 
>>> ConsumeDependency, I just want these two values.
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> ,
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


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

Re: [webkit-dev] [webkit-reviewers] usage of auto

[Filip Pizlo]

> On Jan 12, 2017, at 08:54, Brady Eidson  wrote:
> 
> My take-away from this discussion so far is that there is actually very 
> little consensus on usage of auto, which means there’s probably very little 
> room for actual style guideline rules.
> 
> I think there are two very limited rules that are probably not objectionable 
> to anybody.
> 
> 1 - If you are using auto for a raw pointer type, you should use auto*
> 2 - If you are using auto in a range-based for loop for values that aren’t 
> pointers, you should use (const) auto&

In some cases you need a copy for the code to be correct. I understand why & is 
often better for performance but there is a significant and dangerous 
behavioral difference.

I agree with encouraging people to use auto& because it's usually ok, but I 
disagree with mandating it because it's sometimes wrong. 

-Filip

> 
> If there’s no objections to these rules, I think it’s valuable to have them 
> in the style guidelines at the very least.
> 
> Thanks,
> ~Brady
> 
> 
>> On Jan 11, 2017, at 10:27 PM, saam barati  wrote:
>> 
>> 
>> 
>>> On Jan 11, 2017, at 11:15 AM, JF Bastien  wrote:
>>> 
>>> Would it be helpful to focus on small well-defined cases where auto makes 
>>> sense, and progressively grow that list as we see fit?
>>> 
>>> 
>>> e.g. I think this is great:
>>> auto ptr = std::make_unique(bar);
>>> Proposed rule: if the type is obvious because it's on the line, then auto 
>>> is good.
>>> Similarly:
>>> auto i = static_cast(j);
>>> auto foo = make_foo();
>>> auto bar = something.get_bar(); // Sometimes, "bar" is obvious.
>> I'm not sure I agree with this style. There are times where the type of an 
>> auto variable is obvious-enough, but it's almost never more obvious than 
>> actually writing out the types. Writing out types, for my brain at least, 
>> almost always makes the code easier to understand. The most obvious place 
>> where I prefer auto over explicit types is when something has a lot of 
>> template bloat.
>> 
>> I feel like the places where auto makes the code better are limited, but 
>> places where auto makes the code more confusing, or requires me to spend 
>> more time figuring it out, are widespread. (Again, this is how my brain 
>> reads code.)
>> 
>> Also, I completely agree with Geoff that I use types to grep around the 
>> source code and to figure out what data structures are being used. If we 
>> used auto more inside JSC it would hurt my workflow for reading and 
>> understanding new code.
>> 
>> - Saam
>> 
>>> 
>>> 
>>> Range-based loops are a bit tricky. IMO containers with "simple" types are 
>>> good candidates for either:
>>> for (const auto& v : cont) { /* don't change v */ }
>>> for auto& v : cont) { /* change v */ }
>>> But what's "simple"? I'd say all numeric, pointer, and string types at 
>>> least. It gets tricky for more complex types, and I'd often rather have the 
>>> type in the loop. Here's more discussion on this, including a 
>>> recommendation to use auto&& on range-based loops! I think this gets 
>>> confusing, and I'm not a huge fan of r-value references everywhere.
>>> 
>>> 
>>> Here's another I like, which Yusuke pointed out a while ago (in ES6 
>>> Module's implementation?):
>>> struct Foo {
>>>   typedef Something Bar;
>>>   // ...
>>>   Bar doIt();
>>> };
>>> auto Foo::doIt() -> Bar
>>> {
>>>   // ...
>>> }
>>> Why? Because Bar is scoped to Foo! It looks odd the first time, but I think 
>>> this is idiomatic "modern" C++.
>>> 
>>> 
>>> I also like creating unnamed types, though I know this isn't everyone's 
>>> liking:
>>> auto ohMy()
>>> {
>>>   struct { int a; float b; } result;
>>>   // ...
>>>   return result;
>>> }
>>> void yeah()
>>> {
>>>   auto myMy = ohMy();
>>>   dataLogLn(myMy.a, myMy.b);
>>> }
>>> I initially had that with consumeLoad, which returns a T as well as a 
>>> ConsumeDependency. I couldn't care less about the container for T and 
>>> ConsumeDependency, I just want these two values.
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [webkit-reviewers] usage of auto

[Konstantin Tokarev]

12.01.2017, 19:54, "Brady Eidson" :
> My take-away from this discussion so far is that there is actually very 
> little consensus on usage of auto, which means there’s probably very little 
> room for actual style guideline rules.
>
> I think there are two very limited rules that are probably not objectionable 
> to anybody.
>
> 1 - If you are using auto for a raw pointer type, you should use auto*
> 2 - If you are using auto in a range-based for loop for values that aren’t 
> pointers, you should use (const) auto&
>
> If there’s no objections to these rules, I think it’s valuable to have them 
> in the style guidelines at the very least.

I daresay nobody will object against auto in "cast experessions" as defined in 
[1], i.e. "calls to function templates" where "first template argument is 
explicit and is a type, and the function returns that type, or a pointer or 
reference to it". Examples: standard casts, downcast<>, dynamic_objc_cast<>, 
js(Dynamic)Cast.

Also, it seems like there were no objections against

auto t = std::make_unique(...)

[1] 
http://clang.llvm.org/extra/clang-tidy/checks/modernize-use-auto.html#cast-expressions

>
> Thanks,
> ~Brady
>
>> On Jan 11, 2017, at 10:27 PM, saam barati  wrote:
>>
>> On Jan 11, 2017, at 11:15 AM, JF Bastien  wrote:
>>
>>> Would it be helpful to focus on small well-defined cases where auto makes 
>>> sense, and progressively grow that list as we see fit?
>>>
>>> e.g. I think this is great:
 auto ptr = std::make_unique(bar);
>>> Proposed rule: if the type is obvious because it's on the line, then auto 
>>> is good.
>>> Similarly:
 auto i = static_cast(j);
 auto foo = make_foo();
 auto bar = something.get_bar(); // Sometimes, "bar" is obvious.
>> I'm not sure I agree with this style. There are times where the type of an 
>> auto variable is obvious-enough, but it's almost never more obvious than 
>> actually writing out the types. Writing out types, for my brain at least, 
>> almost always makes the code easier to understand. The most obvious place 
>> where I prefer auto over explicit types is when something has a lot of 
>> template bloat.
>>
>> I feel like the places where auto makes the code better are limited, but 
>> places where auto makes the code more confusing, or requires me to spend 
>> more time figuring it out, are widespread. (Again, this is how my brain 
>> reads code.)
>>
>> Also, I completely agree with Geoff that I use types to grep around the 
>> source code and to figure out what data structures are being used. If we 
>> used auto more inside JSC it would hurt my workflow for reading and 
>> understanding new code.
>>
>> - Saam
>>
>>> Range-based loops are a bit tricky. IMO containers with "simple" types are 
>>> good candidates for either:
 for (const auto& v : cont) { /* don't change v */ }
 for auto& v : cont) { /* change v */ }
>>> But what's "simple"? I'd say all numeric, pointer, and string types at 
>>> least. It gets tricky for more complex types, and I'd often rather have the 
>>> type in the loop. Here's more discussion on this, including a 
>>> recommendation to use auto&& on range-based loops! I think this gets 
>>> confusing, and I'm not a huge fan of r-value references everywhere.
>>>
>>> Here's another I like, which Yusuke pointed out a while ago (in ES6 
>>> Module's implementation?):
 struct Foo {
   typedef Something Bar;
   // ...
   Bar doIt();
 };
 auto Foo::doIt() -> Bar
 {
   // ...
 }
>>> Why? Because Bar is scoped to Foo! It looks odd the first time, but I think 
>>> this is idiomatic "modern" C++.
>>>
>>> I also like creating unnamed types, though I know this isn't everyone's 
>>> liking:
 auto ohMy()
 {
   struct { int a; float b; } result;
   // ...
   return result;
 }
 void yeah()
 {
   auto myMy = ohMy();
   dataLogLn(myMy.a, myMy.b);
 }
>>> I initially had that with consumeLoad, which returns a T as well as a 
>>> ConsumeDependency. I couldn't care less about the container for T and 
>>> ConsumeDependency, I just want these two values.
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> ,
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


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

Re: [webkit-dev] [webkit-reviewers] usage of auto

[Brady Eidson]

My take-away from this discussion so far is that there is actually very little 
consensus on usage of auto, which means there’s probably very little room for 
actual style guideline rules.

I think there are two very limited rules that are probably not objectionable to 
anybody.

1 - If you are using auto for a raw pointer type, you should use auto*
2 - If you are using auto in a range-based for loop for values that aren’t 
pointers, you should use (const) auto&

If there’s no objections to these rules, I think it’s valuable to have them in 
the style guidelines at the very least.

Thanks,
~Brady


> On Jan 11, 2017, at 10:27 PM, saam barati  wrote:
> 
> 
> 
> On Jan 11, 2017, at 11:15 AM, JF Bastien  > wrote:
> 
>> Would it be helpful to focus on small well-defined cases where auto makes 
>> sense, and progressively grow that list as we see fit?
>> 
>> 
>> e.g. I think this is great:
>> auto ptr = std::make_unique(bar);
>> Proposed rule: if the type is obvious because it's on the line, then auto is 
>> good.
>> Similarly:
>> auto i = static_cast(j);
>> auto foo = make_foo();
>> auto bar = something.get_bar(); // Sometimes, "bar" is obvious.
> I'm not sure I agree with this style. There are times where the type of an 
> auto variable is obvious-enough, but it's almost never more obvious than 
> actually writing out the types. Writing out types, for my brain at least, 
> almost always makes the code easier to understand. The most obvious place 
> where I prefer auto over explicit types is when something has a lot of 
> template bloat.
> 
> I feel like the places where auto makes the code better are limited, but 
> places where auto makes the code more confusing, or requires me to spend more 
> time figuring it out, are widespread. (Again, this is how my brain reads 
> code.)
> 
> Also, I completely agree with Geoff that I use types to grep around the 
> source code and to figure out what data structures are being used. If we used 
> auto more inside JSC it would hurt my workflow for reading and understanding 
> new code.
> 
> - Saam
> 
>> 
>> 
>> Range-based loops are a bit tricky. IMO containers with "simple" types are 
>> good candidates for either:
>> for (const auto& v : cont) { /* don't change v */ }
>> for auto& v : cont) { /* change v */ }
>> But what's "simple"? I'd say all numeric, pointer, and string types at 
>> least. It gets tricky for more complex types, and I'd often rather have the 
>> type in the loop. Here's more discussion on this 
>> , 
>> including a recommendation to use auto&& on range-based loops! I think this 
>> gets confusing, and I'm not a huge fan of r-value references everywhere.
>> 
>> 
>> Here's another I like, which Yusuke pointed out a while ago (in ES6 Module's 
>> implementation?):
>> struct Foo {
>>   typedef Something Bar;
>>   // ...
>>   Bar doIt();
>> };
>> auto Foo::doIt() -> Bar
>> {
>>   // ...
>> }
>> Why? Because Bar is scoped to Foo! It looks odd the first time, but I think 
>> this is idiomatic "modern" C++.
>> 
>> 
>> I also like creating unnamed types, though I know this isn't everyone's 
>> liking:
>> auto ohMy()
>> {
>>   struct { int a; float b; } result;
>>   // ...
>>   return result;
>> }
>> void yeah()
>> {
>>   auto myMy = ohMy();
>>   dataLogLn(myMy.a, myMy.b);
>> }
>> I initially had that with consumeLoad 
>> ,
>>  which returns a T as well as a ConsumeDependency. I couldn't care less 
>> about the container for T and ConsumeDependency, I just want these two 
>> values.
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org 
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] [webkit-reviewers] usage of auto

[Xabier Rodríguez Calvar]

Hi,

O Mér, 11-01-2017 ás 11:15 -0800, JF Bastien escribiu:
> e.g. I think this is great:
> auto ptr = std::make_unique(bar);
> Proposed rule: if the type is obvious because it's on the line, then
> auto is good.
> Similarly:
> auto i = static_cast(j);
> auto foo = make_foo();
> auto bar = something.get_bar(); // Sometimes, "bar" is obvious.
> 
> 
> Range-based loops are a bit tricky. IMO containers with "simple"
> types are good candidates for either:
> for (const auto& v : cont) { /* don't change v */ }
> for auto& v : cont) { /* change v */ }
> But what's "simple"? I'd say all numeric, pointer, and string types
> at least. It gets tricky for more complex types, and I'd often rather
> have the type in the loop. Here's more discussion on this, including
> a recommendation to use auto&& on range-based loops! I think this
> gets confusing, and I'm not a huge fan of r-value references
> everywhere.

I'm ok with a rule similar to this one.

Br.

-- 
Xabier Rodríguez Calvar
Software Engineer
IGALIA http://www.igalia.com

signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev