Re: [webkit-dev] Pattern for singleton classes instance getters

2015-01-28 Thread Yong Li
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

2014-10-02 Thread Yong Li
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

2014-08-29 Thread Yong Li
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

2014-08-18 Thread Yong Li
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

2014-08-18 Thread Yong Li
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()

2013-09-30 Thread Yong Li
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()

2013-09-30 Thread Yong Li

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

2013-04-22 Thread Yong Li
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 Thread Yong Li
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 Thread Yong Li
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-07-25 Thread Yong Li
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?

2012-03-30 Thread Yong Li
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

2011-09-14 Thread Yong Li
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

2011-07-12 Thread Yong Li
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?

2011-06-02 Thread 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 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?

2011-06-02 Thread Yong Li
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

2010-04-16 Thread 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] cannot receive e-mail from webkit bugzilla

2010-01-26 Thread Yong Li
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

2010-01-22 Thread Yong Li
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

2010-01-20 Thread Yong Li
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

2010-01-13 Thread Yong Li
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-01-13 Thread Yong Li
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

2009-11-13 Thread Yong Li
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

2009-11-02 Thread Yong Li
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

2009-10-29 Thread Yong Li
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


[webkit-dev] virtual functions in ChromeClient and other clients

2009-10-22 Thread Yong Li
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] virtual functions in ChromeClient and other clients

2009-10-22 Thread Yong Li

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

2009-10-22 Thread Yong Li

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

2009-10-19 Thread Yong Li


- 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

2009-10-19 Thread Yong Li

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

2009-09-11 Thread Yong Li
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

2009-09-03 Thread Yong Li
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

2009-09-02 Thread Yong Li
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

2009-09-02 Thread Yong Li
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

2009-09-02 Thread Yong Li
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

2009-08-21 Thread Yong Li

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

2009-08-21 Thread Yong Li
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

2009-08-19 Thread Yong Li
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

2009-08-18 Thread Yong Li

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

2009-08-18 Thread Yong Li

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

2009-08-18 Thread Yong Li
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