Re: [webkit-dev] C++17 is here. Should we use it?

2018-03-26 Thread JF Bastien 


> On Mar 26, 2018, at 07:38, Michael Catanzaro <mcatanz...@igalia.com> wrote:
> 
> On Fri, Mar 23, 2018 at 4:32 PM, JF Bastien <jfbast...@apple.com> wrote:
>> Hello again WebKitten!
>> 
>> April 2018 is fast approaching, which means that we might be able to require 
>> GCC 6 and all the great C++17 features that´ll come with it. So what say you?
>> From C++17 it looks like we wouldn´t get quite a few things, but we´d be 
>> able to use a few nice things (see the table 
>> <http://en.cppreference.com/w/cpp/compiler_support>).
>> 
>> JF
> 
> Hi,
> 
> I've been asking around, and it sounds like this will be a significant 
> inconvenience for some Igalia projects where upgrading the compiler is a bit 
> difficult, but everyone agrees the time specified in the dependencies policy 
> (the next Ubuntu LTS release) is fast approaching, and that the policy is a 
> good compromise. It looks like the next Ubuntu release is due on April 26 
> [1], one month from today, so we should be good to require GCC 6 at that 
> time. Sound good?
> 
> Michael
> 
> [1] https://wiki.ubuntu.com/BionicBeaver/ReleaseSchedule 
> <https://wiki.ubuntu.com/BionicBeaver/ReleaseSchedule>
Thanks! I’d be very happy to bring a few new features in! Let’s see if anyone 
else wants to chime in by then :-)___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Hosting precompiled `jsc` binaries for Linux

2017-12-12 Thread JF Bastien 
On Tue, Dec 12, 2017 at 11:42 AM Mathias Bynens <m...@google.com> wrote:

> On Tue, Dec 12, 2017 at 8:38 PM, JF Bastien <j...@chromium.org> wrote:
>
>>
>> On Tue, Dec 12, 2017 at 11:27 AM Mathias Bynens <m...@google.com> wrote:
>>
>>> Ideally, projects such as jsvu wouldn’t have to make such decisions.
>>> They would trust the maintainer of the JS engine, in this case Apple, to
>>> provide the downloads.
>>>
>>> If Apple trusts Igalia enough, that’s Apple’s decision. Projects such as
>>> jsvu shouldn’t have to duplicate that decision IMHO. The way to do that is
>>> to host binaries on an official domain.
>>>
>>
>> It sounds like our disconnect is on who maintains JSC outside of Apple
>> ecosystems. The GTK port is not maintained by Apple, though we work closely
>> with the maintainers and avoid breakage where we can.
>>
>
> JSC is Apple’s JS engine. Who maintains which port of it is a detail that
> downstream projects should not concern themselves with, IMHO.
>

Isn’t that exactly the same as the PPC or S390 versions of V8?
https://github.com/v8/v8/wiki/Handling-of-Ports

Or the MIPS version of NaCl?

To be clear, folks are trying to figure out how to provide binaries despite
who owns what, but it seems like your policy is partly misguided because of
a misunderstanding.

What I’m getting at is: if GTK folks build and host binaries on the
official GTK port site, we should all rejoice.

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

Re: [webkit-dev] Hosting precompiled `jsc` binaries for Linux

2017-12-12 Thread JF Bastien 
On Tue, Dec 12, 2017 at 11:27 AM Mathias Bynens  wrote:

> Ideally, projects such as jsvu wouldn’t have to make such decisions. They
> would trust the maintainer of the JS engine, in this case Apple, to provide
> the downloads.
>
> If Apple trusts Igalia enough, that’s Apple’s decision. Projects such as
> jsvu shouldn’t have to duplicate that decision IMHO. The way to do that is
> to host binaries on an official domain.
>

It sounds like our disconnect is on who maintains JSC outside of Apple
ecosystems. The GTK port is not maintained by Apple, though we work closely
with the maintainers and avoid breakage where we can.


On Tue, Dec 12, 2017 at 8:21 PM, Alexey Proskuryakov  wrote:
>
>>
>> 12 дек. 2017 г., в 10:58, Mathias Bynens  написал(а):
>>
>> Yes, there is such an expectation. jsvu has a policy of only using URLs
>> “that are controlled by the creators of the JavaScript engine”:
>> https://github.com/GoogleChromeLabs/jsvu#security-considerations
>>
>>
>> This is explained as a security policy. If the project considers Igalia
>> builds unsafe, how are the same bits copied to another domain by an
>> automated process any better?
>>
>> I'm not necessarily objecting against the copying, but trying to make a
>> legitimate story for why any extra work is needed.
>>
>> - Alexey
>>
>>
>> Anything not on *.webkit.org or similar, or anything not on on S2
>> buckets that are owned by Apple directly, does not fit that policy.
>>
>> On Tue, Dec 12, 2017 at 7:35 PM, Alexey Proskuryakov 
>> wrote:
>>
>>>
>>> 12 дек. 2017 г., в 1:34, Mathias Bynens  написал(а):
>>>
>>> It would be great to make such downloads available from webkit.org or
>>> a similar domain!
>>>
>>>
>>> Can you explain in more detail why this is important?
>>>
>>> If there is an expectation that this will make the builds more official
>>> in some way, then I'd like to understand the difference better. For
>>> example, will having links to igalia.com on webkit.org work just as
>>> well?
>>>
>>> - Alexey
>>>
>>>
>>
>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Hosting precompiled `jsc` binaries for Linux

2017-12-08 Thread JF Bastien 
Also, as we discussed on the github bug the JSC binary is available as part
of the WebAssembly waterfall that Google maintains at wasm-stat.us

The build is pretty straightforward:

https://github.com/WebAssembly/waterfall/blob/7cda260b8ea5264900624a4cdc45df2c9e2de010/src/build.py#L943


I understand that you've got a policy of only taking "official" binaries.
The GTK team would be the official maintainer of the Linux port? There's an
official jsc binary is available on MacOS :-)


On Fri, Dec 8, 2017 at 9:07 AM, Lucas Forschler 
wrote:

> Hi Mathias,
>
> The Linux archives could be exposed on the build-archives page. In fact,
> we already store the output of the builders in S3. However, the igalia team
> only uploads a small file with a pointer to their internal builds. If I
> recall, they have limited bandwidth, and prefer to store their builds
> behind their firewall to save on external traffic to buildbot/s3.
>
> If you look here
> 
>  you
> will see a ‘transfer-to-s3’ build step.
> The archive the builder creates is uploaded, here is a sample
> 
> .
>
> Opening that up shows the location where the archive is stored:
> Built product is available here:
> http://webkitgtk-release.igalia.com/built-products/
> release_r225678_b7832.zip
>
> I cannot reach that link, so I would assume it’s behind the igalia
> firewall. If the GTK team wanted to support making these accessible, they
> have everything they need. They could either choose to open up their
> firewall so external folks could access them. Or, they could put full
> archives on build.webkit.org (which would be transferred to s3/webkit
> build archives).
>
> Maybe someone over there would be willing to take on this work if it is in
> their budget. (Both time and bandwidth)
>
> Lucas
>
>
>
> On Dec 8, 2017, at 12:44 AM, Mathias Bynens  wrote:
>
> Dear WebKit friends,
>
> Please consider hosting precompiled `jsc` binaries for Linux somewhere
> official. Perhaps https://webkit.org/build-archives/? The build bots
> already generate those binaries anyway — all that’s missing is an
> additional build step that archives and uploads them.
>
> Doing so would make it easier for developers to test JSC directly, or to
> include JSC when running benchmarks such as the Web Tooling Benchmark (ref.
> https://github.com/v8/web-tooling-benchmark/pull/29#discussion_r155587697
> ).
>
> I recently built a tool that automates the process of installing
> precompiled binaries for various JS engines: https://github.com/
> GoogleChromeLabs/jsvu It’d be great to be able to support JavaScriptCore
> on linux32 and linux64 as well!
>
> Prior discussion: https://bugs.webkit.org/show_bug.cgi?id=179945#c11
>
> Regards,
> Mathias
> ___
> 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] Forward.h's Vector

2017-09-15 Thread JF Bastien 
Having not heard any objections, here’s a patch which does this: 
https://bugs.webkit.org/show_bug.cgi?id=176984 
<https://bugs.webkit.org/show_bug.cgi?id=176984>


> On Sep 13, 2017, at 12:49, JF Bastien <jfbast...@apple.com> wrote:
> 
> 
> 
>> On Sep 13, 2017, at 11:07, Maciej Stachowiak <m...@apple.com 
>> <mailto:m...@apple.com>> wrote:
>> 
>> 
>> 
>>> On Sep 13, 2017, at 8:11 AM, JF Bastien <jfbast...@apple.com 
>>> <mailto:jfbast...@apple.com>> wrote:
>>> 
>>> Hello WebCritters,
>>> 
>>> I’m moving some code around, and one particular header I have is included 
>>> everywhere in JSC so I’d like it to be lightweight and include as few other 
>>> headers as possible. It unfortunately uses WTF::Vector, but it only does so 
>>> as a pointer:
>>> 
>>> void ohNoes(Vector*);
>>> 
>>> It seems like something a forward declaration would fix nicely, and oh joy 
>>> and wonder we have Forward.h just for this! Here’s what it does:
>>> 
>>> template>> size_t minCapacity, typename Malloc> class Vector;
>>> 
>>> That’s nice and great for T, but all the other template parameters are SOL 
>>> because Vector is actually declared with default template parameters:
>>> 
>>> template>> CrashOnOverflow, size_t minCapacity = 16, typename Malloc = FastMalloc>
>>> class Vector : private VectorBuffer<T, inlineCapacity, Malloc> {
>>> 
>>> The extra painful thing is that, contrary to what I originally thought, one 
>>> cannot declare Vector in Forward.h and then define it in Vector.h with the 
>>> same defaults twice! Ideally the compiler would just yell at a mismatch, 
>>> but instead it says error: template parameter redefines default argument 
>>> (thanks clang, that’s exactly what I’m trying to do, just tell me if you 
>>> catch a mismatch and ODR away otherwise).
>>> 
>>> Here’s what I propose:
>>> 
>>> Change the forward declaration in Forward.h to contain the default template 
>>> parameters (and forward-declare CrashOnOverflow).
>>> Remove these default template parameters from Vector.h.
>>> Include Forward.h in Vector.h.
>>> Optionally, if the WebCritters think it useful, leave a comment just above 
>>> the Vector definition redirecting to Forward.h for defaults (or more fancy, 
>>> use size_t inlineCapacity /*=0*/ style like LLVM’s codebase does, and have 
>>> a tool that checks for consistency).
>>> Optionally, try to fix C++20 so this isn’t A Thing anymore. Note that my 
>>> hopes are low because of modules (why fix it if modules will magically make 
>>> this not a thing).
>>> 
>>> Alternatively, I could just include Vector.h and be done with it.
>>> 
>>> Thoughts?
>> 
>> Is there anything in Forward.h that should not be included everywhere you 
>> include Vector.h, whether for efficiency or any other reasons? That's the 
>> only potential thing I can think of that may be wrong with this plan. In 
>> that case, the simple fix would be to have a separate VectorForward.h which 
>> can be included by both.
> 
> I thought about that, and it seems like Forward.h is so tiny that it 
> shouldn’t be an issue. If it ever starts including other WTF things then we 
> should definitely do what you say, but I don’t think we should at the moment. 
> Or put another way, if Forward.h doesn’t purely forward-declare things then 
> it’s doing it wrong. :-)
> 
> ___
> 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] Forward.h's Vector

2017-09-13 Thread JF Bastien 


> On Sep 13, 2017, at 11:07, Maciej Stachowiak <m...@apple.com> wrote:
> 
> 
> 
>> On Sep 13, 2017, at 8:11 AM, JF Bastien <jfbast...@apple.com 
>> <mailto:jfbast...@apple.com>> wrote:
>> 
>> Hello WebCritters,
>> 
>> I’m moving some code around, and one particular header I have is included 
>> everywhere in JSC so I’d like it to be lightweight and include as few other 
>> headers as possible. It unfortunately uses WTF::Vector, but it only does so 
>> as a pointer:
>> 
>> void ohNoes(Vector*);
>> 
>> It seems like something a forward declaration would fix nicely, and oh joy 
>> and wonder we have Forward.h just for this! Here’s what it does:
>> 
>> template> minCapacity, typename Malloc> class Vector;
>> 
>> That’s nice and great for T, but all the other template parameters are SOL 
>> because Vector is actually declared with default template parameters:
>> 
>> template> CrashOnOverflow, size_t minCapacity = 16, typename Malloc = FastMalloc>
>> class Vector : private VectorBuffer<T, inlineCapacity, Malloc> {
>> 
>> The extra painful thing is that, contrary to what I originally thought, one 
>> cannot declare Vector in Forward.h and then define it in Vector.h with the 
>> same defaults twice! Ideally the compiler would just yell at a mismatch, but 
>> instead it says error: template parameter redefines default argument (thanks 
>> clang, that’s exactly what I’m trying to do, just tell me if you catch a 
>> mismatch and ODR away otherwise).
>> 
>> Here’s what I propose:
>> 
>> Change the forward declaration in Forward.h to contain the default template 
>> parameters (and forward-declare CrashOnOverflow).
>> Remove these default template parameters from Vector.h.
>> Include Forward.h in Vector.h.
>> Optionally, if the WebCritters think it useful, leave a comment just above 
>> the Vector definition redirecting to Forward.h for defaults (or more fancy, 
>> use size_t inlineCapacity /*=0*/ style like LLVM’s codebase does, and have a 
>> tool that checks for consistency).
>> Optionally, try to fix C++20 so this isn’t A Thing anymore. Note that my 
>> hopes are low because of modules (why fix it if modules will magically make 
>> this not a thing).
>> 
>> Alternatively, I could just include Vector.h and be done with it.
>> 
>> Thoughts?
> 
> Is there anything in Forward.h that should not be included everywhere you 
> include Vector.h, whether for efficiency or any other reasons? That's the 
> only potential thing I can think of that may be wrong with this plan. In that 
> case, the simple fix would be to have a separate VectorForward.h which can be 
> included by both.

I thought about that, and it seems like Forward.h is so tiny that it shouldn’t 
be an issue. If it ever starts including other WTF things then we should 
definitely do what you say, but I don’t think we should at the moment. Or put 
another way, if Forward.h doesn’t purely forward-declare things then it’s doing 
it wrong. :-)

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

[webkit-dev] Forward.h's Vector

2017-09-13 Thread JF Bastien 
Hello WebCritters,

I’m moving some code around, and one particular header I have is included 
everywhere in JSC so I’d like it to be lightweight and include as few other 
headers as possible. It unfortunately uses WTF::Vector, but it only does so as 
a pointer:

void ohNoes(Vector*);

It seems like something a forward declaration would fix nicely, and oh joy and 
wonder we have Forward.h just for this! Here’s what it does:

template class Vector;

That’s nice and great for T, but all the other template parameters are SOL 
because Vector is actually declared with default template parameters:

template
class Vector : private VectorBuffer {

The extra painful thing is that, contrary to what I originally thought, one 
cannot declare Vector in Forward.h and then define it in Vector.h with the same 
defaults twice! Ideally the compiler would just yell at a mismatch, but instead 
it says error: template parameter redefines default argument (thanks clang, 
that’s exactly what I’m trying to do, just tell me if you catch a mismatch and 
ODR away otherwise).

Here’s what I propose:

Change the forward declaration in Forward.h to contain the default template 
parameters (and forward-declare CrashOnOverflow).
Remove these default template parameters from Vector.h.
Include Forward.h in Vector.h.
Optionally, if the WebCritters think it useful, leave a comment just above the 
Vector definition redirecting to Forward.h for defaults (or more fancy, use 
size_t inlineCapacity /*=0*/ style like LLVM’s codebase does, and have a tool 
that checks for consistency).
Optionally, try to fix C++20 so this isn’t A Thing anymore. Note that my hopes 
are low because of modules (why fix it if modules will magically make this not 
a thing).

Alternatively, I could just include Vector.h and be done with it.

Thoughts?

JF

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

Re: [webkit-dev] Get rid of RefPtr, replace with std::optional?

2017-09-01 Thread JF Bastien 
The standard wants you to specialize things in std sometimes, and not other
times... I’m not sure here’s clear guidance here. :(

On Fri, Sep 1, 2017 at 10:46 AM Maciej Stachowiak  wrote:

>
>
> > On Sep 1, 2017, at 10:07 AM, Brady Eidson  wrote:
> >
> >
> >
> >> On Sep 1, 2017, at 9:46 AM, Maciej Stachowiak  wrote:
> >>>
> >>> Does RefPtr do anything for us today that std::optional doesn’t?
> >>
> >> The obvious things would be: uses less storage space
> >
> > Grumble. If that’s true (which, thinking about it, of course it is true)
> this is pretty much a nonstarter. So… nevermind.
>
> It might be possible to make a specialization of std::optional that
> avoids the overhead for a separate initialized bool. I'm not sure if it is
> wise to write specializations of standard library template classes though.
>
> Regards,
> Maciej
>
>
> ___
> 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] How we enable template functions

2017-08-22 Thread JF Bastien 
I'd suggest considering what it'll look like when we're migrating to
concepts in C++20.

Here's an example for our bitwise_cast:
https://github.com/jfbastien/bit_cast/blob/master/bit_cast.h#L10

Notice the 3 ways to enable. There's also the option of using enable_if on
the return value, or as a defaulted function parameter, but I'm not a huge
fan of either.

On Tue, Aug 22, 2017 at 9:13 PM, Chris Dumez  wrote:

> I personally prefer std::enable_if<>. For e.g.
>
> template int>::value>
> Class Foo { }
>
> I don’t like that something inside the body of a class / function would
> cause a template to be enabled or not.
>
> --
>  Chris Dumez
>
>
>
>
> On Aug 22, 2017, at 8:34 PM, Keith Miller  wrote:
>
> Hello fellow WebKittens,
>
> I’ve noticed over time that we don’t have standard way that we enable
> versions of template functions/classes (flasses?). For the most part it
> seems that people use std::enable_if, although, it seems like it is
> attached to every possible place in the function/class.
>
> I propose that we choose a standard way to conditionally enable a template.
>
> There are a ton of options; my personal favorite is to add the following
> macro:
>
> #define ENABLE_TEMPLATE_IF(condition) static_assert(condition, “template
> disabled”)
>
> Then have every function do:
>
> template
> void foo(…)
> {
>ENABLE_TEMPLATE_IF(std::is_same::value);
>…
> }
>
> And classes:
>
> template
> class Foo {
>ENABLE_TEMPLATE_IF(std::is_same::value);
> };
>
> I like this proposal because it doesn’t obstruct the signature/declaration
> of the function/class but it’s still obvious when the class is enabled.
> Obviously, I think we should require that this macro is the first line of
> the function or class for visibility. Does anyone else have thoughts or
> ideas?
>
> Cheers,
> Keith
>
> P.S. in case you are wondering why this macro works (ugh C++), it’s
> because if there is any compile time error in a template it cannot be
> selected as the final candidate. In my examples, if you provided a type
> other than int foo/Foo could not be selected because the static_assert
> condition would be false, which is a compile error.
> ___
> 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] C++17 is here. Should we use it?

2017-08-04 Thread JF Bastien 
Hello WebKilters,

Our Chrome-y friends are considering the use of C++14 
.
 I have to say that C++14 in WebKit has been quite amazing, and we should 
consider using C++17: it has many wonderful new things 
, some of 
which we already use through WTF’s re-implementation of library features. By 
now (table as witness ) most 
C++17 languages features are in clang and GCC, and MSVC isn’t doing too bad 
either. Language things can just come through WTF if we really want them.

So how about it?

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

Re: [webkit-dev] Using "auto <function()> -> returnType" breaks prepare-ChangeLog

2017-07-28 Thread JF Bastien 


> On Jul 28, 2017, at 10:58, Sam Weinig <wei...@apple.com> wrote:
> 
> 
> 
>> On Jul 28, 2017, at 10:31 AM, JF Bastien <jfbast...@apple.com 
>> <mailto:jfbast...@apple.com>> wrote:
>> 
>> 
>> 
>>> On Jul 28, 2017, at 10:29, Sam Weinig <wei...@apple.com 
>>> <mailto:wei...@apple.com>> wrote:
>>> 
>>> For some generic programming, this form can be dramatically shorter:
>>> 
>>> e.g. 
>>> 
>>> template>> KeyTraitsArg, typename MappedTraitsArg>
>>> template
>>> ALWAYS_INLINE auto HashMap<KeyArg, MappedArg, HashArg, KeyTraitsArg, 
>>> MappedTraitsArg>::inlineAdd(K&& key, V&& value) -> AddResult
>>> {
>>> return m_impl.template add<HashMapTranslator<KeyValuePairTraits, 
>>> HashFunctions>>(std::forward(key), std::forward(value));
>>> }
>>> 
>>> vs.
>>> 
>>> template>> KeyTraitsArg, typename MappedTraitsArg>
>>> template
>>> ALWAYS_INLINE typename HashMap<KeyArg, MappedArg, HashArg, KeyTraitsArg, 
>>> MappedTraitsArg>::AddResult HashMap<KeyArg, MappedArg, HashArg, 
>>> KeyTraitsArg, MappedTraitsArg>::inlineAdd(K&& key, V&& value)
>>> {
>>> return m_impl.template add<HashMapTranslator<KeyValuePairTraits, 
>>> HashFunctions>>(std::forward(key), std::forward(value));
>>> }
>>> 
>>> It is also the only format available for lambdas, so people are probably 
>>> getting used to it.
>>> 
>>> Not sure it’s worth it to avoid it.
>> 
>> Agreed.
>> 
>> That being said, I’m not volunteering to fix the parser’s handling of 
>> lambdas. At that point we should really consider using clang’s AST.
> 
> I absolutely agree. For this and the style checker, it’s probably time to 
> migrate to clang tooling.

I think you misspelled “volunteer”.


> - Sam
> 
>> 
>> 
>>> - Sam
>>> 
>>>> On Jul 27, 2017, at 11:06 PM, Brady Eidson <beid...@apple.com 
>>>> <mailto:beid...@apple.com>> wrote:
>>>> 
>>>> I just noticed this tonight. When a change is made to one of these 
>>>> functions, prepare-ChangeLog doesn't log the functions that changed.
>>>> 
>>>> I have a question and a request.
>>>> 
>>>> Question:
>>>> 
>>>> The functions in question where I noticed this:
>>>> auto WebURLSchemeTask::didComplete(const ResourceError& error) -> 
>>>> ExceptionType
>>>> 
>>>> Would normally be written as:
>>>> WebURLSchemeTask::ExceptionType WebURLSchemeTask::didComplete(const 
>>>> ResourceError& error)
>>>> 
>>>> Is there some actual value to using this syntax other than… being 
>>>> syntactically different, and being just a little shorter?
>>>> 
>>>> Request:
>>>> 
>>>> Until we fix prepare-ChangeLog, and unless there is some great advantage 
>>>> to this syntax that I'm not aware of… it's hold off on using it more.
>>>> 
>>>> Thanks,
>>>> ~Brady
>>>> ___
>>>> webkit-dev mailing list
>>>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>>>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>>> <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] Using "auto <function()> -> returnType" breaks prepare-ChangeLog

2017-07-28 Thread JF Bastien 


> On Jul 28, 2017, at 10:29, Sam Weinig  wrote:
> 
> For some generic programming, this form can be dramatically shorter:
> 
> e.g. 
> 
> template KeyTraitsArg, typename MappedTraitsArg>
> template
> ALWAYS_INLINE auto HashMap MappedTraitsArg>::inlineAdd(K&& key, V&& value) -> AddResult
> {
> return m_impl.template add HashFunctions>>(std::forward(key), std::forward(value));
> }
> 
> vs.
> 
> template KeyTraitsArg, typename MappedTraitsArg>
> template
> ALWAYS_INLINE typename HashMap MappedTraitsArg>::AddResult HashMap MappedTraitsArg>::inlineAdd(K&& key, V&& value)
> {
> return m_impl.template add HashFunctions>>(std::forward(key), std::forward(value));
> }
> 
> It is also the only format available for lambdas, so people are probably 
> getting used to it.
> 
> Not sure it’s worth it to avoid it.

Agreed.

That being said, I’m not volunteering to fix the parser’s handling of lambdas. 
At that point we should really consider using clang’s AST.


> - Sam
> 
>> On Jul 27, 2017, at 11:06 PM, Brady Eidson > > wrote:
>> 
>> I just noticed this tonight. When a change is made to one of these 
>> functions, prepare-ChangeLog doesn't log the functions that changed.
>> 
>> I have a question and a request.
>> 
>> Question:
>> 
>> The functions in question where I noticed this:
>> auto WebURLSchemeTask::didComplete(const ResourceError& error) -> 
>> ExceptionType
>> 
>> Would normally be written as:
>> WebURLSchemeTask::ExceptionType WebURLSchemeTask::didComplete(const 
>> ResourceError& error)
>> 
>> Is there some actual value to using this syntax other than… being 
>> syntactically different, and being just a little shorter?
>> 
>> Request:
>> 
>> Until we fix prepare-ChangeLog, and unless there is some great advantage to 
>> this syntax that I'm not aware of… it's hold off on using it more.
>> 
>> Thanks,
>> ~Brady
>> ___
>> 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] Using "auto <function()> -> returnType" breaks prepare-ChangeLog

2017-07-28 Thread JF Bastien 
https://bugs.webkit.org/show_bug.cgi?id=174930 


I’ll trade this C++ fix for ES6 functions getting parsed properly too :D

> On Jul 27, 2017, at 23:06, Brady Eidson  wrote:
> 
> I just noticed this tonight. When a change is made to one of these functions, 
> prepare-ChangeLog doesn't log the functions that changed.
> 
> I have a question and a request.
> 
> Question:
> 
> The functions in question where I noticed this:
> auto WebURLSchemeTask::didComplete(const ResourceError& error) -> 
> ExceptionType
> 
> Would normally be written as:
> WebURLSchemeTask::ExceptionType WebURLSchemeTask::didComplete(const 
> ResourceError& error)
> 
> Is there some actual value to using this syntax other than… being 
> syntactically different, and being just a little shorter?
> 
> Request:
> 
> Until we fix prepare-ChangeLog, and unless there is some great advantage to 
> this syntax that I'm not aware of… it's hold off on using it more.
> 
> Thanks,
> ~Brady
> ___
> 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] Data Memory Barrier ARMv6 question

2017-07-05 Thread JF Bastien 


> On Jul 5, 2017, at 19:19, Caio Lima <ticaiol...@gmail.com> wrote:
> 
> 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.

I unfortunately don’t have a reference for this, but yes IIUC it’s either UP 
systems or non-A profile CPUs.

> 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] Data Memory Barrier ARMv6 question

2017-07-05 Thread JF Bastien 
Alternatively, the JIT can read the content of these addresses and write them 
back as-is 

> On Jul 5, 2017, at 09:01, Filip Pizlo <fpi...@apple.com> wrote:
> 
> We should not use those helpers, especially in the JIT. It does not make 
> sense for the JIT to emit calls to system functions when the user is 
> expecting it to emit an instruction. If we cannot perfectly select the right 
> barrier on a particular CPU, we should disable concurrency on that CPU. 
> 
> -Filip
> 
> On Jul 5, 2017, at 8:41 AM, JF Bastien <jfbast...@apple.com 
> <mailto:jfbast...@apple.com>> wrote:
> 
>> 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 
>> <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.
>> 
>> For ARMv7 and later, DMB ish is the right thing.
>> 
>> 
>>> On Jul 3, 2017, at 17:19, Caio Lima <ticaiol...@gmail.com 
>>> <mailto:ticaiol...@gmail.com>> wrote:
>>> 
>>> Hi all.
>>> 
>>> I'm working in this patch
>>> (https://bugs.webkit.org/show_bug.cgi?id=172767 
>>> <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 <mailto:webkit-dev@lists.webkit.org>
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> <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] Data Memory Barrier ARMv6 question

2017-07-05 Thread JF Bastien 
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.

For ARMv7 and later, DMB ish is the right thing.


> On Jul 3, 2017, at 17:19, Caio Lima  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] Why does our std::optional lack the has_value() function?

2017-06-19 Thread JF Bastien 
Ours was imported from: https://github.com/akrzemi1/Optional 

at: 727c729dd1d9f06f225868280e50154594d7e59d

And it was subsequently added in: 
https://github.com/akrzemi1/Optional/commit/8993daae3e9ed90be98ffb2517315f43fe9f09e4#diff-b7e55535b5ac355f0d683d30b3c87f86
 




> On Jun 19, 2017, at 21:45, Darin Adler  wrote:
> 
> I noticed we don’t have has_value() in our version of std::optional. Does 
> anyone know why?
> 
> — Darin
> ___
> 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

2017-04-28 Thread JF Bastien 

> On Apr 28, 2017, at 12:12, Maciej Stachowiak <m...@apple.com> wrote:
> 
> 
> Here's some comments in the other direction:
> 
> - If there are times we recommend x != 0 instead of !x, it should maybe be 
> based on whether the condition is better expressed as "not zero" or "false". 
> In the numTestsForEqualityComparison, that's clearly a "not zero" check given 
> the naming of the variable. This could be addressed by removing zero/non-zero 
> from the list with true/false and null/non-null instead of making a carve-out 
> based on type.
> 
> - Allowing both forms for zero/non-zero comparisons would be unfortunate. We 
> have style guidelines to avoid tiny inconsistencies like this. So if the 
> guideline changes, it should be to *require* == 0 or != 0 for numeric 
> comparisons to 0, not merely allow it. Proliferating both styles would be sad.
> 
> - If we adopted the new rule, it would be slightly sad that a bunch of old 
> code doesn't follow it. Changing it all at once would be needless churn, but 
> we'll end up with a lot of code in both styles, partly defeating the 
> consistency benefits of having a style guideline at all. This is sort of a 
> general issue with any change to the coding style guidelines. If we change 
> the guideline for a frequently used construct, the benefit has to be really 
> high to account for the fact that we'll have many years of inconsistency. 
> Note that the guidelines are mainly for the benefit of people reading the 
> code, not writing, and inconsistent style may be worse than consistently 
> using a slightly worse form.
> 
> - The style checker wouldn't be able to check the rule since it's not smart 
> enough to tell if you are doing a null check, a false check or a zero check. 
> (I am not sure if it enforces the current rule.)

That’s kind of a sad reason though. If we think it’s really worth it, we can 
move to a clang-based approach. It’ll definitely be way more powerful than 
regular expressions. I really liked how That Other Browser did this 
<https://chromium.googlesource.com/chromium/src/tools/clang/+/master> (hook 
into clang for extra diagnostics, and you also get rewriting tools for Free™).


> I don't actually have a strong opinion on the substance of the rule, either 
> version seems fine to me if we were starting from a blank slate. I'm not 
> entirely sure why the rule ended up that way in the first place. But I wanted 
> to note these as things to think about.
> 
> Regards,
> Maciej
> 
>> On Apr 28, 2017, at 1:00 AM, Keith Miller <keith_mil...@apple.com 
>> <mailto:keith_mil...@apple.com>> wrote:
>> 
>> Is there any opposition to relaxing this rule? Speak now or forever hold 
>> your piece! (not really but I would be curious to hear opposition). 
>> 
>> Cheers,
>> Keith
>> 
>>> On Apr 27, 2017, at 10:32 PM, Carlos Garcia Campos <carlo...@webkit.org 
>>> <mailto:carlo...@webkit.org>> wrote:
>>> 
>>> El jue, 27-04-2017 a las 16:06 -0700, JF Bastien escribió:
>>>> 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.
>>> 
>>> I agree, it's also quite confusing when using strcmp, because !strcmp
>>> means the strings are equal. It's not only more difficult to read, I've
>>> seen patches with wrong strcmp checks because of tha

Re: [webkit-dev] !!Tests for equality comparison

2017-04-27 Thread JF Bastien 

> On Apr 27, 2017, at 16:30, Geoffrey Garen <gga...@apple.com> wrote:
> 
> I’ve never really liked this style rule, and I’ve always felt like it snuck 
> into the style document without much discussion.

It date from 2009: https://bugs.webkit.org/show_bug.cgi?id=27333 
<https://bugs.webkit.org/show_bug.cgi?id=27333>


> Even so, I usually tolerate it.
> 
> Geoff
> 

> On Apr 27, 2017, at 16:10, Filip Pizlo <fpi...@apple.com> wrote:
> 
> I think that this aspect of the style - its implications for ints - was 
> deliberate.
> 
> The code uses the !int style in so many places that this style change would 
> be a lot of churn for little benefit.  I eventually got used to this style, 
> and now it feels pretty natural.

I’m not suggesting we replace existing code. Just that we allow it for now on.

> -Filip

>> On Apr 27, 2017, at 4:06 PM, JF Bastien <jfbast...@apple.com 
>> <mailto:jfbast...@apple.com>> 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 <mailto: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] !!Tests for equality comparison

2017-04-27 Thread JF Bastien 
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

Re: [webkit-dev] Compile time increase over time

2017-04-24 Thread JF Bastien 
On Mon, Apr 24, 2017 at 11:10 AM, Alex Christensen 
wrote:

> Thanks for the data, Carlos! This is a growing problem that is hurting
> productivity.  We’ve discussed it a bit and haven’t done enough about it.
> Here are some of the ideas I’ve heard:
>
> 1) Reduce #includes by doing more forward declaring and less inlining.  We
> would probably need link time optimization to not lose performance benefits
> of inlining functions in headers.
>

https://include-what-you-use.org/
?


> 2) Use distributed build tools and caches to cover up the problem.  WebKit
> would still be prohibitively hard to compile for people without lots of
> expensive computers, but we could greatly improve the productivity of large
> teams.
> 3) Use C++ modules
>




> 4) Put more commonly included headers into precompiled headers
> 5) I remember somebody claiming a few years ago that replacing #include
> “Something.h” with #include “path/to/Something.h” reduced compile times
> because it required fewer include paths, but I don’t think anybody has
> measured the improvement recently.
> 6) Optimize the compilers we use
>
> We should look into all of these and more.  Compiling WebKit also uses a
> lot of memory, and our binary size continues to increase.
> ___
> 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] SVN trouble

2017-02-24 Thread JF Bastien 
The github mirror also seems sad:

https://github.com/WebKit/webkit/commits/master

It's at r212950.

On Fri, Feb 24, 2017 at 11:29 AM, Carlos Alberto Lopez Perez <
clo...@igalia.com> wrote:

> On 24/02/17 20:16, Alexey Proskuryakov wrote:
> >
> > How does one create a local git-svn checkout to try this out? Given that
> > the offending file has been effectively deleted from svn, I think that
> > git-svn should work too.
>
> You have the script:
> Tools/Scripts/webkit-patch setup-git-clone
>
> And there is more doc here:
> https://trac.webkit.org/wiki/UsingGitWithWebKit
>
> I can confirm that now it seems to work :) Thanks.
>
> Also the git mirror is now updated beyond r212951.
>
> How do you fixed this?
>
> I see now that the files on r212951 have different sha1 hashes:
>
> $ svn co https://svn.webkit.org/repository/webkit/trunk/
> LayoutTests/http/tests/cache/@r212951
>
> $ find cache/|grep pdf|xargs sha1sum
> 1880d3e60a5f888c5eb077dd6c52a9a80423d971  cache/disk-cache/resources/
> shattered-1-nocollision.pdf
> 38762cf7f55934b34d179ae6a4c80cadccbb7f0a  cache/disk-cache/resources/
> shattered-1.pdf
> 682ca0c01721fe5e49a91da2253b4aa2fe2cde1c  cache/disk-cache/resources/
> shattered-2-nocollision.pdf
>
>
>
> ___
> 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] Why does RELEASE_ASSERT not have an error message?

2017-02-22 Thread JF Bastien 
Do we get the dataLog output in a crash report? It seems useful to have at
a minimum some "reason" enum which ends up in a register, so the crash
report is somewhat helpful, like we do with JIT code.

At that point the release assert might as well capture __LINE__ and other
things in a register, so that crash reporter picks it up.

Not that the dataLog isn't useful -- it is! -- just not as useful if it
isn't in crash reports.

On Wed, Feb 22, 2017 at 11:09 AM, Filip Pizlo  wrote:

> I disagree actually.  I've lost countless hours to converting this:
>
> RELEASE_ASSERT(blah)
>
> into this:
>
> if (!blah) {
>dataLog("Reason why I crashed");
>RELEASE_ASSERT_NOT_REACHED();
> }
>
> Look in the code - you'll find lots of stuff like this.
>
> I don't think analyzing register state at crashes is more important than
> keeping our code sane.
>
> -Filip
>
>
> > On Feb 21, 2017, at 5:56 PM, Mark Lam  wrote:
> >
> > Oh yeah, I forgot about that.  I think the register state is more
> important for crash analysis, especially if we can make sure that the
> compiler does not aggregate the int3s.  I’ll explore alternatives.
> >
> >> On Feb 21, 2017, at 5:54 PM, Saam barati  wrote:
> >>
> >> I thought the main point of moving to SIGTRAP was to preserve register
> state?
> >>
> >> That said, there are probably places where we care more about the
> message than the registers.
> >>
> >> - Saam
> >>
> >>> On Feb 21, 2017, at 5:43 PM, Mark Lam  wrote:
> >>>
> >>> Is there a reason why RELEASE_ASSERT (and friends) does not call
> WTFReportAssertionFailure() to report where the assertion occur?  Is this
> purely to save memory?  svn blame tells me that it has been this way since
> the introduction of RELEASE_ASSERT in r140577 many years ago.
> >>>
> >>> Would anyone object to adding a call to WTFReportAssertionFailure() in
> RELEASE_ASSERT() like we do for ASSERT()?  One of the upside (side-effect)
> of adding this call is that it appears to stop the compiler from
> aggregating all the RELEASE_ASSERTS into a single code location, and this
> will help with post-mortem crash debugging.
> >>>
> >>> Any thoughts?
> >>>
> >>> Mark
> >>>
> >>> ___
> >>> 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

2017-01-11 Thread JF Bastien 
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.



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

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

2017-01-10 Thread JF Bastien 
>
> auto thingLength = getLengthOfThing();
> IntSize size(thingLength, 2); // Can’t tell by reading if thingLength is
> LayoutUnit or float and thus truncated here.
>

The same is true for:
int thingLength = getLengthOfThing();
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Reducing the use of EncodedJSValue and use JSValue directly instead.

2017-01-03 Thread JF Bastien 
On Tue, Jan 3, 2017 at 2:54 PM, Geoffrey Garen  wrote:

> EncodedJSValue was always just a work-around to convince the compiler to
> put a JSValue in registers (instead of on the stack, with different
> compilers disagreeing about where on the stack).
>
> I agree with removing EncodedJSValue if possible.
>
> Did something change to make this possible? For example, are you sure that
> Windows and 32bit are OK with this change?
>

Recent MSVC seems happy, 32- and 64-bit: https://godbolt.org/g/XVaDyz
Unless you had another example in mind?


I don’t understand why C linkage would affect things: Either the compiler
> puts structs in registers or it doesn’t.
>
> Geoff
>
> On Jan 3, 2017, at 2:44 PM, Filip Pizlo  wrote:
>
> I think that this is great!
>
> I agree with the policy that we should use JSValue everywhere that it
> would give us the same codegen/ABI (args in registers, return in registers,
> etc).
>
> -Filip
>
> On Jan 3, 2017, at 14:33, Mark Lam  wrote:
>
> Over the holiday period, I looked into the possibility of giving
> EncodedJSValue a default constructor (because I didn’t like having to
> return encodedJSValue() instead of { } in lots of places), and learned why
> we had EncodedJSValue in the first place (i.e. for C linkage).  This led me
> to discover (in my reading of the code) that we don’t really need to use
> EncodedJSValue for most of our host functions (those of type
> NativeFunction, GetValueFunc, and PutValueFunc).
>
> I propose that we switch to using JSValue directly where we can.  This has
> the benefit of:
> 1. better type safety with the use of JSValue (EncodedJSValue is a int64_t
> typedef).
> 2. more readable code (less marshaling back and forth with
> JSValue::encode()/decode()).
>
> The patch for this change can be found here:
> https://bugs.webkit.org/show_bug.cgi?id=166658
>
> Perf is neutral.  Any opinions?
>
> Thanks.
>
> Mark
>
> ___
> 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] Naming preference: SetForScope vs. TemporaryChange

2016-12-22 Thread JF Bastien 
"Scope" seems to capture the C++ nature better.

"Temporary" isn't clear on how long it'll last IMO.


On Thu, Dec 22, 2016 at 6:28 PM Saam barati  wrote:

> Hi all,
>
> Recently, Yusuke found that JSC and WTF both had the exact same RAII
> helper data structure. JSC called it SetForScope, and WTF called it
> TemporaryChange. (Details here:
> https://bugs.webkit.org/show_bug.cgi?id=164761). Yusuke went to replace
> JSC’s use of SetForScope with TemporaryChange. When I reviewed his patch, I
> suggested to him to rename the class to SetForScope because it was my
> personal preference of the two names. However, I should have first
> discussed this change with other WebKit developers (so I’m doing that now,
> retroactively).
>
> If there is a strong preference to use the name TemporaryChange instead of
> SetForScope, I’ll rename the class back to its original name.
>
> My personal preference is still for the name SetForScope, but my feelings
> are not strongly tied to one name or the other.
>
> - 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