Re: [webkit-dev] want to port JIT to MIPS - can anybody explain JIT::linkCall?
The hot path for a call performs a check for a specific callee, with a fast mechanism for making JS->JS calls. The code is generated such that it will initially always bail out to the slow path, and the second time the call is executed it will dynamically linked itself to that callee. There are currently two slow paths generated for each callee, the initial one that calls out to relink the code, and a second form that does not. hotPathBegin & hotPathOther are used (along with an offset) to find three things to repatch in the hot path: (1) The JSFunction* value that is checked, to identify the callee (2) The jump out to the slow path, so this can be relinked to the second form (which will not attempt to relink – this is stored in coldPathOther). (3) The call instruction to be linked the callee's code. The value callReturnLocation points to the call in the cold path to the relink mechanisms. This is used by the dynamic linking mechanisms to lookup the CallLinkInfo record describing the call to be linked, and is also used in exception handling. G. On Mar 6, 2009, at 5:40 PM, x yz wrote: e.g, emitted asm code before/after patch? what does its four pointers do? MacroAssembler::CodeLocationNearCall callReturnLocation; MacroAssembler::CodeLocationDataLabelPtr hotPathBegin; MacroAssembler::CodeLocationNearCall hotPathOther; MacroAssembler::CodeLocationLabel coldPathOther; CodeBlock* callee; anywhere got doc of the JIT implementations? thanks a lot! joe --- On Wed, 3/4/09, Zoltan Herczeg wrote: From: Zoltan Herczeg Subject: Re: [webkit-dev] want to port JIT to MIPS - how patchOffset* constant determined? To: webkit-dev@lists.webkit.org Date: Wednesday, March 4, 2009, 3:33 PM Hi, they generate instructions, which size is known in advance. Think about the following sequence: hotPathBegin: mov regX, 32bit_const <- 6 bytes (*) (**) add regX, regY <- 2 bytes jo 32bit_addr <- 5 bytes (*) * (Note) : these instructions will be modified during runtime. ** (Note) : there is a short form for "mov regX, 8bit_const", which length is only 3 bytes, but they force the longer version in such cases to keep the size of the instruction. As you can see, the address of "jo" is always (hotPathBegin + 6 + 2). They simply introduce a new constant: patchOffsetXXX = 8, and use this constant to access the "jo" instruction later. In ARM we can't rely on such constant, because the constant pool can be placed after any instruction. hotPathBegin: ldr rX, [pc + const_pool_addr] ; 32 bit const [...] <- the const pool can be placed here add rX, rX, rY [...] <- the const pool can be placed here hotPath2: ldr pc, [pc + const_pool_addr] ; 32 bit target address We need to store both pointers (hotPathBegin and hotPath2). Zoltan Zoltan, Thanks for reply, I'm trying to understand your example. But,X86 instruction size is from 1 to 17bytes, not constant. I may misunderstand your comments? Many X86 instruction can have imm32 at the end, thus this pointer can be used for patch as well as next address after call. Does Arm have similar things? or else you still need to figure out why "patchOffsetOpCallCompareToJump = 9;"? may be some instruction lengths relates to the 9? rgds joe --- On Wed, 3/4/09, Zoltan Herczeg wrote: From: Zoltan Herczeg Subject: Re: [webkit-dev] want to port JIT to MIPS - how patchOffset* constant determined? To: webkit-dev@lists.webkit.org Date: Wednesday, March 4, 2009, 3:45 AM On x86, the size of the instructions are fixed. If you want to access multiple instructions in the instruction stream, you only need to store the address of the first one, and can access the others by their relative address. This saves a little memory. Example (see JIT::linkCall): instruction at callLinkInfo->hotPathBegin: points to callee comparison instruction at callLinkInfo->hotPathBegin + patchOffsetOpCallCompareToJump: points to the slow case entry jump Zoltan in jit.h, for example: static const int patchOffsetOpCallCompareToJump = 9; static const int patchOffsetPutByIdStructure = 7; static const int patchOffsetPutByIdPropertyMapOffset = 22; static const int patchOffsetGetByIdBranchToSlowCase = 13; thanks for help, I'm stucked here now. joe --- On Sat, 2/28/09, Gavin Barraclough wrote: From: Gavin Barraclough Subject: Re: [webkit-dev] want to port JIT to MIPS - JIT reg usage clean up? To: "WebKit Development" Date: Saturday, February 28, 2009, 12:19 PM On Feb 27, 2009, at 4:55 PM, x yz wrote: The regTx seems to be working registers here, yet their definition are regparm(3) registers for function arugments. Such usage would cause conflict on other platforms. May I suggest that we use individual defined set of regs for func i/o argument and working? First up, I think you're getting slightly confused about regparm(3). This is not used anywhere in the JS language JIT, onl
Re: [webkit-dev] A question regarding to JavaScriptCore's C/C++ API.
Thanks for your reply. On Sat, Mar 7, 2009 at 7:41 AM, Geoffrey Garen wrote: > Hi Zhe. > >I'm developing an application which uses webkit's JavaScriptCore and a >> customized global object (by providing a special class when creating the >> context). My customized global object provides some built-in properties that >> can be accessed by javascript code. Now, I want to support a special >> behavior: allows javascript code to override a built-in property of global >> object by using variable declaraction statement. For example, assuming the >> global object has a built-in property, named "foo", a "var foo;" statement >> shall create a javascript variable, named "foo" and the original built-in >> "foo" shall be overrid by this new javascript variable. But if there is no >> "var foo;" statement, the built-in foo shall be able to get and set from >> javascript code. >> >> Now the problem is, current JavaScriptCore's C API (especially those >> HasProperty, GetProperty, SetProperty callbacks of a class definition) can't >> distinguish variable delcaration statement and variable assigment statement. >> I checked SpiderMonkey's API and found it can distinguish such things by >> providing a flag when calling ResolveProperty callback. >> > > I'm surprised to hear that SpiderMonkey's property setting API includes a > flag distinguishing var declarations from other kinds of property setting. > Internet Explorer supports shadowing global properties with var > declarations, but Firefox does not. (Perhaps you're thinking of the > SpiderMonkey flag to distinguish "x = y" syntax from "this.x = y" syntax, > which is slightly different.) SpiderMonkey can distinguish among many different type of statements. See https://developer.mozilla.org/En/SpiderMonkey/JSAPI_Reference/JSNewResolveOp > > > It may not be my place, but I would discourage you from giving var > declarations a special behavior, distinct from their behavior on the web. > Much of the value of JavaScript derives from the fact that so many > programmers understand how it works, due to their experience with the web. I also don't want to support such non-standard behavior, however we need support legacy javascript code written for windows which rely on this behavior. What a pity. Anyway, thanks for your reply. > > > Do you have any idea on this issue? How can I implement such behavior >> based on current API? >> > > There is no API in JavaScriptCore for distinguishing between "var" and > other property setting. I'm not sure how you would implement that. JavaScriptCore's API is simple and easy to use, however in most cases, it's too simple to achieve some feature, comparing to SpiderMonkey, which is too complex and flexible. > > > Geoff > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] want to port JIT to MIPS - can anybody explain JIT::linkCall?
e.g, emitted asm code before/after patch? what does its four pointers do? MacroAssembler::CodeLocationNearCall callReturnLocation; MacroAssembler::CodeLocationDataLabelPtr hotPathBegin; MacroAssembler::CodeLocationNearCall hotPathOther; MacroAssembler::CodeLocationLabel coldPathOther; CodeBlock* callee; anywhere got doc of the JIT implementations? thanks a lot! joe --- On Wed, 3/4/09, Zoltan Herczeg wrote: > From: Zoltan Herczeg > Subject: Re: [webkit-dev] want to port JIT to MIPS - how patchOffset* > constant determined? > To: webkit-dev@lists.webkit.org > Date: Wednesday, March 4, 2009, 3:33 PM > Hi, > > they generate instructions, which size is known in advance. > > Think about the following sequence: > hotPathBegin: > mov regX, 32bit_const <- 6 bytes (*) (**) > add regX, regY <- 2 bytes > jo 32bit_addr <- 5 bytes (*) > > * (Note) : these instructions will be modified during > runtime. > > ** (Note) : there is a short form for "mov regX, > 8bit_const", which length > is only 3 bytes, but they force the longer version in such > cases to keep > the size of the instruction. > > As you can see, the address of "jo" is always > (hotPathBegin + 6 + 2). They > simply introduce a new constant: patchOffsetXXX = 8, and > use this constant > to access the "jo" instruction later. > > In ARM we can't rely on such constant, because the > constant pool can be > placed after any instruction. > > hotPathBegin: > ldr rX, [pc + const_pool_addr] ; 32 bit const > [...] <- the const pool can be placed here > add rX, rX, rY > [...] <- the const pool can be placed here > hotPath2: > ldr pc, [pc + const_pool_addr] ; 32 bit target address > > We need to store both pointers (hotPathBegin and hotPath2). > > Zoltan > > > Zoltan, > > Thanks for reply, I'm trying to understand your > example. But,X86 > > instruction size is from 1 to 17bytes, not constant. I > may misunderstand > > your comments? > > Many X86 instruction can have imm32 at the end, thus > this pointer can be > > used for patch as well as next address after call. > Does Arm have similar > > things? or else you still need to figure out why > > "patchOffsetOpCallCompareToJump = 9;"? may > be some instruction lengths > > relates to the 9? > > rgds > > joe > > > > > > --- On Wed, 3/4/09, Zoltan Herczeg > wrote: > > > >> From: Zoltan Herczeg > > >> Subject: Re: [webkit-dev] want to port JIT to MIPS > - how patchOffset* > >> constant determined? > >> To: webkit-dev@lists.webkit.org > >> Date: Wednesday, March 4, 2009, 3:45 AM > >> On x86, the size of the instructions are fixed. If > you want > >> to access > >> multiple instructions in the instruction stream, > you only > >> need to store > >> the address of the first one, and can access the > others by > >> their relative > >> address. This saves a little memory. > >> > >> Example (see JIT::linkCall): > >> instruction at callLinkInfo->hotPathBegin: > points to > >> callee comparison > >> instruction at > >> callLinkInfo->hotPathBegin + > >> patchOffsetOpCallCompareToJump: > >>points to the slow case entry jump > >> > >> Zoltan > >> > >> > in jit.h, for example: > >> > static const int > >> patchOffsetOpCallCompareToJump = 9; > >> > static const int > patchOffsetPutByIdStructure = > >> 7; > >> > static const int > >> patchOffsetPutByIdPropertyMapOffset = 22; > >> > static const int > >> patchOffsetGetByIdBranchToSlowCase = 13; > >> > thanks for help, I'm stucked here now. > >> > joe > >> > > >> > > >> > --- On Sat, 2/28/09, Gavin Barraclough > >> wrote: > >> > > >> >> From: Gavin Barraclough > >> > >> >> Subject: Re: [webkit-dev] want to port > JIT to MIPS > >> - JIT reg usage clean > >> >> up? > >> >> To: "WebKit Development" > >> > >> >> Date: Saturday, February 28, 2009, 12:19 > PM > >> >> On Feb 27, 2009, at 4:55 PM, x yz wrote: > >> >> > >> >> > The regTx seems to be working > registers here, > >> yet > >> >> their definition are regparm(3) registers > for > >> function > >> >> arugments. Such usage would cause > conflict on > >> other > >> >> platforms. May I suggest that we use > individual > >> defined set > >> >> of regs for func i/o argument and > working? > >> >> > >> >> First up, I think you're getting > slightly > >> confused > >> >> about regparm(3). This is not used > anywhere in > >> the JS > >> >> language JIT, only in WREC. In some > >> configurations of the > >> >> JIT we use fastcall semantics on x86... > but none > >> of this is > >> >> really relevant to MIPS. Just ignore all > this. > >> Stick to > >> >> the default MIPS ABI for stub functions. > >> >> > >> >> Reading between the lines, I'm > guessing your > >> concern > >> >> here is that in setting up arguments for > a JIT > >> stub call you > >> >> may trample the JIT's temporary > registers? If > >> so, I > >> >> think you need to look at the argument > passing > >> more closely. > >> >> The mechanisms to pass arguments to stub > >> functions pass all > >> >>
Re: [webkit-dev] compile webkit on windows
Hi, 2009/3/6 jie zhang : > Hi all > > I try to compile webkit on Window+cygwin+vs2005 ES(Sp1), > But I got some error like this: > > QTMovieWin.obj : error LNK2001: external symbol "__imp > CFStringMakeConstantString" is unresolved。 > [...] You do not have the Apple support libraries in your build path, either because you did not follow the instruction about doing so, or you did not follow the instruction about downloading and installing them (see http://webkit.org/building/checkout.html, "Install the WebKit Support Libraries"). These error messages indicate that you are missing the CoreFoundation.lib link library. Good luck! -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A question regarding to JavaScriptCore's C/C++ API.
Hi Zhe. I'm developing an application which uses webkit's JavaScriptCore and a customized global object (by providing a special class when creating the context). My customized global object provides some built-in properties that can be accessed by javascript code. Now, I want to support a special behavior: allows javascript code to override a built-in property of global object by using variable declaraction statement. For example, assuming the global object has a built-in property, named "foo", a "var foo;" statement shall create a javascript variable, named "foo" and the original built-in "foo" shall be overrid by this new javascript variable. But if there is no "var foo;" statement, the built-in foo shall be able to get and set from javascript code. Now the problem is, current JavaScriptCore's C API (especially those HasProperty, GetProperty, SetProperty callbacks of a class definition) can't distinguish variable delcaration statement and variable assigment statement. I checked SpiderMonkey's API and found it can distinguish such things by providing a flag when calling ResolveProperty callback. I'm surprised to hear that SpiderMonkey's property setting API includes a flag distinguishing var declarations from other kinds of property setting. Internet Explorer supports shadowing global properties with var declarations, but Firefox does not. (Perhaps you're thinking of the SpiderMonkey flag to distinguish "x = y" syntax from "this.x = y" syntax, which is slightly different.) It may not be my place, but I would discourage you from giving var declarations a special behavior, distinct from their behavior on the web. Much of the value of JavaScript derives from the fact that so many programmers understand how it works, due to their experience with the web. Do you have any idea on this issue? How can I implement such behavior based on current API? There is no API in JavaScriptCore for distinguishing between "var" and other property setting. I'm not sure how you would implement that. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] currently failing regression tests on Mac OS X Leopard
Oops. I meant reply-to-all but just replied to Darin. 2009/3/6 Jungshik Shin (신정식, 申政湜) > > > 2009/3/6 Darin Adler > >> On Mar 6, 2009, at 8:36 AM, Dimitri Glazkov wrote: >> >> Since I checked in the failing tests, I feel responsible, too. >>> >>> I'd say let's remove these tests and work to get the CSS2.1 suite >>> updated. WDYT? >>> >> >> I think it's an acceptable strategy to have these new separate tests. I >> just think someone needs to generate the correct expected results. >> >> Changing the CSS 2.1 suite itself would be OK, but I don't think it would >> have a big effect. We'd still need correct expected results. > > > Sorry for all the confusion. I mentioned the following on IRC and in the > bug, but perhaps, I was not clear enough. > > What happened was that test results are correct, but actual test files > (html files) that were svn-copied to a new location were NOT revised in the > new place. (my patch has new html files, but during the landing, svn-apply > did not work as intended and svn-copied files without actual changes went > int). > As a result, there's a mismatch between the expected result and what's > supposed to be new test files (that ARE actually just the copies of the > original tests). > > So, we can do any of the following (I'm also replying to Darin's question > here). > > 1. What Dave suggested on IRC. > > 1a. Revise the original CSS 2.1 tests in place and remove what's added > recently. >(this will be done by landing the latest patch in bug 23482) > > 1b. Same end result as 1a: >- roll out what's added recently right away without waiting for > Dave's r+. >- once Dave gives me a nod for in-place modification of the original > tests, make that change. > > 2. Leave the original tests alone and just update 'new' test html files in > fast/block/float to match expected results. > > If we do 1a/1b, I'm willing to talk to Ian once more about our changes and > talk him into revising CSS 2.1 suite the same way. I already asked him in > the bugzilla, but he may have missed it. > > #2 was what was agreed upon and what my second latest patch does, but > yesterday, Dave said that it's better to revise the original tests in place. > So, I made the latest patch (3rd patch in the bug) and asked him for > review. > > Jungshik > > > > > > >> >> >> I think the main question is who will generate expected results that are >> correct for Mac OS X. >> >>-- Darin >> >> > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Safari 4 Beta now required for building Apple's Windows WebKit port
Hi everyone- As of today we now require Safari 4 Beta for building/running Apple's Windows WebKit port. Just a heads up! -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] currently failing regression tests on Mac OS X Leopard
On Fri, Mar 6, 2009 at 7:47 AM, Darin Adler wrote: > After fixing the test I could easily deal with myself, the following tests > are failing for me: > >fast/block/float/t0905-c414-flt-fit-01-d-g.html >fast/block/float/t0905-c5525-fltblck-00-d-ag.html >fast/block/float/t0905-c5526-flthw-00-c-g.html > > It looks like the check-in to deal with the YinYang character included some > incorrect test results, or at least results that don't work on my computer. > We need to correct the test results. It may not be the only problem, but those tests are missing some necessary resources. None of the images in support/ that they look for are there. - Pam >fast/repaint/transform-absolute-in-positioned-container.html > > Simon, you added this test originally so maybe you can figure out why it's > giving me a result with an element 20 pixels wide instead of 40 now. > >-- Darin > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] currently failing regression tests on Mac OS X Leopard
On Mar 6, 2009, at 9:25 AM, Dimitri Glazkov wrote: Jungshik already did, just waiting for review: https://bugs.webkit.org/show_bug.cgi?id=23482 I am really confused now. I thought we agreed to leave the CSS 2.1 tests alone unless the official test suite changed. I'd like to see a patch that just fixes the current regression test failures and doesn't make additional changes. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] currently failing regression tests on Mac OS X Leopard
Oh wait. He did an in-place update patch. I'll ask him. :DG< On Fri, Mar 6, 2009 at 9:25 AM, Dimitri Glazkov wrote: > Jungshik already did, just waiting for review: > https://bugs.webkit.org/show_bug.cgi?id=23482 > > :DG< > > On Fri, Mar 6, 2009 at 9:20 AM, Darin Adler wrote: >> On Mar 6, 2009, at 8:36 AM, Dimitri Glazkov wrote: >> >>> Since I checked in the failing tests, I feel responsible, too. >>> >>> I'd say let's remove these tests and work to get the CSS2.1 suite updated. >>> WDYT? >> >> I think it's an acceptable strategy to have these new separate tests. I just >> think someone needs to generate the correct expected results. >> >> Changing the CSS 2.1 suite itself would be OK, but I don't think it would >> have a big effect. We'd still need correct expected results. >> >> I think the main question is who will generate expected results that are >> correct for Mac OS X. >> >> -- Darin >> >> > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] currently failing regression tests on Mac OS X Leopard
Jungshik already did, just waiting for review: https://bugs.webkit.org/show_bug.cgi?id=23482 :DG< On Fri, Mar 6, 2009 at 9:20 AM, Darin Adler wrote: > On Mar 6, 2009, at 8:36 AM, Dimitri Glazkov wrote: > >> Since I checked in the failing tests, I feel responsible, too. >> >> I'd say let's remove these tests and work to get the CSS2.1 suite updated. >> WDYT? > > I think it's an acceptable strategy to have these new separate tests. I just > think someone needs to generate the correct expected results. > > Changing the CSS 2.1 suite itself would be OK, but I don't think it would > have a big effect. We'd still need correct expected results. > > I think the main question is who will generate expected results that are > correct for Mac OS X. > > -- Darin > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] currently failing regression tests on Mac OS X Leopard
On Mar 6, 2009, at 8:36 AM, Dimitri Glazkov wrote: Since I checked in the failing tests, I feel responsible, too. I'd say let's remove these tests and work to get the CSS2.1 suite updated. WDYT? I think it's an acceptable strategy to have these new separate tests. I just think someone needs to generate the correct expected results. Changing the CSS 2.1 suite itself would be OK, but I don't think it would have a big effect. We'd still need correct expected results. I think the main question is who will generate expected results that are correct for Mac OS X. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] currently failing regression tests on Mac OS X Leopard
On Mar 6, 2009, at 8:01 AM, Dan Bernstein wrote: On Mar 6, 2009, at 7:47 AM, Darin Adler wrote: After fixing the test I could easily deal with myself, the following tests are failing for me: fast/block/float/t0905-c414-flt-fit-01-d-g.html fast/block/float/t0905-c5525-fltblck-00-d-ag.html fast/block/float/t0905-c5526-flthw-00-c-g.html It looks like the check-in to deal with the YinYang character included some incorrect test results, or at least results that don't work on my computer. We need to correct the test results. fast/repaint/transform-absolute-in-positioned-container.html This was caused by Hyatt's continuations patch. I filed a bug in Bugzilla and copied him. When I mentioned this to Hyatt he said it was a progression, and a new expected should be checked in. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] currently failing regression tests on Mac OS X Leopard
On Mar 6, 2009, at 7:47 AM, Darin Adler wrote: After fixing the test I could easily deal with myself, the following tests are failing for me: fast/block/float/t0905-c414-flt-fit-01-d-g.html fast/block/float/t0905-c5525-fltblck-00-d-ag.html fast/block/float/t0905-c5526-flthw-00-c-g.html It looks like the check-in to deal with the YinYang character included some incorrect test results, or at least results that don't work on my computer. We need to correct the test results. fast/repaint/transform-absolute-in-positioned-container.html This was caused by Hyatt's continuations patch. I filed a bug in Bugzilla and copied him. Simon, you added this test originally so maybe you can figure out why it's giving me a result with an element 20 pixels wide instead of 40 now. -- 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] A question regarding to JavaScriptCore's C/C++ API.
ping. On Thu, Mar 5, 2009 at 2:44 PM, Zhe Su wrote: > Hi, >I'm developing an application which uses webkit's JavaScriptCore and a > customized global object (by providing a special class when creating the > context). My customized global object provides some built-in properties that > can be accessed by javascript code. Now, I want to support a special > behavior: allows javascript code to override a built-in property of global > object by using variable declaraction statement. For example, assuming the > global object has a built-in property, named "foo", a "var foo;" statement > shall create a javascript variable, named "foo" and the original built-in > "foo" shall be overrid by this new javascript variable. But if there is no > "var foo;" statement, the built-in foo shall be able to get and set from > javascript code. > > Now the problem is, current JavaScriptCore's C API (especially those > HasProperty, GetProperty, SetProperty callbacks of a class definition) can't > distinguish variable delcaration statement and variable assigment statement. > I checked SpiderMonkey's API and found it can distinguish such things by > providing a flag when calling ResolveProperty callback. > > Do you have any idea on this issue? How can I implement such behavior based > on current API? > > Regards > James Su > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] currently failing regression tests on Mac OS X Leopard
After fixing the test I could easily deal with myself, the following tests are failing for me: fast/block/float/t0905-c414-flt-fit-01-d-g.html fast/block/float/t0905-c5525-fltblck-00-d-ag.html fast/block/float/t0905-c5526-flthw-00-c-g.html It looks like the check-in to deal with the YinYang character included some incorrect test results, or at least results that don't work on my computer. We need to correct the test results. fast/repaint/transform-absolute-in-positioned-container.html Simon, you added this test originally so maybe you can figure out why it's giving me a result with an element 20 pixels wide instead of 40 now. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] compile webkit on windows
Hi Did you try installing a safari ? Thanks & Regards Niilesh 2009/3/6 jie zhang : > Hi all > > I try to compile webkit on Window+cygwin+vs2005 ES(Sp1), > But I got some error like this: > > QTMovieWin.obj : error LNK2001: external symbol "__imp > CFStringMakeConstantString" is unresolved。 > QTMovieWin.obj : error LNK2001: external symbol > "__imp__CFStringGetCharacters" is unresolved。 > QTMovieWin.obj : error LNK2001: external symbol "__imp__CFStringCompare" is > unresolved。 > QTMovieWin.obj : error LNK2001: external symbol "__imp__CFRelease" is > unresolved。 > QTMovieWin.obj : error LNK2001: external symbol > "__imp__CFStringCreateWithCString" is unresolved。 > QTMovieWin.obj : error LNK2001: external symbol > "__imp__CFURLCreateWithString" is unresolved。 > QTMovieWin.obj : error LNK2001: external symbol "__imp__kCFAllocatorDefault" > is unresolved。 > QTMovieWin.obj : error LNK2001: external symbol "__imp__CFStringHasPrefix" > is unresolved。 > QTMovieWin.obj : error LNK2001: external symbol > "__imp__CFStringCreateWithCharacters" is unresolved。 > QTMovieWin.obj : error LNK2001: external symbol "__imp__CFStringGetLength" > is unresolved。 > d:\cygwin\zhangj\webkit\WebKitBuild\bin\QTMovieWin.dll : fatal error > LNK1120: > > I installed QuickTime SDK and set the include/liberay folder. > > How can I fix that errors? > > Thanks > ___ > 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] compile webkit on windows
Hi all I try to compile webkit on Window+cygwin+vs2005 ES(Sp1), But I got some error like this: QTMovieWin.obj : error LNK2001: external symbol "__impCFStringMakeConstantString" *is unresolved*。 QTMovieWin.obj : error LNK2001: external symbol "__imp__CFStringGetCharacters" *is unresolved*。 QTMovieWin.obj : error LNK2001: external symbol "__imp__CFStringCompare" *is unresolved*。 QTMovieWin.obj : error LNK2001: external symbol "__imp__CFRelease" *is unresolved*。 QTMovieWin.obj : error LNK2001: external symbol "__imp__CFStringCreateWithCString" *is unresolved*。 QTMovieWin.obj : error LNK2001: external symbol "__imp__CFURLCreateWithString" *is unresolved*。 QTMovieWin.obj : error LNK2001: external symbol "__imp__kCFAllocatorDefault" *is unresolved*。 QTMovieWin.obj : error LNK2001: external symbol "__imp__CFStringHasPrefix" *is unresolved*。 QTMovieWin.obj : error LNK2001: external symbol "__imp__CFStringCreateWithCharacters" *is unresolved*。 QTMovieWin.obj : error LNK2001: external symbol "__imp__CFStringGetLength" *is unresolved*。 d:\cygwin\zhangj\webkit\WebKitBuild\bin\QTMovieWin.dll : fatal error LNK1120: I installed QuickTime SDK and set the include/liberay folder. How can I fix that errors? Thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
