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

2010-06-28 Thread Maciej Stachowiak
On Jun 28, 2010, at 6:32 PM, David Kilzer wrote: > How do Firefox and MSIE render the test case? Our rendering on this content matches Firefox in both quirks and standards mode. I also do not know if a reason per spec for the div to get 100% height. Height does not inherit. - Maciej > > Da

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. On

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 wrote: > My understanding is that in quirks mode, causes the > table to fill the entire client window. Now, I believe the height attribute > should trickle down to the TR a

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

2010-06-28 Thread Holger Freyther
On 06/29/2010 04:39 AM, Darin Adler wrote: > 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 in

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 existe

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, bu

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 wrote: > Hi folks. > > I’d like to use our smart pointers more consistently to decrease the chan

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 wrote: > Hi folks. > > I’d like to use our smart pointers more consistently to decrease the chances > o

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 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 > side. If we disable this rule

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

[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

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

2010-06-28 Thread Fady Samuel
My understanding is that in quirks mode, 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 cell, or should it

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/failu

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

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

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 wrote: > Hello, > >

[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 s