Re: [webkit-dev] Pattern for singleton classes instance getters
Class::unique() is one of the known names for singletons Yong Li From: Maciej Stachowiakmailto:m...@apple.com Sent: 1/28/2015 9:11 PM To: Darin Adlermailto:da...@apple.com Cc: WebKit Developmentmailto: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 da...@apple.com 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 castA(B) means: { return (A)B; }
Yong Li
From: Darin Adlermailto:da...@apple.com
Sent: 10/3/2014 3:16 AM
To: WebKit Developmentmailto: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 Gansterermailto:par...@paroga.com Sent: 8/29/2014 10:56 AM To: Osztrogonác Csabamailto:o...@inf.u-szeged.hu Cc: WebKit Developmentmailto: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 o...@inf.u-szeged.hu wrote: Hi, Patrick Gansterer írta: On 31.01.2014, at 22:10, Anders Carlsson ander...@apple.com 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=wincenoquickjump=1changeset=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
Has anyone managed to make an FTL build on Linux? Yong Li From: Sergio Villar Seninmailto:svil...@igalia.com Sent: 8/7/2014 11:58 AM To: webkit-dev@lists.webkit.orgmailto: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] ftlopt merge - basically done
Thanks a lot:) Yong Li From: Osztrogonác Csabamailto:o...@inf.u-szeged.hu Sent: 8/18/2014 3:51 PM To: WebKit Developmentmailto: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] 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 gyuyoung@webkit.org 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] Type cast by using toFoo()
Bottom line is turning on RTTI in debug build? From: Darin Adlermailto:da...@apple.com Sent: 2013-09-30 1:50 PM To: Yong Limailto:yong.li.web...@outlook.com Cc: Gyuyoung Kimmailto:gyuyoung@webkit.org; Sam Weinigmailto:wei...@apple.com; WebKit Developmentmailto:webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Type cast by using toFoo() On Sep 30, 2013, at 9:54 AM, Yong Li yong.li.web...@outlook.com 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] 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/15 Ryosuke Niwa rn...@webkit.org: On Thu, Nov 15, 2012 at 4:28 PM, Mike Lawther mikelawt...@google.com wrote: On 16 November 2012 09:59, Ryosuke Niwa rn...@webkit.org 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] r- your own patches [was: Re: RenderArena: Teaching an old dog new tricks]
2012/11/16 Julien Chaffraix julien.chaffr...@gmail.com: 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] Easing printf based debugging in WebKit with an helper.
2012/7/19 Brady Eidson beid...@apple.com: On Jul 19, 2012, at 10:53 AM, Andreas Kling kl...@webkit.org wrote: On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson beid...@apple.com wrote: On Jul 10, 2012, at 5:25 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson beid...@apple.com wrote: On Jul 9, 2012, at 2:43 PM, Alexis Menard alexis.men...@openbossa.org 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()HelloWorld34.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 byelozyo...@cs.uni-saarland.de:
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 o...@chromium.org wrote:
One case where this matters: div
style=-webkit-user-select:nonefoo/divbar
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
byelozyo...@cs.uni-saarland.de 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 gga...@apple.com: 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 da...@apple.com: 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*, Vectorchar, 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 VectorUChar 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?
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 gga...@apple.com: 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?
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 yong.li.web...@gmail.com:
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 gga...@apple.com:
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] 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
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 da...@apple.com 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
Re: [webkit-dev] global new/delete operator in WebKit
2010/1/13 Zoltan Horvath zol...@webkit.org 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 fastNewArrayint 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
[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
Oops, even m_page is a data member.
Hm... I need to think more about it.
-Yong
- Original Message -
From: Yong Li yong...@torchmobile.com
To: Adam Barth aba...@webkit.org
Cc: WebKit Development webkit-dev@lists.webkit.org
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 aba...@webkit.org
To: Yong Li yong...@torchmobile.com
Cc: WebKit Development webkit-dev@lists.webkit.org
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 yong...@torchmobile.com 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
Ha, never mind, then. -yong - Original Message - From: Eric Seidel e...@webkit.org To: Yong Li yong...@torchmobile.com Cc: WebKit Development webkit-dev@lists.webkit.org 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 yong...@torchmobile.com 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] Calling all committers: The pending-commit list isoverflowing
- Original Message - From: Adam Barth aba...@webkit.org To: webkit-dev@lists.webkit.org 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
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 esei...@google.com To: Yong Li yong...@torchmobile.com Cc: Adam Barth aba...@webkit.org; webkit-dev@lists.webkit.org 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 yong...@torchmobile.com wrote: - Original Message - From: Adam Barth aba...@webkit.org To: webkit-dev@lists.webkit.org 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
[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] 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 yong...@torchmobile.com 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
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 yong...@torchmobile.com 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] 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 a...@webkit.org To: Darin Adler da...@apple.com Cc: WebKit Development webkit-dev@lists.webkit.org 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] [webkit-changes] [47592] trunk/JavaScriptCore
I remember it happens to VC6. Seems VS2005 doesn't have this problem. -Yong - Original Message - From: Darin Adler da...@apple.com To: Yong Li yong...@torchmobile.com Cc: WebKit Development webkit-dev@lists.webkit.org 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 derefIfNotNullfoo 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
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 ant...@chromium.org To: webkit-dev Development webkit-dev@lists.webkit.org 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
[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
[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] 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: laszlo.1.gom...@nokia.com To: stai...@kde.org; webkit-dev@lists.webkit.org 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
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 yong...@torchmobile.com 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
