Re: [webkit-dev] CMake as a build system?
On Fri, Apr 23, 2010 at 12:54 AM, Darin Fisher da...@chromium.org wrote: On Tue, Apr 20, 2010 at 10:53 AM, Peter Kasting pkast...@google.comwrote: On Tue, Apr 20, 2010 at 1:26 AM, Patrick Roland Gansterer par...@paroga.com wrote: Bradley Nelson: 1. Ability to incrementally transition on Windows. It took us about 6 months to switch fully to gyp. Previous attempts to move to scons had taken a long time and failed, due to the requirement to transition while in flight. For a substantial period of time, we had a hybrid of checked in vcproj and gyp generated CMake should be treated like a separate buildsystem like qmake or gyp during a possible switch. The point was that we wanted to be able to switch over in a gradual fashion, not by constructing a complete, functional parallel build system and then throwing the switch. If you take a look in the current vcprojs you can't understand them more easy than compared to CMake IMHO. Anyway: How often do you look at these settings? I use the IDE only for writing code and debugging. I do all my buildsystem changes directly in the CMake files. If i see the source files in the IDE I'm already happy. Do you have other requirements? AIUI, readability isn't the issue, it's the ability for e.g. Visual Studio to correctly understand dependencies itself so that incremental builds from inside the IDE (which is where most Windows Chromium developers do their builds) work correctly and are as fast as possible (e.g. the null build should take close to zero time and not have to rerun steps or relink executables). Indeed. It also allows features like Ctrl+F7 (compile only the current source file) to work. A number of other common IDE features are lost if you use a makefile based vcproj. GYP nicely preserves all of those great IDE features, which to me is one of the main selling points as an end-user. -Darin Please disregard my comments above. Thanks to Patrick for showing me that CMake does indeed generate vcproj files that preserve this degree of integration with the IDE. GYP and CMake appear to have that in common. -Darin PK ___ 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] Bugzilla Triaged keyword
On 26.04.10 22.16, Andras Becsi wrote: As far as I know QtWebKit uses this keyword to indicate that the corresponding bug has been checked and prioritized based on its severity by a triaging group of two QtWebKit developers. https://trac.webkit.org/wiki/QtWebKitBugs#Triagingbugs That's correct. It's an attempt at using Bugzilla for all our bugs, and to manage them with some sense of control over what's there :) 2010-04-26 21:06 keltezéssel, Alexey Proskuryakov írta: There are bugs marked with Triaged keyword in Bugzilla now. Keyword description says Indicates that the bug was triaged according to the Bug Reporting Guidelines, and passed. What is the intended usage for this keyword? Who adds it, and what is it used for? From the description, the difference sounds just like the difference between UNCONFIRMED and NEW, and we never had a lot of use for that, other than indicating to the reporter that someone looked at the bug. You're right, it is similar to UNCONFIRMED/NEW. The reason for choosing a keyword was the inherit limitations of the status, eg. anyone with editbugs will default to NEW, you can't go back from UNCONFIRMED to NEW, and an ASSIGNED or REOPENED bug loses the state, etc. Tor Arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] attach/detach or insertedIntoDocument/removedFromDocument
Hello, I am implementing XML3D http://www.xml3d.org/ format into WebKit. I have a number of new elements that I have added to a separate namespace. Root element is xml3d and it's the only one who has a renderer. Every child that is attached to the subtree of this element should notify parent element about itself and register themselves with this renderer. I need to have a function that I can override to perform this initialization. My implementation uses third party library for rendering and requires me to have a single renderer to render the whole scene, therefore I can't split renderer into many subrenderers for each node. Moreover, 3D scenes do not follow box model and rendering of single node often requires to interact with other elements in the scene (e.g. for ray tracing) thus storing the entire scene in the single data-structure is more effective. To perform the registration with the parent renderer I have tried using insertedIntoDocument/removedFromDocument, but they result in overhead when I am attaching element to a tree which is not rendered at all (such as loaded by Ajax). Then I switched to attach/detach but these are called many times, i.e. every node gets attached, detached, attached again etc. while loading the document, which still causes the overhead. Is there any set of functions that would allow me to know when I am attached to the subtree and that tree should be rendered? Thank you in advance, Sergiy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bugzilla Triaged keyword
27.04.2010, в 00:56, Tor Arne Vestbø написал(а): As far as I know QtWebKit uses this keyword to indicate that the corresponding bug has been checked and prioritized based on its severity by a triaging group of two QtWebKit developers. https://trac.webkit.org/wiki/QtWebKitBugs#Triagingbugs That's correct. It's an attempt at using Bugzilla for all our bugs, and to manage them with some sense of control over what's there :) I can imagine ongoing confusion about this keyword. Would it makes sense to rename to something like QtTriaged? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Disabling the JIT
If you want to set the flags manually, you should write CXXFLAGS+=... instead of CXXFLAGS=. However, the first method what you tried is right, so if it is crashing then smg wrong with the JIT. What platform (Architecture, OS, qt-version) do you use? On 04/27/2010 05:41 PM, Nyx wrote: I am trying to disable the JIT when building the QT version of webkit so that I can instrument the interpreter for profiling purposes. I have been googling around and found a few suggestions, which so far have all not worked: If I run the following build command: WebKit/WebKitTools/Scripts/build-webkit --qt JAVASCRIPTCORE_JIT=no WebKit builds, but when I try to run it: WebKit/WebKitTools/Scripts/run-launcher --qt It crashes as soon as I try to load a page that uses JavaScript (eg: google). Someone also suggested building WebKit as follows: WebKit/WebKitTools/Scripts/build-webkit --qt --makeargs='CXXFLAGS=-DENABLE_JIT=0' This works *once*, but if I try to run build-webkit a second time, I get lots of nonsensical compilation errors, which I can't seem to get rid of, even if I try to build without -DENABLE_JIT=0... Any help would be appreciated, - Max ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] QtWebkit vs GtkWebkit
Hi, Yes, I have tried this on several versions of Ubuntu, including Lucid. I don't have Windows machine so I can't try that. There is not a single instance of a QtWebKit browser (or my own snippet of QtWebKit code) that works - and 100% of every GtkWebKit browsers (and my own snippet of GtkWebKit code) that works on my Linux system. This is forcing me to create a hybrid application written in Qt, with the webkit portion being handled in Gtk - which, I am sure I don't need to inform anyone, is a royal pain in the ass. If I am missing something obvious, I would appreciate a hint. Cheers, ---AK From: Chinmaya Sn chinm...@gmail.com To: Phoenix Revived phoenixrevi...@yahoo.com Cc: webkit-dev@lists.webkit.org Sent: Sun, April 25, 2010 1:33:05 PM Subject: Re: [webkit-dev] QtWebkit vs GtkWebkit I don't see this in Windows (Using latest arora 0.10.0). Are you using Linux? On Sun, Apr 25, 2010 at 11:07 AM, Phoenix Revived phoenixrevi...@yahoo.com wrote: After a frustrating number of hours, I finally discovered a problem with QtWebkit (and all browsers derived from it: Arora, Konqueror, etc.) - when trying to play a video in youtube.com/xl, they all display a white screen. I had this problem in my application and spent many hours beating my head against the wall before discovering that I wasn't doing anything wrong. This problem does not exist with any of the GtKWebkit based browsers (or GtkWebkit itself). I can play these videos without problem on everything from the small browsers like midori and uzbl, to the giants like Chrome and Firefox. Any ideas? Cheers, ---AK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- -- chinmaya sn ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] QtWebkit vs GtkWebkit
Sorry, I wasn't clear. My probems are all on Ubuntu Linux - both in Jaunty and Lucid - with all QtEbkit-based browsers. what is http://doobie.sf.net;? A QtWebkit-based browser? Is it open-source? Cheers, ---AK From: Max petersonm...@googlemail.com To: Phoenix Revived phoenixrevi...@yahoo.com Cc: webkit-dev@lists.webkit.org Sent: Sun, April 25, 2010 1:36:55 PM Subject: Re: [webkit-dev] QtWebkit vs GtkWebkit http://dooble.sf.net has this only on windows, on linux it is working good. maybe a windows specific problem. Do others work on windows? On Sun, Apr 25, 2010 at 7:07 PM, Phoenix Revived phoenixrevi...@yahoo.com wrote: After a frustrating number of hours, I finally discovered a problem with QtWebkit (and all browsers derived from it: Arora, Konqueror, etc.) - when trying to play a video in youtube.com/xl, they all display a white screen. I had this problem in my application and spent many hours beating my head against the wall before discovering that I wasn't doing anything wrong. This problem does not exist with any of the GtKWebkit based browsers (or GtkWebkit itself). I can play these videos without problem on everything from the small browsers like midori and uzbl, to the giants like Chrome and Firefox. Any ideas? Cheers, ---AK ___ 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] Disabling the JIT
If you want to set the flags manually, you should write CXXFLAGS+=... instead of CXXFLAGS=. Thanks. I will be trying that. However, the first method what you tried is right, so if it is crashing then smg wrong with the JIT. What platform (Architecture, OS, qt-version) do you use? Ubuntu 9.10, x86 32 bit, qt package is libqt4-dev (4.5.3). I would assume the problem is in fact with the JIT, because it happens when I browse away from the blank page to google.com, which is when the JavaScript interpreter gets instantiated. By the way, I intend to be messing around with the interpreter a fair bit. Is running buld-webkit every time I make a change to the source really the way to go about this, or is there a more efficient way? -- View this message in context: http://old.nabble.com/Disabling-the-JIT-tp28378562p28379151.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Experimental new code reviews
Here's the prototype I made during the hackathon that simply uses a bunch of Javascript to make it easier to type up comments: http://ascherkus.appspot.com/bugzilla/index.html I'm not a WebKit reviewer, but from what I gathered during the session there's a lot of copying and pasting involved. I focused on trying to fix that particular issue. Double click a line to add a comment. Code context + comment gets appended into the patch comment box. It's purely visual -- nothing gets persisted. Andrew On Mon, Apr 19, 2010 at 4:20 PM, Ojan Vafai o...@chromium.org wrote: I don't know if it's up anywhere. The other group's approach adds more directly upon the current review system. I don't think we need to choose one vs. another (at least not in the short term). Not that you were suggesting that. Ojan On Mon, Apr 19, 2010 at 4:06 PM, Adam Barth aba...@webkit.org wrote: +scherkus On Mon, Apr 19, 2010 at 4:01 PM, Maciej Stachowiak m...@apple.com wrote: I heard another group coded up a different approach to improving reviews - does anyone have a URL for that, so we can compare? Cheers, Maciej On Apr 19, 2010, at 3:35 PM, Ojan Vafai wrote: At the hackathon last Tuesday, a few of us put together mashup style rietveld integration with bugs.webkit.org. It currently requires a chrome extension. We'll integrate properly with bugzilla based on feedback if this seems to be a value add for the project. http://webkit-rietveld.googlecode.com/svn/trunk/chrome-extension/webkit-cr.crx You can try it out on the *last* attachment on https://bugs.webkit.org/show_bug.cgi?id=37531. You'll see another link next to each attachment labelled Fancy Review. This loads a page much like the current review page, but with wkrietveld.appspot.com in the top frame (wkrietveld is our fork of rietveld). You can then make comments in rietveld. When you click the submit button, the comments are published *both* in Reitveld and to bugs.webkit.org. We do not intend to remove the old code review system for people who prefer to stick to that. Known issues: -Currently, only works with patches that are uploaded using webkit-patch upload --fancy-review. -Due to using a chrome extension rather than a tighter integration, some things are a bit janky (e.g. the initial load). -Each time a patch is uploaded, it currently creates a new rietveld issue. Ojan ___ 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] Trouble reviewing patches since the experimental commenting support went into bugs.webkit.org's action=review page
On Thu, Apr 22, 2010 at 1:13 PM, Adam Roben aro...@apple.com wrote: On Apr 22, 2010, at 4:01 PM, Darin Adler wrote: - The comments all cite only a single line of the patch and I almost never have a comment that's for a single line. So I have to do a lot of editing, pretending to comment on multiple lines. I think it would be nice if you could drag to select multiple lines of code. When you release the mouse button, the comment box would appear, and when you commit that comment all the lines you selected would be quoted. The other person who I was working with had this feature implemented, but I forget his name and didn't grab his email. I hope he reads webkit-dev :\ Andrew ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bugzilla Triaged keyword
On 4/27/2010 5:38 PM, ext Alexey Proskuryakov wrote: 27.04.2010, в 00:56, Tor Arne Vestbø написал(а): As far as I know QtWebKit uses this keyword to indicate that the corresponding bug has been checked and prioritized based on its severity by a triaging group of two QtWebKit developers. https://trac.webkit.org/wiki/QtWebKitBugs#Triagingbugs That's correct. It's an attempt at using Bugzilla for all our bugs, and to manage them with some sense of control over what's there :) I can imagine ongoing confusion about this keyword. Would it makes sense to rename to something like QtTriaged? If you believe that for other ports it will bring more confusion than use, then please do so. Jocelyn ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] QtWebkit vs GtkWebkit
On Tue, Apr 27, 2010 at 9:14 AM, Phoenix Revived phoenixrevi...@yahoo.com wrote: Yes, I have tried this on several versions of Ubuntu, including Lucid. I don't have Windows machine so I can't try that. There is not a single instance of a QtWebKit browser (or my own snippet of QtWebKit code) that works - and 100% of every GtkWebKit browsers (and my own snippet of GtkWebKit code) that works on my Linux system. This is forcing me to create a hybrid application written in Qt, with the webkit portion being handled in Gtk - which, I am sure I don't need to inform anyone, is a royal pain in the ass. If I am missing something obvious, I would appreciate a hint. The best candidate for something obvious you overlooked is the Getting Involved heading on the webkit.org site! :) From your diagnosis it sounds like perhaps either WebKitQt is lacking support for these plugins (or possibly there's a misconfiguration or something). Rather than the royal pain of working around it, why not fix WebKitQt? From a grep in the WebKitQt plugin code it does look like it has some preliminary bit of Gtk support. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bugzilla Triaged keyword
I've renamed Triaged to QtTriaged. Dave - Original Message From: Jocelyn Turcotte jocelyn.turco...@nokia.com To: webkit-dev@lists.webkit.org Sent: Tue, April 27, 2010 10:02:36 AM Subject: Re: [webkit-dev] Bugzilla Triaged keyword On 4/27/2010 5:38 PM, ext Alexey Proskuryakov wrote: 27.04.2010, в 00:56, Tor Arne Vestbø написал(а): As far as I know QtWebKit uses this keyword to indicate that the corresponding bug has been checked and prioritized based on its severity by a triaging group of two QtWebKit developers. href=https://trac.webkit.org/wiki/QtWebKitBugs#Triagingbugs; target=_blank https://trac.webkit.org/wiki/QtWebKitBugs#Triagingbugs That's correct. It's an attempt at using Bugzilla for all our bugs, and to manage them with some sense of control over what's there :) I can imagine ongoing confusion about this keyword. Would it makes sense to rename to something like QtTriaged? If you believe that for other ports it will bring more confusion than use, then please do so. Jocelyn ___ webkit-dev mailing list href=mailto:webkit-dev@lists.webkit.org;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] Disabling the JIT
On 04/27/2010 07:02 PM, Nyx wrote: If you want to set the flags manually, you should write CXXFLAGS+=... instead of CXXFLAGS=. Another way would be to set export QMAKEARGS=$QMAKEARGS DEFINES+=ENABLE_JIT=0 before building. However, the first method what you tried is right, so if it is crashing then smg wrong with the JIT. What platform (Architecture, OS, qt-version) do you use? Ubuntu 9.10, x86 32 bit, qt package is libqt4-dev (4.5.3). I would assume Your qt version is fairly old, if you want to develop, you probably need a newer version from upstream (eg. 4.6.2). the problem is in fact with the JIT, because it happens when I browse away from the blank page to google.com, which is when the JavaScript interpreter gets instantiated. That is strange. Did you checkout the source from svn? Did you mess around in the code? By the way, I intend to be messing around with the interpreter a fair bit. Is running buld-webkit every time I make a change to the source really the way to go about this, or is there a more efficient way? If you do not change things which are related to generated code, you can also use make -C WebKitBuild/Release (or Debug respectively), but it is probably safer to use build-webkit, which also builds incrementally, but generates the needed code, if there was a change, and runs qmake. BR; Andras ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Disabling the JIT
Another way would be to set export QMAKEARGS=$QMAKEARGS DEFINES+=ENABLE_JIT=0 before building. Will try it too. That is strange. Did you checkout the source from svn? Did you mess around in the code? Yes. I checked it out last night from the trunk. -- View this message in context: http://old.nabble.com/Disabling-the-JIT-tp28378562p28380211.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Disabling the JIT
Another way would be to set export QMAKEARGS=$QMAKEARGS DEFINES+=ENABLE_JIT=0 before building. Ok. I tried this approach. I have a build script that looks like this: QTDIR=/usr/share/qt4/ export QMAKEARGS=$QMAKEARGS DEFINES+=ENABLE_JIT=0 WebKit/WebKitTools/Scripts/build-webkit --qt It builds, but the JIT is not disabled. It seems that the new argument is simply ignored. I also tried adding #define ENABLE_JIT 0 at the top of the Interpreter.cpp file in JavaScriptCore. This builds, but produces a segmentation fault. I will try doing the WebKit/WebKitTools/Scripts/build-webkit --qt JAVASCRIPTCORE_JIT=no with a fresh SVN checkout... Is there any equivalent of make clean script, as a completment to build-webkit? -- View this message in context: http://old.nabble.com/Disabling-the-JIT-tp28378562p28382091.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Disabling the JIT
On Apr 27, 2010, at 2:10 PM, Nyx wrote: I also tried adding #define ENABLE_JIT 0 at the top of the Interpreter.cpp file in JavaScriptCore. This builds, but produces a segmentation fault. This would not work as you would end up with some parts of WebKit compiled with the jit enabled, and some not. If you want to try forcing the jit to be disabled with a #define you need to do it in Platform.h --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Windows setjmp/longjmp issue
In WebCore/platform/image- decoders/jpeg/JPEGImageDecoder.cpp ( https://trac.webkit.org/browser/trunk/WebCore/platform/image-decoders/jpeg/JPEGImageDecoder.cpp) and png/PNGImageDecoder.cpp, setjmp and longjmp are called. This causes this code unportable to Windows environment. At http://msdn.microsoft.com/en-us/library/xe7acxfb%28VS.80%29.aspx, it is mentioned that setjmp and longjmp do not support C++ object semantics. My understanding is that WebKit has been ported to Windows for three years. Can someone educate me on how current Chrome and Safari work on Windows? Why does such a basic problem exist but without being seen? Do they use the above image decoder files? I tried to run a program linked with a prebuilt Windows WebKit library and it crashes at setjmp() when accessing a jpeg file. Can this problem be fixed? Thanks, S.R. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Accessing WebKit JS binding classes from non-WebKit JavaScript Core applications?
Hi, I'm working on a project which makes use of JavaScriptCore as a scripting engine outside of WebKit. It would be very helpful to us if we could get access to the DOMParser and XMLSerializer classes which are in WebKit's DerivedSources area. However, it seems that those libraries are using JavaScript Core's internal/private API (JSC::ExecState, JSC::Value, etc.) rather than the public interface expected by external users of JavaScript Core. We'd also like to avoid pulling in the internal WebKit headers anyway, as this would complicate our build system (for example, we'd like to be able to do this just using the header files provided by Ubuntu's libwebkit-dev package). I'm fine with writing forward-declaration classes and stub methods for the purpose of letting the C++ linker figure it all out, but JSC::JSValue seems to get in the way of this idea, since the getConstructor() methods on the libraries we want return it by value rather than by reference (and it doesn't appear to be a simple reinterpret_cast like it is for the other public-API classes). Is there some official way that we can get at WebKit's DerivedSources library functionality in a non-WebKit JavaScript Core application, or can anyone think of some tricky-but-relatively-clean way to do it that doesn't involve our app having to see JSC's internal API? Thanks in advance. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Accessing WebKit JS binding classes from non-WebKit JavaScript Core applications?
DerivedSources are generated from here: http://trac.webkit.org/browser/trunk/WebCore/DerivedSources.make I think what your'e thinking of as DerivedSources is actually just the javascript bindings, which will be useless to you w/o the actual implementations in WebCore. If for some reason you wanted to write your own custom bindings which use JSC's public API instead of the internal one which WebCore uses, you could make your own generator script: http://trac.webkit.org/browser/trunk/WebCore/bindings/scripts/ You can see examples of those scripts being run in DerivedSources.make or in run-bindings-tests: http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/run-bindings-tests In short, this is not a supported configuration. :) I'm also not really sure it's on topic for this list. Best of luck! -eric On Tue, Apr 27, 2010 at 3:44 PM, Josh Shagam joshua.sha...@am.sony.com wrote: Hi, I'm working on a project which makes use of JavaScriptCore as a scripting engine outside of WebKit. It would be very helpful to us if we could get access to the DOMParser and XMLSerializer classes which are in WebKit's DerivedSources area. However, it seems that those libraries are using JavaScript Core's internal/private API (JSC::ExecState, JSC::Value, etc.) rather than the public interface expected by external users of JavaScript Core. We'd also like to avoid pulling in the internal WebKit headers anyway, as this would complicate our build system (for example, we'd like to be able to do this just using the header files provided by Ubuntu's libwebkit-dev package). I'm fine with writing forward-declaration classes and stub methods for the purpose of letting the C++ linker figure it all out, but JSC::JSValue seems to get in the way of this idea, since the getConstructor() methods on the libraries we want return it by value rather than by reference (and it doesn't appear to be a simple reinterpret_cast like it is for the other public-API classes). Is there some official way that we can get at WebKit's DerivedSources library functionality in a non-WebKit JavaScript Core application, or can anyone think of some tricky-but-relatively-clean way to do it that doesn't involve our app having to see JSC's internal API? Thanks in advance. ___ 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] Accessing WebKit JS binding classes from non-WebKit JavaScript Core applications?
Thanks. I apologize for mincing terminology - I'm not particularly versed in how WebKit is put together, where WebKit ends and JavaScriptCore begins, etc., and I've mostly been banging my head against this based on looking at work that some of my coworkers have done. :) I should be more specific that we are in fact linking against WebKit and so we will have the implementations available. We are actually using full WebKit for another part of the system as well, but we'd like to be able to access WebKit's JS bindings from outside of the WebKit view. It looks like bindings/scripts bit will help me get on the right track, in any case. Thanks for the pointer. Eric Seidel wrote: DerivedSources are generated from here: http://trac.webkit.org/browser/trunk/WebCore/DerivedSources.make I think what your'e thinking of as DerivedSources is actually just the javascript bindings, which will be useless to you w/o the actual implementations in WebCore. If for some reason you wanted to write your own custom bindings which use JSC's public API instead of the internal one which WebCore uses, you could make your own generator script: http://trac.webkit.org/browser/trunk/WebCore/bindings/scripts/ You can see examples of those scripts being run in DerivedSources.make or in run-bindings-tests: http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/run-bindings-tests In short, this is not a supported configuration. :) I'm also not really sure it's on topic for this list. Best of luck! -eric On Tue, Apr 27, 2010 at 3:44 PM, Josh Shagam joshua.sha...@am.sony.com wrote: Hi, I'm working on a project which makes use of JavaScriptCore as a scripting engine outside of WebKit. It would be very helpful to us if we could get access to the DOMParser and XMLSerializer classes which are in WebKit's DerivedSources area. However, it seems that those libraries are using JavaScript Core's internal/private API (JSC::ExecState, JSC::Value, etc.) rather than the public interface expected by external users of JavaScript Core. We'd also like to avoid pulling in the internal WebKit headers anyway, as this would complicate our build system (for example, we'd like to be able to do this just using the header files provided by Ubuntu's libwebkit-dev package). I'm fine with writing forward-declaration classes and stub methods for the purpose of letting the C++ linker figure it all out, but JSC::JSValue seems to get in the way of this idea, since the getConstructor() methods on the libraries we want return it by value rather than by reference (and it doesn't appear to be a simple reinterpret_cast like it is for the other public-API classes). Is there some official way that we can get at WebKit's DerivedSources library functionality in a non-WebKit JavaScript Core application, or can anyone think of some tricky-but-relatively-clean way to do it that doesn't involve our app having to see JSC's internal API? Thanks in advance. ___ 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] Accessing WebKit JS binding classes from non-WebKit JavaScript Core applications?
Various WebKit ports expose different bindings. The JS bindings are only exposed to scripts on pages run inside WebKit. If you have your own separate javascript environment, you would need to set up your own custom bindings for that environment. We don't really provide clean APIs for that, however, there has been talk over the years of taking the bindings/scripts and making it possible for clients of WebKit to generate JSC-API compatible autogenerated bindings wrapping their own implementation objects. You'd still have to write your own implementation objects which talked to the right pieces of WebKit/WebCore however. I think you'll run into a world of pain if you try and just expose guts of WebCore to clients outside of WebCore w/o having gone through the normal WebCore parsing mechanisms and created a Page, Frame, Client objects, etc. Anyway, best of luck and we look forward to seeing your contributions. -eric On Tue, Apr 27, 2010 at 3:56 PM, Josh Shagam joshua.sha...@am.sony.com wrote: Thanks. I apologize for mincing terminology - I'm not particularly versed in how WebKit is put together, where WebKit ends and JavaScriptCore begins, etc., and I've mostly been banging my head against this based on looking at work that some of my coworkers have done. :) I should be more specific that we are in fact linking against WebKit and so we will have the implementations available. We are actually using full WebKit for another part of the system as well, but we'd like to be able to access WebKit's JS bindings from outside of the WebKit view. It looks like bindings/scripts bit will help me get on the right track, in any case. Thanks for the pointer. Eric Seidel wrote: DerivedSources are generated from here: http://trac.webkit.org/browser/trunk/WebCore/DerivedSources.make I think what your'e thinking of as DerivedSources is actually just the javascript bindings, which will be useless to you w/o the actual implementations in WebCore. If for some reason you wanted to write your own custom bindings which use JSC's public API instead of the internal one which WebCore uses, you could make your own generator script: http://trac.webkit.org/browser/trunk/WebCore/bindings/scripts/ You can see examples of those scripts being run in DerivedSources.make or in run-bindings-tests: http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/run-bindings-tests In short, this is not a supported configuration. :) I'm also not really sure it's on topic for this list. Best of luck! -eric On Tue, Apr 27, 2010 at 3:44 PM, Josh Shagam joshua.sha...@am.sony.com wrote: Hi, I'm working on a project which makes use of JavaScriptCore as a scripting engine outside of WebKit. It would be very helpful to us if we could get access to the DOMParser and XMLSerializer classes which are in WebKit's DerivedSources area. However, it seems that those libraries are using JavaScript Core's internal/private API (JSC::ExecState, JSC::Value, etc.) rather than the public interface expected by external users of JavaScript Core. We'd also like to avoid pulling in the internal WebKit headers anyway, as this would complicate our build system (for example, we'd like to be able to do this just using the header files provided by Ubuntu's libwebkit-dev package). I'm fine with writing forward-declaration classes and stub methods for the purpose of letting the C++ linker figure it all out, but JSC::JSValue seems to get in the way of this idea, since the getConstructor() methods on the libraries we want return it by value rather than by reference (and it doesn't appear to be a simple reinterpret_cast like it is for the other public-API classes). Is there some official way that we can get at WebKit's DerivedSources library functionality in a non-WebKit JavaScript Core application, or can anyone think of some tricky-but-relatively-clean way to do it that doesn't involve our app having to see JSC's internal API? Thanks in advance. ___ 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] Accessing WebKit JS binding classes from non-WebKit JavaScript Core applications?
Okay, that's what I was afraid of. For now I think I'll just write bindings against libxml, then. Thanks. Eric Seidel wrote: Various WebKit ports expose different bindings. The JS bindings are only exposed to scripts on pages run inside WebKit. If you have your own separate javascript environment, you would need to set up your own custom bindings for that environment. We don't really provide clean APIs for that, however, there has been talk over the years of taking the bindings/scripts and making it possible for clients of WebKit to generate JSC-API compatible autogenerated bindings wrapping their own implementation objects. You'd still have to write your own implementation objects which talked to the right pieces of WebKit/WebCore however. I think you'll run into a world of pain if you try and just expose guts of WebCore to clients outside of WebCore w/o having gone through the normal WebCore parsing mechanisms and created a Page, Frame, Client objects, etc. Anyway, best of luck and we look forward to seeing your contributions. -eric On Tue, Apr 27, 2010 at 3:56 PM, Josh Shagam joshua.sha...@am.sony.com wrote: Thanks. I apologize for mincing terminology - I'm not particularly versed in how WebKit is put together, where WebKit ends and JavaScriptCore begins, etc., and I've mostly been banging my head against this based on looking at work that some of my coworkers have done. :) I should be more specific that we are in fact linking against WebKit and so we will have the implementations available. We are actually using full WebKit for another part of the system as well, but we'd like to be able to access WebKit's JS bindings from outside of the WebKit view. It looks like bindings/scripts bit will help me get on the right track, in any case. Thanks for the pointer. Eric Seidel wrote: DerivedSources are generated from here: http://trac.webkit.org/browser/trunk/WebCore/DerivedSources.make I think what your'e thinking of as DerivedSources is actually just the javascript bindings, which will be useless to you w/o the actual implementations in WebCore. If for some reason you wanted to write your own custom bindings which use JSC's public API instead of the internal one which WebCore uses, you could make your own generator script: http://trac.webkit.org/browser/trunk/WebCore/bindings/scripts/ You can see examples of those scripts being run in DerivedSources.make or in run-bindings-tests: http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/run-bindings-tests In short, this is not a supported configuration. :) I'm also not really sure it's on topic for this list. Best of luck! -eric On Tue, Apr 27, 2010 at 3:44 PM, Josh Shagam joshua.sha...@am.sony.com wrote: Hi, I'm working on a project which makes use of JavaScriptCore as a scripting engine outside of WebKit. It would be very helpful to us if we could get access to the DOMParser and XMLSerializer classes which are in WebKit's DerivedSources area. However, it seems that those libraries are using JavaScript Core's internal/private API (JSC::ExecState, JSC::Value, etc.) rather than the public interface expected by external users of JavaScript Core. We'd also like to avoid pulling in the internal WebKit headers anyway, as this would complicate our build system (for example, we'd like to be able to do this just using the header files provided by Ubuntu's libwebkit-dev package). I'm fine with writing forward-declaration classes and stub methods for the purpose of letting the C++ linker figure it all out, but JSC::JSValue seems to get in the way of this idea, since the getConstructor() methods on the libraries we want return it by value rather than by reference (and it doesn't appear to be a simple reinterpret_cast like it is for the other public-API classes). Is there some official way that we can get at WebKit's DerivedSources library functionality in a non-WebKit JavaScript Core application, or can anyone think of some tricky-but-relatively-clean way to do it that doesn't involve our app having to see JSC's internal API? Thanks in advance. ___ 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] Windows setjmp/longjmp issue
On Tue, Apr 27, 2010 at 2:33 PM, SCU Rock scur...@gmail.com wrote: In WebCore/platform/image- decoders/jpeg/JPEGImageDecoder.cpp ( https://trac.webkit.org/browser/trunk/WebCore/platform/image-decoders/jpeg/JPEGImageDecoder.cpp) and png/PNGImageDecoder.cpp, setjmp and longjmp are called. This causes this code unportable to Windows environment. At http://msdn.microsoft.com/en-us/library/xe7acxfb%28VS.80%29.aspx, it is mentioned that setjmp and longjmp do not support C++ object semantics. I believe that means that things like stack-allocated objects may not be destroyed correctly (as opposed to when using C++ exceptions, which can make more guarantees about object destruction). At the locations in question, there are no C++ objects in the current stack frame (and the JPEG and PNG decoding libraries are C code). Thus I don't believe there should be any problem here. A key design goal of C++ is making sure that well-formed C programs still operate the same way, and thus it is certainly untrue that any usage of setjmp() and longjmp() within an ostensibly-C++ program will inherently cause crashes. My understanding is that WebKit has been ported to Windows for three years. Can someone educate me on how current Chrome and Safari work on Windows? Why does such a basic problem exist but without being seen? Do they use the above image decoder files? I tried to run a program linked with a prebuilt Windows WebKit library and it crashes at setjmp() when accessing a jpeg file. Can this problem be fixed? I have no idea what prebuilt Windows library you may have used or what kind of crash you may have seen. Chromium uses the above files on Windows without issue (note that we compile with C++ exceptions disabled). Brent Fulgham's Cairo-based Windows port also uses these without problem. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
