[webkit-dev] parallel controls in JavaScriptCore engine

2010-06-28 Thread Srinivasa Rao Edara
Hello, As part of my project, we need to implement custom JS objects using JavaScriptCore API. I am seeking help in implementing in implementing one of the requirement and its possibility of accomplishing it in Webkit/JavaScriptcore. So, the requirement is, We need to add custom JS object , lets

Re: [webkit-dev] parallel controls in JavaScriptCore engine

2010-06-28 Thread Adam Barth
I'm not sure if there's a short-cut, but you essentially want a JavaScript engine that uses continuation-passing style: http://en.wikipedia.org/wiki/Continuation-passing_style Certainly doable but likely difficult. Adam On Mon, Jun 28, 2010 at 1:30 AM, Srinivasa Rao Edara

Re: [webkit-dev] parallel controls in JavaScriptCore engine

2010-06-28 Thread Zoltan Herczeg
Hi, why don't you simply use a workaround? script function success() { alert(Success); continueTask(true); } function failure() { alert(Failure); continueTask(false); } function continueTask(success) { x= 10+1; } /script Zoltan Hello, As part of my project, we

Re: [webkit-dev] parallel controls in JavaScriptCore engine

2010-06-28 Thread Geoffrey Garen
So my question here is, is this really possible to stop execution at one place and execute some thing else and resume back to previous execution point with JavaScript engine of Webkit. Yes. I have tried this using two threads by blocking the wait using mutex and calling success/failure

[webkit-dev] Should Table Cell (TD) children inherit height?

2010-06-28 Thread Fady Samuel
My understanding is that in quirks mode, table height=100% causes the table to fill the entire client window. Now, I believe the height attribute should trickle down to the TR and TD tags, correct? What about children of a TD tag? If you add an empty div child to a table, should it fit the whole

[webkit-dev] Tightening up smart pointer usage rules

2010-06-28 Thread Darin Adler
Hi folks. I’d like to use our smart pointers more consistently to decrease the chances of memory leaks or other similar problems. My proposal is that we have a rule that all calls to new are immediately followed by putting the object into a smart pointer. The main types of smart pointer that

Re: [webkit-dev] Tightening up smart pointer usage rules

2010-06-28 Thread Kenneth Christiansen
   6) Add validator rules that make invocation of the new operator legal only inside adoptRef and adoptPtr function calls. That is probably going to be a problem for Qt code on the WebKit API side. If we disable this rule for WebKitTools and WebKit I think we should be OK Kenneth

Re: [webkit-dev] Tightening up smart pointer usage rules

2010-06-28 Thread Adam Barth
On Mon, Jun 28, 2010 at 1:43 PM, Kenneth Christiansen kenneth.christian...@openbossa.org wrote:    6) Add validator rules that make invocation of the new operator legal only inside adoptRef and adoptPtr function calls. That is probably  going to be a problem for Qt code on the WebKit API

Re: [webkit-dev] Tightening up smart pointer usage rules

2010-06-28 Thread Adam Barth
Sounds great. Let me know how I can help. Do we need an exception for statics that we intend to leak at shutdown? Maybe leakPtr(new Foo)? Adam On Mon, Jun 28, 2010 at 1:39 PM, Darin Adler da...@apple.com wrote: Hi folks. I’d like to use our smart pointers more consistently to decrease the

Re: [webkit-dev] Tightening up smart pointer usage rules

2010-06-28 Thread Antti Koivisto
Is the plan also to banish the std::auto_ptr? It seems pointless and confusing to allow both the OwnPtr and the auto_ptr. antti (who wants PwnPtr too) On Mon, Jun 28, 2010 at 11:39 PM, Darin Adler da...@apple.com wrote: Hi folks. I’d like to use our smart pointers more consistently to

Re: [webkit-dev] Tightening up smart pointer usage rules

2010-06-28 Thread Darin Adler
On Jun 28, 2010, at 2:14 PM, Adam Barth wrote: Do we need an exception for statics that we intend to leak at shutdown? Maybe leakPtr(new Foo)? Maybe. My first thought for such things is that I’d prefer to write them as: adoptPtr(new Foo).releasePtr() At first that may look strange, but

Re: [webkit-dev] Tightening up smart pointer usage rules

2010-06-28 Thread Darin Adler
On Jun 28, 2010, at 2:55 PM, Antti Koivisto wrote: Is the plan also to banish the std::auto_ptr? It seems pointless and confusing to allow both the OwnPtr and the auto_ptr. Yes, that would be my preference. PassOwnPtr is intended as a replacement for std::auto_ptr. Before PassOwnPtr

Re: [webkit-dev] Should Table Cell (TD) children inherit height?

2010-06-28 Thread David Kilzer
How do Firefox and MSIE render the test case? Dave -- Sent from my iPhone 3GS On Jun 28, 2010, at 11:42 AM, Fady Samuel fsam...@chromium.org wrote: My understanding is that in quirks mode, table height=100% causes the table to fill the entire client window. Now, I believe the height

Re: [webkit-dev] Tightening up smart pointer usage rules

2010-06-28 Thread Maciej Stachowiak
I like this idea. Addressing some of the side comments: - Yes, we should get rid of auto_ptr. - I can imagine a leakPtr function being more self-documenting than adoptPtr(...).releasePtr() when it appears in code, but on the other hand the greater convenience may lead to using it carelessly.