QtScript considered dangerous

[Milian Wolff]

On Thursday 24 May 2012 11:28:41 Thomas Friedrichsmeier wrote:
> -- Note: Reposting to follow Dominik's example of CCing kde-core-devel --
> 
> Hi,
> 
> On Wednesday 23 May 2012, Milian Wolff wrote:
> > We have port Kate away from QtScript.
> 
> I'm not sure, whether this is a serious suggestion, or just a way to catch
> attention. In the latter case: it worked. In the former case, I think there
> are some important reasons going against this:
> 
> 1. AFAIR, there are some subtle differences between KJS and QtScript. I'd be
> hard pressed to provide an example, but I know for sure that I have run
> into some, personally. Some code that worked fine in QtScript did not work
> for me in KJS (note: I was using kjsembed via Kross, then).
> 
> 1b. While, certainly, any such incompatibilities could easily be addressed
> inside the Kate code base, keep in mind that a switch of engine could also
> cause trouble for users' custom scripts.
> 
> 1c. Even if the above incompatibilities were a mere figment of my
> imagination, KJS does have it's own set of bugs. These may (or may not) be
> more benign than those of QtScript. They may be easier for us to get fixed,
> but that's because there is no third party to point fingers at, in the
> first place.

I don't know of any issues, but as was said elsewhere: KJS is at least 
actively maintained, while JSC in QtScript is just dead code in my eyes...

> 2. Kate is not the only user of QtScript in the KDE world. Do we want to
> switch all other KDE apps to KJS, too? Will that really be the most
> efficient solution?
> 
> I think, on a theoretical level, we can easily agree that getting this fixed
> inside Qt would be the optimal solution. So is this really totally out-of-
> scope?

You are right of course, fixing QtScript's JSC checkout would be the best way 
to go. I tried looking into it, but JIT code is really not my strength nor was 
it straight forward to find reusable patches. As you said in your other mail, 
the JSC in Mozilla and the one in WebKit e.g. diverge considerably. Esp. the 
latter I've looked at, but it's "64bit hardening" patches all depend on other 
refactorings making the porting far from trivial.

> Well, apparently, the people who should take care of this, don't. That's
> extremely annoying. But also, let's not turn to suboptimal solutions, too
> early, out of frustration. So they are not willing to invest the required
> amount of work, themselves. But would they accept a patch? And how hard
> would it be to produce a patch?

It would be hard to produce the patch but I hope it would be accepted. The big 
question is just whether it's easy to test whether the custom Qt changes where 
kept inplace properly, i.e. that we don't regress these with the update... 
It's really a big hassle, I hoped that the Qt engineers that have done this 
before and thus have experience with that task, could do the work... Sadly 
they don't care about Qt4 anymore and the Digia people probably don't have the 
skills and/or interest in fixing this bug :(

> I don't know. I have neither the skills, nor the right number of bits to be
> of any help with debugging this. But I think this is the very first
> question to think about, before thinking about alternatives: What about the
> proposed solution, i.e. updating JSC(*)? Can you provide an estimate of how
> much work that would mean? If that patch would be too large to be
> acceptable, is it possible to identify and port the fix to this particular
> issue, in the JSC sources?
> 
> Regards
> Thomas
> 
> (*) Just to point out the obvious, though: The bug appears to have surfaced
> considerably later than the last update of JSC. Which doesn't prove
> anything, but softens the evidence pointing to JSC as the (only) cause of
> the bug.

Don't forget that the issue only crops up when the host app uses much memory, 
something that maybe isn't the case so often and thus the bug was not so 
prominent until now?

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120526/dc3d7feb/attachment.sig>
-------------- next part --------------
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel at kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel