Re: [webkit-dev] Best way to track feature evolution from release-to-release
On Thu, Jan 6, 2011 at 8:57 PM, Ryosuke Niwa ryosuke.n...@gmail.com wrote: On Thu, Jan 6, 2011 at 8:31 PM, Darin Fisher da...@chromium.org wrote: Using svn revision numbers has the downside of not reflecting branches very well. A bigger number may correspond to a recent change to an old branch for instance. So, you cannot do simple if version N checks to test for the availability of features. I think Ojan meant that the version number can be used to learn about bugs such as crashes and incompatibilities that have been fixed but cannot be detected as a feature. Right. Having a shared version number across WebKit builds will never catch every case (e.g. patches pulled into branches, disabled features, etc.), but it is better in general than developers using the individual products' version numbers. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Best way to track feature evolution from release-to-release
On Fri, Jan 7, 2011 at 9:12 AM, Ojan Vafai o...@chromium.org wrote: On Thu, Jan 6, 2011 at 8:57 PM, Ryosuke Niwa ryosuke.n...@gmail.comwrote: On Thu, Jan 6, 2011 at 8:31 PM, Darin Fisher da...@chromium.org wrote: Using svn revision numbers has the downside of not reflecting branches very well. A bigger number may correspond to a recent change to an old branch for instance. So, you cannot do simple if version N checks to test for the availability of features. I think Ojan meant that the version number can be used to learn about bugs such as crashes and incompatibilities that have been fixed but cannot be detected as a feature. Right. Having a shared version number across WebKit builds will never catch every case (e.g. patches pulled into branches, disabled features, etc.), but it is better in general than developers using the individual products' version numbers. Ojan Totally agree. We probably just need some kind of dotted notation to handle branches. The WebKit trunk should just increment N in N.0, and then branches can increment the minor number. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Best way to track feature evolution from release-to-release
On Fri, Jan 7, 2011 at 9:24 AM, Darin Fisher da...@chromium.org wrote: On Fri, Jan 7, 2011 at 9:12 AM, Ojan Vafai o...@chromium.org wrote: Right. Having a shared version number across WebKit builds will never catch every case (e.g. patches pulled into branches, disabled features, etc.), but it is better in general than developers using the individual products' version numbers. Totally agree. We probably just need some kind of dotted notation to handle branches. The WebKit trunk should just increment N in N.0, and then branches can increment the minor number. The branches are not cross-port though, right? We already have individual product numbers in the UA string that meet this need (e.g. the Chrome or Safari version number). Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Best way to track feature evolution from release-to-release
On Fri, Jan 7, 2011 at 9:30 AM, Ojan Vafai o...@chromium.org wrote: On Fri, Jan 7, 2011 at 9:24 AM, Darin Fisher da...@chromium.org wrote: On Fri, Jan 7, 2011 at 9:12 AM, Ojan Vafai o...@chromium.org wrote: Right. Having a shared version number across WebKit builds will never catch every case (e.g. patches pulled into branches, disabled features, etc.), but it is better in general than developers using the individual products' version numbers. Totally agree. We probably just need some kind of dotted notation to handle branches. The WebKit trunk should just increment N in N.0, and then branches can increment the minor number. The branches are not cross-port though, right? We already have individual product numbers in the UA string that meet this need (e.g. the Chrome or Safari version number). Ojan That's fair. I think this is a complicated issue due to the likelihood of features being disabled on a branch. So, any version number corresponding to the branch point alone may not be sufficient to describe the instance of WebKit. Yeah, the individual product numbers may just have to be the solution there :-/ -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScriptCore Binding Problem
On Wed, Jan 5, 2011 at 7:38 PM, Alex Milowski a...@milowski.org wrote:
I've got a new IDL class I'm working of for some experiments in XML
and I've run into an interesting snag. I have a call to a parse
method from Javascript where the string argument seems to be getting
mangled. The IDL for the method looks like:
boolean parse(in DOMString str);
and the call from javascript looks like:
reader.parse(doctitleI am a document/title/doc);
Everything else about this interface implementation works fine.
Unfortunately, for the above method, the string of XML to parse comes
in as empty. It looks to me like things are mangled in some way but
I can't determine why.
Just as an experiment, I set a breakpoint in the Javascript debugger
inside Safari and found another interesting data point. The code in
the test case goes from the source:
window.onload = function() {
var xml = doc/;
reader.parse(xml);
}
to this displayed in the inspector when the breakpoint is hit:
window.onload = function() {
var xml = ;
reader.parse(xml);
}
That's very strange. Any ideas of what to look at here? Could the
JIT compiler for JavascriptCore be dropping/mangling the string
constant somehow?
--
--Alex Milowski
The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered.
Bertrand Russell in a footnote of Principles of Mathematics
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] How can I call a javascript function from the hosting application
My application is hosting a WebView instance to render its GUI using the Windows CE port of Webkit. I need to be able to call some JavaScript functions that are written into the loaded HTML page. For example, I have an Init(backgroundColor) function that needs to be called once the page is loaded. I guess calling a JavaScript function is trivial, but I did not find an answer to my question yet. Can anyone give me pointer on how I can call a JavaScript function from the hosting application? Regards, Fred ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScriptCore Binding Problem
Completely embarrassing ... but it is an XHTML file and so the markup in the string gets parsed unless I escape it ... *sigh* Too many hours wasted in the debugger on this one. :( So, it is a non-issue. Thanks to Evan Martin for pointed that out. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How can I call a javascript function from the hosting application
On Fri, Jan 7, 2011 at 14:35, fredx21 fred...@hotmail.com wrote: My application is hosting a WebView instance to render its GUI using the Windows CE port of Webkit. I need to be able to call some JavaScript functions that are written into the loaded HTML page. For example, I have an Init(backgroundColor) function that needs to be called once the page is loaded. I guess calling a JavaScript function is trivial, but I did not find an answer to my question yet. Can anyone give me pointer on how I can call a JavaScript function from the hosting application? http://doc.qt.nokia.com/4.7-snapshot/qwebframe.html#evaluateJavaScript WebView-page()-mainFrame()-evaluateJavaScript(Init(backgroundColor)); BR, -- Andre Pedralho http://pedralho.blogspot.com/ Regards, Fred ___ 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
