Re: [webkit-dev] Caio Lima is now a WebKit reviewer

[Caio Lima via webkit-dev]

Thanks a lot!

Em qui., 18 de mar. de 2021 às 20:31, Shu-yu Guo via webkit-dev
 escreveu:
>
> Congrats from V8 and a fellow TC39 delegate!
>
> On Thu, Mar 18, 2021 at 4:18 PM Yusuke Suzuki via webkit-dev 
>  wrote:
>>
>> Congrats!
>>
>> -Yusuke
>>
>> > On Mar 18, 2021, at 3:42 PM, Saam Barati via webkit-dev 
>> >  wrote:
>> >
>> > Hi folks,
>> >
>> > I'm happy to announce that Caio Lima is now a WebKit reviewer. Send your 
>> > JavaScriptCore reviews his way!
>> >
>> > Congrats, Caio.
>> >
>> > - Saam
>> > ___
>> > 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] Adrian Perez de Castro is now a WebKit reviewer

[Caio Lima]

Congratulations Adrian!

Em seg, 14 de out de 2019 às 15:17, Carlos Alberto Lopez Perez <
clo...@igalia.com> escreveu:

> Hi everyone,
>
> I would like to announce that Adrian Perez de Castro (aperezdc on #webkit)
> is now a WebKit reviewer.
>
> Adrian has several years of experience working with the WebKitGTK and WPE
> WebKit ports. He is the release manager of the WPE port and the main
> developer
> behind the Cog WPE browser.
>
>
> Please join me in congratulating Adrian, and send him some patches to
> review.
>
>
> Adrian, congratulations.
>
>
> Cheers!
>
> ___
> 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] JSC EWS being too optimistic

[Caio Lima]

Hi Aakash.

Thank you very much for this fix!

BR,
Caio.

Em qua, 9 de out de 2019 às 12:35, Aakash Jain  escreveu:
>
> Hi Caio,
>
> Thanks for reporting this issue.
>
> Jonathan fixed the bug you reported 
> (https://bugs.webkit.org/show_bug.cgi?id=202419). It was a regression from a 
> recent change.
>
> I verified the fix using the same patch you tested with earlier. jsc EWS is 
> now (correctly) failing on that patch 
> (https://bugs.webkit.org/show_bug.cgi?id=202140). Please let me know if you 
> notice any issue.
>
> Thanks
> Aakash
>
> On Oct 3, 2019, at 10:14 AM, Caio Lima  wrote:
>
> Hi all.
>
> I've noticed that JSC bots (jsc, jsc-armv7, jsc-mips, jsc-386) are
> marking every patch as success, even if there is a build failure (see
> https://bug-202140-attachments.webkit.org/attachment.cgi?id=379917 for
> https://bugs.webkit.org/show_bug.cgi?id=202140). Is it already in
> someone's radar?If not, could anybody take a look on this? I tried to
> investigate, but I'm lacking knowledge of EWS code base. This already
> caused some noise into JSC patches that broke ARMv7 and MIPS ports. I
> opened this bug to report it
> https://bugs.webkit.org/show_bug.cgi?id=202419.
>
> Thanks in advance,
> Caio Lima.
> ___
> 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] JSC EWS being too optimistic

[Caio Lima]

Hi all.

I've noticed that JSC bots (jsc, jsc-armv7, jsc-mips, jsc-386) are
marking every patch as success, even if there is a build failure (see
https://bug-202140-attachments.webkit.org/attachment.cgi?id=379917 for
https://bugs.webkit.org/show_bug.cgi?id=202140). Is it already in
someone's radar?If not, could anybody take a look on this? I tried to
investigate, but I'm lacking knowledge of EWS code base. This already
caused some noise into JSC patches that broke ARMv7 and MIPS ports. I
opened this bug to report it
https://bugs.webkit.org/show_bug.cgi?id=202419.

Thanks in advance,
Caio Lima.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Work on new JS language features

[Caio Lima]

Up on this thread.

Em seg, 1 de jul de 2019 às 13:19, Caio Lima  escreveu:
>
> Hi WebKittens,
>
> As some of you may know, my colleagues from Igalia have been working
> to implement new {Java|ECMA}Script language features in
> JavaScriptCore, including BigInt and Class Fields.
>
> We have a number of Class Fields patches awaiting review:
>
> - Instance Class Fields (https://bugs.webkit.org/show_bug.cgi?id=174212)
>   - Private Methods (https://bugs.webkit.org/show_bug.cgi?id=194434)
> - Private Accessors (https://bugs.webkit.org/show_bug.cgi?id=194435)
>   - Static Class Fields (https://bugs.webkit.org/show_bug.cgi?id=194095)
>
> And one BigInt patch:
> - BigInt operator "<<" in DFG
> (https://bugs.webkit.org/show_bug.cgi?id=192664)
>
> BR,
> Caio.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Work on new JS language features

[Caio Lima]

Hi WebKittens,

As some of you may know, my colleagues from Igalia have been working
to implement new {Java|ECMA}Script language features in
JavaScriptCore, including BigInt and Class Fields.

We have a number of Class Fields patches awaiting review:

- Instance Class Fields (https://bugs.webkit.org/show_bug.cgi?id=174212)
  - Private Methods (https://bugs.webkit.org/show_bug.cgi?id=194434)
- Private Accessors (https://bugs.webkit.org/show_bug.cgi?id=194435)
  - Static Class Fields (https://bugs.webkit.org/show_bug.cgi?id=194095)

And one BigInt patch:
- BigInt operator "<<" in DFG
(https://bugs.webkit.org/show_bug.cgi?id=192664)

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

Re: [webkit-dev] Tadeu and Robin are now WebKit reviewers

[Caio Lima]

Congratulations!

Em ter, 11 de jun de 2019 às 05:13, Filip Pizlo  escreveu:

> Congrats!
>
> -Filip
>
> > On Jun 10, 2019, at 6:10 PM, Yusuke Suzuki  wrote:
> >
> > Congrats! :D
> >
> >> On Jun 10, 2019, at 3:49 PM, Saam Barati  wrote:
> >>
> >> Hi folks,
> >>
> >> Tadeu and Robin are both now WebKit reviewers. Join me in
> congratulating them. Please ask them to review your code! They both have a
> focus in JSC.
> >>
> >> - Saam
> >> ___
> >> 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] Don Olmstead and Ross Kirsling are now WebKit reviewers

[Caio Lima]

Congratulations!

Em qui, 13 de dez de 2018 às 20:08, Brian Burg  escreveu:

> Congrats everyone!
>
>
> On Dec 13, 2018, at 1:46 PM, Fujii Hironori 
> wrote:
>
> Hi everyone,
>
> I would like to announce that Don Olmstead (dolmstead on #webkit) and
> Ross Kirsling (rkirsling) are now WebKit reviewers. They have worked
> on WinCairo port and PlayStation port, and Ross worked on Web
> Inspector Layers Tab, too.
>
> Please join me in congratulating Don and Ross, and send them patches
> to review.
>
> Don and Ross, congratulations. 
>
> - Fujii Hironori, Sony Interactive Entertainment Inc.
>
> ___
> 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] BigIntBench

[Caio Lima]

Hi Saam.
Em seg, 8 de out de 2018 às 02:41, Saam Barati  escreveu:
>
> Hi Caio,
>
> > On Oct 6, 2018, at 7:30 AM, Caio Lima  wrote:
> >
> > Hi all.
> >
> > I'm starting working to fix JIT support of BigInt in some operations
> > we already have upstream. In such case, I'm sending
> > (https://bugs.webkit.org/show_bug.cgi?id=186177) to support BigInt
> > speculation into ValueAdd node. As I want to know if BigInt
> > speculation represents some performance improvement, I'm also
> > proposing a new benchmark suite called BigIntBench. The idea right now
> > is to enable us to write microbenchmarks while working into JIT fixes.
> > The main reason behind that is due the practicality of enabling
> > "--useBigInt=true" flags for tests in this suite. The big plan is to
> > move all microbenchmarks to "JSTests/microbenchmarks" and then add
> > relevant tests to evaluate how fast JSC can manipulate BigInts. IIRC,
> > Robin Morisset mentioned about introducing some benchmarks to evaluate
> > BigInt implementation sometime ago.
> >
> > What do you think about that? Does it make sense?
> I think it makes a lot of sense to start using benchmarks to drive 
> performance improvements in our BigInt implementation.
>
> It's probably good to use both microbenchmarks and macro benchmarks to do 
> this. I definitely agree it's worth writing microbenchmarks to show that 
> changes are good for perf. But it's probably worth converting some 
> preexisting benchmarks to use BigInts and measure performance on that as 
> well. Some ideas could be taking some of the math-heavy benchmarks from 
> JetStream/Kraken as a starting point.

This sounds a good idea. I'll also do that as soon as we have support
to all operations.

> - Saam
>
> >
> > Regards,
> > Caio.
> > ___
> > 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] BigIntBench

[Caio Lima]

Hi all.

I'm starting working to fix JIT support of BigInt in some operations
we already have upstream. In such case, I'm sending
(https://bugs.webkit.org/show_bug.cgi?id=186177) to support BigInt
speculation into ValueAdd node. As I want to know if BigInt
speculation represents some performance improvement, I'm also
proposing a new benchmark suite called BigIntBench. The idea right now
is to enable us to write microbenchmarks while working into JIT fixes.
The main reason behind that is due the practicality of enabling
"--useBigInt=true" flags for tests in this suite. The big plan is to
move all microbenchmarks to "JSTests/microbenchmarks" and then add
relevant tests to evaluate how fast JSC can manipulate BigInts. IIRC,
Robin Morisset mentioned about introducing some benchmarks to evaluate
BigInt implementation sometime ago.

What do you think about that? Does it make sense?

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

Re: [webkit-dev] Ask for review in BigInt Patch

[Caio Lima]

Hi all.

Could any JSC reviewer take a look into my BigInt Patches? Right now I
have 4 patches uploaded asking for review.

https://bugs.webkit.org/show_bug.cgi?id=182214
https://bugs.webkit.org/show_bug.cgi?id=183721
https://bugs.webkit.org/show_bug.cgi?id=184327
https://bugs.webkit.org/show_bug.cgi?id=184474

Some of these patches are blocking others like the addition and
subtraction operations
(https://bugs.webkit.org/show_bug.cgi?id=179002) and mod operation
(https://bugs.webkit.org/show_bug.cgi?id=184327).

Best regards,
Caio.

2018-04-17 23:52 GMT-03:00 Caio Lima <ticaiol...@gmail.com>:
> Hi all.
>
> After the landing of https://bugs.webkit.org/show_bug.cgi?id=182470 I
> rebased pending patches of BigInt that I'm waiting review. Here is the
> current List:
>
> https://bugs.webkit.org/show_bug.cgi?id=182214
> https://bugs.webkit.org/show_bug.cgi?id=183721
> https://bugs.webkit.org/show_bug.cgi?id=183996
>
> Could anyone take a look on these bugs?
>
> Regards,
> Caio.
>
>
> 2018-03-19 4:36 GMT-03:00 Caio Lima <ticaiol...@gmail.com>:
>> Hi all.
>>
>> It's been a while I am asking for review into BigInt Patches but get
>> no answer. I have 4 Patches in the queue to be reviewed but some of
>> them are dependent one to another. The addition of SpecBigInt
>> (https://bugs.webkit.org/show_bug.cgi?id=182470) is blocking BigInt
>> Unary "+" and "-" operation
>> (https://bugs.webkit.org/show_bug.cgi?id=182214) that is then blocking
>> support for addition operations
>> (https://bugs.webkit.org/show_bug.cgi?id=179002) and will block other
>> future Patches. I think the addition of SpecBigInt
>> (https://bugs.webkit.org/show_bug.cgi?id=182470) is the one that
>> should be reviewed first. Is there any better approach of how I could
>> get review on them? It is starting to be time consuming rebasing all
>> these dependent patches downstream.
>>
>> Regards,
>> Caio.
>>
>> Em qua, 14 de mar de 2018 às 21:08, Caio Lima <ticaiol...@gmail.com> 
>> escreveu:
>>>
>>> Hi all.
>>>
>>> Pinging this review request.
>>>
>>> Em sáb, 10 de mar de 2018 às 18:29, Caio Lima <ticaiol...@gmail.com> 
>>> escreveu:
>>>>
>>>> Hi All.
>>>>
>>>> I am working into some BigInt patches  and right now I'm looking for
>>>> someone to review the following Patch
>>>> (https://bugs.webkit.org/show_bug.cgi?id=182470). Saam reviewed it
>>>> once, but since he is not available, he advised me to ask some other
>>>> reviewer to take a look. Could anyone take a look on that?
>>>>
>>>> Regards,
>>>> Caio.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Ask for review in BigInt Patch

[Caio Lima]

Hi all.

It's been a while I am asking for review into BigInt Patches but get
no answer. I have 4 Patches in the queue to be reviewed but some of
them are dependent one to another. The addition of SpecBigInt
(https://bugs.webkit.org/show_bug.cgi?id=182470) is blocking BigInt
Unary "+" and "-" operation
(https://bugs.webkit.org/show_bug.cgi?id=182214) that is then blocking
support for addition operations
(https://bugs.webkit.org/show_bug.cgi?id=179002) and will block other
future Patches. I think the addition of SpecBigInt
(https://bugs.webkit.org/show_bug.cgi?id=182470) is the one that
should be reviewed first. Is there any better approach of how I could
get review on them? It is starting to be time consuming rebasing all
these dependent patches downstream.

Regards,
Caio.

Em qua, 14 de mar de 2018 às 21:08, Caio Lima <ticaiol...@gmail.com> escreveu:
>
> Hi all.
>
> Pinging this review request.
>
> Em sáb, 10 de mar de 2018 às 18:29, Caio Lima <ticaiol...@gmail.com> escreveu:
>>
>> Hi All.
>>
>> I am working into some BigInt patches  and right now I'm looking for
>> someone to review the following Patch
>> (https://bugs.webkit.org/show_bug.cgi?id=182470). Saam reviewed it
>> once, but since he is not available, he advised me to ask some other
>> reviewer to take a look. Could anyone take a look on that?
>>
>> Regards,
>> Caio.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Ask for review in BigInt Patch

[Caio Lima]

Olá Leo!

I'm getting some tests from Test262,  but I'm not running them directly
with the Test262-harness. If you need any help, let me know.

Em sáb, 10 de mar de 2018 às 21:05, Leo Balter <l...@bocoup.com> escreveu:

> Olá Caio!
>
> I'm game to fetch your work and run it against the recent changes in
> Test262, but I also imagined you're already doing it. I'll give it a try
> anyway as I'm particularly interested in this new feature implementation.
>
>
>
> On Sat, Mar 10, 2018 at 12:29 PM, Caio Lima <ticaiol...@gmail.com> wrote:
>
>> Hi All.
>>
>> I am working into some BigInt patches  and right now I'm looking for
>> someone to review the following Patch
>> (https://bugs.webkit.org/show_bug.cgi?id=182470). Saam reviewed it
>> once, but since he is not available, he advised me to ask some other
>> reviewer to take a look. Could anyone take a look on that?
>>
>> Regards,
>> Caio.
>>
> ___
>> 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] Ask for review in BigInt Patch

[Caio Lima]

Hi All.

I am working into some BigInt patches  and right now I'm looking for
someone to review the following Patch
(https://bugs.webkit.org/show_bug.cgi?id=182470). Saam reviewed it
once, but since he is not available, he advised me to ask some other
reviewer to take a look. Could anyone take a look on that?

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

[webkit-dev] Is Win7 build broken in tests with large Arrays?

[Caio Lima]

Hi all.

I landed a BigInt Patch last week[1] and noticed that I introduced a
new fail into Win7 builds
(stress/big-int-constructor-gc.js.big-int-enabled for reference) and
investigating the issue, I could notice that there are other stress
tests failing (stress/big-match.js and stress/big-split.js) as well.
All these tests use large arrays and they are failing due to wrong
value returned when accessing such arrays. I don't have easy access to
Win7 machines to debug them, but I feel that these bugs are related
and is probably a issue related with large array access.

Is anyone already working on that? If yes, please send me the bug. If
no, Who could I ping to get support on Win7 builds?


Regards,
Caio.

[1] - https://trac.webkit.org/changeset/226338/webkit
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build issues due to anonymous namespace

[Caio Lima]

I agree on that. The Patch on the way as well and I will fix it.

https://bugs.webkit.org/show_bug.cgi?id=180335

Em dom, 3 de dez de 2017 às 18:10, Darin Adler  escreveu:

> I think it’s also worthwhile to remove the anonymous namespace wrapping
> each of these DestroyFunc structures when renaming them. Generally
> speaking, anonymous namespace doesn’t work when compilation units are
> arbitrary, since they say “limit this to one compilation unit”. So I’m not
> sure we should ever use them any more.
>
> — Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Build issues due to anonymous namespace

[Caio Lima]

Ok.

It's a common pattern to use "struct DestroyFunc {".

I'm going to rename all of them.

Em dom, 3 de dez de 2017 às 14:52, Filip Pizlo <fpi...@apple.com> escreveu:

> Maybe just give that DestroyFunc a more unique name like
> JSSegmentedVariableObjectDestroyFunc. Cc me on such a patch and I’ll
> happily review it.
>
> -Filip
>
> > On Dec 3, 2017, at 8:44 AM, Caio Lima <ticaiol...@gmail.com> wrote:
> >
> > Hi guys. I'm working in a Patch that is adding some files to JSC and I
> faced following issue:
> >
> > ./runtime/JSStringHeapCellType.cpp:36:8: error: redefinition of
> 'DestroyFunc'
> > ...
> > In file included from /Users/caiolima/open_projects/
> WebKit/WebKitBuild/Debug/DerivedSources/JavaScriptCore/unified-sources/
> UnifiedSource109.cpp:1:
> > ./runtime/JSSegmentedVariableObjectHeapCellType.cpp:36:8: note:
> previous definition is here
> >
> > That is my UnifiedSource109.cpp content:
> >
> > #include "runtime/JSSegmentedVariableObjectHeapCellType.cpp"
> > #include "runtime/JSSet.cpp"
> > #include "runtime/JSSetIterator.cpp"
> > #include "runtime/JSSourceCode.cpp"
> > #include "runtime/JSString.cpp"
> > #include "runtime/JSStringHeapCellType.cpp"
> > #include "runtime/JSStringIterator.cpp"
> > #include "runtime/JSStringJoiner.cpp"
> >
> > So, I tried to use "namespace FILENAME" magic, but it doesn't seem
> working, mainly because there is no other file using it.
> >
> > What are the actions do I need to take in such case to fix it properly?
> >
> > Regards,
> > Caio.
> > ___
> > 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] Build issues due to anonymous namespace

[Caio Lima]

Hi guys. I'm working in a Patch that is adding some files to JSC and I
faced following issue:

./runtime/JSStringHeapCellType.cpp:36:8: error: redefinition of
'DestroyFunc'
...
In file included from
/Users/caiolima/open_projects/WebKit/WebKitBuild/Debug/DerivedSources/JavaScriptCore/unified-sources/UnifiedSource109.cpp:1:
./runtime/JSSegmentedVariableObjectHeapCellType.cpp:36:8: note: previous
definition is here

That is my UnifiedSource109.cpp content:

#include "runtime/JSSegmentedVariableObjectHeapCellType.cpp"
#include "runtime/JSSet.cpp"
#include "runtime/JSSetIterator.cpp"
#include "runtime/JSSourceCode.cpp"
#include "runtime/JSString.cpp"
#include "runtime/JSStringHeapCellType.cpp"
#include "runtime/JSStringIterator.cpp"
#include "runtime/JSStringJoiner.cpp"

So, I tried to use "namespace FILENAME" magic, but it doesn't seem working,
mainly because there is no other file using it.

What are the actions do I need to take in such case to fix it properly?

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

[webkit-dev] BigInt implementation

[Caio Lima]

Hi WebKittens.

I’m planning to start implement JS BigInt proposal on JSC, however I
would like to sync with you the way you are planning to implement such
feature.

Right now, I’m thinking in implement BigInt operations into C++
(possibly on WTF?) and make the JSBigInt use this implementation. As I
have checked with some other implementors, some of them are going to
use libgmp (SpiderMonkey case), but I don’t think its license (GPLv2)
aligns with WebKit’s license and I heard that V8 is implementing their
BigInt lib as well. By now, I’m thinking in implement a proof of
concept and then, optimize the BigInt lib part. So, what I would like
to collect from you is: Is there any problem start work on that
feature?

It is one of the proposals that I’ve made to my Coding Experience at
Igalia, so I will also have the support of developers from there,
since they are implementing it on SpiderMonkey and the spec champion
is also in the team.

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

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Caio Lima]

Hi guys,I've posted this on the bug thread, but I would also like to
revive the discussion here.

After our last discussion, I put some effort to enable IC for ARMv6
into JIT layers and now I finally collected some results for that.

Now, we have regressions just into 2 tests in SunSpider (they aren't
regressing in LongSpider) and 3 into Octane (gbemu, typescript and
box2d). Also, I see regressions into microbenchmarks, mainly cases
with observable-side-effects and set/map tests.

With these results, what do you think about keep working into ARMv6 support?

Maybe an important report is that I'm almost fixing the errors taking
the http://trac.webkit.org/changeset/220532 as baseline. Currently
there are ~40 tests failing, and the majority of them are due to OOM
into my runtime env, due to memory constraints. I will try to merge it
with current master this week to check the status of build+failures.

Regards,
Caio.

2017-08-01 20:52 GMT-03:00 Caio Lima <ticaiol...@gmail.com>:
> Hi all.
>
> FYI, I keep the last weeks investigating the issue with ARMv6 IC and I
> was able to find the source of the bug and apply a quick fix to run
> benchmarks again to get results. I just ran V8Spider, Octane and
> Kraken by now and I'm attaching the results in this email.
>
> We found some test cases regressing, and my attention now is to
> identify the reason of the regression and how to fix them. Also, the
> improvements got with JIT in ARMv6 aren't as big as Filip commented in
> [1] to supported architectures.
>
> [1] - https://bugs.webkit.org/show_bug.cgi?id=172765#c9
>
> 2017-07-13 19:27 GMT-03:00 Caio Lima <ticaiol...@gmail.com>:
>> Yes. It probably will take a while to process on device, but I'll run it.
>>
>> Em qui, 13 de jul de 2017 às 17:50, Saam barati <sbar...@apple.com>
>> escreveu:
>>>
>>> And ARES6.
>>>
>>> - Saam
>>>
>>>
>>> On Jul 13, 2017, at 1:50 PM, Saam barati <sbar...@apple.com> wrote:
>>>
>>> Can you please run Octane and Kraken too?
>>>
>>> - Saam
>>>
>>> On Jul 13, 2017, at 7:47 AM, Caio Lima <ticaiol...@gmail.com> wrote:
>>>
>>> Finally I got the results from the last benchmark run. The results
>>> shows that the speed-ups are considerable comparing with CLoop
>>> version, since we get faster results in a big number of tests and
>>> regress in a minor number of scripts. I would like to get feedback
>>> from you as well, but IMHO enabling JIT for ARMv6 looks a good
>>> improvement step and the amount of code we are touching in current
>>> trunk code to make it possible is small.
>>>
>>> The results are attached and I also uploaded them in
>>> https://bugs.webkit.org/show_bug.cgi?id=172765.
>>>
>>> PS.: Some test cases (bigswitch-indirect-symbol-or-undefined,
>>> bigswitch-indirect-symbol, bigswitch, etc) are failing now and I'm
>>> already investigating the source of problem to fix them.
>>>
>>> Regards,
>>> Caio.
>>>
>>> 2017-07-05 22:54 GMT-03:00 Filip Pizlo <fpi...@apple.com>:
>>>
>>> To be clear, I’m concerned that the 32-bit JIT backends have such bad
>>> tuning for these embedded platforms that it’s just pure badness. Until you
>>> can prove that you can change this, I think that porting should focus on
>>> making the cloop great. Then, we can rip out support for weird CPUs rather
>>> than bringing it back.
>>>
>>> -Filip
>>>
>>> On Jul 5, 2017, at 6:14 PM, Caio Lima <ticaiol...@gmail.com> wrote:
>>>
>>> 2017-07-05 18:25 GMT-03:00 Filip Pizlo <fpi...@apple.com>:
>>>
>>> You need to establish that the JIT is a performance progression over the
>>> LLInt on ARMv6. I am opposed to more ARMv6 patches landing until there is
>>> some evidence provided that you’re actually getting speed-ups.
>>>
>>>
>>> It makes sense. I can get these numbers related to JIT.
>>>
>>> BTW, there is a Patch that isn't JIT related
>>> (https://bugs.webkit.org/show_bug.cgi?id=172766).
>>>
>>> Regards,
>>> Caio.
>>>
>>> -Filip
>>>
>>> On Jun 13, 2017, at 6:48 PM, Caio Lima <ticaiol...@gmail.com> wrote:
>>>
>>> Hi All.
>>>
>>> Some of you guys might know me through the work I have been doing in
>>> JSC. The experience working with WebKit has been great so far, thank
>>> you for the reviews!
>>>
>>> Since 1st May, we at Igalia have been working on bring back the ARMv6
>>>

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Caio Lima]

Hi all.

FYI, I keep the last weeks investigating the issue with ARMv6 IC and I
was able to find the source of the bug and apply a quick fix to run
benchmarks again to get results. I just ran V8Spider, Octane and
Kraken by now and I'm attaching the results in this email.

We found some test cases regressing, and my attention now is to
identify the reason of the regression and how to fix them. Also, the
improvements got with JIT in ARMv6 aren't as big as Filip commented in
[1] to supported architectures.

[1] - https://bugs.webkit.org/show_bug.cgi?id=172765#c9

2017-07-13 19:27 GMT-03:00 Caio Lima <ticaiol...@gmail.com>:
> Yes. It probably will take a while to process on device, but I'll run it.
>
> Em qui, 13 de jul de 2017 às 17:50, Saam barati <sbar...@apple.com>
> escreveu:
>>
>> And ARES6.
>>
>> - Saam
>>
>>
>> On Jul 13, 2017, at 1:50 PM, Saam barati <sbar...@apple.com> wrote:
>>
>> Can you please run Octane and Kraken too?
>>
>> - Saam
>>
>> On Jul 13, 2017, at 7:47 AM, Caio Lima <ticaiol...@gmail.com> wrote:
>>
>> Finally I got the results from the last benchmark run. The results
>> shows that the speed-ups are considerable comparing with CLoop
>> version, since we get faster results in a big number of tests and
>> regress in a minor number of scripts. I would like to get feedback
>> from you as well, but IMHO enabling JIT for ARMv6 looks a good
>> improvement step and the amount of code we are touching in current
>> trunk code to make it possible is small.
>>
>> The results are attached and I also uploaded them in
>> https://bugs.webkit.org/show_bug.cgi?id=172765.
>>
>> PS.: Some test cases (bigswitch-indirect-symbol-or-undefined,
>> bigswitch-indirect-symbol, bigswitch, etc) are failing now and I'm
>> already investigating the source of problem to fix them.
>>
>> Regards,
>> Caio.
>>
>> 2017-07-05 22:54 GMT-03:00 Filip Pizlo <fpi...@apple.com>:
>>
>> To be clear, I’m concerned that the 32-bit JIT backends have such bad
>> tuning for these embedded platforms that it’s just pure badness. Until you
>> can prove that you can change this, I think that porting should focus on
>> making the cloop great. Then, we can rip out support for weird CPUs rather
>> than bringing it back.
>>
>> -Filip
>>
>> On Jul 5, 2017, at 6:14 PM, Caio Lima <ticaiol...@gmail.com> wrote:
>>
>> 2017-07-05 18:25 GMT-03:00 Filip Pizlo <fpi...@apple.com>:
>>
>> You need to establish that the JIT is a performance progression over the
>> LLInt on ARMv6. I am opposed to more ARMv6 patches landing until there is
>> some evidence provided that you’re actually getting speed-ups.
>>
>>
>> It makes sense. I can get these numbers related to JIT.
>>
>> BTW, there is a Patch that isn't JIT related
>> (https://bugs.webkit.org/show_bug.cgi?id=172766).
>>
>> Regards,
>> Caio.
>>
>> -Filip
>>
>> On Jun 13, 2017, at 6:48 PM, Caio Lima <ticaiol...@gmail.com> wrote:
>>
>> Hi All.
>>
>> Some of you guys might know me through the work I have been doing in
>> JSC. The experience working with WebKit has been great so far, thank
>> you for the reviews!
>>
>> Since 1st May, we at Igalia have been working on bring back the ARMv6
>> support into JSC. We already have commits into our downstream branch
>> port[2] that fixes some compile/runtime errors when building JSC to
>> ARMv6 and also fixes some bugs. However, this branch is not synced
>> with WebKit upstream tree and I would like to pursue the upstreaming
>> of this ARMv6/JSC support to WebKit.
>>
>> As a long shot, we are planning to maintain the ARMv6 support and make
>> tests run as green as possible. Also, it's our goal make ARMv6 support
>> not interfere with other ARM versions support code negatively and we
>> will be in charge of implement platform-specific fixes/features for
>> JSC/ARM6, this way no imposing burden to the rest of the community.
>>
>> To keep track of work to be done, I've create a meta-bug in
>> bugzilla[3] and it's going to be used firstly to organize the commits
>> from our downstream branch, but pretty soon I'm going to create issues
>> related with javascriptcore-test failures and send patches to fix
>> them. We have already submitted 3 patches (they are marked as
>> dependence of [3]) that fixes ARMv6 into LLInt and JIT layers and got
>> a round of review into them.
>>
>> Best Regards,
>> Caio.
>>
>> [1] - https://www.igalia.com/about-us/coding-experience

Re: [webkit-dev] Bring back ARMv6 support to JSC

[Caio Lima]

Yes. It probably will take a while to process on device, but I'll run it.

Em qui, 13 de jul de 2017 às 17:50, Saam barati <sbar...@apple.com>
escreveu:

> And ARES6.
>
> - Saam
>
>
> On Jul 13, 2017, at 1:50 PM, Saam barati <sbar...@apple.com> wrote:
>
> Can you please run Octane and Kraken too?
>
> - Saam
>
> On Jul 13, 2017, at 7:47 AM, Caio Lima <ticaiol...@gmail.com> wrote:
>
> Finally I got the results from the last benchmark run. The results
> shows that the speed-ups are considerable comparing with CLoop
> version, since we get faster results in a big number of tests and
> regress in a minor number of scripts. I would like to get feedback
> from you as well, but IMHO enabling JIT for ARMv6 looks a good
> improvement step and the amount of code we are touching in current
> trunk code to make it possible is small.
>
> The results are attached and I also uploaded them in
> https://bugs.webkit.org/show_bug.cgi?id=172765.
>
> PS.: Some test cases (bigswitch-indirect-symbol-or-undefined,
> bigswitch-indirect-symbol, bigswitch, etc) are failing now and I'm
> already investigating the source of problem to fix them.
>
> Regards,
> Caio.
>
> 2017-07-05 22:54 GMT-03:00 Filip Pizlo <fpi...@apple.com>:
>
> To be clear, I’m concerned that the 32-bit JIT backends have such bad
> tuning for these embedded platforms that it’s just pure badness. Until you
> can prove that you can change this, I think that porting should focus on
> making the cloop great. Then, we can rip out support for weird CPUs rather
> than bringing it back.
>
> -Filip
>
> On Jul 5, 2017, at 6:14 PM, Caio Lima <ticaiol...@gmail.com> wrote:
>
> 2017-07-05 18:25 GMT-03:00 Filip Pizlo <fpi...@apple.com>:
>
> You need to establish that the JIT is a performance progression over the
> LLInt on ARMv6. I am opposed to more ARMv6 patches landing until there is
> some evidence provided that you’re actually getting speed-ups.
>
>
> It makes sense. I can get these numbers related to JIT.
>
> BTW, there is a Patch that isn't JIT related
> (https://bugs.webkit.org/show_bug.cgi?id=172766).
>
> Regards,
> Caio.
>
> -Filip
>
> On Jun 13, 2017, at 6:48 PM, Caio Lima <ticaiol...@gmail.com> wrote:
>
> Hi All.
>
> Some of you guys might know me through the work I have been doing in
> JSC. The experience working with WebKit has been great so far, thank
> you for the reviews!
>
> Since 1st May, we at Igalia have been working on bring back the ARMv6
> support into JSC. We already have commits into our downstream branch
> port[2] that fixes some compile/runtime errors when building JSC to
> ARMv6 and also fixes some bugs. However, this branch is not synced
> with WebKit upstream tree and I would like to pursue the upstreaming
> of this ARMv6/JSC support to WebKit.
>
> As a long shot, we are planning to maintain the ARMv6 support and make
> tests run as green as possible. Also, it's our goal make ARMv6 support
> not interfere with other ARM versions support code negatively and we
> will be in charge of implement platform-specific fixes/features for
> JSC/ARM6, this way no imposing burden to the rest of the community.
>
> To keep track of work to be done, I've create a meta-bug in
> bugzilla[3] and it's going to be used firstly to organize the commits
> from our downstream branch, but pretty soon I'm going to create issues
> related with javascriptcore-test failures and send patches to fix
> them. We have already submitted 3 patches (they are marked as
> dependence of [3]) that fixes ARMv6 into LLInt and JIT layers and got
> a round of review into them.
>
> Best Regards,
> Caio.
>
> [1] - https://www.igalia.com/about-us/coding-experience
> [2] - https://github.com/WebPlatformForEmbedded/WPEWebKit
> [3] - https://bugs.webkit.org/show_bug.cgi?id=172765
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>  buildroot_20170712_1029_report.txt>___
> 
> 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] Bring back ARMv6 support to JSC

[Caio Lima]

Finally I got the results from the last benchmark run. The results
shows that the speed-ups are considerable comparing with CLoop
version, since we get faster results in a big number of tests and
regress in a minor number of scripts. I would like to get feedback
from you as well, but IMHO enabling JIT for ARMv6 looks a good
improvement step and the amount of code we are touching in current
trunk code to make it possible is small.

The results are attached and I also uploaded them in
https://bugs.webkit.org/show_bug.cgi?id=172765.

PS.: Some test cases (bigswitch-indirect-symbol-or-undefined,
bigswitch-indirect-symbol, bigswitch, etc) are failing now and I'm
already investigating the source of problem to fix them.

Regards,
Caio.

2017-07-05 22:54 GMT-03:00 Filip Pizlo <fpi...@apple.com>:
> To be clear, I’m concerned that the 32-bit JIT backends have such bad tuning 
> for these embedded platforms that it’s just pure badness. Until you can prove 
> that you can change this, I think that porting should focus on making the 
> cloop great. Then, we can rip out support for weird CPUs rather than bringing 
> it back.
>
> -Filip
>
>> On Jul 5, 2017, at 6:14 PM, Caio Lima <ticaiol...@gmail.com> wrote:
>>
>> 2017-07-05 18:25 GMT-03:00 Filip Pizlo <fpi...@apple.com>:
>>> You need to establish that the JIT is a performance progression over the 
>>> LLInt on ARMv6. I am opposed to more ARMv6 patches landing until there is 
>>> some evidence provided that you’re actually getting speed-ups.
>>
>> It makes sense. I can get these numbers related to JIT.
>>
>> BTW, there is a Patch that isn't JIT related
>> (https://bugs.webkit.org/show_bug.cgi?id=172766).
>>
>> Regards,
>> Caio.
>>
>>> -Filip
>>>
>>>> On Jun 13, 2017, at 6:48 PM, Caio Lima <ticaiol...@gmail.com> wrote:
>>>>
>>>> Hi All.
>>>>
>>>> Some of you guys might know me through the work I have been doing in
>>>> JSC. The experience working with WebKit has been great so far, thank
>>>> you for the reviews!
>>>>
>>>> Since 1st May, we at Igalia have been working on bring back the ARMv6
>>>> support into JSC. We already have commits into our downstream branch
>>>> port[2] that fixes some compile/runtime errors when building JSC to
>>>> ARMv6 and also fixes some bugs. However, this branch is not synced
>>>> with WebKit upstream tree and I would like to pursue the upstreaming
>>>> of this ARMv6/JSC support to WebKit.
>>>>
>>>> As a long shot, we are planning to maintain the ARMv6 support and make
>>>> tests run as green as possible. Also, it's our goal make ARMv6 support
>>>> not interfere with other ARM versions support code negatively and we
>>>> will be in charge of implement platform-specific fixes/features for
>>>> JSC/ARM6, this way no imposing burden to the rest of the community.
>>>>
>>>> To keep track of work to be done, I've create a meta-bug in
>>>> bugzilla[3] and it's going to be used firstly to organize the commits
>>>> from our downstream branch, but pretty soon I'm going to create issues
>>>> related with javascriptcore-test failures and send patches to fix
>>>> them. We have already submitted 3 patches (they are marked as
>>>> dependence of [3]) that fixes ARMv6 into LLInt and JIT layers and got
>>>> a round of review into them.
>>>>
>>>> Best Regards,
>>>> Caio.
>>>>
>>>> [1] - https://www.igalia.com/about-us/coding-experience
>>>> [2] - https://github.com/WebPlatformForEmbedded/WPEWebKit
>>>> [3] - https://bugs.webkit.org/show_bug.cgi?id=172765
>>>> ___
>>>> webkit-dev mailing list
>>>> webkit-dev@lists.webkit.org
>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
Benchmark report for SunSpider, LongSpider, V8Spider, Microbenchmarks, and 
SixSpeed on buildroot.

VMs tested:
"baseline" at /home/igalia/clima/webkit/WebKitBaselineBuild/Release/bin/jsc
"changes" at /home/igalia/clima/webkit/WebKitBuild/Release/bin/jsc

Collected 4 samples per benchmark/VM, with 4 VM invocations per benchmark. 
Emitted a call to gc() between sample
measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used 
the jsc-specific preciseTime() function to get
microsecond-level timing. Reporting benchmark execution times with 95% 
confidence intervals in milliseconds.

  baseline  
change

Re: [webkit-dev] Data Memory Barrier ARMv6 question

[Caio Lima]

2017-07-05 12:41 GMT-03:00 JF Bastien <jfbast...@apple.com>:
> On Linux you can do the following:
>
> ((void(*)())0x0fa0)();
>
>
> That address contains a helper which does the “right” barrier, including if
> you’re not on an SMP system it’ll do nothing.
>
> Details:
> https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt
> That file also lists other Linux helpers.
>
> I think for ARMv6 it makes sense to use these helpers. AFAIK the mcr barrier
> instruction ins’t supported by all ARMv6 CPUs.

Hi JF. Do you mind point me where the mcr isn't supported by all ARMv6
CPU? I've found in ARMv6-M manual
(http://infocenter.arm.com/help/topic/com.arm.doc.ddi0419d/DDI0419D_armv6m_arm.pdf)
that it doesn't support coprocessor operations, but this architecture
is used by microcontroller chips.

Regards,
Caio.

> For ARMv7 and later, DMB ish is the right thing.
>
>
> On Jul 3, 2017, at 17:19, Caio Lima <ticaiol...@gmail.com> wrote:
>
> Hi all.
>
> I'm working in this patch
> (https://bugs.webkit.org/show_bug.cgi?id=172767) and Mark Lam raised
> some questions about the data memory barrier (DMB for short) in ARMv6
> using "mcr 15 ...". The point is that we are having divergences in ARM
> official reference manual about the semantics of this instruction. We
> have it discussed in the bug above and I would like to know if there
> is somebody with stronger ARM background that could help us there and
> then approve the patch to be committed.
>
> I thanks in advance and best regards,
> Caio Lima.
> ___
> 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] Bring back ARMv6 support to JSC

[Caio Lima]

2017-07-05 18:25 GMT-03:00 Filip Pizlo <fpi...@apple.com>:
> You need to establish that the JIT is a performance progression over the 
> LLInt on ARMv6. I am opposed to more ARMv6 patches landing until there is 
> some evidence provided that you’re actually getting speed-ups.

It makes sense. I can get these numbers related to JIT.

BTW, there is a Patch that isn't JIT related
(https://bugs.webkit.org/show_bug.cgi?id=172766).

Regards,
Caio.

> -Filip
>
>> On Jun 13, 2017, at 6:48 PM, Caio Lima <ticaiol...@gmail.com> wrote:
>>
>> Hi All.
>>
>> Some of you guys might know me through the work I have been doing in
>> JSC. The experience working with WebKit has been great so far, thank
>> you for the reviews!
>>
>> Since 1st May, we at Igalia have been working on bring back the ARMv6
>> support into JSC. We already have commits into our downstream branch
>> port[2] that fixes some compile/runtime errors when building JSC to
>> ARMv6 and also fixes some bugs. However, this branch is not synced
>> with WebKit upstream tree and I would like to pursue the upstreaming
>> of this ARMv6/JSC support to WebKit.
>>
>> As a long shot, we are planning to maintain the ARMv6 support and make
>> tests run as green as possible. Also, it's our goal make ARMv6 support
>> not interfere with other ARM versions support code negatively and we
>> will be in charge of implement platform-specific fixes/features for
>> JSC/ARM6, this way no imposing burden to the rest of the community.
>>
>> To keep track of work to be done, I've create a meta-bug in
>> bugzilla[3] and it's going to be used firstly to organize the commits
>> from our downstream branch, but pretty soon I'm going to create issues
>> related with javascriptcore-test failures and send patches to fix
>> them. We have already submitted 3 patches (they are marked as
>> dependence of [3]) that fixes ARMv6 into LLInt and JIT layers and got
>> a round of review into them.
>>
>> Best Regards,
>> Caio.
>>
>> [1] - https://www.igalia.com/about-us/coding-experience
>> [2] - https://github.com/WebPlatformForEmbedded/WPEWebKit
>> [3] - https://bugs.webkit.org/show_bug.cgi?id=172765
>> ___
>> 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] Data Memory Barrier ARMv6 question

[Caio Lima]

Hi all.

I'm working in this patch
(https://bugs.webkit.org/show_bug.cgi?id=172767) and Mark Lam raised
some questions about the data memory barrier (DMB for short) in ARMv6
using "mcr 15 ...". The point is that we are having divergences in ARM
official reference manual about the semantics of this instruction. We
have it discussed in the bug above and I would like to know if there
is somebody with stronger ARM background that could help us there and
then approve the patch to be committed.

I thanks in advance and best regards,
Caio Lima.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Bring back ARMv6 support to JSC

[Caio Lima]

Hi All.

Some of you guys might know me through the work I have been doing in
JSC. The experience working with WebKit has been great so far, thank
you for the reviews!

Since 1st May, we at Igalia have been working on bring back the ARMv6
support into JSC. We already have commits into our downstream branch
port[2] that fixes some compile/runtime errors when building JSC to
ARMv6 and also fixes some bugs. However, this branch is not synced
with WebKit upstream tree and I would like to pursue the upstreaming
of this ARMv6/JSC support to WebKit.

As a long shot, we are planning to maintain the ARMv6 support and make
tests run as green as possible. Also, it's our goal make ARMv6 support
not interfere with other ARM versions support code negatively and we
will be in charge of implement platform-specific fixes/features for
JSC/ARM6, this way no imposing burden to the rest of the community.

To keep track of work to be done, I've create a meta-bug in
bugzilla[3] and it's going to be used firstly to organize the commits
from our downstream branch, but pretty soon I'm going to create issues
related with javascriptcore-test failures and send patches to fix
them. We have already submitted 3 patches (they are marked as
dependence of [3]) that fixes ARMv6 into LLInt and JIT layers and got
a round of review into them.

Best Regards,
Caio.

[1] - https://www.igalia.com/about-us/coding-experience
[2] - https://github.com/WebPlatformForEmbedded/WPEWebKit
[3] - https://bugs.webkit.org/show_bug.cgi?id=172765
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Konstantin Tokarev is now a WebKit reviewer

[Caio Lima]

Congrats annulen!

2017-05-22 21:18 GMT-03:00 Myles C. Maxfield :
> Yyyy!!
>
>
> On May 22, 2017, at 5:09 PM, Yusuke SUZUKI  wrote:
>
> Congrats!
>
> On Tue, May 23, 2017 at 2:25 Mark Lam  wrote:
>>
>> Hi everyone,
>>
>> I would like to announce that Konstantin Tokarev (annulen on #webkit) is
>> now a WebKit reviewer.  Konstantin has extensive knowledge of WebKit, and
>> has resurrected the QtWebKit port, helped WebKit compete against Chromium in
>> the Qt project, and ensured that the dozens of applications that depend on
>> QtWebKit will soon be able to receive updated versions of WebKit.
>>
>> Please join me in congratulating Konstantin, and send him some patches to
>> review.
>>
>> Konstantin, congratulations.
>>
>> Mark
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> --
> Regards,
> Yusuke Suzuki
> ___
> 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] !!Tests for equality comparison

[Caio Lima]

O also think it's a good notation. It helps a lot the code reading IMO.

Caio.
Em qui, 27 de abr de 2017 às 20:33, Chris Dumez  escreveu:

> I also do not like this rule when it comes to integers.
>
> I personally think JF’s proposal to allow == 0 sounds nice. I don’t think
> JF was suggesting rewriting existing code (which would indeed cause a lot
> of churn).
>
> --
>  Chris Dumez
>
>
>
>
> On Apr 27, 2017, at 4:30 PM, Geoffrey Garen  wrote:
>
> I’ve never really liked this style rule, and I’ve always felt like it
> snuck into the style document without much discussion.
>
> Even so, I usually tolerate it.
>
> Geoff
>
> On Apr 27, 2017, at 4:06 PM, JF Bastien  wrote:
>
> Hello C++ fans!
>
> The C++ style check currently say:
>
> Tests for true/false, null/non-null, and zero/non-zero should all be done
> without equality comparisons
>
>
> I totally agree for booleans and pointers… but not for integers. I know
> it’s pretty much the same thing, but I it takes me slightly longer to
> process code like this:
>
> int numTestsForEqualityComparison = 0:
> // Count ‘em!
> // …
> if (!numTestsForEqualityComparison)
>   printf(“Good job!”);
>
>
> I read it as “if not number of tests for equality comparison”. That's
> weird. It takes me every slightly longer to think about, and I’ve gotten it
> wrong a bunch of times already. I’m not trying to check for “notness", I’m
> trying to say “if there were zero tests for equality comparison”, a.k.a.:
>
> if (numTestsForEqualityComparison == 0)
>   printf(“Good job!”);
>
>
> So how about the C++ style let me just say that? I’m not suggesting we
> advise using that style for integers everywhere, I’m just saying it should
> be acceptable to check zero/non-zero using equality comparison.
>
>
> !!Thanks (i.e. many thanks),
>
> JF
>
> p.s.: With you I am, fans of Yoda comparison, but for another day this
> will be.
> ___
> 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