Re: [webkit-dev] XPath Issues?
[...] (I wrote the XPath, XQuery and XSL-T code and mentored the Schema code. However, I'm no longer employed by Nokia.) That's good to know! Have the compliance tests for XSLT 2.0 and XQuery been run? Yes, the details are at: http://doc.qt.nokia.com/4.7/xmlprocessing.html#features-and-conformance -- Frans Englich ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
On Nov 10, 2010, at 11:29 , Maciej Stachowiak wrote: The first thing we should figure out is whether XSLT 2.0 is something we even want to implement. If it's not backwards compatible with XSLT 1.0 and other browsers are not planning on implementing it, then it's a significant risk to move to XSLT 2.0. We'd likely break backwards compatibility with Web content, and end up long-term incompatible with other browsers. That's not very well aligned with the goals of the project. Breaking backwards compatibility is generally considered unacceptable, unless we can convincingly show it won't affect real-world content. If, in addition, XSLT 2.0 requires a major engineering effort and/or a large external dependency, then this would not be a cheap experiment. Now, we could add it under a new API, but then we'd be stuck carrying around two versions of XSLT forever, and Web content might not be able to reliably use the new version in any case. What we'd normally do in a situation like this is check with other implementors whether they are prepared to implement the new technology. I would recommend starting there, before we talk implementation strategy. It could be that everyone is sitting on the fence waiting for someone to take initiative(who brings technology forward?). In that case it could be good to look one step further back and see if there's user interest in the technology, as opposed to if any implementor has decided to please that demand, which needs to be followed. One could look at if significant things could be achieved with the technology, and then potentially Webkit could take the lead in this area. Although the technology is huge, it's good to know that it's stable(it's no html situation), the specifications are clean, and the backward/forward compatibility modes function well. -- Frans Englich ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] wincairo buildbot failing, cannot install WebKitSupportLibrary, errors in JavaScriptCore[Generated]
On 11/16/2010 6:42 AM, Thomas Brodt wrote: The buildbot for the wincairo port is running again, thanks to whoever did repair it (Brent?). But the build fails again, as before when it went offline. There are errors installing the new WebKitSupportLibrary: cp: cannot create regular file `D:/Projects/BuildSlave/win-cairo-debug/build/WebKitLibraries/win/Software License Agreement for WebKit Support Libraries.rtf': No such file or directory and some file name concatenation seems to go wrong: in JavaScriptCoreGenerated 1 xcopy /y/d/e/i ..\..\..\WebKitLibraries\win\tools D:/Projects/BuildSlave/win-cairo-debug/build/WebKitLibraries/win\tools 1Invalid number of parameters and later on in JavaScriptCore 2cat: D:/Projects/BuildSlave/win-cairo-debug/build/WebKitLibraries/win/tools/scripts/VERSION: No such file or directory 2cat: D:/Projects/BuildSlave/win-cairo-debug/build/WebKitLibraries/win/tools/scripts/COPYRIGHT-END-YEAR: No such file or directory 2Compiling resources... 2.\JavaScriptCore.rc(17) : error RC2127 : version WORDs separated by commas expected 2.\JavaScriptCore.rc(18) : error RC2127 : version WORDs separated by commas expected 2.\JavaScriptCore.rc(37) : error RC2104 : undefined keyword or key name: __COPYRIGHT_YEAR_END_TEXT__ As I am not familiar with that, can anyone please look at it? All of these problems seem to have the same cause: the value of the WEBKITLIBRARIESDIR environment variable is quoted, but should not be. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKit Cairo port questions
Hi,
I am trying to build the WebKit Cairo port but running into some issues. I
fixed my local compiler errors(mostly by tweaking code to avoid the errors) but
now running into a crash that looks like something inside CFLite.dll.
I built as per instructions here -
http://trac.webkit.org/wiki/BuildingCairoOnWindows . I downloaded the support
packages from the pre bundled copies on that page. I built the debug_cairo
config. After that, I ran the WinLauncher which complained about the missing
CFLite.dll/CFLite_Debug.dll/libcurl.dll. I copied them from the pre built
package to the \WebKit\WebKitBuild\bin directory. Then, I get a crash that
looks as follows(at the end of the email).
Am I doing something wrong here? Is there a last known good version of WinCairo
port?
For the compile issues, I had to (I am sure the correct solution would need to
take into account the WinCairo/Curl stuff but following worked for quick
compilation)
1) Modify the PlatformCertificateInfo constructor to not create
CFURLResponseRef object.
2) Modify CFURLRequestRef STDMETHODCALLTYPE WebMutableURLRequest::cfRequest()
to return 0.
Crash -
CFLite.dll!00471789()
[Frames below may be incorrect and/or missing, no symbols loaded for
CFLite.dll]
WebKit_debug.dll!WTF::RefPtrWebCore::ResourceRawHeaders::operator=(const
WTF::RefPtrWebCore::ResourceRawHeaders o={...}) Line 113 + 0x9 bytes
C++
WebKit_debug.dll!WebCore::ResourceResponseBase::operator=(const
WebCore::ResourceResponseBase __that={...}) + 0x13c bytesC++
WebKit_debug.dll!WTF::RetainPtr_CFURLResponse
*::~RetainPtr_CFURLResponse *() Line 69 + 0x32 bytes C++
cc00()
WebKit_debug.dll!WebCore::ResourceResponse::~ResourceResponse() + 0x1c
bytes C++
WebKit_debug.dll!WebCore::FrameLoader::init() Line 236 + 0x6b bytes
C++
WebKit_debug.dll!WebCore::Frame::init() Line 254 C++
WebKit_debug.dll!WebView::initWithFrame(tagRECT frame={...}, wchar_t *
frameName=0x, wchar_t * groupName=0x) Line 2622 C++
WinLauncher_debug.exe!wWinMain(HINSTANCE__ * hInstance=0x0040,
HINSTANCE__ * hPrevInstance=0x, wchar_t * lpCmdLine=0x00020b7a, int
nCmdShow=1) Line 207 + 0x36 bytes C++
WinLauncher_debug.exe!__tmainCRTStartup() Line 589 + 0x1c bytes
C
kernel32.dll!7c817077()
icuin40.dll!0066006f()
icuin40.dll!00620069()
icuin40.dll!0066006f()
JavaScriptCore_debug.dll!0075006c()
icuin40.dll!0066006f()
JavaScriptCore_debug.dll!0075006c()
JavaScriptCore_debug.dll!JSC::ProgramExecutable::compileInternal(JSC::ExecState
* exec=0xb800, JSC::ScopeChainNode * scopeChainNode=0x) Line 151 +
0xe bytes C++
0fb9c47d()
Thanks.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Hunspell based spellchecker
Hi WebKit folks, I'm thinking about porting Hunspell-based spellchecking code from Chromium to WebKit/WebCore. Although it's unclear whether the porting is feasible, I'd like to hear how much interest is there from other ports before starting actual work. Because the main goal is to make spellcheck available for more ports, It would be just a waste if there is no demand. For example, I heard that GTK+ has GtkSpell, which is based on Enchant. Because our code is based on Hunspell, GtkSpell based integration is out of scope of this proposal... I have no idea about Qt, EFL, etc. BTW, here is an under-half-baked-rough plan: - Extract spellcheck related methods on EditorClient, to interface (or abstract class) named, say, platform/text/TextChecker. - with keeping existing method, for compatibility - Add a getter like TextChecker* textChecker() = 0; to EditorClient. - Implement TextCheckerHunspell, a subclass of TextCheckerHunspell - TextCheckerHunspellChromium and some other variants will also be added, to make Chromium specific hooks. - (optional) Move Mac's spellchecker implementation from WebCoreSupport/WebEditorClient to platform/text/TextCheckerCocoa, another subclass of TextChecker. - (optional) Remove legacy methods on EditorClient This approach would make spellchecker pluggable, so WebKit can choose preferable spellchecker at runtime with this. (For example, Chromium port wants to use both Hunspell and system spellchecker. GTK port might want use Enchant and Hunspell.) Is this beneficial for your port? Are there other design possibilities? Any feedback is welcome. -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] OSX build break after system update
This is preventing me from building. Is there a solution that doesn't require signing up for an Apple ID? On Fri, Oct 29, 2010 at 3:17 AM, Tony Gentilcore to...@chromium.org wrote: On Wed, Oct 27, 2010 at 10:11 PM, Eric Seidel e...@webkit.org wrote: Can we just include the headers in WebKit? Or find some way to auto-download them? +1 This seems silly. Or certainly requiring an update to http://webkit.org/building/tools.html. In the meantime, there is: https://bugs.webkit.org/show_bug.cgi?id=48423 -eric On Thu, Oct 21, 2010 at 3:56 PM, Tony Gentilcore to...@chromium.org wrote: Quick PSA: if you install the Java for Mac OS X 10.6 Update 3 system update you may start getting build errors like: error: JavaVM/jni.h: No such file or directory The solution is to install Java for Mac OS X 10.6 Update 3 Developer Package from http://connect.apple.com Downloads Java [1]. Thanks andersca for the solution! -Tony [1] This link might work: http://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wo/5.1.17.2.1.3.3.1.0.1.1.0.3.8.3.3.1 ___ 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] Hunspell based spellchecker
Hi Hajime, On Nov 16, 2010, at 8:52 PM, Hajime Morita wrote: Hi WebKit folks, I'm thinking about porting Hunspell-based spellchecking code from Chromium to WebKit/WebCore. Although it's unclear whether the porting is feasible, I'd like to hear how much interest is there from other ports before starting actual work. Because the main goal is to make spellcheck available for more ports, It would be just a waste if there is no demand. For example, I heard that GTK+ has GtkSpell, which is based on Enchant. Because our code is based on Hunspell, GtkSpell based integration is out of scope of this proposal... I have no idea about Qt, EFL, etc. BTW, here is an under-half-baked-rough plan: - Extract spellcheck related methods on EditorClient, to interface (or abstract class) named, say, platform/text/TextChecker. - with keeping existing method, for compatibility - Add a getter like TextChecker* textChecker() = 0; to EditorClient. - Implement TextCheckerHunspell, a subclass of TextCheckerHunspell - TextCheckerHunspellChromium and some other variants will also be added, to make Chromium specific hooks. - (optional) Move Mac's spellchecker implementation from WebCoreSupport/WebEditorClient to platform/text/TextCheckerCocoa, another subclass of TextChecker. - (optional) Remove legacy methods on EditorClient This approach would make spellchecker pluggable, so WebKit can choose preferable spellchecker at runtime with this. (For example, Chromium port wants to use both Hunspell and system spellchecker. GTK port might want use Enchant and Hunspell.) Is this beneficial for your port? Are there other design possibilities? Any feedback is welcome. The wx port is very interested. :) I think this design would do everything that our port needs. We'd probably use the native spellchecker on Mac, and Hunspell on other platforms for now. Thanks, Kevin -- morrita ___ 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] OSX build break after system update
Stubbing out the headers in an easy way. I've still not updated my build machine due to this. But it's generally hard to build w/o signing up for an apple id since the latest XCode generally requires one. -eric On Tue, Nov 16, 2010 at 9:10 PM, Luke Macpherson macpher...@chromium.orgwrote: This is preventing me from building. Is there a solution that doesn't require signing up for an Apple ID? On Fri, Oct 29, 2010 at 3:17 AM, Tony Gentilcore to...@chromium.org wrote: On Wed, Oct 27, 2010 at 10:11 PM, Eric Seidel e...@webkit.org wrote: Can we just include the headers in WebKit? Or find some way to auto-download them? +1 This seems silly. Or certainly requiring an update to http://webkit.org/building/tools.html. In the meantime, there is: https://bugs.webkit.org/show_bug.cgi?id=48423 -eric On Thu, Oct 21, 2010 at 3:56 PM, Tony Gentilcore to...@chromium.org wrote: Quick PSA: if you install the Java for Mac OS X 10.6 Update 3 system update you may start getting build errors like: error: JavaVM/jni.h: No such file or directory The solution is to install Java for Mac OS X 10.6 Update 3 Developer Package from http://connect.apple.com Downloads Java [1]. Thanks andersca for the solution! -Tony [1] This link might work: http://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wo/5.1.17.2.1.3.3.1.0.1.1.0.3.8.3.3.1 ___ 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
