Re: [webkit-dev] Move to NavigationClient
On Oct 20, 2017 4:30 PM, "Alex Christensen" <achristen...@apple.com> wrote: Right now we have an API::LoaderClient, API::PolicyClient and an API::NavigationClient. We intend to remove the first two in the future in favor of the API::NavigationClient. Is there a semantic model this design decision is based on? >From the current semantic and architectural perspectives, it sounds like it would be a mistake. Particularly merging navigation duties with policy. Not helpful to all clients. Warmest regards, Alfonso Guerra Founder/CEO Apokalypse Software Corp @Huperniketes (626) 667-4285 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Idiom for functions with all return values in a switch case
On May 9, 2017 2:07 PM, "Michael Catanzaro" <mcatanz...@igalia.com> wrote:
Hi,
Consider this function:
static WKAutoplayEvent toWKAutoplayEvent(WebCore::AutoplayEvent
event)
{
switch (event) {
case WebCore::AutoplayEvent::DidEndMediaPlaybackWithoutUserInterf
erence:
return kWKAutoplayEventDidEndMediaPla
ybackWithoutUserInterference;
case WebCore::AutoplayEvent::DidPlayMediaPreventedFromPlaying:
return kWKAutoplayEventDidPlayMediaPreventedFromAutoplaying;
case WebCore::AutoplayEvent::DidPreventMediaFromPlaying:
return kWKAutoplayEventDidPreventFromAutoplaying;
case WebCore::AutoplayEvent::UserDidInterfereWithPlayback:
return kWKAutoplayEventUserDidInterfereWithPlayback;
case WebCore::AutoplayEvent::UserNeverPlayedMediaPreventedFromPla
ying:
return kWKAutoplayEventUserNeverPlaye
dMediaPreventedFromPlaying;
}
}
Out of curiosity, why is using a switch statement better than defining an
array to hold the return values?
Alfonso Guerra
Founder/CEO
Apokalypse Software Corp
@Huperniketes
(626) 667-4285
It will trigger this GCC warning:
[3490/4357] Building CXX object Source...bKit2.dir/UIProcess/A
PI/C/WKPage.cpp.o
../../Source/WebKit2/UIProcess/API/C/WKPage.cpp: In static member function
‘static WKAutoplayEvent WKPageSetPageUIClient(WKPageRef, const
WKPageUIClientBase*)::UIClient::toWKAutoplayEvent(WebCore::AutoplayEvent)’:
../../Source/WebKit2/UIProcess/API/C/WKPage.cpp:2277:9: warning: control
reaches end of non-void function [-Wreturn-type]
}
^
Such functions are very common in WebKit. What should be our preferred
idiom for suppressing this warning?
https://bugs.webkit.org/show_bug.cgi?id=171851 suggests this approach:
static WKAutoplayEvent toWKAutoplayEvent(WebCore::AutoplayEvent
event)
{
switch (event) {
// ...
}
ASSERT_NOT_REACHED();
return 0;
}
That works for the cases in that bug, but it won't work in this case,
because the return value here is an enum, so a cast would be needed.
I've been putting a RELEASE_ASSERT_NOT_REACHED() in the default case:
static WKAutoplayEvent toWKAutoplayEvent(WebCore::AutoplayEvent
event)
{
switch (event) {
// ...
default:
RELEASE_ASSERT_NOT_REACHED();
}
}
Of course, that would work just as well coming after the switch. This is
more general as it works for enums, but RELEASE_ASSERT_NOT_REACHED() is a
bunch of typing. I've seen CRASH() used frequently as well, but what's the
point of having RELEASE_ASSERT_NOT_REACHED() at all if we are using CRASH()
directly?
Opinions?
Bugs to close once we've decided how to handle this:
https://bugs.webkit.org/show_bug.cgi?id=171851
https://bugs.webkit.org/show_bug.cgi?id=171866
https://bugs.webkit.org/show_bug.cgi?id=171867
Michael
___
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] Terminology for giving up ownership: take, release, move
On Tue, Sep 6, 2016 at 4:29 AM, Daniel Olegovich Lazarenko < dani...@opera.com> wrote: .. > * "take" - a typical name for collections like a blocking queue, heap and > some others (usually ordered). If it's a collection's method, it's > logically expected to return an item. The key distinction between > fred.takeCandy() and say bowl.takeCandy() is that bowl is passive. > That doesn't make sense to me. Why would the object "bowl" be passive, but not "fred"? We treat bowl as a passive bag of data, and expect others to take from it. > I see. Like an actual bowl in the real world? > It's pretty easy to understand and remember, it makes intention more clear > than say "bowl.removeCandy()". > Not to me. When I read or write object-oriented code, I think of it as sending messages of what I want done to the object. I see the object as being an intermediator performing actions on behalf of the caller. Containers and collections are classes that group a set of functions the caller needs done, so it's more convenient to view them as being a mediator, if you will, for the caller. I think trying to map real-world behaviors into object interfaces is trying too hard to mirror the real world. I see it as imposing additional cognitive load on comprehension by requiring me to remember if it's passive or not. In fact, if it's passive that would violate the OOP and real-world paradigms: why would I be sending it a message? Especially in this day and age of smart appliances and IoT I think it's more consistent to think of the bowl as a "smart" bowl that responds to my messages. "Give me all the green candy", "sort candy by size", etc. > Pure OOP style is always the right way when it comes to readability. A > good example mentioned by Stroustrup once that it should be sqrt(5), not > 5.sqrt(). > Do you have a link for that? The closest thing I see to that example ( https://isocpp.org/blog/2014/12/myths-2) is demonstrating the exact opposite, that a non-OOP solution provides better performance by eliminating the dereferencing of a pointer. > Naming is fun. > Learning how to communicate across cultures of all types is fun. ;-) -- Alfonso Guerra Founder/CEO Apokalypse Software Corp. (626) 667-4285 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Terminology for giving up ownership: take, release, move
Is it imperative to restrict the choices to the current nomenclature? If you're finding it difficult to pick from among them, perhaps a glance through Dictionary's thesaurus will help. Something like cede, yield, or relinquish? and for the counterpart perhaps manage, contain, hold or another synonym? Alfonso Guerra Founder/CEO Apokalypse Software Corp. (626) 667-4285 On Mon, Sep 5, 2016 at 7:22 PM, Maciej Stachowiak <m...@apple.com> wrote: > > On Sep 5, 2016, at 3:30 PM, Dan Bernstein <m...@apple.com> wrote: > > > On Sep 5, 2016, at 10:13 AM, Darin Adler <da...@apple.com> wrote: > > Hi folks. > > WebKit has some critical functions that involve asking an object to give > up ownership of something so the caller can take ownership. > > In the C++ standard library itself, this is called move, as in std::move. > > In WebKit smart pointers, we call this operation release, as in > RefPtr::releaseNonNull and String::releaseImpl. > > In WebKit collections, we call this operation take, as in HashMap::take > and ExceptionOr::takeReturnValue. > > The release vs. take terminology is distracting to my eyes. The verb > “take" states what the caller wishes to do, and the verb “release” states > what the caller wants the collection or smart pointer to do. > > > This can be addressed by renaming take to give (hey, it’s right there in > the subject). > > > It's logical but reads perhaps a little strangely: > > Value& = map.give(key) > X* = x_ref.give() > > - Maciej > > > My first thought was be to rename the take functions to use the word > release instead, but I fear it might make them harder to understand instead > of easier and clearly it would make them longer. > > Does anyone have other ideas on how to collapse WebKit project terminology > down so we don’t have three different single words that are used to mean > almost the same thing? > > > Rename release to give, too? > ___ > 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] Proposal for serializing alpha channel values; request for algorithm help
On Wed, Nov 4, 2015 at 1:22 PM, Filip Pizlo <fpi...@apple.com> wrote: > > On Nov 4, 2015, at 10:03 AM, Alfonso Guerra <hupernike...@gmail.com> > wrote: > > was ~20% faster on my machine. > > > It’s very surprising that this made any difference. Compilers are > ordinarily smart enough to understand the equivalence of ++x and x++ if the > result is unused. Are you sure you compiled with optimizations enabled? > I hadn't. With full optimizations and tweaking of the driver to prevent the compiler from optimizing away invocation of the functions entirely, the difference is only ~1.3-3.3%. No longer as substantial. It beats Lightspeed C, but it's best not to depend on optimization for code which is modeled on an obsolete processor architecture, and is so easy to write. Doubly so when using non-optimized builds for development. Alfonso ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal for serializing alpha channel values; request for algorithm help
Gavin,
That's impressive problem-solving and analytical work.
However, for performance reasons the pre-increment (and pre-decrement)
operators are preferable unless one actually needs to obtain a variable's
value before updating it.
void fasterUnsignedCharToFloatString(unsigned char uc, char* out)
{
const unsigned char* data = unsignedCharToFloatData[uc];
*out = '0' + (uc == 255);
*++out = '.';
*++out = '0' + (data[0] >> 4);
*++out = '0' + (data[0] & 0xF);
*++out = '0' + (data[1] >> 4);
*++out = '0' + (data[1] & 0xF);
*++out = '0' + (data[2] >> 4);
*++out = '0' + (data[2] & 0xF);
// Remove trailing zeros.
while (*out == '0')
--out;
if (*out == '.')
--out;
*++out = '\0';
}
was ~20% faster on my machine.
Alfonso
On Wed, Nov 4, 2015 at 1:29 AM, Gavin Barraclough
wrote:
> I’m too addicted to this.
>
> I tested a few variants of BCD conversion, and based on some quick
> benchmarking on my machine it appears any would be a 40X – 50X improvement
> compared to an equivalent sprintf(_, “%f”, x/255.0).
>
> The following chart shows the speedup, table size required to hold the
> BCD, and resulting string lengths for a few different policies.
>
> *Precision*
> *Speedup vs*
> *sprintf*
> *Table Size*
> *String Length,*
> *Min*
> *String Length,*
> *Average*
> *String Length,*
> *Max*
> *default,*
> *with trailing zeros*
> ~50X
> 768 bytes
> 8
> 8
> 8
> *default,*
> *no trailing zeros*
> ~40X
> 768 bytes
> 1
> 7.8
> 8
> *±1% tolerance*
> ~40X
> 768 bytes
> 1
> 6.1
> 7
> *±5% tolerance*
> ~45X
> 512 bytes
> 1
> 5.5
> 6
> *minimal*
> ~45X
> 512 bytes
> 1
> 4.5
> 5
>
> The first configuration matches printf default precision.
> The second maintains the same accuracy but strips trailing zeros.
> The third ensures accuracy within ±1% of the granularity of the step
> between values – so 1 converts to 0.003922 ±0.3922, and 2 converts to
> 0.007843 ±0.3922, etc.
> The fourth is similar, with slightly looser tolerance.
> The fifth is the minimal precision required for values to round trip.
>
> Code for default precision with no trailing zeros below.
>
> cheers,
> G.
>
>
>
> void unsignedCharToFloatString(unsigned char uc, char* out)
> {
> const unsigned char* data = unsignedCharToFloatData[uc];
>
> *out++ = uc == 255 ? '1' : '0';
> *out++ = '.';
> *out++ = '0' + (data[0] >> 4);
> *out++ = '0' + (data[0] & 0xF);
> *out++ = '0' + (data[1] >> 4);
> *out++ = '0' + (data[1] & 0xF);
> *out++ = '0' + (data[2] >> 4);
> *out++ = '0' + (data[2] & 0xF);
>
> // Remove trailing zeros.
> while (out[-1] == '0')
> --out;
> if (out[-1] == '.')
> --out;
>
> *out = '\0';
> }
>
> static const unsigned char unsignedCharToFloatData[256][3] = {
> { 0x00, 0x00, 0x00 },
> { 0x00, 0x39, 0x22 },
> { 0x00, 0x78, 0x43 },
> { 0x01, 0x17, 0x65 },
> { 0x01, 0x56, 0x86 },
> { 0x01, 0x96, 0x08 },
> { 0x02, 0x35, 0x29 },
> { 0x02, 0x74, 0x51 },
> { 0x03, 0x13, 0x73 },
> { 0x03, 0x52, 0x94 },
> { 0x03, 0x92, 0x16 },
> { 0x04, 0x31, 0x37 },
> { 0x04, 0x70, 0x59 },
> { 0x05, 0x09, 0x80 },
> { 0x05, 0x49, 0x02 },
> { 0x05, 0x88, 0x24 },
> { 0x06, 0x27, 0x45 },
> { 0x06, 0x66, 0x67 },
> { 0x07, 0x05, 0x88 },
> { 0x07, 0x45, 0x10 },
> { 0x07, 0x84, 0x31 },
> { 0x08, 0x23, 0x53 },
> { 0x08, 0x62, 0x75 },
> { 0x09, 0x01, 0x96 },
> { 0x09, 0x41, 0x18 },
> { 0x09, 0x80, 0x39 },
> { 0x10, 0x19, 0x61 },
> { 0x10, 0x58, 0x82 },
> { 0x10, 0x98, 0x04 },
> { 0x11, 0x37, 0x25 },
> { 0x11, 0x76, 0x47 },
> { 0x12, 0x15, 0x69 },
> { 0x12, 0x54, 0x90 },
> { 0x12, 0x94, 0x12 },
> { 0x13, 0x33, 0x33 },
> { 0x13, 0x72, 0x55 },
> { 0x14, 0x11, 0x76 },
> { 0x14, 0x50, 0x98 },
> { 0x14, 0x90, 0x20 },
> { 0x15, 0x29, 0x41 },
> { 0x15, 0x68, 0x63 },
> { 0x16, 0x07, 0x84 },
> { 0x16, 0x47, 0x06 },
> { 0x16, 0x86, 0x27 },
> { 0x17, 0x25, 0x49 },
> { 0x17, 0x64, 0x71 },
> { 0x18, 0x03, 0x92 },
> { 0x18, 0x43, 0x14 },
> { 0x18, 0x82, 0x35 },
> { 0x19, 0x21, 0x57 },
> { 0x19, 0x60, 0x78 },
> { 0x20, 0x00, 0x00 },
> { 0x20, 0x39, 0x22 },
> { 0x20, 0x78, 0x43 },
> { 0x21, 0x17, 0x65 },
> { 0x21, 0x56, 0x86 },
> { 0x21, 0x96, 0x08 },
> { 0x22, 0x35, 0x29 },
> { 0x22, 0x74, 0x51 },
> { 0x23, 0x13, 0x73 },
> { 0x23, 0x52, 0x94 },
> { 0x23, 0x92, 0x16 },
> { 0x24, 0x31, 0x37 },
> { 0x24, 0x70, 0x59 },
> { 0x25, 0x09, 0x80 },
> { 0x25, 0x49, 0x02 },
> { 0x25, 0x88, 0x24 },
> { 0x26, 0x27, 0x45 },
> { 0x26, 0x66, 0x67 },
> { 0x27, 0x05, 0x88 },
> { 0x27, 0x45, 0x10 },
> { 0x27, 0x84, 0x31 },
> { 0x28, 0x23, 0x53 },
> { 0x28, 0x62, 0x75 },
> { 0x29, 0x01, 0x96 },
> { 0x29, 0x41, 0x18 },
> { 0x29, 0x80, 0x39 },
> {
Re: [webkit-dev] Unused parameter warnings / errors / warning fixes
On Mon, Jan 26, 2015 at 2:31 PM, Geoffrey Garen gga...@apple.com wrote:
And I do agree that it can be inconvenient to deal with these warnings in
heavily #ifdef’d code. I think there are some good strategies for avoiding
that, and I’d like to talk about specific irritating cases so I can propose
the strategy I’d push for. Generally the strategy is to push more
configuration specifics to the edges rather than spreading them through
multiple functions.
A few irritating cases for me:
(1)
static inline void validate(const Range range)
{
UNUSED(range);
IF_DEBUG(
BeginTag* beginTag = LargeChunk::beginTag(range.begin());
EndTag* endTag = LargeChunk::endTag(range.begin(), range.size());
BASSERT(!beginTag-isEnd());
BASSERT(range.size() = largeMin);
BASSERT(beginTag-size() == range.size());
BASSERT(beginTag-size() == endTag-size());
BASSERT(beginTag-isFree() == endTag-isFree());
BASSERT(beginTag-hasPhysicalPages() == endTag-hasPhysicalPages());
BASSERT(static_castBoundaryTag*(endTag) ==
static_castBoundaryTag*(beginTag) || endTag-isEnd());
);
}
(2)
inline void vmValidate(size_t vmSize)
{
// We use getpagesize() here instead of vmPageSize because vmPageSize
is
// allowed to be larger than the OS's true page size.
UNUSED(vmSize);
BASSERT(vmSize);
BASSERT(vmSize ==
roundUpToMultipleOf(static_castsize_t(getpagesize()), vmSize));
}
(3)
inline void vmValidate(void* p, size_t vmSize)
{
// We use getpagesize() here instead of vmPageSize because vmPageSize
is
// allowed to be larger than the OS's true page size.
vmValidate(vmSize);
UNUSED(p);
BASSERT(p);
BASSERT(p == mask(p, ~(getpagesize() - 1)));
}
The common theme in these cases is that I wanted to write a helper
function to do some ASSERTs which compiled to nothing in a release build.
Compiling the function to nothing made its parameters look like errors.
[snip]
Geoff
Are there reasons any or all of these shouldn't be written as macros?
Alfonso
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a rule to use UNUSED_PARAM ?
It's never acceptable to use comments to hide code from the compiler,
particularly when the compiler provides constructs which permit one to
indicate intent (eg, ifdef and the pragma unused).
On Oct 1, 2012 9:47 AM, Gyuyoung Kim gyuyo...@gmail.com wrote:
Hello WebKit folks,
There were build warning related to unused parameter nowadays. I think
there are three solutions. One is to remove parameter,
another is to use UNUSED_PARAM macro and the other is to use /* */ in
parameters.
I like to use UNUSED_PARAM macro except for primitive parameters
personally, for example
void foo(RenderObject* object, int /*width*/, int /*height*/) {
UNUSED_PARAM(object);
}
I'd like to know what webkittens think about this.
Cheers,
Gyuyoung
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
