Re: [webkit-dev] Pattern for singleton classes instance getters
"Class::unique()" is one of the known names for singletons Yong Li From: Maciej Stachowiak<mailto:m...@apple.com> Sent: 1/28/2015 9:11 PM To: Darin Adler<mailto:da...@apple.com> Cc: WebKit Development<mailto:webkit-dev@lists.webkit.org> Subject: Re: [webkit-dev] Pattern for singleton classes instance getters > On Jan 28, 2015, at 4:28 PM, Darin Adler wrote: > > I like the economy of the smaller non-member function name; it seems overly > wordy to be constantly stating the class name as well as the nearly > meaningless word “shared”. I think the word “shared” is what I like least > about the member function approach. > > It had always thought that we used static member functions for this to > replicate the pattern from Objective-C, and it seems more idiomatic modern > C++ to use a free function for this kind of thing. > > Maciej’s point about Class::create() might be enough to convince me to change > my view, though; it’s hard to see any reason the same logic wouldn’t apply in > that case. I would also find it acceptable to use free functions for all these cases. Mostly it bugs me for them to be different - the singleton case is rarer, so it seems odd to treat it as especially conciseness-worthy. Yet another possibility is finding a better name than ‘shared’ for the singleton pattern function, but I don’t have any better ideas. Class::getSingleton() is more explicit but the extra verbosity doesn’t seem helpful to me. 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] Type checking / casting helpers
Downcast is the old good name.
"cast" is so vague. I would assume cast(B) means: { return (A)B; }
Yong Li
From: Darin Adler<mailto:da...@apple.com>
Sent: 10/3/2014 3:16 AM
To: WebKit Development<mailto:webkit-dev@lists.webkit.org>
Subject: Re: [webkit-dev] Type checking / casting helpers
I suggested the name; my inspiration was the boost::polymorphic_downcast
function template. I also like the way a name ending with the word cast fits in
with the family of static_cast, dynamic_cast, and reinterpret_cast.
— 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] Subject: Windows CE port in WebKit: status, future work
I can also help if needed. Yong Li From: Patrick Gansterer<mailto:par...@paroga.com> Sent: 8/29/2014 10:56 AM To: Osztrogonác Csaba<mailto:o...@inf.u-szeged.hu> Cc: WebKit Development<mailto:webkit-dev@lists.webkit.org> Subject: Re: [webkit-dev] Subject: Windows CE port in WebKit: status, future work Hi Ossy, removing Windows CE code sounds ok to me, since it shouldn't be a big deal to restore it from SVN if it becomes useful again. If it's ok, I'll check the source code and post a patch in one of the next weeks? -- Patrick On 29.08.2014, at 13:42, Osztrogonác Csaba wrote: > Hi, > > Patrick Gansterer írta: >> On 31.01.2014, at 22:10, Anders Carlsson wrote >>> looks like the last legitimate commit to the Windows CE port was on >>> November 3rd November 2013, almost 3 months ago. >> What's the minimum upstream interval for downstream fixes to show ongoing >> activity? >>> I also seem to remember that there's no version of MSVC for Windows CE that >>> can handle the C++11 features that we now use in WebKit. (Correct me if I'm >>> wrong on this!) >> Windows Embedded Compact 2013 updated the compiler for CE. >>> With this in mind, does it make sense to keep the Windows CE port in the >>> tree or should we remove it? >> Does it hurt somebody in the daily workflow? If yes, where exactly? >> I'm still working on getting rid of WebKit/wince by merging it into >> WebKit/win (with only a few #if WINCE) to reduce the impact of the WinCE >> port, but it's hard if there is nobody who finds time for reviewing patches. >> :-/ (e.g. webkit.org/b/119518 or webkit.org/b/123803 waiting for months - >> but I don't want to blame somebody by this!) > > The last commit from WinCE maintainer was on 20th November 2013, > 9 months ago - https://trac.webkit.org/changeset/159534 > > Since then other contributors landed 41 changes touched WinCE files: > https://trac.webkit.org/search?q=wince&noquickjump=1&changeset=on > > Do we have any benefit if we keep these crufts in the trunk? > > br, > Ossy > ___ > 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] ftlopt merge - basically done
Thanks a lot:) Yong Li From: Osztrogonác Csaba<mailto:o...@inf.u-szeged.hu> Sent: 8/18/2014 3:51 PM To: WebKit Development<mailto:webkit-dev@lists.webkit.org> Subject: Re: [webkit-dev] ftlopt merge - basically done It works fine with EFL port on x86_64 Linux. You only need the following things: (on Ubuntu 14.04!) - apply the patch from https://bugs.webkit.org/show_bug.cgi?id=133571 - run sudo Tools/efl/install-dependencies - run WEBKIT_EXTRA_MODULES=llvm Tools/Scripts/update-webkitefl-libs - run Tools/Scripts/build-webkit --efl --ftl-jit Yong Li írta: > Has anyone managed to make an FTL build on Linux? > > Yong Li ___ 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] ftlopt merge - basically done
Has anyone managed to make an FTL build on Linux? Yong Li From: Sergio Villar Senin<mailto:svil...@igalia.com> Sent: 8/7/2014 11:58 AM To: webkit-dev@lists.webkit.org<mailto:webkit-dev@lists.webkit.org> Subject: Re: [webkit-dev] ftlopt merge - basically done On 06/08/14 23:35, Filip Pizlo wrote: > Hi everyone, > > The JSC “ftlopt” branch is basically merged. I think I have one more > revision to merge over, and it is a minor one. Please don’t land more things > on the branch. Landing on trunk is fine; it’s unlikely to get in my way as I > merge the last revision over. > > Thanks to everyone who helped with diagnostic problems and fixing things! For those not following the development in that branch, mind sharing details about what that work was about? BR ___ 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] Type cast by using toFoo()
Bottom line is turning on RTTI in debug build? From: Darin Adler<mailto:da...@apple.com> Sent: 2013-09-30 1:50 PM To: Yong Li<mailto:yong.li.web...@outlook.com> Cc: Gyuyoung Kim<mailto:gyuyoung@webkit.org>; Sam Weinig<mailto:wei...@apple.com>; WebKit Development<mailto:webkit-dev@lists.webkit.org> Subject: Re: [webkit-dev] Type cast by using toFoo() On Sep 30, 2013, at 9:54 AM, Yong Li wrote: >> > Finally I plan to add this toFoo() policy to the WebKit style checker. >> >> Can you explain more about this? How are you going to determine >> static_casts that are acceptable from ones that aren’t. > > I think it can be done by checking the vtable pointer if the classes are > virtual. The style checker runs on source code, so it can’t check things like vtable pointers. — Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Type cast by using toFoo()
I think it can be done by checking the vtable pointer if the classes are virtual. From: Sam Weinig Sent: Monday, September 30, 2013 12:53 PM To: Gyuyoung Kim Cc: Webkit Development List On Sep 30, 2013, at 3:39 AM, Gyuyoung Kim wrote: > Hello WebKittens, > > I have focused on using toFoo() for SVG and CSS instead of using > static_cast<>. Because I think there are some advantages when we use it. > > - Bad type cast can be detected by using ASSERTION in toFoo(). The toFoo() > function has an ASSERTION to check if source value is a proper super class. > - Unnecessary local variables can be removed. There are some local > variables, which are only used once in WebKit. In those cases, we don’t need > to use a local variable. Besides, we can remove unnecessary ASSERTION because > toFoo() already has it. > - I believe toFoo() can improve code readability. > > Currently, HTML, SVG Elements support toHTML|SVGFooElement() and CSSValue > also starts to support toCSSFooValue(). Please check if there is toFoo() when > you need to use static_cast<> in HTML, SVG and CSS module. Nice. > > Finally I plan to add this toFoo() policy to the WebKit style checker. Can you explain more about this? How are you going to determine static_casts that are acceptable from ones that aren’t. -Sam ___ 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] FrameLoader::stopAllLoaders and sync XHR
Hi Joe, From what I remembered and understood, actions like FrameLoader::stopAllLoaders is not safe to be executed in a nested event loop. I would try to find a way to exit all nested event loops first and then close the page if it has to be done gracefully. In EventLoopBlackBerry.cpp, the loop’s end flag is set when the thread’s isRunning() method returns false. m_ended = !BlackBerry::Platform::webKitThreadMessageClient()->isRunning(); It could be something like: m_ended = !BlackBerry::Platform::webKitThreadMessageClient()->isRunning() || ...->shouldExitNestedEventLoop(); -yong From: Joe Mason Sent: Monday, April 22, 2013 11:37 AM To: webkit-dev@lists.webkit.org Cc: Mike Lattanzio, Mike Fenton I'm trying to debug a deadlock on exit in a BlackBerry app that uses webkit (which is pretty hard to reproduce, so I don't have a cut-down test case yet). Right now my suspicions are on this behaviour: a synchronous XMLHttpRequest starts loading (from a script running in the main frame) ResourceHandle::platformLoadResourceSynchronously gets called On BlackBerry, this is implemented by creating a nested EventLoop and calling loop.cycle() While in the nested event loop, BlackBerry::WebPage::stopLoading is called This is implemented by calling m_mainFrame->loader()->stopAllLoaders() As far as I can see, FrameLoader::stopAllLoaders does NOT stop any XMLHttpRequest started from this frame - it just stops the provisionalDocumentLoader and documentLoader for the frame itself, and recursively does the same for all subframes. Is that correct? Is there a way to find and stop all synchronous requests associated with a frame? (There should be only one...) Thanks, Joe - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ 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] r- your own patches [was: Re: RenderArena: Teaching an old dog new tricks]
2012/11/16 Julien Chaffraix : >> Seconded. I also think only the one who submitted the patch can clear >> the r? flag. Others should NOT do that, please, even you are a >> reviewer. You can r- the patch if you believe it is bad. > > I disagree with that. You seem to think that patches falls into either > good or bad. However the reality is more complex and there are levels > of goodness and badness. I use r- for patches that I really think are > not in the right direction or shouldn't be landed: it is a statement True. I was inaccurate in that statement. > Clearing the flag is for patches that are close > enough but still not up to our standards and that I want to kick off > the review queue. In this case you should still r- it. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] r- your own patches [was: Re: RenderArena: Teaching an old dog new tricks]
2012/11/15 Ryosuke Niwa : > On Thu, Nov 15, 2012 at 4:28 PM, Mike Lawther > wrote: >> >> On 16 November 2012 09:59, Ryosuke Niwa wrote: >>> >>> >>> While I don’t want to further agitate the issue or go off on a tangent, >>> and agree that we must address the security aspect before getting rid of >>> RenderArena, only WebKit reviewers can r- patches written by other >>> contributors. You’re not even supposed to set r- on your own patches. See >>> http://www.webkit.org/coding/commit-review-policy.html >> >> >> I see that page says 'Note that you should not put r+ nor r- on patches in >> such unofficial reviews' with respect to a non-reviewer doing a shadow >> review. >> >> I can't see the extrapolation from that to 'you can't r- your own >> patches'. I thought r-'ing your own patch was a relatively common practice >> when uploading a WIP patch, as a signal that 'I have no intention of landing >> this patch', and as a courtesy so a reviewer will not waste any time looking >> at it (unless specifically asked). > > > r+ and r- flags are supposed to be set only by reviewers. If you wanted to > withdraw your patch from the review queue, then you should be clearing r? > flag, instead of setting r-. If you’re uploading a WIP patch, then it should > not bear either r?, r-, or r+ flags. You can accomplish this by either not > setting the flag when you upload a patch on Bugzilla, clearing flag on the > Bugzilla, or using --no-review option on webkit-patch. > > A patch with "r-" should be a patch rejected by a reviewer, not a WIP patch > the contributor decided not to proceed with. Otherwise, reviewers can’t > differentiate the patches rejected by other reviewers and patches authors > didn’t like (unless you recognize author’s IRC nickname). > > - R. Niwa > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev > Seconded. I also think only the one who submitted the patch can clear the r? flag. Others should NOT do that, please, even you are a reviewer. You can r- the patch if you believe it is bad. -yong ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
2012/7/19 Brady Eidson :
>
> On Jul 19, 2012, at 10:53 AM, Andreas Kling wrote:
>
> On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson wrote:
>>
>>
>> On Jul 10, 2012, at 5:25 AM, Alexis Menard
>> wrote:
>>
>> > On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson wrote:
>> >>
>> >> On Jul 9, 2012, at 2:43 PM, Alexis Menard
>> >> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> For those who "secretly" use printf debugging :). I know the
>> >>> recommended way is to use a debugger and it's not the point of this
>> >>> discussion.
>> >>
>> >> A lot of us do this, and sometimes it's necessary. I agree with the
>> >> gripe and support adding something easier.
>> >>
>> >>> So I propose wtf() and its stream operator.
>> >>>
>> >>> Usage :
>> >>>
>> >>> wtf()<<"Hello"<<"World"<<3<<4.53322323; will output : Hello World 3
>> >>> 4.53322
>> >>
>> >> There is no reason to bring in stream operators - that are willfully
>> >> absent from WebCore - just for debugging.
>> >>
>> >
>> > But it's really nice for that purpose, and somehow match std::cout
>>
>> And we quite purposefully don't use std::cout in the project.
>>
>> >> Overloading functions works just as well.
>> >
>> > I'm not sure to understand what you mean here…
>>
>> I mean relying on C++'s overloading of functions for the different types
>> you'd like to printf debug.
>>
>> void debug(WebCore::String&);
>> void debug(WebCore::Frame*);
>> void debug(WebCore::Node*);
>>
>> etc etc etc.
>>
>> debug(someFrame);
>> debug(someNode);
>> debug(someString);
>>
>> Especially that last one would help me from remembering how to type
>> "printf("%s", someString.utf8().data())" which is all I've ever really
>> wanted.
>
>
> Hello fellow printfers!
>
> While I'm just as ashamed of my printf habits as the next guy, I think it'd
> be great if we could move forward with this somehow.
>
> Coming from a background in Qt, the stream operator syntax looks perfectly
> normal to me, perhaps you could expand on why we want to avoid using these
> in WebKit. Is there a technical reason, or is it more of a language purity
> issue?
>
>
> A possible technical reason - that I am 100% theorizing about - is that it
> might bring in more libraries at link time or runtime since it would be the
> absolute first use of stream operators in the project.
>
> That possibility aside, the stronger part of my objection is language
> purity. WebCore uses C++ as "C with classes" and I don't think it's worth
> it to confuse new (or existing) contributors about that going forward.
>
Can you elaborate why WebCore uses C++ as "C with classes"?
We are using namespace, template, operator overloading, virtual
functions, multi-inheritance, scope object, and even
pointer-to-member. We prefer Vector<> to C array, and prefer
OwnPtr/RefPtr to C pointer. Where is C stuff?
> Regardless, adding a consistent set of debug(WebCore::MyCoolOverload)
> methods as suggested would still be massively useful.
>
>
> Definitely.
>
> ~Brady
>
>
> -Kling
>
>
>
> ___
> 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
Re: [webkit-dev] Why does PositionIterator iterates until the end of the document when selecting?
I tried skipping hidden nodes bug didn't finish the task
(https://bugs.webkit.org/show_bug.cgi?id=65377).
It would be very nice we can skip entire nodes when possible.
2012/3/30 Sergiy Byelozyorov :
> I see now. However, this creates a problem if the nearest position is really
> far. In my case we are having a huge document with over ~300 million
> characters all of which are not selectable. Just iterating over all of these
> characters takes over 10 seconds.
>
> I think the solution would be to add a possibility to skip the element with
> its children alltogether into increment function by calling
> new Node::areChildrenSelectable method. This would return true by default
> and will be overriden in some element types. Do you think it's a feasible
> solution? I am worried about the cost to the virtual function call, however
> it should only cause problems if there are really many elements as well. Is
> PositionInterator used somewhere else other than in selecting charaters?
>
> P.S. All of this text is actually not even displayed - it is used as 3D
> vertex arrays for geometry.
>
>
> Sergiy Byelozyorov
> Computer Graphics Chair
> Universitat des Saarlandes
> Tel.: +49 (681) 302-3837
> Web: http://graphics.cs.uni-saarland.de/sbyelozyorov/
>
>
>
> On Thu, Mar 29, 2012 at 22:56, Ojan Vafai wrote:
>>
>> One case where this matters: > style="-webkit-user-select:none">foobar
>>
>> If you mousedown on foo and drag right, you want to start selecting
>> bar. In the common case, we don't do any walking. The next position we grab
>> from the iterator is valid and we use it.
>>
>> On Thu, Mar 29, 2012 at 7:27 AM, Sergiy Byelozyorov
>> wrote:
>>>
>>> Hi,
>>>
>>> When searching for the character to be selected (on mouse click), we run
>>> an interator over the characters to determine the one under the cursor. I am
>>> trying to understand why does PositionInterator that is used in this case
>>> iterates over all characters starting from the element that was clicked and
>>> until the end of the document(!). The following method is called to verify
>>> whether PositionIterator has finished traversing the characters (see
>>> comments inline):
>>>
>>> bool PositionIterator::atEnd() const
>>>
>>> {
>>>
>>> if (!m_anchorNode) // This is clear - if we don't have an an anchor -
>>> then we are done.
>>>
>>> return true;
>>>
>>> if (m_nodeAfterPositionInAnchor) // This is also understandable - if
>>> there is a next position then we are not at the end.
>>>
>>> return false;
>>>
>>> // This is what puzzles me. First check will be true until we will
>>> reach the root of the Document.
>>>
>>> return !m_anchorNode->parentNode() && (m_anchorNode->hasChildNodes()
>>> || m_offsetInAnchor >= lastOffsetForEditing(m_anchorNode));
>>>
>>> }
>>>
>>>
>>> Is this the intended behaviour? Why wouldn't we just stay within the
>>> element that was clicked on? This would save us a lot of CPU cycles because
>>> we won't be checking text that in all other elements until the end of the
>>> document, wouldn't it? This check has been around since at least 2004, so I
>>> doub't that it's wrong, but I don't get the logic here. Please explain this
>>> to me. Thanks.
>>>
>>> Sergiy Byelozyorov
>>> Computer Graphics Chair
>>> Universitat des Saarlandes
>>> Tel.: +49 (681) 302-3837
>>> Web: http://graphics.cs.uni-saarland.de/sbyelozyorov/
>>>
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Removing ENABLE_SINGLE_THREADED and ENABLE_JSC_MULTIPLE_THREADS
Hi Geoffrey, >From what I understand, HTML5 Web Worker doesn't rely on threaded GC because each worker thread has its own heap. The other place affected by ENABLE_JSC_MULTIPLE_THREADS is JSLock. However it is also said platforms other than MacOS doesn't need to implement JSLock. It seems the only use of ENABLE_JSC_MULTIPLE_THREADS is to use JS API from another thread. Is this correct? Thanks, Yong Li 2011/9/8 Geoffrey Garen : > Hi folks. > > To help move WebKit and JavaScriptCore forward, I'd like to remove old > platform cruft that creates particular pain points for development. > > To that end, I'd like to remove ENABLE_SINGLE_THREADED and > !ENABLE_JSC_MULTIPLE_THREADS. I believe these code paths are untested by core > WebKit developers. Also, in the modern world of multicore CPUs, it seems > prudent to allow programmers to assume that all OS's running WebKit at least > know what a thread is how to create one. > > Thoughts? > > Thanks, > Geoff > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Slow idioms with WTF::String
How about using RopeImpl as JSString does to boost operator+=? Not
sure how bad it affects simple strings. Then another idea is to
introduce a LargeString implemented with ropes for special purposes
like parsers.
Another slow case is converting a const C string to WTF::String every
time. For example,
return (m_httpHeaderFields.contains("If-Match") ||
m_httpHeaderFields.contains("If-Modified-Since") ||
m_httpHeaderFields.contains("If-None-Match") ||
m_httpHeaderFields.contains("If-Range") ||
m_httpHeaderFields.contains("If-Unmodified-Since"));
This function creates 5 Strings (calls fastMalloc 5 times), and also
calculates the hash key 5 times, and then throws them away.
2011/7/12 Darin Adler :
> Hi folks.
>
> The key to fast use of WTF::String is to avoid creating temporary
> WTF::StringImpl objects or temporary copies of string data.
>
> With the latest enhancements to WTF::String, here are the preferred fast ways
> to build a new string:
>
> - A single expression with the + operator and arguments of type
> WTF::String, char, UChar, const char*, const UChar*, Vector, and
> WTF::AtomicString.
> - A call to the WTF::makeString function.
> - An expression that uses a single function on the string, or uses the +
> operator exactly once, or the += operator with the types it supports directly.
> - WTF::StringBuilder, in cases where the logic to compute the pieces of
> the string has complex branching logic or requires a loop.
>
> Here are acceptable, but not preferred ways to build a new string:
>
> - Building up a Vector followed by WTF::String::adopt. I believe
> StringBuilder is always better, so we should probably retire this idiom.
>
> Inefficient ways to build a new string include any uses of more than one of
> the following:
>
> - WTF::String::append.
> - The += operator.
>
> There are other operations that modify the WTF::String; none of those are
> efficient if the string in question is then modified further.
>
> - WTF::String::insert.
> - WTF::String::replace.
>
> In addition, there are quite a few operations that return a WTF::String, and
> none of those are efficient if the string in question is then modified
> further.
>
> - WTF::String::number.
> - WTF::String::substring.
> - WTF::String::left.
> - WTF::String::right.
> - WTF::String::lower.
> - WTF::String::upper.
> - WTF::String::stripWhiteSpace.
> - WTF::String::simplifyWhiteSpace.
> - WTF::String::removeCharacters.
> - WTF::String::foldCase.
> - WTF::String::format.
> - WTF::String::fromUTF8.
>
> One reason I bring this up is that if we wanted to make combinations of these
> more efficient, we might be able to use techniques similar to those used in
> StringOperators.h to make it so the entire result string is built at one
> time, eliminating unnecessary copies of the string characters and
> intermediate StringImpl objects on the heap.
>
> It would be interesting to find out how often the inefficient idioms are
> used. Until recently, there was no significantly better alternative to the
> inefficient idioms, so it’s highly likely we have them in multiple places.
>
> A quick grep showed me inefficient uses of += in
> XMLDocumentParser::handleError and XPath::FunTranslate::evaluate,
> parseRFC822HeaderFields, InspectorStyleSheet::addRule, drawElementTitle in
> DOMNodeHighlighter.cpp, WebKitCSSTransformValue::cssText,
> CSSSelector::selectorText, CSSPrimitiveValue::cssText,
> CSSBorderImageValue::cssText, and CSSParser::createKeyframeRule.
>
> I would not be surprised if at least some of these will show up immediately
> with the right kind of performance test. The CSS parsing and serialization
> functions seem almost certain to be measurably slow.
>
> I’m looking for two related things:
>
> 1) A clean way to find and root out uses of the inefficient idioms that we
> can work on together as a team.
>
> 2) Some ways to further refine WTF::String so it’s harder to “use it
> wrong”. I don’t have any immediate steps in mind, but one possibility would
> be to remove functions that are usually part of poorly-performing idioms,
> pushing WebKit programmers subtly in the direction of operations that don’t
> build intermediate strings.
>
> -- Darin
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
Similar thing: doc->frame()->document().
The solution should be defining both const and non-const members:
const Frame* frame() const { reutrn m_frame; }
Frame* frame() { return m_frame; }
2011/6/2 Yong Li :
> I think we should add a rule like "a const member function should
> never return non-const pointer/reference".
>
> I have seen the problem in many places that you can get non-const
> reference on a const object.
>
> For example, InlineTextBox has
>
> InlineTextBox* prevTextBox() const;
> InlineTextBox* nextTextBox() const;
>
> Assume you have a function: void myFunction(const InlineTextBox* textBox)
>
> When the text box has a sibling, you can easily get a non-const
> pointer by calling textBox->nextTextBox()->prevTextBox(), which sounds
> ridiculous.
>
> 2011/5/31 Geoffrey Garen :
>>>>> Even in a class that is used in a tree, I still think simple member
>>>>> variable accessor methods (that do not return tree neighbors) should be
>>>>> const.
>>>>
>>>> OK. Why?
>>>
>>> Because it indicates to me and the compiler, that the method doesn't have
>>> side effects.
>>
>> A const member function can have side effects. It can modify any global
>> state outside the object. It can also modify sub-objects inside the object,
>> and return non-const references to sub-objects and related objects that
>> might be used to produce side-effects at any time.
>>
>> It's exactly statements like this that make me think that const member
>> functions are a bad idea -- people think they provide a guarantee, but they
>> don't.
>>
>> Geoff
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
I think we should add a rule like "a const member function should never return non-const pointer/reference". I have seen the problem in many places that you can get non-const reference on a const object. For example, InlineTextBox has InlineTextBox* prevTextBox() const; InlineTextBox* nextTextBox() const; Assume you have a function: void myFunction(const InlineTextBox* textBox) When the text box has a sibling, you can easily get a non-const pointer by calling textBox->nextTextBox()->prevTextBox(), which sounds ridiculous. 2011/5/31 Geoffrey Garen : Even in a class that is used in a tree, I still think simple member variable accessor methods (that do not return tree neighbors) should be const. >>> >>> OK. Why? >> >> Because it indicates to me and the compiler, that the method doesn't have >> side effects. > > A const member function can have side effects. It can modify any global state > outside the object. It can also modify sub-objects inside the object, and > return non-const references to sub-objects and related objects that might be > used to produce side-effects at any time. > > It's exactly statements like this that make me think that const member > functions are a bad idea -- people think they provide a guarantee, but they > don't. > > Geoff > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] How much does webkit rely on non-recursive mutex?
Hi, All, I've noticed that webkit is using ASSERT(!mutex.tryLock()) in many places asserting the mutex is already locked. However this introduces a hidden assumption that WebKit Mutex is not recursive. I haven't found any other place that depends on this assumption. Have anyone seen one? If this assumption is only used in assertions, I think it would probably be better to use a boolean flag in #ifndef NDEBUG and ASSERT(mutex.isLocked()), so we can remove this unnecessary assumption. Otherwise, we should make it clear that WebKit Mutex must be non-recursive. I've opened a bug for ThreadingPthread to explicitly use PTHREAD_MUTEX_NORMAL: https://bugs.webkit.org/show_bug.cgi?id=39893 Best regards, Yong Li ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] currentTime() and UTC time
Just raised a bug for this. Except the usage in jsCurrentTime(), all calls to currentTime() in both JavaScriptCore (threading, TimeoutChecker, ProfileNode...) and WebCore (Timer, and many other cases...) are time counting and assume it never goes backward. If we make currentTime() return the system UTC time (like gettimeofday), then it will break time counting when system time is changed (e.g. by calling settimeofday()), and give unexpected results. If we make currentTime() always increase, then after user changes system time, the browser cannot provide correct JS Date until being restarted. https://bugs.webkit.org/show_bug.cgi?id=37743 2010/4/16 Yong Li > Hi All > > The default implementation of JS Date is calling currentTime() (by > jsCurrentTime()), so it assumes currentTime() returns current UTC time, and > system UTC time can be changed. However, currentTime() is also used in most > cases as a system tick count, which means it should always be monotonically > increasing. I guess we should remove the dependency on currentTime() from JS > Date to fix the confliction. > > Any idea? > > -Yong > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] currentTime() and UTC time
Hi All The default implementation of JS Date is calling currentTime() (by jsCurrentTime()), so it assumes currentTime() returns current UTC time, and system UTC time can be changed. However, currentTime() is also used in most cases as a system tick count, which means it should always be monotonically increasing. I guess we should remove the dependency on currentTime() from JS Date to fix the confliction. Any idea? -Yong ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] cannot receive e-mail from webkit bugzilla
I cannot receive any e-mail notification from webkit bugzilla since I unsubscribed from list webkit-unassigned. And when I tried to subscribe to webkit-unassigned again, I got "you hit a bug" message. Can anyone help me? -Yong ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] "statement is unreachable" warnings
RVCT reports a "statement is unreachable" warning in this case:
while (true) {
// no break in the loop
...
return someValue;
...
return someValue;
}
ASSERT_NOT_REACHED();
return someValue;
I understand that if we remove the last return statement, some compilers
will complain that "not all paths return a value".
So how about adding a macro "UNREACHABLE_RETURN(valueToReturn)"?
Like this:
#if COMPILER(RVCT)
#define UNREACHABLE_RETURN(valueToReturn) // nothing here
#else
#define UNREACHABLE_RETURN(valueToReturn) \
ASSERT_NOT_REACHED(); \
return valueToReturn;
#endif
-Yong
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit style for switch statement
Thanks, Eric, Darin. I get it. -Yong ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKit style for switch statement
As everyone may know, current webkit style (at least for most source code)
for a switch statement is like this:
switch (var) {
case valueFirst:
...
break;
...
case valueLast:
...
break;
default:
ASSERT_NOT_REACHED()
}
This looks good. But some compilers may give a warning like: "statement is
unreachable". Disabling this warning is a solution. But this warning can
be helpful in some cases.
So, how about changing the webkit style to this?
switch (var) {
case valueFirst:
...
break;
...
default:
ASSERT(var == valueLast);
...
break;
}
-Yong
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] global new/delete operator in WebKit
2010/1/13 Zoltan Horvath > > First, Darin thanks for the summary! > > On Wednesday 13 January 2010, at 20:23, Yong Li wrote: > > Darin, thank you very much for writing this for my questions. I have > > another question for "new int[10]", but I guess the answer will be "using > > Vector instead". > > At the most of the cases WebKit doesn't use arrays like this. > I'm told that fastNewArray is for this. > > > I like the idea that webkit should allow using a custom memory allocator, > > but I think for most platforms/compilers, overloading global new/delete > > operators is much better than deriving all classes from FastAllocBase. > I've > > seen even the simple utility class "Noncopyable" is derived from > > FastAllocBase, and the follwing code: > > class A: Noncopyable > > must be changed to: > > class A: public Noncopyable > > in order to make "new A" accessible. > > As Darin said, there are platforms where you can not orverload global > new/delete, because it causes problems. > A silly question: will this abnormal problem be fixed some day? Yes, you have to inherit it publicly, fortunately, the publicly inheriting > doesn't cause performance or other loss at this cases. > > > As webkit provides the option of using custom allocator with > FastAllocBase > > for some special platform/compiler, why does it ban the option of using > > global new/delete operators on other platforms/compilers? At least, when > > USE_SYSTEM_MALLOC=1, FastAllocBase should just be empty or redirect to > > global new/delete in my opinion. > > > > -Yong > > We don't ban it yet. :-) What kind of platforms do mean? > Sorry for my English. "does" should be "will". I just think overloading global new/delete operators is much cleaner than deriving all classes from a root class and using fastNew<> and fastNewArray<>, unless the platform doesn't support it, though :) > Zoltan > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] global new/delete operator in WebKit
Darin, thank you very much for writing this for my questions. I have another question for "new int[10]", but I guess the answer will be "using Vector instead". I like the idea that webkit should allow using a custom memory allocator, but I think for most platforms/compilers, overloading global new/delete operators is much better than deriving all classes from FastAllocBase. I've seen even the simple utility class "Noncopyable" is derived from FastAllocBase, and the follwing code: class A: Noncopyable must be changed to: class A: public Noncopyable in order to make "new A" accessible. As webkit provides the option of using custom allocator with FastAllocBase for some special platform/compiler, why does it ban the option of using global new/delete operators on other platforms/compilers? At least, when USE_SYSTEM_MALLOC=1, FastAllocBase should just be empty or redirect to global new/delete in my opinion. -Yong 2010/1/13 Darin Adler > In the discussion in bug 32831, Yong Li asked me why we are planning, in > the future, to remove the global new/delete operator in the Mac OS X WebKit. > > I decided it was worth answering here. > > Why does WebKit override operator new/delete? Historically on Mac OS X we > got faster performance by using a custom malloc in the WebKit framework. At > some future date we may discover that we no longer get a performance boost > from this, and change this on Mac OS X. > > Ports to other platforms should not assume they need to use a custom > allocator. It’s not a given that the FastMalloc code will be faster than > using the platform malloc/free directly. But it was true in the first WebKit > platform, Mac OS X, at the time. > > On Mac OS X, WebKit overrides the global operator new and delete to > accomplish this. That was a big time saver — it made all new and delete use > the faster allocator without code changes to all the classes. This > particular technique works well for frameworks on Mac OS X. The inlined new > and delete operator functions are marked “private extern”, which means they > are visible inside the WebKit umbrella framework, but not seen by programs > loading the framework. As long as we don’t have any new/delete allocations > that cross the boundary between WebKit and the host application or other > frameworks, this works fine. The new/delete invocations inside WebKit use > the global new/delete defined inside the framework and the new/delete > invocations outside WebKit are not affected. > > On some other platforms, though, this creates problems. An operator new and > delete defined inside the WebKit library may not even work, depending on how > C++ binds the symbols. The “private extern” extension may not work at all. > Or the API for that platform might involve objects where the new is done > inside the framework and the delete is done outside the framework. A simple > solution would be to not override the global new/delete operator on those > platforms. > > But some contributors want to use a custom allocator even though the global > new/delete operator technique does not work on the platform they care about. > So they began the massive task of adding code so that all allocations in > WebKit were done through the custom allocator without relying on global > new/delete. This project, see < > https://bugs.webkit.org/show_bug.cgi?id=20422> began in 2008. The > check-ins to put it into practice began las April < > http://trac.webkit.org/changeset/42344>. We’ve still got a ways to go to > get it deployed throughout the WebKit code. > > To keep this code maintained properly, I propose that no platform rely on > overriding the global new/delete operator inside WebKit once the work is > complete. Instead I think we can use global new/delete operator as a > debugging technique to make sure people remember to use FastAllocBase and > fastNew/Delete rather than invoking the built-in C++ new/delete by accident. > This has no direct benefit for the Mac OS X version of WebKit, but I believe > it’s helpful for the community to use that platform to support the others > that wish to do this. > > Yong Li also asked about standard library functions calling new and delete, > specifically STL. I believe we have been avoiding calling these functions in > WebKit, but I may be mistaken. > > I haven’t discussed this tradeoff in detail with others at Apple, so I’m > not absolutely certain what we’ll do in the Mac OS X version. > > If you have any questions or concerns, please bring them up here. > >-- Darin > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] String 4-byte alignment issue
Hi, Please take a look at bug 31475 https://bugs.webkit.org/show_bug.cgi?id=31475 There're 2 ways to fix this: 1. let StringImpl::create(UString...) create new copy if UString::data() is not aligned to 4 bytes. 2. remove dependencies on 4-byte aligment of String::characters(), probably just with #ifdef... Which one is better solution? -Yong ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] MutationEvent
Hi, All,
Why there are #if 0 here? First, I'm told "#if 0" is not webkit style.
Second, the disabled code seems useful.
void Element::dispatchAttrRemovalEvent(Attribute*)
{
ASSERT(!eventDispatchForbidden());
#if 0
if (!document()->hasListenerType(Document::DOMATTRMODIFIED_LISTENER))
return;
ExceptionCode ec = 0;
dispatchEvent(new MutationEvent(DOMAttrModifiedEvent, true, false, attr,
attr->value(),
attr->value(), document()->attrName(attr->id()),
MutationEvent::REMOVAL), ec);
#endif
}
void Element::dispatchAttrAdditionEvent(Attribute*)
{
ASSERT(!eventDispatchForbidden());
#if 0
if (!document()->hasListenerType(Document::DOMATTRMODIFIED_LISTENER))
return;
ExceptionCode ec = 0;
dispatchEvent(new MutationEvent(DOMAttrModifiedEvent, true, false, attr,
attr->value(),
attr->value(), document()->attrName(attr->id()),
MutationEvent::ADDITION), ec);
#endif
}
Best regards,
-Yong
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] DEFINE_STATIC_LOCAL
I just noticed the following code: #else #define DEFINE_STATIC_LOCAL(type, name, arguments) \ static type& name = *new type arguments #endif Is there any reason of doing this? For example, we want to prevent dtors of all static objects from being called? Best regards, Yong Li ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] virtual functions in ChromeClient and other clients
Ha, never mind, then. -yong - Original Message - From: "Eric Seidel" To: "Yong Li" Cc: "WebKit Development" Sent: Thursday, October 22, 2009 3:52 PM Subject: Re: [webkit-dev] virtual functions in ChromeClient and other clients On Thu, Oct 22, 2009 at 12:20 PM, Yong Li wrote: ChromeClient and other clients defined in webkit are using a lot of WebCore objects. So it seems impossible to provide a ChromeClient from another binary other than webkit itself. In other words, ChromeClient is almost always implemented in a static lib that's linked with WebCore together. This statement is false. WebCore is built as a dynamic library on Mac OS X. WebKit provides a ChromeClient: http://trac.webkit.org/browser/trunk/WebKit/mac/WebCoreSupport/WebChromeClient.h -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] virtual functions in ChromeClient and other clients
Oops, even m_page is a data member.
Hm... I need to think more about it.
-Yong
- Original Message -
From: "Yong Li"
To: "Adam Barth"
Cc: "WebKit Development"
Sent: Thursday, October 22, 2009 3:28 PM
Subject: Re: [webkit-dev] virtual functions in ChromeClient and other
clients
Usually, those clients call WebPage or WebFrame to access the data
members.
For example:
ChromeClient::doSomething()
{
m_page->doSomething();
}
-Yong
- Original Message -
From: "Adam Barth"
To: "Yong Li"
Cc: "WebKit Development"
Sent: Thursday, October 22, 2009 3:25 PM
Subject: Re: [webkit-dev] virtual functions in ChromeClient and other
clients
How would the class implementing ChromeClient hold any data members?
I guess we could use pimpl...
Adam
On Thu, Oct 22, 2009 at 12:20 PM, Yong Li wrote:
Hi All,
ChromeClient and other clients defined in webkit are using a lot of
WebCore
objects. So it seems impossible to provide a ChromeClient from another
binary other than webkit itself. In other words, ChromeClient is almost
always implemented in a static lib that's linked with WebCore together.
If that's true, why do we need those "virtual" functions? One reason
might
be for this case:
class WebPage: public ChromeClient, public EditorClient, public . {
};
But I see most ports implement these clients with single classes. If we
can
make this mandatory, then we can remove these "virtual" words from these
client interface, and then the compilers could make those functions
"inline"
whenever suitable. I guess this could boost performance a little bit.
Best regards,
Yong Li
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] virtual functions in ChromeClient and other clients
Usually, those clients call WebPage or WebFrame to access the data members.
For example:
ChromeClient::doSomething()
{
m_page->doSomething();
}
-Yong
- Original Message -
From: "Adam Barth"
To: "Yong Li"
Cc: "WebKit Development"
Sent: Thursday, October 22, 2009 3:25 PM
Subject: Re: [webkit-dev] virtual functions in ChromeClient and other
clients
How would the class implementing ChromeClient hold any data members?
I guess we could use pimpl...
Adam
On Thu, Oct 22, 2009 at 12:20 PM, Yong Li wrote:
Hi All,
ChromeClient and other clients defined in webkit are using a lot of
WebCore
objects. So it seems impossible to provide a ChromeClient from another
binary other than webkit itself. In other words, ChromeClient is almost
always implemented in a static lib that's linked with WebCore together.
If that's true, why do we need those "virtual" functions? One reason might
be for this case:
class WebPage: public ChromeClient, public EditorClient, public . {
};
But I see most ports implement these clients with single classes. If we
can
make this mandatory, then we can remove these "virtual" words from these
client interface, and then the compilers could make those functions
"inline"
whenever suitable. I guess this could boost performance a little bit.
Best regards,
Yong Li
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] virtual functions in ChromeClient and other clients
Hi All,
ChromeClient and other clients defined in webkit are using a lot of WebCore
objects. So it seems impossible to provide a ChromeClient from another binary
other than webkit itself. In other words, ChromeClient is almost always
implemented in a static lib that's linked with WebCore together.
If that's true, why do we need those "virtual" functions? One reason might be
for this case:
class WebPage: public ChromeClient, public EditorClient, public . {
};
But I see most ports implement these clients with single classes. If we can
make this mandatory, then we can remove these "virtual" words from these client
interface, and then the compilers could make those functions "inline" whenever
suitable. I guess this could boost performance a little bit.
Best regards,
Yong Li___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Calling all committers: The pending-commit list isoverflowing
I'm able to do it now. Thanks. -Yong - Original Message - From: "Eric Seidel" To: "Yong Li" Cc: "Adam Barth" ; Sent: Monday, October 19, 2009 11:33 AM Subject: Re: [webkit-dev] Calling all committers: The pending-commit list isoverflowing yong...@torchmobile.com did not have "Edit Bugs" privileges in bugzilla's database. I've fixed that. You should be able to set flags now. On Mon, Oct 19, 2009 at 8:25 AM, Yong Li wrote: - Original Message - From: "Adam Barth" To: Sent: Monday, October 19, 2009 3:21 AM Subject: Re: [webkit-dev] Calling all committers: The pending-commit list isoverflowing If you're a committer, you can help drive that number to zero. Here's what you can do: 1) If you have a patch on that list, please land it. 2) If you see a patch on the list that's ready to land (almost all of them), you can mark it commit-queue+ to have the commit bot land it. When you do this, please be sure to watch the tree for regressions, just like you would if you typed svn commit yourself. I got this: "You are not authorized to edit this patch." Thanks and happy WebKitting, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Calling all committers: The pending-commit list isoverflowing
- Original Message - From: "Adam Barth" To: Sent: Monday, October 19, 2009 3:21 AM Subject: Re: [webkit-dev] Calling all committers: The pending-commit list isoverflowing If you're a committer, you can help drive that number to zero. Here's what you can do: 1) If you have a patch on that list, please land it. 2) If you see a patch on the list that's ready to land (almost all of them), you can mark it commit-queue+ to have the commit bot land it. When you do this, please be sure to watch the tree for regressions, just like you would if you typed svn commit yourself. I got this: "You are not authorized to edit this patch." Thanks and happy WebKitting, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Single threaded database solution
Would any reviewer want to review this patch? https://bugs.webkit.org/show_bug.cgi?id=28019 It has been hanging there for a while, after I modified the patch according to Jeremy's suggestions. (Many thanks to Jeremy) Best regards, Yong Li___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] unwritten rules of webkit style
I guess gcc complains if file doesn end with new line? -Yong - Original Message - From: Darin Adler To: Brent Fulgham Cc: WebKit Development Sent: Thursday, September 03, 2009 1:11 PM Subject: Re: [webkit-dev] unwritten rules of webkit style On Sep 2, 2009, at 11:18 PM, Brent Fulgham wrote: On Sep 2, 2009, at 9:46 AM, Peter Kasting wrote: Misc Files who should end with newlines. s/who//. In fact it might be clearer to say "Files should end with a trailing newline". I always follow this rule, but I don't remember why it came to exist. Is this convention needed for source control or something? It’s not needed for anything. Tools like diff produce slightly unpleasant output for files that don’t end in newlines, so we include them. -- Darin -- ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] static const
MSDN also has such statement: "const" global variables in C++ is implicitly static, where it's implicitly extern in C. For "extern const", the module that contains a initializer "extern const int bar = foo;" is the owner of the object. re: Albert J. Wong: I also use "static const" for function scope variables. Thanks for the experiment. -Yong - Original Message - From: "Alexey Proskuryakov" To: "Darin Adler" Cc: "WebKit Development" Sent: Wednesday, September 02, 2009 12:55 PM Subject: Re: [webkit-dev] static const 02.09.2009, в 9:32, Darin Adler написал(а): As an aside, is there any practical difference between "static const" and "const" in C++? The only difference I'm aware of is that the former is deprecated in the standard. I believe the former gives internal linkage and the latter external linkage, so I always use the former for things defined in a source file and not declared in a header file and the latter for things defined or declared in a header file. I don't have a normative reference at hand, but I'm fairly sure that both give internal linkage in C++ (unlike in C). http://stackoverflow.com/questions/998425/why-does-const-imply-internal-linkage-in-c-when-it-doesnt-in-c http://bytes.com/topic/c/answers/62013-const-has-internal-linkage-c - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] unwritten rules of webkit style
For multi-line condition, the following style is most readable to me.
if (condition1
&& condition2)
{
// code...
}
- Original Message -
From: Yong Li
To: David Levin
Cc: WebKit Development
Sent: Wednesday, September 02, 2009 3:05 PM
Subject: Re: [webkit-dev] unwritten rules of webkit style
Current guideline also contains these 2 cases that {} should be used. I think
when the condition is multi-lined, this should also apply. (BTW, hate the
existing rule "no braces for one line". it doesn't give any benefit. worse than
"always use braces")if (condition) {
// Some comment
doIt();
}
if (condition) {
myFunction(reallyLongParam1, reallyLongParam2, ...
reallyLongParam5);
}
- Original Message -
From: David Levin
To: Yong Li
Cc: WebKit Development
Sent: Wednesday, September 02, 2009 2:56 PM
Subject: Re: [webkit-dev] unwritten rules of webkit style
On Wed, Sep 2, 2009 at 11:54 AM, Yong Li wrote:
{} should be added in this case:
if (condition1
&& condition2)
statement;
Not according to current WebKit style because it is a single line statement.
--
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] unwritten rules of webkit style
Current guideline also contains these 2 cases that {} should be used. I think
when the condition is multi-lined, this should also apply. (BTW, hate the
existing rule "no braces for one line". it doesn't give any benefit. worse than
"always use braces")if (condition) {
// Some comment
doIt();
}
if (condition) {
myFunction(reallyLongParam1, reallyLongParam2, ...
reallyLongParam5);
}
- Original Message -
From: David Levin
To: Yong Li
Cc: WebKit Development
Sent: Wednesday, September 02, 2009 2:56 PM
Subject: Re: [webkit-dev] unwritten rules of webkit style
On Wed, Sep 2, 2009 at 11:54 AM, Yong Li wrote:
{} should be added in this case:
if (condition1
&& condition2)
statement;
Not according to current WebKit style because it is a single line statement.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] unwritten rules of webkit style
{} should be added in this case:
if (condition1
&& condition2)
statement;
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] unwritten rules of webkit style
-- Using a prefix for constants also reduces brainprint when scanning code; you know that its value is never going to change. I agree. c_xxx might look ugly, but it is even more helpful for making the code readable than other coding rules. -Yong - Original Message - From: Simon Fraser To: Yong Li Cc: David Levin ; WebKit Development Sent: Wednesday, September 02, 2009 1:36 PM Subject: Re: [webkit-dev] unwritten rules of webkit style On Sep 2, 2009, at 9:59 AM, Yong Li wrote: I think global variables should start with "g_". -Yong I actually agree fairly strongly that constants and global/static variables should have consistent, identifiable prefixes. For globals, having a prefix code easier to understand with a quick scan. If the global has no prefix, you have to search for it and discover that it's not a local variable, member variable or parameter before understanding where it comes from. This is a particular problem in Xcode, which does not use a different syntax highlight color for globals (unlike the venerable CodeWarrior). I also think that globals are a particular concern because they impact thread safety, and misunderstanding their scope of influence can have bad ramifications. Using a prefix for constants also reduces brainprint when scanning code; you know that its value is never going to change. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] unwritten rules of webkit style
I think global variables should start with "g_". -Yong - Original Message - From: David Levin To: Yong Li Cc: WebKit Development Sent: Wednesday, September 02, 2009 12:30 PM Subject: Re: [webkit-dev] unwritten rules of webkit style On Wed, Sep 2, 2009 at 8:53 AM, Yong Li wrote: Personally I don't like most of these. Too many coding rules makes C++ programming a painful job. Some basic rules are necessary though. I think coding rules should be minimized, but not maximized. BTW, a very basic thing not defined yet: what's the webkit pattern for global variables? g_xxx? gXxx? or just same like local variables? It was in there but probably not well phrased: Constants (static const int's) should be named just like a variable and have no special prefix. Perhaps it would be Global variables should be named just like a variable and have no special prefix. fwiw, I welcome any wording adjustments that anyone may suggest. Dave -Yong - Original Message - From: David Levin To: WebKit Development Sent: Wednesday, September 02, 2009 11:40 AM Subject: [webkit-dev] unwritten rules of webkit style Here's my attempt to statestyle/coding issues which aren't in the WebKit style guide, but seem to be widely recommended. Please speak up if you think something is incorrect. If everyone agrees with these items, then eventually I plan to add them to the WebKit style document ( but I certainly wouldn't mind if someone beat me to it). Comments Comments should look like sentences by beginning with a capital and ending with a period (punctation). There should be a single space after punctation and before the next sentence. There should only be a single space before end of line comments. Use FIXME: to denote items that need to be addressed in the future. In copyright entries, don't use ranges for years. Use capital (C) for the copyright and no comma after the last year. Example of a well formed copyright entry: * Copyright (C) 2004, 2005, 2006, 2007, 2008 Apple Inc. All rights reserved. Function parameters Don't put in parameter names if they don't add information. A good rule of thumb is if the parameter type name contains the parameter name (with trailing numbers or pluralization), then the parameter name isn't needed. Usually, there should be a parameter name for bools, strings, and numerical types. Use enums instead of bools for parameters. The one exception is function names that start with "set" and take one parameter (e.g. setAllowHeaders). Classes/Structs No blank line before the first item in the class/structs. Add a blank line before public:, protected:, and private: otherwise. No blank line after them. Each section should be defined only once and they should be in the order public:, protected:, and private:. One class per file. Ideally one struct per file too but sometimes small structs that are only used in a cpp file may be in place. Constants Constants (static const int's) should be named just like a variable and have no special prefix Line length Don't add explicit line breaks in the middle of a statement unless it is severely illegible even at wide editor window width (which current code tends to treats as about 120-180 characters). Braces There should be at least one space after a brace and one space before a closing brace (when there are any characters before or after them respectively including another brace). Indentation Additional clauses in a conditional may be indented 4 extra spaces to visually separate them from the statement to be executed. Like this if (condition1 && condition2) statement; #include statements All ifdef'ed includes should be in a section after all other includes. Don't use ifdef's around includes if you don't need to. For example, if you include a header that has if ENABLE(FEATURE) around its contents, you don't need to repeat the if ENABLE when including it. #ifdef statements If a ifdef spans more than a few lines, end it like this: #endif // WhateverWasInTheIfdef Namespaces If a namespace spans more than a few lines, end it like this } // namespace NameOfNamespace Misc Do not use static initializers for classes/structs. Use DEFINE_STATIC_LOCAL instead (or AtomicallyInitializedStatic if the initialization should be threadsafe). Files who should end with newlines. Thanks, Dave --
Re: [webkit-dev] unwritten rules of webkit style
Personally I don't like most of these. Too many coding rules makes C++ programming a painful job. Some basic rules are necessary though. I think coding rules should be minimized, but not maximized. BTW, a very basic thing not defined yet: what's the webkit pattern for global variables? g_xxx? gXxx? or just same like local variables? -Yong - Original Message - From: David Levin To: WebKit Development Sent: Wednesday, September 02, 2009 11:40 AM Subject: [webkit-dev] unwritten rules of webkit style Here's my attempt to statestyle/coding issues which aren't in the WebKit style guide, but seem to be widely recommended. Please speak up if you think something is incorrect. If everyone agrees with these items, then eventually I plan to add them to the WebKit style document (but I certainly wouldn't mind if someone beat me to it). Comments Comments should look like sentences by beginning with a capital and ending with a period (punctation). There should be a single space after punctation and before the next sentence. There should only be a single space before end of line comments. Use FIXME: to denote items that need to be addressed in the future. In copyright entries, don't use ranges for years. Use capital (C) for the copyright and no comma after the last year. Example of a well formed copyright entry: * Copyright (C) 2004, 2005, 2006, 2007, 2008 Apple Inc. All rights reserved. Function parameters Don't put in parameter names if they don't add information. A good rule of thumb is if the parameter type name contains the parameter name (with trailing numbers or pluralization), then the parameter name isn't needed. Usually, there should be a parameter name for bools, strings, and numerical types. Use enums instead of bools for parameters. The one exception is function names that start with "set" and take one parameter (e.g. setAllowHeaders). Classes/Structs No blank line before the first item in the class/structs. Add a blank line before public:, protected:, and private: otherwise. No blank line after them. Each section should be defined only once and they should be in the order public:, protected:, and private:. One class per file. Ideally one struct per file too but sometimes small structs that are only used in a cpp file may be in place. Constants Constants (static const int's) should be named just like a variable and have no special prefix Line length Don't add explicit line breaks in the middle of a statement unless it is severely illegible even at wide editor window width (which current code tends to treats as about 120-180 characters). Braces There should be at least one space after a brace and one space before a closing brace (when there are any characters before or after them respectively including another brace). Indentation Additional clauses in a conditional may be indented 4 extra spaces to visually separate them from the statement to be executed. Like this if (condition1 && condition2) statement; #include statements All ifdef'ed includes should be in a section after all other includes. Don't use ifdef's around includes if you don't need to. For example, if you include a header that has if ENABLE(FEATURE) around its contents, you don't need to repeat the if ENABLE when including it. #ifdef statements If a ifdef spans more than a few lines, end it like this: #endif // WhateverWasInTheIfdef Namespaces If a namespace spans more than a few lines, end it like this } // namespace NameOfNamespace Misc Do not use static initializers for classes/structs. Use DEFINE_STATIC_LOCAL instead (or AtomicallyInitializedStatic if the initialization should be threadsafe). Files who should end with newlines. Thanks, Dave -- ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Review Queue
Hi Adam, I'm a very first user of check-webkit-style (was called cpplint when I used it), and reported some bugs of it. The current indentation issue of some construtor inialization list were actually introduced by following the suggestion of old version cpplint. It must have been improved a lot, so I should run it again. Thank you so much for those comments. I like most of them. But I have questions about something: 1. one class one file I agree that it's a good style to create a file for each class. But sometimes the class is very light, and is only useful to one module, in this case putting it in the same file won't hurt anything. Second, there're a lot of such cases in webkit existing files, including some committed in near future. So why is it the reason for r- bug 28167? 2. static initializer forbidden I'm not aware of this. Is it added in webkit code guidline? Most the patches are for WINCE port only, and they won't affect any other existing port. Also, they are not read-only after being committed. So if we think some of them should be refactored or extracted out for sharing, we can always do it in the future. The png encoder of skia can definitely be shared by other ports, but the files were still committed to image-encoders\skia. Why are people requiring so much for brand-new wince port? Thanks a lot. -Yong - Original Message ----- From: "Adam Barth" To: "Yong Li" Cc: "Eric Seidel" ; "WebKit Development" Sent: Wednesday, September 02, 2009 9:36 AM Subject: Re: [webkit-dev] Review Queue Hi Yong, Sorry for r-ing a bunch of your patches last night. I tried to give you constructive comments. As you might be aware, we have a style linter now: ./WebKitTools/Scripts/check-webkit-style It might help us skip past some of the trivial review comments (like improper indenting of initializer lists). For the patches with licensing issues, I'm not sure how best to proceed. Adam On Wed, Sep 2, 2009 at 8:29 AM, Yong Li wrote: Thanks a lot for spending time on reviewing. As a developer, I hope I can have more constructive comments for r-. I understand it's a hard work and truly appreciate all of you who spend time on it. -Yong - Original Message - From: Eric Seidel To: WebKit Development Sent: Wednesday, September 02, 2009 6:10 AM Subject: [webkit-dev] Review Queue Just your friendly reminder that the review-queue is out of control again. We're @ 54 (was 84 on Monday): https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=review%3F If a reviewers could each take a stab at r-'ing (or r+'ing!) a few patches today we'd be back under 30 in no time... -eric p.s. Thanks to Adam Barth (and others) for applying the flaming sword of r- last night. It's slightly more under control. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Review Queue
Thanks a lot for spending time on reviewing. As a developer, I hope I can have more constructive comments for r-. I understand it's a hard work and truly appreciate all of you who spend time on it. -Yong - Original Message - From: Eric Seidel To: WebKit Development Sent: Wednesday, September 02, 2009 6:10 AM Subject: [webkit-dev] Review Queue Just your friendly reminder that the review-queue is out of control again. We're @ 54 (was 84 on Monday): https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=review%3F If a reviewers could each take a stab at r-'ing (or r+'ing!) a few patches today we'd be back under 30 in no time... -eric p.s. Thanks to Adam Barth (and others) for applying the flaming sword of r- last night. It's slightly more under control. -- ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Building release on Windows Vista
I guess you've enabled link time optimization. The lib file is too big. The solution suggested by MS is to split the project. - Original Message - From: "Anton Muhin" To: "webkit-dev Development" Sent: Friday, August 21, 2009 12:03 PM Subject: [webkit-dev] Building release on Windows Vista Dear WebKit gurus, is it possible to build WebKit on Windows Vista in Release configuration? Both build from Cygwin and VS dies with: c:\WebKit\WebKit\WebKitBuild\lib\WebCore.lib : fatal error LNK1106: invalid file or disk full: cannot seek to 0x44DA4146 Clean build (wiping off WebKitBuild) has been tried. I git clone'ed rather recent version of WebKit (something two or three hours long from the time this message has been sent). Debug could be built fine from cygwin. Any hints are most appreciated. tia and yours, anton. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [47592] trunk/JavaScriptCore
I remember it happens to VC6. Seems VS2005 doesn't have this problem. -Yong - Original Message - From: "Darin Adler" To: "Yong Li" Cc: "WebKit Development" Sent: Thursday, August 20, 2009 6:12 PM Subject: Re: [webkit-changes] [47592] trunk/JavaScriptCore On Aug 20, 2009, at 2:04 PM, Yong Li wrote: If derefIfNotNull() is not inline, it should be static. Otherwise, you can potentially get a build error like multiple bodies of "derefIfNotNull" are found. If this is not a problem to winscw compiler, ignore this mail. I believe that is true for functions, but not function templates. Have you seen an actual problem? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] renaming namespace ARM to ARMRegisters
Would anyone please take a look at https://bugs.webkit.org/show_bug.cgi?id=28428 ? It's very simple and clear change: namespace ARM => ARMRegisters. The reason of this change is "ARM" can be used as a macro. -Yong___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Single-threaded database/storage solution
> Also, I don't think you answered my question about plans to set up a bot. Sorry for that. we're still trying to finish upstreaming our WINCE port. However, the progress is very slow. I'm not confident that it could be finished in a month :( - Original Message - From: Jeremy Orlow To: Yong Li Cc: laszlo.1.gom...@nokia.com ; stai...@kde.org ; webkit-dev@lists.webkit.org Sent: Tuesday, August 18, 2009 5:33 PM Subject: Re: [webkit-dev] Single-threaded database/storage solution On Tue, Aug 18, 2009 at 1:52 PM, Yong Li wrote: It has been broken for many times :) If you guys change it very much or very often, probably it's good to create another StorageAreaSync.cpp in storage\single-threaded as you suggested. I don't understand how splitting things into another file would affect things breaking either way. Also, I don't think you answered my question about plans to set up a bot.___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Single-threaded database/storage solution
It has been broken for many times :) If you guys change it very much or very often, probably it's good to create another StorageAreaSync.cpp in storage\single-threaded as you suggested. -Yong - Original Message - From: Jeremy Orlow To: Yong Li Cc: laszlo.1.gom...@nokia.com ; stai...@kde.org ; webkit-dev@lists.webkit.org Sent: Tuesday, August 18, 2009 4:39 PM Subject: Re: [webkit-dev] Single-threaded database/storage solution On Tue, Aug 18, 2009 at 1:02 PM, Yong Li wrote: Hi, Laszlo, Do you think our single-threaded storage(database) solution can be helpful to you? If so, I'm going to change the switch from PLATFORM(WINCE) to ENABLE(SINGLE_THREADED) or something like that. I think this would be good. Btw, is there any intention to set up a WINCE or single threaded QT build bot any time soon? Otherwise I'm concerned that some of us working in storage are going to inadvertently break this stuff and have no idea that it happened. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Single-threaded database/storage solution
Hi, Laszlo, Do you think our single-threaded storage(database) solution can be helpful to you? If so, I'm going to change the switch from PLATFORM(WINCE) to ENABLE(SINGLE_THREADED) or something like that. -Yong - Original Message - From: To: ; Sent: Tuesday, August 18, 2009 3:57 PM Subject: Re: [webkit-dev] Single-threaded database/storage solution Hi All, QtWebKit has a build time flag called ENABLE_SINGLE_THREADED to turn off ENABLE_JSC_MULTIPLE_THREADS and WebCore features that create additional threads. I'm interested to make this feature available for QtWebKit (and maybe other ports) as well, not just to the WINCE port. See http://trac.webkit.org/changeset/44411. Regards, Laszlo -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of ext George Staikos Sent: Tuesday, August 18, 2009 10:36 PM To: WebKit Development Subject: Re: [webkit-dev] Single-threaded database/storage solution On 18-Aug-09, at 1:44 PM, Yong Li wrote: Hi, All, The current webkit database/storage is implemented with creating new threads. But not all platform/products support mulple- threading. Also, threading can be expensive on some platforms. Except this database/storage implementation, WEBKIT platform- crossing code can build and run in a single thread. WEBKIT generally uses WebCore::Timer To avoid blocking UI. Another way to avoid blocking UI is to create a separate thread for UI, and WEBKIT code can still run in a single-thread. Now it's broken by database/ storage code, which forces to use multiple threads for WEBKIT. In our WINCE port, we have implemented a single-threaded solution with WebCore::Timer. The patch has been post to https://bugs.webkit.org/ show_bug.cgi?id=28019 . The patch is a bit out-of-date, due to changes in upstream. New patch will come soon. Please give some comments if you're interested. There's a macro ENABLE_JSC_MULTIPLE_THREADS used in JSC. Probably there should also be a macro ENABLE_WEBCORE_MULTIPLE_THREADS. Or just use ENABLE_MULTIPLE_THREADS for all multi-threading code. I agree with that and I think a cleanup of the patch would make it a good addition. Forcing the use of threads here is not ideal. -- George Staikos Torch Mobile Inc. http://www.torchmobile.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Single-threaded database/storage solution
Hi, All, The current webkit database/storage is implemented with creating new threads. But not all platform/products support mulple-threading. Also, threading can be expensive on some platforms. Except this database/storage implementation, WEBKIT platform-crossing code can build and run in a single thread. WEBKIT generally uses WebCore::Timer To avoid blocking UI. Another way to avoid blocking UI is to create a separate thread for UI, and WEBKIT code can still run in a single-thread. Now it's broken by database/storage code, which forces to use multiple threads for WEBKIT. In our WINCE port, we have implemented a single-threaded solution with WebCore::Timer. The patch has been post to https://bugs.webkit.org/show_bug.cgi?id=28019 . The patch is a bit out-of-date, due to changes in upstream. New patch will come soon. Please give some comments if you're interested. There's a macro ENABLE_JSC_MULTIPLE_THREADS used in JSC. Probably there should also be a macro ENABLE_WEBCORE_MULTIPLE_THREADS. Or just use ENABLE_MULTIPLE_THREADS for all multi-threading code. Best regards to everyone, Yong Li ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JSC without Dependencies
We used Active Perl and other tools for building wince port with VS. But it requires extra work for keeping up with upstream changes. So finally we switch to use cygwin totally. I like this way, because webkit is a platform-crossing project, we should avoid unnecessary changes for any specific platform/complier, and share as much as possible. -Yong - Original Message - From: "Brent Fulgham" To: "Brian Barnes" Cc: Sent: Monday, August 17, 2009 7:08 PM Subject: Re: [webkit-dev] JSC without Dependencies Hi Brian, On Mon, Aug 17, 2009 at 11:54 AM, Brian Barnes wrote: This one is harder, since JavaScriptCore uses bash, make, perl, and bison (at least) from cygwin. See the JavaScriptCoreGenerated vcproj, I don't think this is worth the pain, since it's entirely a build-time dependency and won't affect your generated library at all. Is installing cygwin really that hard? (If it's a matter of bloat, can you replace the Yes, this is the one that stops the compile, which is why I was going to attempt to rebuild the project from the source files (if possible.) It's no so much "how hard or not hard" it is to install cygwin, it's that most win32 development happens on VS, it's the tool most win32 developer are used to (and a lot of them have seen no other tool), and it makes a bit more sense that the win32 VS compile should just require VS. As a full time Windows developer, I'm afraid I really disagree with you on this topic. I don't think it's correct that since most win32 development happens (only) in VS, that it follows that we should aim to only use Visual Studio. I think this limits us to the same poor environment that leads to so much awful Windows software. For that matter, most Windows developers don't bother building 'utility' libraries like JavaScriptCore themselves; they generally just want to install an SDK and get on with their work. Windows development does occur primarily in VS, but I think this is part of the reason there is so much bad windows code written. WebKit uses tools like Perl to automate generation of various boilerplate interfaces from definitions, and does so in a cross-platform way. Restricting ourselves to VS-only would probably mean having to manually keep all of this stuff in sync (no thank you!) It might be possible to use only ActiveState Perl and Python (and ditch all bash scripting), but I'm not sure how much effort would be involved in doing so. This would still require generating the gperf output used somehow (perhaps that could be maintained as a static text file in the build). Oh -- It would also require the creation of NMAKE-compatible Makefiles to drive the build process (yet another needless replication of a cross-platform tool). While the current set of tools in WebKit is by no means perfect, it is a well designed system for maintaining functionally-equivalent builds of WebKit on all major (and many very tiny!) platforms. I think your efforts would be better served by: 1. Getting your environment set up with Cygwin and building properly. 2. Coming up with patches to reduce the external dependencies (CFLite, ICU, pthreadsv2). 3. Providing pre-build binaries of your dependency-free JavaScriptCore.dll for people to use in their own projects. I fully agree that reduced dependencies are a good idea, but I've come to really like CoreFoundation (CFLite) and don't really care that much about having the other dependencies as long as I can stay up-to-date with WebKit's main development. -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
