[webkit-dev] Alicia Boya as new reviewer

2021-03-11 Thread Xabier Rodríguez Calvar via webkit-dev
Hi,

It's my pleasure to announce that my colleague Alicia Boya has earned
the reviewer status. I'm sure she will be a wonderful reviewer.

Well done Alicia! ️

Best regards.


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


Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

2017-09-04 Thread Xabier Rodríguez Calvar
Hi,

O Lun, 04-09-2017 ás 10:13 +0200, Xabier Rodríguez Calvar escribiu:
> I have another one. You can deploy IceCC distributed compilation and
> CCache. This will work only for people in offices as they those are
> the
> ones who can share the build time. If any of you comes from Cupertino
> to the Web Engines Hackfest, we can help with the set up here as we
> use
> it (at least me and some other folks at Igalia HQ) extensively.

Just to give you some more context, I just did a clean build of WPE
after having done one of WebKitGTK+ (which explains the preprocessed
cached of 5%) and the numbers are:

 Time: 19m:02s.
 CCache stats:
13 direct hits (0%), 264 preprocessed hits (5%),
5047 misses (95%), 5324 total.

This was a clean build without changing anything in the code:

 Time: 04m:16s.
 CCache stats:
5269 direct hits (99%), 55 preprocessed hits (1%),
0 misses (0%), 5324 total.

I can tell you that more than 50% for those four minutes were devoted
to CMake configuration and IDL generation. CCache + CMake + Ninja =
profit! and if you add IceCC to the equation for non cached builds in
an office environment, even better.

Best regards.

PS: I had even wrote a patch for build-webkit to show CCache stats if
present long time ago but it was rejected so I wrap my builds with a
run.pl script doing that.


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


Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

2017-09-04 Thread Xabier Rodríguez Calvar
Hi,

Gosh, I go on vacation for a week and I find this "controversial"
thread about builds and another even more controversial about RefPtr
:))

Generally speaking, I have the not formed impression that this will
unleash hell and fire and will affect code readability.

O Lun, 28-08-2017 ás 22:10 -0500, Michael Catanzaro escribiu:
> What, with CMake? That's true of the make backend, but definitely
> not 
> the ninja backend. You should pass -GNinja to get the ninja
> generator. 
> I thought the build-webkit script already did this by default.

> Some alternative strawman proposals:

I have another one. You can deploy IceCC distributed compilation and
CCache. This will work only for people in offices as they those are the
ones who can share the build time. If any of you comes from Cupertino
to the Web Engines Hackfest, we can help with the set up here as we use
it (at least me and some other folks at Igalia HQ) extensively.

And answering Chris about incremental builds, yes, depending on how the
bundling is done (dinamically or staticly per build session) it can
give make incremental builds much slower.

Best regards.

-- 
Xabier Rodríguez Calvar
Software Engineer
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


Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

2017-09-04 Thread Xabier Rodríguez Calvar
Hi,

O Mar, 29-08-2017 ás 12:27 -0700, Sam Weinig escribiu:
> This isn’t the scenario I find myself in most often.  A much more
> common scenario is working on a change; touch one or two files, and
> then compile and test/debug.  Rinse and repeat.

When I have to change tasks, sometimes I do a clean build which takes
more or less a couple of minutes if you use CCache (and have everything
cached already which will be true most of the times during regular
work).

Best regards.

-- 
Xabier Rodríguez Calvar
Software Engineer
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


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

2017-01-12 Thread 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


Re: [webkit-dev] Joanmarie Diggs is now a WebKit reviewer

2016-03-29 Thread Xabier Rodríguez Calvar
Hi,

O Lun, 28-03-2016 ás 10:38 -0700, Mark Lam escribiu:
> Just want to announce that Joanmarie Diggs is now a reviewer.
>  Joanmarie primarily works on GTK accessibility and is a current
> editor of the ARIA spec (https://www.w3.org/TR/wai-aria-1.1/).

Awesome!


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


[webkit-dev] Protect promise capabilities from being vended again

2015-11-12 Thread Xabier Rodríguez Calvar
Hello,

When you create a promise capability, there's nothing preventing you
from calling again @resolve and @reject on the capability to vend the
promise twice. In the case of the Streams implementation to create
capabilities are are already vended, we do it as { @promise: @Promise.@
resolve } or @reject and those capability objects don't have the
@resolve and @reject slots so calling them would obviously fail.

Vending a promise twice means probably an issue in the algorithm that
you are implementing and if it were properly designed that shouldn't
happen. Software and specs can have bugs though and we could end up
hitting those unexpected cases.

For that I think we could change the internal promise capabilities to
use the newly added @assert when they are vended twice and also add two
functions to create those vended capabilities in a single call.

Any comments?

-- 
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


Re: [webkit-dev] Youenn Fablet is now a WebKit reviewer

2015-10-27 Thread Xabier Rodríguez Calvar
Hi,

O Lun, 26-10-2015 ás 19:15 -0700, Mark Lam escribiu:
> Youenn, congratulations.

Definitely, congratulations!


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


[webkit-dev] Adding generated files to the Mac build

2015-07-30 Thread Xabier Rodríguez Calvar
Hi,

Maybe it is something very stupid that I am missing, but I added a new
IDL file, I added the object cpp and h files to the WebCore target, the
idl file to the corresponding list, etc, but when I build I get linking
errors caused by the non compilation of the generated JSxxxfile.cpp.
How do I add that? Do I have to really do it by hand?

Thanks for the help advance!

PS: Please, please, please, Alex, finish the migration to CMake :)


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


Re: [webkit-dev] Invocation with undefined this on JS binding object

2015-07-02 Thread Xabier Rodríguez Calvar
O Mér, 01-07-2015 ás 18:48 +, youenn fablet escribiu:
 One way may be to make 'size' an attribute, cachable and returning a 
 JSFunction wrapping a C++ function returning 1. Not sure this will 
 pass signature tests though.

I was thinking of trying this, yes.

 IIUC, 'size' is somehow similar to a C++ static class method. A third
 approach could be to add a 'static' IDL keyword to the binding 
 generator to enable calling static methods of the DOM class. No 
 custom code in that case.

I thought of this too. I will probably go to the first case and then
using that as a use case to extend the bindings with a
[StaticNonObjectMethod] idl attribute.

Br.

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


Re: [webkit-dev] Invocation with undefined this on JS binding object

2015-07-02 Thread Xabier Rodríguez Calvar
Hi,

O Mér, 01-07-2015 ás 11:07 -0700, Geoffrey Garen escribiu:
 What exactly did you do when you tried that, and why exactly didn’t
 it work?

What I tried was running the tests, concretely streams/reference
-implementation/count-queuing-strategy.html and subtest Correctly
governs the return value of a ReadableStream\'s enqueue function (HWM =
0) which causes enqueue to be called and therefore the
readableStream@strategySize function to be run with undefined this,
that was previously assigned from the size method of a newly created
CountQueuingStrategy.

 Side note: Shouldn’t this function bear the name “strategySize” 
 rather than “size”?

No, the spec says that our internal slot at ReadableStream should be
called strategySize [1], but it clearly states that the method at
CountQueuingStrategy should be called size [2]. Besides this, the
reference implementation tests also operate on this assumption.

[1] https://streams.spec.whatwg.org/#rs-internal-slots
[2] https://streams.spec.whatwg.org/#cqs-class-definition

Thanks and best regards.


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


[webkit-dev] Invocation with undefined this on JS binding object

2015-07-01 Thread Xabier Rodríguez Calvar
Hello,

I need some help with some JS bindings code. I am implementing
CountQueuingStrategy [1], which is an object containing two properties,
one of them a function. That strategy is passed to another
ReadableStream object [2] and as you can see at step 8, the size method
is extracted from the strategy and kept inside the stream for later
use. That use happens at [3], step 5.b.i, when the spec says that we
have to pass undefined as this (and we do).

[1] https://streams.spec.whatwg.org/#cqs-class
[2] https://streams.spec.whatwg.org/#rs-constructor
[3] https://streams.spec.whatwg.org/#enqueue-in-readable-stream

The problem comes when invoking that method at the generated bindings:

EncodedJSValue JSC_HOST_CALL
jsCountQueuingStrategyPrototypeFunctionSize(ExecState* exec)
{
JSValue thisValue = exec-thisValue();
JSCountQueuingStrategy* castedThis =
jsDynamicCastJSCountQueuingStrategy*(thisValue);
if (UNLIKELY(!castedThis))
return throwThisTypeError(*exec, CountQueuingStrategy,
size);
ASSERT_GC_OBJECT_INHERITS(castedThis,
JSCountQueuingStrategy::info());
return JSValue::encode(castedThis-size(exec));
}

The problem is that it checks that this casts to the class and of
course it fails because the spec says it has to be undefined. I haven't
found any way to overcome this, even making the method custom.

Any ideas here?

Thanks in advance and best regards.


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


Re: [webkit-dev] Running new/modified tests on EWS bots

2015-03-19 Thread Xabier Rodríguez Calvar
O Xov, 19-03-2015 ás 16:46 +0100, youenn fablet escribiu:
 Related to the webkit contributor meeting discussion related to ports,
 I would find it useful if EWS bots (gtk, efl, win, ios) were running
 the tests that are modified/created by a patch.
 
 The idea would be to turn yellow the port bubble whenever one of these
 tests do not pass. Results would be uploaded to bugzilla.

AFAIK, the only EWS bots running all tests are the Mac ones. It is ok to
have EWS running the at least the affected tests and I guess that
shouldn't take that much computation power (maybe some development to
know which tests need to be run). What would be really nice is having
all tests run, but for that I guess tests bots need to be green, which
is a pace very difficult to maintain for smaller ports.

Br.



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


[webkit-dev] Problem with a crash using JSC code

2015-01-21 Thread Xabier Rodríguez Calvar
Hi!

I am now implementing with Youenn the Streams API standard [1] in
WebKit. You can find the first patch at [2] (it's r? now). While we get
that patch reviewed and landed we are adding more tests and working out
the problems. One of them is one crash that I cannot hunt, with the
following backtrace:

http://fpaste.org/172619/60635142/

You can find the code under the lines to make it easier. What is going
on is:

 1. There's a call to the ReadableStream object, delegated to the
JSReadableStreamSource as a result of the object creation.
 2. There's a call to the JSReadableStream::read method, delegating
in the ReadableStream that ends up pulling again and that second
call crashes.

It is probably something stupid I am not taking into account, but I have
already been fighting this for a couple of days and cannot make it work
properly.

Any help? Thanks a lot in advance!

[1] https://streams.spec.whatwg.org/
[2] https://bugs.webkit.org/show_bug.cgi?id=138967



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


Re: [webkit-dev] Streams API

2014-11-04 Thread Xabier Rodríguez Calvar
O Lun, 03-11-2014 ás 10:08 +0100, youenn fablet escribiu:
 Hi Benjamin,
 
  I have two concerns:
  1) You have many patches waiting for review. I think you need to get better
  communication channels with reviewers in order to iterate over your patches
  faster. It is unfortunate but getting complex patches reviewed in WebKit
  requires poking reviewers directly. Since you work on the network stack, I
  suggest asking Alexey (ap) and Pratik (psolanki) on IRC, they can help with
  reviews or suggest other reviewers.
 
 Thanks for the suggestion, I will try to do so for my pending patches.
 For the particular streams API work, I am teaming up with some Igalia fellows.
 I hope that we can make good progress that way.

Yes, I will be working with Youenn on making this happen. I guess the
action will begin soon.

Best regards.




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


Re: [webkit-dev] Proposal: Remove ENABLE(SVG)

2014-02-05 Thread Xabier Rodríguez Calvar
O Mar, 04-02-2014 ás 13:11 +0100, Osztrogonác Csaba escribiu:
 I've checked the full clean build time of GTK port on a quad core 
 i5-2320 (3GHz) machine with icecc buildfarm and -j30 makeflag:
 - with SVG disabled:WebKit is now built (11m:58s).
 - with SVG enabled: WebKit is now built (13m:38s).

I remember the difference being bigger, in the order of several minutes.
Do you use ccache? That could explain that small difference even with
clean builds.

Br.



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


Re: [webkit-dev] Proposal: Remove ENABLE(SVG)

2014-02-03 Thread Xabier Rodríguez Calvar

Sorry for the late answer, but I was in Brussels at FOSDEM.

O Ven, 31-01-2014 ás 14:01 +0100, Alberto Garcia escribiu:
 Not in the GTK+ port at least, I've been able to do builds without
 SVG perfectly fine, so there's probably something else wrong in your
 environment or the port you're using.
 
 Anyway, I'm also fine with removing it.

It saves some times in our builds and I always use it unless I have to
do something with SVG.

I would keep it unless it doesn't pay off the effort of maintaining it.

Br.



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