[webkit-dev] Reconstructing a RenderTree from a DOM
Hi, After the page loading is done (HTML/CSS has been parsed, JS has been executed), webkit builds a DOM and RenderTree. It is possible that I detach the RenderTree from the DOM (removed that in memory), and that later on , reconstructing the RenderTree for that DOM? and re-attached the RenderTree back to the DOM? Thank you. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] ubuntu build problem
I have checked out revision 44600 today and it gives me build problem is there some stable version which I should be using? I am building it on ubuntu machine with command ./build-webkit --wx --wx-args=wxgc wxpython ranlib /home/anushri/try/WebKit/WebKitBuild/Release/libjscore.a g++ -o /home/anushri/try/WebKit/WebKitBuild/Release/jsc obj-gnu/jsc_jsc.o -lm -L/usr/lib -licui18n -licuuc -licudata -lm -L/home/anushri/try/WebKit/WebKitBuild/Release -L/home/anushri/try/WebKit/WebKitTools/wx/../../WebKitLibraries/unix/lib -L/home/anushri/try/WebKit/WebKitTools/wx/../../WebKitLibraries -ljpeg -lpng `wx-config --libs core,base` -g-ljscore -lpthread /home/anushri/try/WebKit/WebKitBuild/Release/libjscore.a(jscore_JSGlobalData.o): In function `JSC::JSGlobalData::JSGlobalData(bool, JSC::VPtrSet const)': JSGlobalData.cpp:(.text+0x8e1): undefined reference to `JSC::jsonTable' /home/anushri/try/WebKit/WebKitBuild/Release/libjscore.a(jscore_JSGlobalData.o): In function `JSC::JSGlobalData::JSGlobalData(bool, JSC::VPtrSet const)': JSGlobalData.cpp:(.text+0x1241): undefined reference to `JSC::jsonTable' /home/anushri/try/WebKit/WebKitBuild/Release/libjscore.a(jscore_JSGlobalObject.o): In function `JSC::JSGlobalObject::reset(JSC::JSValue)': JSGlobalObject.cpp:(.text+0x5391): undefined reference to `vtable for JSC::JSONObject' collect2: ld returned 1 exit status make: *** [/home/anushri/try/WebKit/WebKitBuild/Release/jsc] Error 1 make: Leaving directory `/home/anushri/try/WebKit/JavaScriptCore rgds Anurag Explore and discover exciting holidays and getaways with Yahoo! India Travel http://in.travel.yahoo.com/___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ubuntu build problem
I also tried to build source of nightly build WebKit-r44591 but it also gives same problem. rgds anurag From: anurag uniyal anuraguni...@yahoo.com To: webkit-dev@lists.webkit.org Sent: Thursday, 11 June, 2009 1:39:28 PM Subject: ubuntu build problem I have checked out revision 44600 today and it gives me build problem is there some stable version which I should be using? I am building it on ubuntu machine with command ./build-webkit --wx --wx-args=wxgc wxpython ranlib /home/anushri/try/WebKit/WebKitBuild/Release/libjscore.a g++ -o /home/anushri/try/WebKit/WebKitBuild/Release/jsc obj-gnu/jsc_jsc.o -lm -L/usr/lib -licui18n -licuuc -licudata -lm -L/home/anushri/try/WebKit/WebKitBuild/Release -L/home/anushri/try/WebKit/WebKitTools/wx/../../WebKitLibraries/unix/lib -L/home/anushri/try/WebKit/WebKitTools/wx/../../WebKitLibraries -ljpeg -lpng `wx-config --libs core,base` -g-ljscore -lpthread /home/anushri/try/WebKit/WebKitBuild/Release/libjscore.a(jscore_JSGlobalData.o): In function `JSC::JSGlobalData::JSGlobalData(bool, JSC::VPtrSet const)': JSGlobalData.cpp:(.text+0x8e1): undefined reference to `JSC::jsonTable' /home/anushri/try/WebKit/WebKitBuild/Release/libjscore.a(jscore_JSGlobalData.o): In function `JSC::JSGlobalData::JSGlobalData(bool, JSC::VPtrSet const)': JSGlobalData.cpp:(.text+0x1241): undefined reference to `JSC::jsonTable' /home/anushri/try/WebKit/WebKitBuild/Release/libjscore.a(jscore_JSGlobalObject.o): In function `JSC::JSGlobalObject::reset(JSC::JSValue)': JSGlobalObject.cpp:(.text+0x5391): undefined reference to `vtable for JSC::JSONObject' collect2: ld returned 1 exit status make: *** [/home/anushri/try/WebKit/WebKitBuild/Release/jsc] Error 1 make: Leaving directory `/home/anushri/try/WebKit/JavaScriptCore rgds Anurag Explore and discover exciting holidays and getaways with Yahoo! India Travel Click here! Explore and discover exciting holidays and getaways with Yahoo! India Travel http://in.travel.yahoo.com/___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] NPAPI Plugin on openembedded
Hi all: I port webkit/Gtk+ to openembedded and try to test flash plugin on GtkLauncher. I take qemu to simulate the embedded environment, incluing arm linux and x86 linux platform. I found that webkit cannot load any plugins on x86 linux, but it can work well on arm linux. The following is my testing steps: 1. Cross-compile WebKit r44125 and flash plugins (Only for arm linux) 2. Put flash plugin on ~/.mozilla/plugins 3. Launch GtkLauncher and browse YouTube. In addition, I also test it on desktop linux(OS is Ubuntu 8.10), and it works well. This looks very strange. Does any one know what I miss or NPAPI plugins need any extra packages? Thanks in advance, Graffine ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] arm jit
Hi guys at Apple, it looks we are in the way of the train. You have plans, we don't know about them, you have commit rights, we don't, so the tides are against us. Hints on the mailing lists are scarce, although a year ago someone from you asked whether others are interested in design discussions, we said 'yes', nothing really changed. Except some simple bugfixes, new patches of ours do not really get into the mainline (except some of our best ideas reimplemented by someone else). Partially this is due to the lack of information and roadmap of JavaScriptCore. That is why I feel the missing of the real openness. And here, I have to make a short comment on the non-acceptance of our ARM JIT implementation. In your mail you mention that you would remain reluctant to accept a duplicate of the JIT into the tree, rather than a port of the existing JIT utilizing the MacroAssembler abstraction. Well, did you check our ARM port? It has been rewritten to conform to the MacroAssembler interfaces more than a month ago and posted it into the bugzilla (https://bugs.webkit.org/show_bug.cgi?id=24986). Anyway, we have updated the MacroAssembler-based ARM port of ours, uploaded it to the bugzilla, and set the review flag on the patch. Regards, Zoltan On Jun 9, 2009, at 2:38 PM, Akos Kiss wrote: Dear Community, Today, we realized that there is a new ARM JIT port for WebKit. (http://trac.webkit.org/changeset/44514 ) Congratulations on getting this working!, great job. Hi Akos, Thank you! Just to clarify, we have just landed a ARMv7 architecture (thumb2) JIT backend into ToT. I say ARMv7 to distinguish this port from the ARM application instruction set found in the ARMv6 architecture and earlier (as I believe would be a common understanding of the term ARM, and and which I believe your port targets). Thumb2 in ARMv7 is, of course, a very different instruction set to the traditional 32-bit instructions found in ARM – with completely different machine encodings, and significantly different capabilities (e.g. two operand versus three operand instructions, sizes of immediate operands, and options for instruction predication). For the JIT to be able to run on both ARM and ARMv7 platforms, it needs to be ported to both architectures – in much the same way the the JIT is ported to both the x86 and x86-64 platforms. Obviously there is a great deal of similarity on the surface between ARM and ARMv7, but in terms of the JIT implementation that may well only be true above the level of the MacroAssembler interface. There may be some limited opportunities to share code within the Assembler classes (register numbering enums, and possibly types describing immediate operands), but since the assembler is primarily concerned with formatting machine instructions, and since the instruction encodings are different, it seems likely the bulk of the code will have to remain separate. Again, the differences in instruction selection options available on the two architectures will likely make it hard to share code within the MacroAssember (different numbers of operands to many common instructions, and the options when working with large immediate values particularly spring to mind). We would certainly want to share code and avoid any duplication where ever it makes sense to do so. I cannot conceal how disappointed I am, as is the whole team at Szeged. I am very sorry to hear this. If you look at the patches that landed into ToT there were very few changes made outside of the new assembler classes which, for the reasons described above, I think are highly unlikely to have much in common on the two platforms. The changes that have been made to common code outside of the assemblers should only help in removing x86 dependencies and assumptions that had existed in the code. I strongly urge you to review the changes that have been made, as I hope and believe you will find that they will assist the team in integrating your ARM port. Of course, we've felt that you were reluctant to accept our implementation. We were (and remain) reluctant to accept a duplicate of the JIT into the tree, rather than a port of the existing JIT utilizing the MacroAssembler abstraction. We are concerned that it would be extremely difficult to continue to maintain such a port as we move the JIT technology forwards. Beyond that, they key barrier to the ARM JIT being accepted into WebKit is that there simply haven't been any patches put forwards for us to review! (I'm sorry, I'm aware you have provided a link to an external git repository, but I'm afraid we really can't seek through version control systems to find changes to review – we do need contributors to attach patches to bugs, and we need a review flag setting to indicate when the contributor believes their patch is ready. If there is any uncertainty as to the procedure, please see http://webkit.org/coding/contributing.html .) - Are you
Re: [webkit-dev] NPAPI Plugin on openembedded
On Thursday 11 June 2009 12:09:37 Graffine wrote: Hi all: I port webkit/Gtk+ to openembedded and try to test flash plugin on GtkLauncher. I take qemu to simulate the embedded environment, incluing arm linux and x86 linux platform. I found that webkit cannot load any plugins on x86 linux, but it can work well on arm linux. The following is my testing steps: 1. Cross-compile WebKit r44125 and flash plugins (Only for arm linux) 2. Put flash plugin on ~/.mozilla/plugins 3. Launch GtkLauncher and browse YouTube. In addition, I also test it on desktop linux(OS is Ubuntu 8.10), and it works well. This looks very strange. Does any one know what I miss or NPAPI plugins need any extra packages? I don't understand... you say it does not work x86 linux but then you mention it works on Ubuntu 08.10 (which is likely) x86... anyway use strace and search for faile dlopen, stats, and such that could indicate loading the plugin z. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GDOM-Binding: using gdom_css_style_sheet_add_rule()
On 6/10/09, Leon Winter l...@ring0.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
the GDOM-Binding provides functions for setting up global CSS rules
and manipulating them. I'm interested in this functions, especially in:
WEBKIT_API glong
gdom_css_style_sheet_add_rule (GdomCSSStyleSheet *thiz, gchar *
selector, gchar * style, gulong index);
Okay, we need a GdomCSSStyleSheet, lets have a look:
WEBKIT_API GdomCSSStyleSheet *
gdom_dom_implementation_create_css_style_sheet (GdomDOMImplementation
*thiz, gchar * title, gchar * media);
So far so good, seems we need a GdomDOMImplementation object but there
is no function that returns this object.
function, no, property, yes.
$ grep DOMImplementation */*/*.idl */*/*/*.idl
WebCore/dom/Document.idl:readonly attribute [V8Custom]
DOMImplementation implementation;
WebCore/dom/DOMImplementation.idl:] DOMImplementation {
WebCore/dom/DOMImplementation.idl:// DOMImplementationCSS
interface from DOM Level 2 CSS
WebCore/dom/DOMImplementation.idl:// HTMLDOMImplementation
interface from DOM Level 2 HTML
WebCore/page/DOMWindow.idl://attribute
DOMImplementationListConstructor DOMImplementationList;
WebCore/page/DOMWindow.idl://attribute
DOMImplementationSourceConstructor DOMImplementationSource;
WebCore/page/DOMWindow.idl:attribute
DOMImplementationConstructor DOMImplementation;
WebKit/win/Interfaces/DOMCore.idl:@interface DOMImplementation : DOMObject
WebKit/win/Interfaces/DOMCore.idl:interface IDOMImplementation : IDOMObject
WebKit/win/Interfaces/DOMCore.idl:- (DOMImplementation *)implementation;
WebKit/win/Interfaces/DOMCore.idl:HRESULT implementation([out,
retval] IDOMImplementation** result);
WebKit/win/Interfaces/WebKit.idl:#include IGEN_DOMDOMImplementation.idl
the top one is the clue. ignore the [V8Custom] modifier flag, that
just says that when doing google v8 engine, there's a custom
implementation of the function that fetches that property.
so:
GdomDocument *doc = get_dom_document();
GdomDOMImplementation *di;
GdomCSSStyleSheet *css;
g_object_get(doc, implementation, di, NULL);
css = gdom_dom_implementation_create_css_style_sheet (di, title, media);
g_object_unref(di);
g_object_unref(css);
g_object_unref(doc);
try that.
i'd be interested to see a successful creation of an example like
this: these things are a bit new, and collecting some working examples
would help people a lot.
l.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] NPAPI Plugin on openembedded
Hi: Sorry for ambiguous describing. My testing environment was list as follows: 1. qemu arm linux (based on poky linux) 2. qemu x86 linux (based on poky linux) 3. Ubuntu 8.10 I adopt poky linux as my openembedded developing environment. The flash plugin can be loaded on case 1 and case 3, but it cannotwork on case 2. For case 2, I just directly use the .so file which genereted on case 3. It is not only flash plugins, but it seems any plugins cannot be loaded. What I missing besides compiling the plugin? Clain. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to interrupt Webkit Dump Render Tree output
On Wed, Jun 10, 2009 at 1:58 PM, tonikitoo (Antonio
Gomes)toniki...@gmail.com wrote:
On Mon, Jun 1, 2009 at 1:31 PM, Simon Frasersimon.fra...@apple.com wrote:
There is a method on RenderObject to get the correct absolute coordinates of
the renderer, which correctly takes transforms, scrolling etc into account:
RenderObject::localToAbsolute(). This is not a trivial problem.
localToAbsolute() is only fragile because if you are querying for
the position of a renderobject inside an iframe, it is not relative to
mainFrame but to the currentFrame. I've done it like below:
static inline IntRect absoluteRenderRect(RenderObject* render)
{
ASSERT(render);
// FIXME: This function is flawed because it doesn't consider the
effects of CSS or SVG transforms.
IntRect rect(render-absoluteClippedOverflowRect());
// handle nested frames.
for (Frame* frame = render-document()-frame(); frame; frame =
frame-tree()-parent())
if(HTMLFrameOwnerElement* ownerElement = frame-ownerElement())
rect.move(ownerElement-renderer()-offsetLeft(),
ownerElement-renderer()-offsetTop());
return rect;
}
maybe there is a better way , but ...
Hi, I have tried using the dumpRenderTree to dump out the absolute
co-ordinates of the
Render Tree of www.google.com. I put the absolute x, y result at the
end marked by { and }.
And www.google.com, the first text is 'Web followed by Images
followed by Video followed by Maps.
But what I don't understand is (from the output below) is all the
absolute coordinates of those text are x = 8.0 and y = 3.0. But
visually, they are next to each other horizontally. So the y values
should be the same but the x values should be different. Can you
please help me understand the result? And there is no iframe problem
the like you described.
Thank you.
Here is the output:
RenderInline {B} at (0,0) size 27x15 {8.00,3.00}
RenderText {#text} at (0,1) size 27x15 {8.00,3.00}
text run at (0,1) width 27: Web
RenderText {#text} at (33,1) size 4x15 {8.00,3.00}
text run at (33,1) width 4:
RenderInline {A} at (0,0) size 43x15 [color=#CC] {8.00,3.00}
RenderText {#text} at (37,1) size 43x15 {8.00,3.00}
text run at (37,1) width 43: Images
RenderText {#text} at (86,1) size 4x15 {8.00,3.00}
text run at (86,1) width 4:
RenderInline {A} at (0,0) size 33x15 [color=#CC] {8.00,3.00}
RenderText {#text} at (90,1) size 33x15 {8.00,3.00}
text run at (90,1) width 33: Video
RenderText {#text} at (129,1) size 4x15 {8.00,3.00}
text run at (129,1) width 4:
RenderInline {A} at (0,0) size 32x15 [color=#CC] {8.00,3.00}
RenderText {#text} at (133,1) size 32x15 {8.00,3.00}
text run at (133,1) width 32: Maps
RenderText {#text} at (171,1) size 4x15 {8.00,3.00}
text run at (171,1) width 4:
RenderInline {A} at (0,0) size 32x15 [color=#CC] {8.00,3.00}
RenderText {#text} at (175,1) size 32x15 {8.00,3.00}
text run at (175,1) width 32: News
RenderText {#text} at (213,1) size 4x15 {8.00,3.00}
text run at (213,1) width 4:
RenderInline {A} at (0,0) size 54x15 [color=#CC] {8.00,3.00}
RenderText {#text} at (217,1) size 54x15 {8.00,3.00}
text run at (217,1) width 54: Shopping
RenderText {#text} at (277,1) size 4x15 {8.00,3.00}
text run at (277,1) width 4:
RenderInline {A} at (0,0) size 34x15 [color=#CC] {8.00,3.00}
RenderText {#text} at (281,1) size 34x15 {8.00,3.00}
text run at (281,1) width 34: Gmail
RenderText {#text} at (321,1) size 4x15 {8.00,3.00}
text run at (321,1) width 4:
RenderInline {A} at (0,0) size 44x15 [color=#CC] {8.00,3.00}
RenderInline {U} at (0,0) size 29x15 {8.00,3.00}
RenderText {#text} at (325,1) size 29x15 {8.00,3.00}
text run at (325,1) width 29: more
--
--Antonio Gomes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] arm jit
--- On Wed, 6/10/09, Gavin Barraclough barraclo...@apple.com wrote: If you consider calling a JS function with too few arguments as being akin to = invoking a C++ method with some defaulted parameters not-provided, then it is also the responsibility of code generated for the call to such a method to ensure that values for all declared parameters are passed.) Thanks for the long explanation. Can the arity check be performed at compile time as in C++? Toshi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Trampoline problem
I've tracked down a crash in our JIT port to a problem with the trampoline
generation.
The symptom of the crash is: the ScopeChain becomes corrupted and acquires the
value of 1.
void JIT::privateCompileCTIMachineTrampolines(RefPtrExecutablePool*
executablePool, void** ctiArrayLengthTrampoline, void**
ctiStringLengthTrampoline, void** ctiVirtualCallPreLink, void**
ctiVirtualCallLink, void** ctiVirtualCall)
{
emitPutJITStubArg(regT3, 2);
...
Call callArityCheck2 = call();
move(regT1, callFrameRegister);
emitGetJITStubArg(1, regT2); (1)
...
compileOpCallInitializeCallFrame();
...
}
void JIT::compileOpCallInitializeCallFrame()
{
store32(regT1, Address(callFrameRegister, RegisterFile::ArgumentCount *
static_castint(sizeof(Register;
loadPtr(Address(regT2, FIELD_OFFSET(JSFunction, m_scopeChain) +
FIELD_OFFSET(ScopeChain, m_node)), regT1); // newScopeChain (2)
storePtr(ImmPtr(JSValuePtr::encode(noValue())), Address(callFrameRegister,
RegisterFile::OptionalCalleeArguments * static_castint(sizeof(Register;
storePtr(regT2, Address(callFrameRegister, RegisterFile::Callee *
static_castint(sizeof(Register;
storePtr(regT1, Address(callFrameRegister, RegisterFile::ScopeChain *
static_castint(sizeof(Register; (3)
}
So basically, what happens is:
(1) The trampoline loads args[1] into regT2
(2) Loads *(regT2 + offset) into reg T1
(3) Stores regT1 at args[-6] and destroys the value (writes 1 to ScopeChain)
I don't understand what this code is trying to do.. Comments appreciated.
Toshi
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Expected behavior of Mutex.lock()
Then perhaps all implementations could ASSERT in debug on mutex reentrancy to help discover where differences in behavior are accidentally 'used' (a stuck thread may sometimes mask some other issues). It's not good to have this kind of differences in 'cross-platform' code, sooner or later it'll cause very cryptic bugs, especially since developers with Windows background take reentrancy of critical section for granted. Dmitry On Tue, Jun 9, 2009 at 11:34 AM, Jeremy Orlow jor...@chromium.org wrote: I actually had exact the same question (but never got around to asking it). Given that pthreads' implementation is more strict, it'd seem like mutexes are not supposed to be reentrant. Maybe the windows version should ASSERT on reentrancy when in debug mode? On Tue, Jun 9, 2009 at 11:09 AM, Drew Wilson atwil...@google.com wrote: Any insights here? I'd be happy to add some documentation to Mutex if someone can verify what the intended behavior is... -atw sending emails to webkit-dev during WWDC is probably futile, I know :) On Sat, Jun 6, 2009 at 8:57 AM, Drew Wilson atwil...@google.com wrote: I can't seem to find any documentation as to what the expected behavior of Mutex.lock() is with regard to calling lock() recursively on the same thread. Looking at the pthreads implementation, it appears that when we create the mutex we pass null as the attributes, which gives us the default behavior (not re-entrant). The Windows implementation uses EnterCriticalSection which *is* re-entrant. I'm assuming that the pthreads implementation is the correct one (calling Mutex.lock() twice on the same mutex on a single thread should deadlock the thread) but I wanted to verify this since the implementations seem to vary. -atw ___ 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] Build number for Safari 4 final
Hi All, Which is build/release of Webkit is Safari 4 final ? Thanks and regards Sajesh ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to execute a JavaScript containing site with JSCore?
Hi Sebastian. JSEvaluateScript can only evaluate JavaScript; it can't parse HTML. Cheers, Geoff On Jun 10, 2009, at 10:05 PM, Sebastian Linke wrote: Hi, based on my experiences when I ran some javascript code on a webkit context, I was trying to do the same with normal html code. It may sound a bit naive, but I simply passed the whole content of a website to `JSEvaluateScript()`, using `JSGlobalContextCreate(NULL)` as the context. This did - as almost expected - not work. The only result I got back was `undefined`. So my question is: How does webkit handle this? In what kind of way is a javascript containing website given to the js engine to get back the right result after code execution (e.g. today's date displayed on the screen)? Or do things not go the way I think about and there is no html generated return value sent from JSCore? (Hope you know what I mean...) Regards Sebastian PS: My code example: http://paste.pocoo.org/show/122370/ ___ WEB.DE FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss für 17,95 Euro/mtl.! http://produkte.web.de/go/02/ ___ 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] arm jit
Can the arity check be performed at compile time as in C++? C++ can perform arity checks at compile time because C++ uses early binding. JavaScript uses late binding. Geoff___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Trampoline problem
On Jun 11, 2009, at 10:20 AM, Toshiyasu Morita wrote:
I've tracked down a crash in our JIT port to a problem with the
trampoline generation.
The symptom of the crash is: the ScopeChain becomes corrupted and
acquires the value of 1.
void
JIT::privateCompileCTIMachineTrampolines(RefPtrExecutablePool*
executablePool, void** ctiArrayLengthTrampoline, void**
ctiStringLengthTrampoline, void** ctiVirtualCallPreLink, void**
ctiVirtualCallLink, void** ctiVirtualCall)
{
emitPutJITStubArg(regT3, 2);
...
Call callArityCheck2 = call();
move(regT1, callFrameRegister);
emitGetJITStubArg(1, regT2); (1)
...
compileOpCallInitializeCallFrame();
...
}
void JIT::compileOpCallInitializeCallFrame()
{
store32(regT1, Address(callFrameRegister,
RegisterFile::ArgumentCount * static_castint(sizeof(Register;
loadPtr(Address(regT2, FIELD_OFFSET(JSFunction, m_scopeChain) +
FIELD_OFFSET(ScopeChain, m_node)), regT1); // newScopeChain (2)
storePtr(ImmPtr(JSValuePtr::encode(noValue())),
Address(callFrameRegister, RegisterFile::OptionalCalleeArguments *
static_castint(sizeof(Register;
storePtr(regT2, Address(callFrameRegister, RegisterFile::Callee
* static_castint(sizeof(Register;
storePtr(regT1, Address(callFrameRegister,
RegisterFile::ScopeChain * static_castint(sizeof(Register; (3)
}
So basically, what happens is:
(1) The trampoline loads args[1] into regT2
This is restoring the pointer to callee JSFunction*.
(2) Loads *(regT2 + offset) into reg T1
This is loading the ScopeChain from the callee function.
(3) Stores regT1 at args[-6] and destroys the value (writes 1 to
ScopeChain)
This is setting the ScopeChain in the callframe header so it is passed
to the callee.
I don't understand what this code is trying to do.. Comments
appreciated.
Toshi
___
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] arm jit
On Jun 11, 2009, at 9:59 AM, Toshiyasu Morita wrote:
--- On Wed, 6/10/09, Gavin Barraclough barraclo...@apple.com wrote:
If you consider calling a JS function with too few arguments as
being akin to =
invoking a C++ method with some defaulted parameters not-provided,
then it is
also the responsibility of code generated for the call to such a
method to ensure
that values for all declared parameters are passed.)
Thanks for the long explanation.
Can the arity check be performed at compile time as in C++?
Toshi
Alas no because you can't really guarantee exactly what function will
be called (except in a few relatively uncommon cases), eg.
function g() {
for (var i = 0; i 100; i++)
f(a*i);
}
g();
So if we look at the call to f(a*i) we need to ask what is the arity
of f?, so the issues we need to deal with to answer this question
statically are
* the object f may not be defined or it may not be a function at
compile time -- at runtime f may have become a function, or it may not
* any function call may result in f being changed and function calls
may occur during arithmetic if you cannot guarantee the input types
These two things together mean it's not reasonably possible to
guarantee the same function will be called every time, let alone have
the same arity.
--Oliver
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Expected behavior of Mutex.lock()
Agreed the ASSERT needn't be Windows only. It's probably better to ASSERT rather than deadlock on platforms without reentrant implementations. :-) I'll file a bug for this (and might just fix it) in a couple days if there are no more comments. J On Thu, Jun 11, 2009 at 10:39 AM, Dmitry Titov dim...@chromium.org wrote: Then perhaps all implementations could ASSERT in debug on mutex reentrancy to help discover where differences in behavior are accidentally 'used' (a stuck thread may sometimes mask some other issues). It's not good to have this kind of differences in 'cross-platform' code, sooner or later it'll cause very cryptic bugs, especially since developers with Windows background take reentrancy of critical section for granted. Dmitry On Tue, Jun 9, 2009 at 11:34 AM, Jeremy Orlow jor...@chromium.org wrote: I actually had exact the same question (but never got around to asking it). Given that pthreads' implementation is more strict, it'd seem like mutexes are not supposed to be reentrant. Maybe the windows version should ASSERT on reentrancy when in debug mode? On Tue, Jun 9, 2009 at 11:09 AM, Drew Wilson atwil...@google.com wrote: Any insights here? I'd be happy to add some documentation to Mutex if someone can verify what the intended behavior is... -atw sending emails to webkit-dev during WWDC is probably futile, I know :) On Sat, Jun 6, 2009 at 8:57 AM, Drew Wilson atwil...@google.com wrote: I can't seem to find any documentation as to what the expected behavior of Mutex.lock() is with regard to calling lock() recursively on the same thread. Looking at the pthreads implementation, it appears that when we create the mutex we pass null as the attributes, which gives us the default behavior (not re-entrant). The Windows implementation uses EnterCriticalSection which *is* re-entrant. I'm assuming that the pthreads implementation is the correct one (calling Mutex.lock() twice on the same mutex on a single thread should deadlock the thread) but I wanted to verify this since the implementations seem to vary. -atw ___ 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] arm jit
it looks we are in the way of the train. You have plans, we don't know about them, you have commit rights, we don't, so the tides are against us. If you're interested in review or commit rights, they're granted based on a track record of good work, good judgement, and good collaboration. You can read more about the policy here: http://webkit.org/coding/commit-review-policy.html . Please work on your collaboration skills. Right now, your tone stinks. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A Javascript Programming Environment for Safari 4
On Wed, Jun 10, 2009 at 7:22 PM, David Goehrig d...@nexttolast.com wrote:
Hello Webkitties,
Let me say, congratulations on getting so close to having real HTML5
support. While there are still some rough edges, Webkit has been making
some huge strides towards making the web a nice place to program. In the
spirit of showing off what can be done with the right tools, I've released a
bit of code that currently only runs under Safari 4.
I'm curious to know what APIs you're using that aren't working correctly in
Google Chrome.
Also, I know it's not done, but here's a few suggestions:
* The white boarder is a bit distracting. You probably want to do something
like body { margin: 0px } in CSS?
* The direction stuff moves on the canvas while scrolling should be
reversed.
Pretty cool for so few lines of code though!
It is a live object programming environment inspired by Randal Smith and
David Ungar's paper Programming as an Experience: The Inspiration for
Self. Like the Self environment, I've built a slot based object editing
system, just with a bit more drag drop support, HTML5 canvas integration,
and a classy object traits style programming model.
If you'd like to see what is possible in Safari 4 in about 3 days:
http://www.dloh.org/
The full source is available under the GPL3 license from github.com:
git clone git://github.com/cthulhuology/Phos.git
There's a set of tutorials available on the webapp, as well as, a series of
video tutorials on youtube. You can find the lot of them:
http://blog.dloh.org/
I'm going to add collaborative object editing support to the environment
this weekend, and should have offline and remote object storage done around
the same time.
Great work for making this sort of app possible,
David J. Goehrig
PS.
For those who are curious, the code base is small, ~588 Lines of code in
172 or so functions. Between 100-200 lines of code are there just to work
around issues with Javascript or API wonkiness. The meat of the application
is ~200 lines of code in 41 functions that provides support for Text,
Graphics, Video, and Sound widgets. The base 385 lines, consists of a
multipurpose library that I've used on two javascript projects. (The other
is NewScript, a Postscript meets Javascript language with an Intel native
compiler implemented in 100 or so lines of javascript).
--
-=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/
___
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] arm jit
If you're interested in review or commit rights, they're granted based on a track record of good work, good judgement, and good collaboration. You can read more about the policy here: http://webkit.org/coding/commit-review-policy.html . Please work on your collaboration skills. Right now, your tone stinks. I am sorry if I was not clear. I was talking about cooperation and openness, not about commit rights. Actually, I think it is unimportant who commit a patch, the important thing is that everyone should know what is happening. That is why I wrote those boring blog posts about technical details. Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Memory usage for Webkit
Hi, Is there any plan to reduce the memory usage of Webkit so that it uses less memory (runs better) on phone? if yes, where can I find ideas to reduce memory usage of Webkit (e.g. bug report, roadmap)? Thank you. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Memory usage for Webkit
On 2009-06-11, at 12:50, James Howlett wrote: Hi, Is there any plan to reduce the memory usage of Webkit so that it uses less memory (runs better) on phone? if yes, where can I find ideas to reduce memory usage of Webkit (e.g. bug report, roadmap)? Memory footprint is an area that we are actively working on. If you have a scenario in which WebKit uses more memory than you would expect, please file a bug report with detailed information so that we can reproduce the problem, and it will be investigated. - Mark smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Memory usage for Webkit
Hi, http://webkit.sed.hu/node/15 As you can see on the charts there, you should consider the whole environment not just WebKit alone. Large amount of resources are allocated by other libs as well. Zoltan On 2009-06-11, at 12:50, James Howlett wrote: Hi, Is there any plan to reduce the memory usage of Webkit so that it uses less memory (runs better) on phone? if yes, where can I find ideas to reduce memory usage of Webkit (e.g. bug report, roadmap)? Memory footprint is an area that we are actively working on. If you have a scenario in which WebKit uses more memory than you would expect, please file a bug report with detailed information so that we can reproduce the problem, and it will be investigated. - Mark ___ 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] to reitveld or not to reitveld
On Sat, Jun 6, 2009 at 7:14 PM, Ojan Vafai o...@google.com wrote: On Sun, Jun 7, 2009 at 7:51 AM, Mark Rowe mr...@apple.com wrote: There are also concerns about access to the data store of the application, backup procedures, etc. Our existing servers are well understood in this regard. We've also found in the past that having services spread across different systems causes confusion when something goes wrong, for whatever reason, as it's not clear who to contact to address the problem. For what it's worth, we've had next to zero maintenance effort go into keeping rietveld running on appengine. As far as I know, it's been pretty much stable and problem free. But I don't actually maintain it, so I can't say that for sure. :) It seems to me that all the issues raised with using reitveld are solvable. Assuming you all are OK with doing this iteratively instead of needing all the issues to be resolved on day one, I think we can probably start taking concrete steps forward. Maintenance/hosting is the biggest unanswered question. Would hosting this on reitveld (which does it's own replication and backups) be a deal-breaker? If so, there are a couple options a quick search brought up. One is http://arachnid.github.com/bdbdatastore/, which is linked to from the AppEngine blog as a way of hosting appengine apps on your own hardware. Another is http://code.google.com/appengine/articles/gae_backup_and_restore.html, which is a backup option for appengine. I'll reiterate that we've had great uptime and reliability for the Chromium reitveld instance on appengine. So, to me, hosting it yourself seems like extra work without much real-world benefit. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] to reitveld or not to reitveld
On 2009-06-11, at 15:16, Ojan Vafai wrote: On Sat, Jun 6, 2009 at 7:14 PM, Ojan Vafai o...@google.com wrote: On Sun, Jun 7, 2009 at 7:51 AM, Mark Rowe mr...@apple.com wrote: There are also concerns about access to the data store of the application, backup procedures, etc. Our existing servers are well understood in this regard. We've also found in the past that having services spread across different systems causes confusion when something goes wrong, for whatever reason, as it's not clear who to contact to address the problem. For what it's worth, we've had next to zero maintenance effort go into keeping rietveld running on appengine. As far as I know, it's been pretty much stable and problem free. But I don't actually maintain it, so I can't say that for sure. :) It seems to me that all the issues raised with using reitveld are solvable. Assuming you all are OK with doing this iteratively instead of needing all the issues to be resolved on day one, I think we can probably start taking concrete steps forward. Given what has been said so far I'm still not clear why Rietvald is a better option than Review Board. - Mark smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] to reitveld or not to reitveld
On Thu, Jun 11, 2009 at 3:21 PM, Mark Rowe mr...@apple.com wrote: Given what has been said so far I'm still not clear why Rietvald is a better option than Review Board. I think it's because we have a bunch of people who are (a) familiar with using it and/or (b) work on it and can fix any problems, whereas neither is true for Review Board. Also I haven't really heard much significantly Review Board Rietveld, more the sense of we could try these both out. It seems like reading between the lines you're really uncomfortable with Rietveld in principle. Is there something about it that you feel is inherently not going to work well? PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] to reitveld or not to reitveld
Mark Rowe wrote: On 2009-06-11, at 15:16, Ojan Vafai wrote: On Sat, Jun 6, 2009 at 7:14 PM, Ojan Vafai o...@google.com mailto:o...@google.com wrote: On Sun, Jun 7, 2009 at 7:51 AM, Mark Rowe mr...@apple.com mailto:mr...@apple.com wrote: There are also concerns about access to the data store of the application, backup procedures, etc. Our existing servers are well understood in this regard. We've also found in the past that having services spread across different systems causes confusion when something goes wrong, for whatever reason, as it's not clear who to contact to address the problem. For what it's worth, we've had next to zero maintenance effort go into keeping rietveld running on appengine. As far as I know, it's been pretty much stable and problem free. But I don't actually maintain it, so I can't say that for sure. :) It seems to me that all the issues raised with using reitveld are solvable. Assuming you all are OK with doing this iteratively instead of needing all the issues to be resolved on day one, I think we can probably start taking concrete steps forward. Given what has been said so far I'm still not clear why Rietvald is a better option than Review Board. Well, I haven't heard anything concrete on why Review Board is better than rveld, either. All I've seen are some posts saying, You know, Review Board exists too. Is the UI better? Is the architecture better? Is the design very different? Is it easier to integrate with git? Exactly how much work is involved in hosting each of these solutions? The only thing concrete I've seen is that Review Board is self-hosting, while rveld is tied to AppEngine. Joe ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] to reitveld or not to reitveld
On Thu, Jun 11, 2009 at 4:50 PM, Joe Mason joe.ma...@torchmobile.comwrote: Mark Rowe wrote: On 2009-06-11, at 15:16, Ojan Vafai wrote: On Sat, Jun 6, 2009 at 7:14 PM, Ojan Vafai o...@google.com mailto: o...@google.com wrote: On Sun, Jun 7, 2009 at 7:51 AM, Mark Rowe mr...@apple.com mailto:mr...@apple.com wrote: There are also concerns about access to the data store of the application, backup procedures, etc. Our existing servers are well understood in this regard. We've also found in the past that having services spread across different systems causes confusion when something goes wrong, for whatever reason, as it's not clear who to contact to address the problem. For what it's worth, we've had next to zero maintenance effort go into keeping rietveld running on appengine. As far as I know, it's been pretty much stable and problem free. But I don't actually maintain it, so I can't say that for sure. :) It seems to me that all the issues raised with using reitveld are solvable. Assuming you all are OK with doing this iteratively instead of needing all the issues to be resolved on day one, I think we can probably start taking concrete steps forward. Given what has been said so far I'm still not clear why Rietvald is a better option than Review Board. Well, I haven't heard anything concrete on why Review Board is better than rveld, either. All I've seen are some posts saying, You know, Review Board exists too. Is the UI better? Is the architecture better? Is the design very different? Is it easier to integrate with git? Exactly how much work is involved in hosting each of these solutions? The only thing concrete I've seen is that Review Board is self-hosting, while rveld is tied to AppEngine. ...and there's some that you could run rietveld without AppEngine infastructure if necessary. FWIW, another project I (used to) work on tried Review Board out about a year ago. We found it to be pretty clunky, so we continued just doing code reviews via diffs in email. Maybe it's improved since then. Either way, I believe the team is now using Rietveld for large reviews. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] to reitveld or not to reitveld
On Thu, Jun 11, 2009 at 5:19 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Jun 11, 2009 at 4:50 PM, Joe Mason joe.ma...@torchmobile.comwrote: Mark Rowe wrote: On 2009-06-11, at 15:16, Ojan Vafai wrote: On Sat, Jun 6, 2009 at 7:14 PM, Ojan Vafai o...@google.com mailto: o...@google.com wrote: On Sun, Jun 7, 2009 at 7:51 AM, Mark Rowe mr...@apple.com mailto:mr...@apple.com wrote: There are also concerns about access to the data store of the application, backup procedures, etc. Our existing servers are well understood in this regard. We've also found in the past that having services spread across different systems causes confusion when something goes wrong, for whatever reason, as it's not clear who to contact to address the problem. For what it's worth, we've had next to zero maintenance effort go into keeping rietveld running on appengine. As far as I know, it's been pretty much stable and problem free. But I don't actually maintain it, so I can't say that for sure. :) It seems to me that all the issues raised with using reitveld are solvable. Assuming you all are OK with doing this iteratively instead of needing all the issues to be resolved on day one, I think we can probably start taking concrete steps forward. Given what has been said so far I'm still not clear why Rietvald is a better option than Review Board. Well, I haven't heard anything concrete on why Review Board is better than rveld, either. All I've seen are some posts saying, You know, Review Board exists too. Is the UI better? Is the architecture better? Is the design very different? Is it easier to integrate with git? Exactly how much work is involved in hosting each of these solutions? The only thing concrete I've seen is that Review Board is self-hosting, while rveld is tied to AppEngine. ...and there's some that you could run rietveld without AppEngine infastructure if necessary. er...there's there's some _evidence_ that you could run rietveld without AppEngine infastructure if necessary. (referring back to Ojan's comment) FWIW, another project I (used to) work on tried Review Board out about a year ago. We found it to be pretty clunky, so we continued just doing code reviews via diffs in email. Maybe it's improved since then. Either way, I believe the team is now using Rietveld for large reviews. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] arm jit
And here, I have to make a short comment on the non-acceptance of our ARM JIT implementation. In your mail you mention that you would remain reluctant to accept a duplicate of the JIT into the tree, rather than a port of the existing JIT utilizing the MacroAssembler abstraction. Well, did you check our ARM port? It has been rewritten to conform to the MacroAssembler interfaces more than a month ago and posted it into the bugzilla (https://bugs.webkit.org/show_bug.cgi?id=24986). Hi Zoltan, I'm sorry if I'm misinterpreting you here, but it sounds like over the last month you have been expecting your MacroAssembler based ARM port to have been reviewed. If so - Then I can quite understand your frustration, and do sympathize greatly with you. There clearly has been a breakdown in communication, and I'm sorry about your disappointment. I'm afraid that we had no way of knowing that you considered your port to be complete. Just last week, in an email on this list, I said, when you have a patch ready for review, please attach it to the bug and set the review flag – I was under the impression that you did not feel your changes were yet final (by the sound of it I was mistaken). I was assuming that when a final patch was ready you would attach it to the bug, and mark it for review. We have a procedure for accepting contributions to avoid exactly this kind of miscommunication. The mechanism for communicating to us that you believe your patch is ready is very simple, and is absolutely critical if you want to get code into WebKit. Patches ready for review must be marked as such in bugzilla. Without this we cannot tell which patches attached to bugs are complete, and which represent work in progress. I urge you to review the instructions on contributing on the website, since following these will be the only way to avoid similar disappointment in the future. Perhaps this is an area where we need to improve our communication – perhaps we need to make these instructions clearer, or more prominent on the website. The website is all stored in svn, so please do file bugs in bugzilla – or patches welcome – if you think these can be improved. Anyway, we have updated the MacroAssembler-based ARM port of ours, uploaded it to the bugzilla, and set the review flag on the patch. I've had a brief chance to look at the patch, and it's looking really great. There are some bits to clean up a little to get it through review, and we will want to land a change of this magnitude incrementally. I'm afraid that I have a busy day today, I will try to comment on the bug tonight but it may have to wait until the morning. Hopefully we can get this landed into ToT fairly quickly. cheers, G. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] about webkit's license in chrome
As listed in http://code.google.com/chromium/terms.html#3rdparty , there're three different licenses of webkit in chrome: BSD/LGPL 2/LGPL 2.1 Why? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] about webkit's license in chrome
2009/6/11 David Jones ds...@163.com As listed in http://code.google.com/chromium/terms.html#3rdparty , there're three different licenses of webkit in chrome: BSD http://www.opensource.org/licenses/bsd-license.php/LGPL 2/LGPL 2.1http://opensource.org/licenses/lgpl-2.1.php Why? For the same reason the Mozilla code lists three licenses: because the code is tri-licensed. It is offered simultaneously under three different licenses. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] about webkit's license in chrome
On Thu, Jun 11, 2009 at 10:44:25PM -0700, Peter Kasting wrote: 2009/6/11 David Jones ds...@163.com As listed in http://code.google.com/chromium/terms.html#3rdparty , there're three different licenses of webkit in chrome: BSD http://www.opensource.org/licenses/bsd-license.php/LGPL 2/LGPL 2.1http://opensource.org/licenses/lgpl-2.1.php Why? For the same reason the Mozilla code lists three licenses: because the code is tri-licensed. It is offered simultaneously under three different licenses. Technically, that is not true. While (most of) Mozilla code is effectively tri-licensed, i.e. released under the terms of the three licences, WebKit code is partly licensed under each one, i.e. parts are under 2-clause BSD, parts under 3-clause BSD, and parts under LGPL 2 or 2.1. Mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ubuntu build problem
do anybody have a clue, or any pointers for me so that I can fix it myself? I have checked out revision 44600 today and it gives me build problem is there some stable version which I should be using? I am building it on ubuntu machine with command ./build-webkit --wx --wx-args=wxgc wxpython ranlib /home/anushri/try/WebKit/WebKitBuild/Release/libjscore.a g++ -o /home/anushri/try/WebKit/WebKitBuild/Release/jsc obj-gnu/jsc_jsc.o -lm -L/usr/lib -licui18n -licuuc -licudata -lm -L/home/anushri/try/WebKit/WebKitBuild/Release -L/home/anushri/try/WebKit/WebKitTools/wx/../../WebKitLibraries/unix/lib -L/home/anushri/try/WebKit/WebKitTools/wx/../../WebKitLibraries -ljpeg -lpng `wx-config --libs core,base` -g-ljscore -lpthread /home/anushri/try/WebKit/WebKitBuild/Release/libjscore.a(jscore_JSGlobalData.o): In function `JSC::JSGlobalData::JSGlobalData(bool, JSC::VPtrSet const)': JSGlobalData.cpp:(.text+0x8e1): undefined reference to `JSC::jsonTable' /home/anushri/try/WebKit/WebKitBuild/Release/libjscore.a(jscore_JSGlobalData.o): In function `JSC::JSGlobalData::JSGlobalData(bool, JSC::VPtrSet const)': JSGlobalData.cpp:(.text+0x1241): undefined reference to `JSC::jsonTable' /home/anushri/try/WebKit/WebKitBuild/Release/libjscore.a(jscore_JSGlobalObject.o): In function `JSC::JSGlobalObject::reset(JSC::JSValue)': JSGlobalObject.cpp:(.text+0x5391): undefined reference to `vtable for JSC::JSONObject' collect2: ld returned 1 exit status make: *** [/home/anushri/try/WebKit/WebKitBuild/Release/jsc] Error 1 make: Leaving directory `/home/anushri/try/WebKit/JavaScriptCore rgds Anurag Explore and discover exciting holidays and getaways with Yahoo! India Travel Click here! Own a website.Get an unlimited package.Pay next to nothing.*Click here!. Cricket on your mind? Visit the ultimate cricket website. Enter http://beta.cricket.yahoo.com___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
