QtScript considered dangerous

[Milian Wolff]

On Thursday 24 May 2012 10:59:21 Dominik Haumann wrote:
> Hi Milian,

Hey Dominik, sorry for the long pause. Answers inline below.

> CC: kde-core-devel, as this is really a tough issue...
> 
> there are other applications like Kile that heavily use QtScript for
> scripting as well, so porting away KatePart from QtScript may solve the
> issue for KDevelop, the real problem lies (as you say) within QtScript, not
> Kate. The reason for why we use QtScript are:
> - QtScript is very (!) easy to use
> - QtScript is maintained (at least at that time?)
> - really good documentation
> 
> There are other arguments, why we finally ended up with QtScript:
> - kjs is pretty much undocumented, meaning that it's not immediately clear
>   e.g. how to export custom classes and so on.
> - at the time we dropped kjs, it wasn't clear whether it's going to be
>   maintained and improved (the speed in QtScript was much better). At that
>   time, there were even lots of people shouting "drop khtml" etc...
> 
> Initially, KatePart even used kjs and the code was a lot more complex to get
> the same thing as we have now with QtScript. That alone is a strong
> argument for using QtScript.

Yep exactly these kind of reasons was what I was looking for. Thanks for the 
explanations.

> With regard to Kate, we are about to export our js-API so that other classes
> can use our returned QScriptValues. Once this is the case, we cannot go
> back due to BIC reasons. So this is a tough issue... We can go back to
> using kjs again, of course, but then, I still have lots of questions [1]
> :-)
> 
> What about other solutions: Reduce memory consumption in KDevelop?

I hope you are kidding, right? ;-) I mean sure, I've tried (and am trying and 
going to continue to try) to reduce the memory consumption of KDevelop but 
it's just a big app and using 1-2 GB of memory is imo OK for it, considering 
the amount of work it does internally.

Anyhow, reducing the memory consumption would just make the crash occur less 
often yet it could still crash randomly...

> Another question is: Maybe we'll have similar/other issues with kjs? ;)

Yes that is of course possible though that one is at least actively maintained 
(as was also said in other mails in this thread).

Cheers

> [1] http://kate-editor.org/2012/05/12/rfc-exporting-javascript-api/
> 
> On Wednesday, May 23, 2012 22:08:08 Milian Wolff wrote:
> > Hey all,
> > 
> > I have a sad discussion to start it seems:
> > 
> > We have port Kate away from QtScript.
> > 
> > See also:
> > 
> > https://bugs.kde.org/show_bug.cgi?id=297661
> > https://bugreports.qt-project.org/browse/QTBUG-23871
> > 
> > This is the number one reason for crashes I get recently, and makes
> > KDevelop unusable. Apparently Kate usually doesn't that issue since it
> > doesn't use as much memory as KDevelop (see the Qt bugreport).
> > 
> > The bug report is open since ~4 months without any feedback from any Qt
> > developers. Today I had a chat with a few Nokia Qt developers at LinuxTag
> > and they said they will probably not spent the considerable amount of time
> > in updating the archaic jsc checkout used in QtScript. Apparently, Digia
> > is supposed to handle Qt 4.x issues like these and seriously, they don't
> > really do anything as long as a commercial customer of them requires a bug
> > to be fixed...
> > 
> > Since this issue renders KDevelop unusable (crashes with stack corruption
> > or assertion every few keypresses that issue a run of the indenter script)
> > I really think we should look for alternatives.
> > 
> > So - what are the reasons that Kate uses QtScript instead of KJS? I hope
> > that we can easily port our existing code to KJS without a too high
> > performance impact, something I'll measure of course. But are there other
> > reasons beside performance?
> > 
> > /me who is angry at Digia/Nokia/Qt for not fixing this mess
-- 
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/2e057b32/attachment.sig>