Re: containing plasmoid crashes
On Sun, Jul 26, 2009 at 8:26 PM, Aaron J. Seigoase...@kde.org wrote: On Sunday 26 July 2009, David Baron wrote: Do not the various interperators or VMs need be loaded in memory to service their plasmoids so we need to: * have full ecma script bindings available * promote use of ecma script over other options * use ruby/python only as really needed (e.g access to additional libraries with python/ruby bindings) It seems to me that you are forming conclusions, when I don't think we have sufficient data yet. There are a whole pile of questions that I don't know the answer to. * How much memory and resources (non-shared and shared) does each interpreter/VM take up? * Would we have less crashes with only one scripting language binding is used? * If we find a cause of a crash in one scripting language environment, would it help to fix similar crashes in other scripting language environments? * What is the trade-off between attracting more programmers by having several languages to choose from, and only one language? * Would having too many languages to choose from actually put people off, if none of them have a critical mass of community? * Does ecma script scale? Is it suitable for complex applets as well as simple ones? How does it compare with Ruby/Python? * Should we take into account the fact that if someone programs applets in say Python, then they have as easy way to begin learning about how to write full scale KDE Python apps. * If we have full ecma script bindings for applets do we really want people to write full scale KDE applications in ecma script? * If there are lots of people who know a little browser based JavaScript coding, does it follow that we are likely to have more people wanting to write Javascript applets? Or are KDE beginner programmers perhaps not representative of a random sample of people who know a little programming? -- Richard ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: containing plasmoid crashes
and pardon my ignorance: What is ecma script? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: containing plasmoid crashes
On Mon, Jul 27, 2009 at 12:36 PM, David Barond_ba...@012.net.il wrote: and pardon my ignorance: What is ecma script? Another word for JavaScript or QtScript -- Richard ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: containing plasmoid crashes
On Saturday 25 July 2009 11:40:52 Bogdan Bivolaru wrote: Hello guys, I'm writing to you because I'd like to make a suggestion to make a containment for errors around each plasmoid, so that when one crashes, it doesn't take the whole plasma environment with it. For example, I had a problem with KDE Network Manager plasmoid crashing and taking with it the whole plasma-desktop process before displaying anything. I might add that the networkmanager plasmoid has never been released, it's still in playground and as such *expected* to be unstable. I know that at least Kubuntu ships it, and I've already asked them not to ship it until we are actually confident that it's not totally in flux (which it is right now). I'm CC:ing kubuntu-devel here, to illustrate why I'd rather not see it shipped until further notice, and certainly not as part of the default install. really, the Right Thing To Do is: DO NOT RUN UNSTABLE CODE (unless you want to help developing it ;-)). I wouldn't even get to see the panel containing the offending plasmoid, so the only workaround I could find was to 'bastardize' the plasma config files to remove the plasmoid from the panel. After removing it from the panel plasma works fine. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: containing plasmoid crashes
On Monday 27 July 2009, Richard Dale wrote: It seems to me that you are forming conclusions, when I don't think we have sufficient data yet. it's at least in part due to watching amarok scripting and what they've been through. * How much memory and resources (non-shared and shared) does each interpreter/VM take up? that's a good question. having more than one VM can't be good on that metric, though. * Would we have less crashes with only one scripting language binding is used? not likely, imo. * If we find a cause of a crash in one scripting language environment, would it help to fix similar crashes in other scripting language environments? probably not; most of the crashes in the python scripting efforts seem to be in the python bindings and fixes to them probably don't affect other bindings? * What is the trade-off between attracting more programmers by having several languages to choose from, and only one language? i'm not saying kill the ruby/pythong script engines. there is a difference between availability and preferred status, however. * Would having too many languages to choose from actually put people off, if none of them have a critical mass of community? non-issue; i don't think having too many languages is a person issue but a practical issue of having the right things installed on the target system and overhead associated with multiple VMs running. * Does ecma script scale? Is it suitable for complex applets as well as simple ones? How does it compare with Ruby/Python? looking at the widgets people are making, i don't think the language will be an impediment in any way. the difference is in what other libraries are bound to the target language. this is, in fact, one reason why ruby/python are so annoying to work with in such environments: they end up dragging in more and more dependencies and some scripts will work and others won't depending on the target system. this is exactly what amarok 1 ran into, according to their devs. * Should we take into account the fact that if someone programs applets in say Python, then they have as easy way to begin learning about how to write full scale KDE Python apps. the python engine will always be there. they can use it as a gateway system. this is about what we prefer and encourage people who are primarily writing plasmoids. * If we have full ecma script bindings for applets do we really want people to write full scale KDE applications in ecma script? probably not. i don't think that's relevant, though. * If there are lots of people who know a little browser based JavaScript coding, does it follow that we are likely to have more people wanting to write Javascript applets? we don't know for sure, but the transferability of knowledge is quite obviously there to be taken advantage of. Or are KDE beginner programmers perhaps not representative of a random sample of people who know a little programming? i don't see writing a plasmoid as necessarily the work of a KDE beginner programmer. it may be all the person is ever interested in, it may be something a person who works with KDE already does, etc. and if it is easier to write something for plasma and successfully share it with others, perhaps that will change the demographic of KDE beginner programmer from what it is today. e.g. this could grow our reach rather than tap into the same group we already do. but this is all about something that is completely separate from the primary metric of choosing which language(s) to emphasize: what will make for the best experience in Plasma? that's measured by: * what we can build security around * what we can easily ensure is deployed and available on target systems so people can actually run these things * what will encourage more plugins to be written -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: containing plasmoid crashes
Hello, Well, I haven't really thought about a how-to before writing that mail... I was expecting it to work just as for catching crashes with Dr. Krash. But it turns out that there is a solution on Plasma wishlist: [Plasma] Plasmoids as separate processes So I voted for it and I hope someone will find the time to do it. I guess that also means I should pay more attention to KDE Brainstorm, well... Have fun hacking, Bogdan On Sat, Jul 25, 2009 at 12:54 PM, Aaron J. Seigo ase...@kde.org wrote: On Saturday 25 July 2009, Bogdan Bivolaru wrote: I'm writing to you because I'd like to make a suggestion to make a containment for errors around each plasmoid, so that when one crashes, it doesn't take the whole plasma environment with it. and how do you suggest this is accomplished, exactly? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- The best way to predict the future is to invent it., 1971, Alan Kay: http://www.smalltalk.org/alankay.html ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: containing plasmoid crashes
Oh, well, there is an intense debate on how to accomplish this... http://forum.kde.org/viewtopic.php?f=83t=45255start=30 Oh everyone brings their pet issue to the table: performance issues, ease of development, stability. I hope you plasma hackers will find the middle ground to keep everyone happy. Bogdan On Sun, Jul 26, 2009 at 10:30 AM, Bogdan Bivolaru bogdan.bivol...@gmail.com wrote: Hello, Well, I haven't really thought about a how-to before writing that mail... I was expecting it to work just as for catching crashes with Dr. Krash. But it turns out that there is a solution on Plasma wishlist: [Plasma] Plasmoids as separate processes So I voted for it and I hope someone will find the time to do it. I guess that also means I should pay more attention to KDE Brainstorm, well... Have fun hacking, Bogdan On Sat, Jul 25, 2009 at 12:54 PM, Aaron J. Seigo ase...@kde.org wrote: On Saturday 25 July 2009, Bogdan Bivolaru wrote: I'm writing to you because I'd like to make a suggestion to make a containment for errors around each plasmoid, so that when one crashes, it doesn't take the whole plasma environment with it. and how do you suggest this is accomplished, exactly? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- The best way to predict the future is to invent it., 1971, Alan Kay: http://www.smalltalk.org/alankay.html -- The best way to predict the future is to invent it., 1971, Alan Kay: http://www.smalltalk.org/alankay.html ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: containing plasmoid crashes
On 7/26/09, Bogdan Bivolaru bogdan.bivol...@gmail.com wrote: Oh, well, there is an intense debate on how to accomplish this... http://forum.kde.org/viewtopic.php?f=83t=45255start=30 Oh everyone brings their pet issue to the table: performance issues, ease of development, stability. I hope you plasma hackers will find the middle ..and you lose the single scene, so no more containments, the desktop becomes a bunch of little windows and the pnel is simply not possible to do anymore Cheers, Marco Martin ground to keep everyone happy. Bogdan On Sun, Jul 26, 2009 at 10:30 AM, Bogdan Bivolaru bogdan.bivol...@gmail.com wrote: Hello, Well, I haven't really thought about a how-to before writing that mail... I was expecting it to work just as for catching crashes with Dr. Krash. But it turns out that there is a solution on Plasma wishlist: [Plasma] Plasmoids as separate processes So I voted for it and I hope someone will find the time to do it. I guess that also means I should pay more attention to KDE Brainstorm, well... Have fun hacking, Bogdan On Sat, Jul 25, 2009 at 12:54 PM, Aaron J. Seigo ase...@kde.org wrote: On Saturday 25 July 2009, Bogdan Bivolaru wrote: I'm writing to you because I'd like to make a suggestion to make a containment for errors around each plasmoid, so that when one crashes, it doesn't take the whole plasma environment with it. and how do you suggest this is accomplished, exactly? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- The best way to predict the future is to invent it., 1971, Alan Kay: http://www.smalltalk.org/alankay.html -- The best way to predict the future is to invent it., 1971, Alan Kay: http://www.smalltalk.org/alankay.html ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: containing plasmoid crashes
Wow! Well, sounds like you've got a tough job to do, but I'm sure you'll find a way to solve this issue, as always. May you have a happy hacking and a nice day! Cheers, Bogdan On Sun, Jul 26, 2009 at 11:07 AM, Marco Martin notm...@gmail.com wrote: On 7/26/09, Bogdan Bivolaru bogdan.bivol...@gmail.com wrote: Oh, well, there is an intense debate on how to accomplish this... http://forum.kde.org/viewtopic.php?f=83t=45255start=30 Oh everyone brings their pet issue to the table: performance issues, ease of development, stability. I hope you plasma hackers will find the middle ..and you lose the single scene, so no more containments, the desktop becomes a bunch of little windows and the pnel is simply not possible to do anymore Cheers, Marco Martin ground to keep everyone happy. Bogdan On Sun, Jul 26, 2009 at 10:30 AM, Bogdan Bivolaru bogdan.bivol...@gmail.com wrote: Hello, Well, I haven't really thought about a how-to before writing that mail... I was expecting it to work just as for catching crashes with Dr. Krash. But it turns out that there is a solution on Plasma wishlist: [Plasma] Plasmoids as separate processes So I voted for it and I hope someone will find the time to do it. I guess that also means I should pay more attention to KDE Brainstorm, well... Have fun hacking, Bogdan On Sat, Jul 25, 2009 at 12:54 PM, Aaron J. Seigo ase...@kde.org wrote: On Saturday 25 July 2009, Bogdan Bivolaru wrote: I'm writing to you because I'd like to make a suggestion to make a containment for errors around each plasmoid, so that when one crashes, it doesn't take the whole plasma environment with it. and how do you suggest this is accomplished, exactly? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- The best way to predict the future is to invent it., 1971, Alan Kay: http://www.smalltalk.org/alankay.html -- The best way to predict the future is to invent it., 1971, Alan Kay: http://www.smalltalk.org/alankay.html ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- The best way to predict the future is to invent it., 1971, Alan Kay: http://www.smalltalk.org/alankay.html ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: containing plasmoid crashes
A similar problem has seemingly been solved, by Google. Since google's browser is opensource, one might take a look. Every one of those tabs, plugin processes, etc., is a separate process, shows up on top as such. I have an upload going on now, apparently in a chrome process initiated from a website. No browser is showing at all--closed it. Their approach is still very beta, has some interesting problems, but it works. We would probably want to use dbus (I do not know whether they do). Example of their success: Clicking a link in kmail, for example, will spawn that as a tab in an existing chrome browser if one is running. Caveat--if one died and is still an existing process, one must kill it before chrome will work correctly. Beta. Wow! Well, sounds like you've got a tough job to do, but I'm sure you'll find a way to solve this issue, as always. May you have a happy hacking and a nice day! Cheers, Bogdan On Sun, Jul 26, 2009 at 11:07 AM, Marco Martin notm...@gmail.com wrote: On 7/26/09, Bogdan Bivolaru bogdan.bivol...@gmail.com wrote: Oh, well, there is an intense debate on how to accomplish this... http://forum.kde.org/viewtopic.php?f=83t=45255start=30 Oh everyone brings their pet issue to the table: performance issues, ease of development, stability. I hope you plasma hackers will find the middle ..and you lose the single scene, so no more containments, the desktop becomes a bunch of little windows and the pnel is simply not possible to do anymore Cheers, Marco Martin ground to keep everyone happy. Bogdan On Sun, Jul 26, 2009 at 10:30 AM, Bogdan Bivolaru bogdan.bivol...@gmail.com wrote: Hello, Well, I haven't really thought about a how-to before writing that mail... I was expecting it to work just as for catching crashes with Dr. Krash. But it turns out that there is a solution on Plasma wishlist: [Plasma] Plasmoids as separate processes So I voted for it and I hope someone will find the time to do it. I guess that also means I should pay more attention to KDE Brainstorm, well... Have fun hacking, Bogdan On Sat, Jul 25, 2009 at 12:54 PM, Aaron J. Seigo ase...@kde.org wrote: On Saturday 25 July 2009, Bogdan Bivolaru wrote: I'm writing to you because I'd like to make a suggestion to make a containment for errors around each plasmoid, so that when one crashes, it doesn't take the whole plasma environment with it. and how do you suggest this is accomplished, exactly? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- The best way to predict the future is to invent it., 1971, Alan Kay: http://www.smalltalk.org/alankay.html -- The best way to predict the future is to invent it., 1971, Alan Kay: http://www.smalltalk.org/alankay.html ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: containing plasmoid crashes
Example of their success: Clicking a link in kmail, for example, will spawn that as a tab in an existing chrome browser if one is running. Caveat--if one died and is still an existing process, one must kill it before chrome will work correctly. Beta. that's got nothing to do with separate processes. konqueror's had that feature for *years*. anyways, this problem only exists for c++ plasmoids. solution: don't write in c++. you can't send c++ ones over GHNS either, anyways. we've been over this before. -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: containing plasmoid crashes
On Sunday 26 July 2009 21:20:55 Chani wrote: Example of their success: Clicking a link in kmail, for example, will spawn that as a tab in an existing chrome browser if one is running. Caveat--if one died and is still an existing process, one must kill it before chrome will work correctly. Beta. that's got nothing to do with separate processes. konqueror's had that feature for *years*. Each such click brings up a new konqueror window, unless I am missing something. Konqueror has not worked right for a while now. anyways, this problem only exists for c++ plasmoids. solution: don't write in c++. you can't send c++ ones over GHNS either, anyways. we've been over this before. Do not the various interperators or VMs need be loaded in memory to service their plasmoids, i.e., if I write in in Java, the entire Java business needs be around all the time now. Add one in Python (OK, much more economical), Ruby, etc. and things can get a bit full up. All those C++ers share the same libraries as Plasma and QT itself. What about Mono/.Net :-) ?? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: containing plasmoid crashes
On Sunday 26 July 2009, David Baron wrote: A similar problem has seemingly been solved, by Google. Since google's browser is opensource, one might take a look. chrome solves a completely different problem. it displays a completely _different_ canvas (in this case, an html one) in each tab. we are showing a single canvas with items in it. the semi-equivalent in chrome would be to make each html element in the page it's own process and then have them all paint to the same canvas. it's still only semi-equivalent because, while there is javascript interaction, the html- paint-to-canvas mechanism is a lot less complex than what QGraphicsView offers. now, if you think that it's still a sane idea, go map out on paper all the details including data synchronization and managing painting from multiple process, remembering that the desktop is supposed to be very responsive and take as little cpu as possible. the real solution is to use scripting languages and make sure the c++ plugins are absolutely solid. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: containing plasmoid crashes
On Sunday 26 July 2009, David Baron wrote: Do not the various interperators or VMs need be loaded in memory to service their plasmoids so we need to: * have full ecma script bindings available * promote use of ecma script over other options * use ruby/python only as really needed (e.g access to additional libraries with python/ruby bindings) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: containing plasmoid crashes
On Sunday 26 July 2009, Bogdan Bivolaru wrote: [Plasma] Plasmoids as separate processes this will not be implemented. see my other replies in this thread as to why. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: containing plasmoid crashes
On July 26, 2009 12:10:25 David Baron wrote: On Sunday 26 July 2009 21:20:55 Chani wrote: Example of their success: Clicking a link in kmail, for example, will spawn that as a tab in an existing chrome browser if one is running. Caveat--if one died and is still an existing process, one must kill it before chrome will work correctly. Beta. that's got nothing to do with separate processes. konqueror's had that feature for *years*. Each such click brings up a new konqueror window, unless I am missing something. Konqueror has not worked right for a while now. WorksForMe. check your configuration. believe me, if this broke I would've raised hell until someone fixed it ;) -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: containing plasmoid crashes
On Sunday 26 July 2009, 16:24 Aaron J. Seigo wrote: the real solution is to use scripting languages and make sure the c++ plugins are absolutely solid. +1 here. It's the sanest (does this word exist in english :) ?) way to do this stuff. Cheers :) -- Artur Duque de Souza openBossa Research Labs INdT - Instituto Nokia de Tecnologia -- Blog: http://blog.morpheuz.cc PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net -- signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: containing plasmoid crashes
On Saturday 25 July 2009, Bogdan Bivolaru wrote: I'm writing to you because I'd like to make a suggestion to make a containment for errors around each plasmoid, so that when one crashes, it doesn't take the whole plasma environment with it. and how do you suggest this is accomplished, exactly? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
