[cross-project-issues-dev] XWT participation in Mars
XWT will be participating in the Mars Simultaneous Release. Offset +1,- Papyrus has planned to depend on XWT. XWT 1.1.0 would be released with Eclipse Mars, not part of, the same way that XWT 1.1.0 was released simultaneously with Mars. We plan to contribute version 1.1.0 [1]. [1] https://projects.eclipse.org/projects/technology.xwt/releases/1.1.0/plan; Best regards Yves YANG Soyatec: http://www.soyatec.com Tel: +33 6 20 74 39 45 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] XWT participation in Mars
Sorry, a little typo: Offset +1,- Papyrus has planned to depend on XWT. XWT 1.1.0 would be released with Eclipse Mars, not part of, the same way that XWT 1.1.0 was released simultaneously with Luna. Best regards Yves YANG Soyatec: http://www.soyatec.com http://www.soyatec.com Tel: +33 6 20 74 39 45 From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Yves YANG Sent: 11 December 2014 17:06 To: 'Cross project issues' Subject: [cross-project-issues-dev] XWT participation in Mars XWT will be participating in the Mars Simultaneous Release. Offset +1,- Papyrus has planned to depend on XWT. XWT 1.1.0 would be released with Eclipse Mars, not part of, the same way that XWT 1.1.0 was released simultaneously with Mars. We plan to contribute version 1.1.0 [1]. [1] https://projects.eclipse.org/projects/technology.xwt/releases/1.1.0/plan; Best regards Yves YANG Soyatec: http://www.soyatec.com Tel: +33 6 20 74 39 45 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] How about now? Are you ready for M4 yet?
The list of dropped projects has decreased from 21 to 12 -- that's good -- and seems to me a few of them showing up there have just now (or in past few days) declared their intent. See list at http://projects.eclipse.org/releases/mars But ... data tools? EPP? Market Place Client? who is in charge of those projects? :) What are their plans? :) Given that Mars M4 +0 is tomorrow with all of M4 done in a week, I'd appreciate getting the lists up to date. (Wayne :) = = = = And, I still see disabled features or repositories in aggregation files: mft.b3aggrcon - org.eclipse.simrel.build (2 matches) mylyn-docs-intent.b3aggrcon - org.eclipse.simrel.build soa-bpmn2-modeler.b3aggrcon - org.eclipse.simrel.build I won't name names, but know one of those projects has tried to enable at the last minute twice before, with no success ... so hope someone has committed some time to work on it! = = = = The real motivation for this note, is that the Platform has put their M4 candidate into staging, and I was browsing the repo reports to make sure we were ok, and I noticed a lot of variation in the non-unique versions report. Now, I realize some of those are intentional, and some may be fixed automatically as people create their M4 deliverables ... but, thought it was worth reminding project leads and release engineers to take a look and make sure you are up to date where you can be. Otherwise, you may end up testing one thing, that will not be what makes it into the EPP packages, or similar. For some of the more obvious cases, we in the platform have moved up to Jetty 9.2.5 .. and I see at least 3 if not 4 versions used in the common repo. Similar for httpcomponents. And, I'm sure many others. Be sure to use the latest Platform and Orbit repo in producing and testing your M4 builds. And, if questions on what those are, please ask. Thanks everyone ... I am just trying to be helpful (even if I sound bossy or scolding :) ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Observation: Frequent UI freezes when working with files
The IResource/IWorkspace API is backed by a completely in-memory skeleton
of your file system structure. So any time you can query the resource
model instead of the file system, you will see orders of magnitude
performance improvement over direct java.io.File access. The IResource API
(and EFS) encourage a batch-style interaction for the rare thing that is
not in memory. For example IResource#getResourceAttributes or
IFileStore#fetchInfo returns a struct of all the attributes in a single
native call, which is vastly more efficient than doing many calls such as
if (file.exists() file.isFile() file.canRead()) {... }.
For the IResource API and much of the rest of the platform API, the best
indicator is whether there is an IProgressMonitor in the API method. If
the method takes a progress monitor, you probably don't want to call it
from the UI thread. If there is no progress monitor, then for the most
part you are ok. There are a few embarrassing exceptions to this (e.g.,,
Job#join), but it's a useful rule of thumb.
John
From: Lars Vogel lars.vo...@gmail.com
To: Cross project issues cross-project-issues-dev@eclipse.org
Date: 12/11/2014 01:38 PM
Subject:Re: [cross-project-issues-dev] Observation: Frequent UI
freezes when working with files
Sent by:cross-project-issues-dev-boun...@eclipse.org
I would guess that java.nio.file.Files.exists() [1] improves this access
performance. Do you see these freezes cause
by org.eclipse.core.resources.IResources or by directly using the Java
File API?
[1]
http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#exists(java.nio.file.Path,%20java.nio.file.LinkOption...)
)
2014-12-10 14:53 GMT+01:00 Marcel Bruch marcel.br...@codetrails.com:
Hi,
I just want to share an insight I got from reviewing several ui freezes.
One common cause for UI freezes are operations that touch the filesystem.
For instance, File.isFile, File.lastModified, or
WinNTFileSystem.getBooleanAttributes seem to be very expensive. From what
I read on the internet it seems that some of these methods (e.g.
getAttributes) may even take up to several seconds to return on windows
systems.
This has been discussed elsewhere in the internet [1] and seems to be a
long-standing issue in Java.
With this mail I’d like to make you aware of this (in case you did not
know this before) and would like to encourage you to actually not execute
file operations in the ui thread. We may also consider doing some kind of
caching but such a discussion would by far be over my knowledge, and thus,
should be left to discuss with the platform team.
For now, I think we would benefit very much if every project that accesses
files/resources would review their code and think about refactoring some
part of the FileSystem work (even if it’s only checking a file’s
attributes) into background processes.
Best,
Marcel
[1]
http://stackoverflow.com/questions/20546676/webstart-winntfilesystem-getbooleanattributes-performance
--
Codetrails GmbH
The knowledge transfer company
Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-179-131-7721
http://www.codetrails.com/
Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Projects missing from Mars
Greetings folks. I believe that I'm caught up with the opt-in. The following projects are on the dropped list: * Intent * Target Management * Data Tools Platform * Java Workflow Tooling * Marketplace Client * Koneki * Target Communication Framework Both Intent and Target Management have informed the community that they've dropped out (though there is still some ongoing discussion regarding TM). The rest have not yet created a release record. I'm expecting that least two of them (Data Tools and Marketplace Client) really do want to participate. I'll give them all a kick. Wayne -- Wayne Beaton @waynebeaton The Eclipse Foundation EclipseCon 2015 http://www.eclipsecon.org/na2015 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] How about now? Are you ready for M4 yet?
Yeah, yeah...no need to name names ;) I'm pedaling as fast as I can - hopefully the project that shall remain unnamed, builds correctly now. - Original Message - The list of dropped projects has decreased from 21 to 12 -- that's good -- and seems to me a few of them showing up there have just now (or in past few days) declared their intent. See list at http://projects.eclipse.org/releases/mars But ... data tools? EPP? Market Place Client? who is in charge of those projects? :) What are their plans? :) Given that Mars M4 +0 is tomorrow with all of M4 done in a week, I'd appreciate getting the lists up to date. (Wayne :) = = = = And, I still see disabled features or repositories in aggregation files: mft.b3aggrcon - org.eclipse.simrel.build (2 matches) mylyn-docs-intent.b3aggrcon - org.eclipse.simrel.build soa-bpmn2-modeler.b3aggrcon - org.eclipse.simrel.build I won't name names, but know one of those projects has tried to enable at the last minute twice before, with no success ... so hope someone has committed some time to work on it! = = = = The real motivation for this note, is that the Platform has put their M4 candidate into staging, and I was browsing the repo reports to make sure we were ok, and I noticed a lot of variation in the non-unique versions report . Now, I realize some of those are intentional, and some may be fixed automatically as people create their M4 deliverables ... but, thought it was worth reminding project leads and release engineers to take a look and make sure you are up to date where you can be. Otherwise, you may end up testing one thing, that will not be what makes it into the EPP packages, or similar. For some of the more obvious cases, we in the platform have moved up to Jetty 9.2.5 .. and I see at least 3 if not 4 versions used in the common repo. Similar for httpcomponents. And, I'm sure many others. Be sure to use the latest Platform and Orbit repo in producing and testing your M4 builds. And, if questions on what those are, please ask. Thanks everyone ... I am just trying to be helpful (even if I sound bossy or scolding :) ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Projects missing from Mars
I'm working with Greg Watson and the TM, PTP, and CDT teams to come up with a new target management system based on org.eclipse.remote. All signs point to that being available for Mars. Coding is underway but I'm just not ready to commit at this time. Let's see what January brings. Doug Sent from my BlackBerry 10 smartphone on the Rogers network. From: Wayne Beaton Sent: Thursday, December 11, 2014 2:29 PM To: Cross project issues Reply To: Cross project issues Subject: [cross-project-issues-dev] Projects missing from Mars Greetings folks. I believe that I'm caught up with the opt-in. The following projects are on the dropped list: * Intent * Target Management * Data Tools Platform * Java Workflow Tooling * Marketplace Client * Koneki * Target Communication Framework Both Intent and Target Management have informed the community that they've dropped out (though there is still some ongoing discussion regarding TM). The rest have not yet created a release record. I'm expecting that least two of them (Data Tools and Marketplace Client) really do want to participate. I'll give them all a kick. Wayne -- Wayne Beaton @waynebeaton The Eclipse Foundation [EclipseCon2015]http://www.eclipsecon.org/na2015 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Projects missing from Mars
I’m fine with waiting until Jan to see if we have enough momentum. I’d be happy to see TM go forward with o.e.remote, the launch bar, and TM/TCF Terminal. Until we have someone who is willing to sign up to support and test RSE, though, I think it’s inclusion for Mars is problematic. If someone does sign up for this, I have no problem with RSE going in as well. Greg On Dec 11, 2014, at 2:49 PM, Doug Schaefer dschae...@qnx.com wrote: I'm working with Greg Watson and the TM, PTP, and CDT teams to come up with a new target management system based on org.eclipse.remote. All signs point to that being available for Mars. Coding is underway but I'm just not ready to commit at this time. Let's see what January brings. Doug Sent from my BlackBerry 10 smartphone on the Rogers network. From: Wayne Beaton Sent: Thursday, December 11, 2014 2:29 PM To: Cross project issues Reply To: Cross project issues Subject: [cross-project-issues-dev] Projects missing from Mars Greetings folks. I believe that I'm caught up with the opt-in. The following projects are on the dropped list: Intent Target Management Data Tools Platform Java Workflow Tooling Marketplace Client Koneki Target Communication Framework Both Intent and Target Management have informed the community that they've dropped out (though there is still some ongoing discussion regarding TM). The rest have not yet created a release record. I'm expecting that least two of them (Data Tools and Marketplace Client) really do want to participate. I'll give them all a kick. Wayne -- Wayne Beaton @waynebeaton The Eclipse Foundation 728X90.jpg http://www.eclipsecon.org/na2015___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Projects missing from Mars
BTW, I am going to take another look at the TM Terminal. Dropping should be considered on hold at the moment. It might have a place with our o.e.remote strategy and has some UX features that are actually better than the TCF Terminal, like multiple views. Again no commitments but I should have a good understanding of where we need this to go by end of Jan. BTW2, my biggest problem is that I’m releasing the LaunchBar in Luna SR-2 with CDT 8.6 and it has dependencies on all this stuff. So I’m walking a bit of a tight rope on this at the moment. Doug. From: Oberhuber, Martin martin.oberhu...@windriver.commailto:martin.oberhu...@windriver.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Thursday, December 11, 2014 at 2:55 PM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Projects missing from Mars Hi Wayne, all – Target Communication Framework (TCF) intends to participate in Mars with an 1.3 release (or probably 1.4 in case we end up releasing 1.3 sooner – at any rate it’ll be backward compatible). Key things we’re working on include - Improve the TCF Terminals View and have it picked up as the default terminal by EPP packages (instead of TM Terminal which drops from Mars) - Symbol resolver improvements for C++11 and ADA Debugging - Improve documentation for new adopters and extenders of TCF Our release record is here: https://projects.eclipse.org/projects/tools.cdt.tcf/releases/1.3.0 Our offset will be +2 (since we depend on CDT) And I couldn’t figure out where to “flip the flag” on the PMI to show Mars participation, so please let me know if anything is still missing. Thanks, Martin -- Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River direct +43.662.457915.85 fax +43.662.457915.6 From: cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Wayne Beaton Sent: Thursday, December 11, 2014 8:29 PM To: Cross project issues Subject: [cross-project-issues-dev] Projects missing from Mars Greetings folks. I believe that I'm caught up with the opt-in. The following projects are on the dropped list: · Intent · Target Management · Data Tools Platform · Java Workflow Tooling · Marketplace Client · Koneki · Target Communication Framework Both Intent and Target Management have informed the community that they've dropped out (though there is still some ongoing discussion regarding TM). The rest have not yet created a release record. I'm expecting that least two of them (Data Tools and Marketplace Client) really do want to participate. I'll give them all a kick. Wayne -- Wayne Beaton @waynebeaton The Eclipse Foundation [EclipseCon2015]http://www.eclipsecon.org/na2015 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Projects missing from Mars
Hi Wayne, all – Target Communication Framework (TCF) intends to participate in Mars with an 1.3 release (or probably 1.4 in case we end up releasing 1.3 sooner – at any rate it’ll be backward compatible). Key things we’re working on include - Improve the TCF Terminals View and have it picked up as the default terminal by EPP packages (instead of TM Terminal which drops from Mars) - Symbol resolver improvements for C++11 and ADA Debugging - Improve documentation for new adopters and extenders of TCF Our release record is here: https://projects.eclipse.org/projects/tools.cdt.tcf/releases/1.3.0 Our offset will be +2 (since we depend on CDT) And I couldn’t figure out where to “flip the flag” on the PMI to show Mars participation, so please let me know if anything is still missing. Thanks, Martin -- Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River direct +43.662.457915.85 fax +43.662.457915.6 From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Wayne Beaton Sent: Thursday, December 11, 2014 8:29 PM To: Cross project issues Subject: [cross-project-issues-dev] Projects missing from Mars Greetings folks. I believe that I'm caught up with the opt-in. The following projects are on the dropped list: · Intent · Target Management · Data Tools Platform · Java Workflow Tooling · Marketplace Client · Koneki · Target Communication Framework Both Intent and Target Management have informed the community that they've dropped out (though there is still some ongoing discussion regarding TM). The rest have not yet created a release record. I'm expecting that least two of them (Data Tools and Marketplace Client) really do want to participate. I'll give them all a kick. Wayne -- Wayne Beaton @waynebeaton The Eclipse Foundation [EclipseCon2015]http://www.eclipsecon.org/na2015 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Observation: Frequent UI freezes when working with files
Hi,
The most significant UI bloopers of the sort that Marcel mentioned I have seen
in dialogs which validate input fields to actually be a file on every keystroke.
This really hurts if the path you’re trying to enter is a Windows UNC path
(\\myserver\myshare\path\to\file.cfile:///\\myserver\myshare\path\to\file.c)
and you make the beginner’s mistake of just starting to type … trying to
validate \\mfile:///\\m and then \\myfile:///\\my and then
\\mysfile:///\\mys will cost an average time of 2-5 seconds per keystroke
which is really painful. The workaround is typing your path in an external
editor and then “pasting” in one shot, or typing a relative path first (which
is obviously no file) and then inserting the \\ at the beginning as your last
action.
I would love to see some sort of common infrastructure, which can be applied on
arbitrary folders (not just IResource) and would return answers like isFile()
asynchronously via callback in order to validate or invalidate dialogs … of
course any new keystroke would need to cancel any pending asynchronous
request(s) in order to just validate the new request.
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of John Arthorne
Sent: Thursday, December 11, 2014 7:54 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Observation: Frequent UI freezes when
working with files
The IResource/IWorkspace API is backed by a completely in-memory skeleton of
your file system structure. So any time you can query the resource model
instead of the file system, you will see orders of magnitude performance
improvement over direct java.io.File access. The IResource API (and EFS)
encourage a batch-style interaction for the rare thing that is not in memory.
For example IResource#getResourceAttributes or IFileStore#fetchInfo returns a
struct of all the attributes in a single native call, which is vastly more
efficient than doing many calls such as if (file.exists() file.isFile()
file.canRead()) {... }.
For the IResource API and much of the rest of the platform API, the best
indicator is whether there is an IProgressMonitor in the API method. If the
method takes a progress monitor, you probably don't want to call it from the UI
thread. If there is no progress monitor, then for the most part you are ok.
There are a few embarrassing exceptions to this (e.g.,, Job#join), but it's a
useful rule of thumb.
John
From:Lars Vogel lars.vo...@gmail.commailto:lars.vo...@gmail.com
To:Cross project issues
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Date:12/11/2014 01:38 PM
Subject:Re: [cross-project-issues-dev] Observation: Frequent UI freezes
when working with files
Sent by:
cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org
I would guess that java.nio.file.Files.exists() [1] improves this access
performance. Do you see these freezes cause by
org.eclipse.core.resources.IResources or by directly using the Java File API?
[1]
http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#exists(java.nio.file.Path,%20java.nio.file.LinkOption...))
2014-12-10 14:53 GMT+01:00 Marcel Bruch
marcel.br...@codetrails.commailto:marcel.br...@codetrails.com:
Hi,
I just want to share an insight I got from reviewing several ui freezes. One
common cause for UI freezes are operations that touch the filesystem. For
instance, File.isFile, File.lastModified, or
WinNTFileSystem.getBooleanAttributes seem to be very expensive. From what I
read on the internet it seems that some of these methods (e.g. getAttributes)
may even take up to several seconds to return on windows systems.
This has been discussed elsewhere in the internet [1] and seems to be a
long-standing issue in Java.
With this mail I’d like to make you aware of this (in case you did not know
this before) and would like to encourage you to actually not execute file
operations in the ui thread. We may also consider doing some kind of caching
but such a discussion would by far be over my knowledge, and thus, should be
left to discuss with the platform team.
For now, I think we would benefit very much if every project that accesses
files/resources would review their code and think about refactoring some part
of the FileSystem work (even if it’s only checking a file’s attributes) into
background processes.
Best,
Marcel
[1]
http://stackoverflow.com/questions/20546676/webstart-winntfilesystem-getbooleanattributes-performance
--
Codetrails GmbH
The knowledge transfer company
Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092tel:%2B49-6151-276-7092
Mobile: +49-179-131-7721tel:%2B49-179-131-7721
Re: [cross-project-issues-dev] Projects missing from Mars
Doug, As a committer on TM and a project lead on TCF I am violently opposed against keeping the TM terminal alive. If you still believe that TCF terminal does not support multiple views, you are 1.5 years or more late with your assessment. As of today, the TCF Terminals view is at 100% feature parity compared to TM Terminal, and offers MUCH more (like drag-and-drop rearrangement of its multiple views for example, local terminal support, proper detection of target encoding and more). I've documented the feature parity on a bugzilla bug long ago if you want details (just don't have time digging that out now). Please, don't make announcements like this without talking to the committers on the projects that you are talking about. Thanks, Martin -- Martin Oberhuber, SMTS / Product Owner - Development Tools, Wind River direct +43.662.457915.85 fax +43.662.457915.6 From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Doug Schaefer Sent: Thursday, December 11, 2014 9:03 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Projects missing from Mars BTW, I am going to take another look at the TM Terminal. Dropping should be considered on hold at the moment. It might have a place with our o.e.remote strategy and has some UX features that are actually better than the TCF Terminal, like multiple views. Again no commitments but I should have a good understanding of where we need this to go by end of Jan. BTW2, my biggest problem is that I'm releasing the LaunchBar in Luna SR-2 with CDT 8.6 and it has dependencies on all this stuff. So I'm walking a bit of a tight rope on this at the moment. Doug. From: Oberhuber, Martin martin.oberhu...@windriver.commailto:martin.oberhu...@windriver.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Thursday, December 11, 2014 at 2:55 PM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Projects missing from Mars Hi Wayne, all - Target Communication Framework (TCF) intends to participate in Mars with an 1.3 release (or probably 1.4 in case we end up releasing 1.3 sooner - at any rate it'll be backward compatible). Key things we're working on include - Improve the TCF Terminals View and have it picked up as the default terminal by EPP packages (instead of TM Terminal which drops from Mars) - Symbol resolver improvements for C++11 and ADA Debugging - Improve documentation for new adopters and extenders of TCF Our release record is here: https://projects.eclipse.org/projects/tools.cdt.tcf/releases/1.3.0 Our offset will be +2 (since we depend on CDT) And I couldn't figure out where to flip the flag on the PMI to show Mars participation, so please let me know if anything is still missing. Thanks, Martin -- Martin Oberhuber, SMTS / Product Owner - Development Tools, Wind River direct +43.662.457915.85 fax +43.662.457915.6 From: cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Wayne Beaton Sent: Thursday, December 11, 2014 8:29 PM To: Cross project issues Subject: [cross-project-issues-dev] Projects missing from Mars Greetings folks. I believe that I'm caught up with the opt-in. The following projects are on the dropped list: ? Intent ? Target Management ? Data Tools Platform ? Java Workflow Tooling ? Marketplace Client ? Koneki ? Target Communication Framework Both Intent and Target Management have informed the community that they've dropped out (though there is still some ongoing discussion regarding TM). The rest have not yet created a release record. I'm expecting that least two of them (Data Tools and Marketplace Client) really do want to participate. I'll give them all a kick. Wayne -- Wayne Beaton @waynebeaton The Eclipse Foundation [EclipseCon2015]http://www.eclipsecon.org/na2015 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] TCF Participation in Mars
(Resend with a proper subject) Target Communication Framework (TCF) intends to participate in Mars with an 1.3 release (or probably 1.4 in case we end up releasing 1.3 sooner – at any rate it’ll be backward compatible). Key things we’re working on include - Improve the TCF Terminals View and have it picked up as the default terminal by EPP packages (instead of TM Terminal which drops from Mars) - Symbol resolver improvements for C++11 and ADA Debugging - Improve documentation for new adopters and extenders of TCF Our release record is here: https://projects.eclipse.org/projects/tools.cdt.tcf/releases/1.3.0 Our offset will be +2 (since we depend on CDT) And I couldn’t figure out where to “flip the flag” on the PMI to show Mars participation, so please let me know if anything is still missing. Thanks, Martin -- Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River direct +43.662.457915.85 fax +43.662.457915.6 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Observation: Frequent UI freezes when working with files
We have something in Sapphire that would be applicable.
http://git.eclipse.org/c/sapphire/org.eclipse.sapphire.git/tree/plugins/org.eclipse.sapphire.ui/src/org/eclipse/sapphire/ui/DelayedTasksExecutor.java
In the text change listener, we schedule a task to update the model (an
operation that can be expensive). The executor only runs the tasks once things
have been quiet for a certain time (no new tasks). This allows us to provide
“immediate” on-change feedback without making the UI appear sluggish to the
user while they are entering data.
Thanks,
- Konstantin
From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Oberhuber,
Martin
Sent: Thursday, December 11, 2014 12:04 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Observation: Frequent UI freezes when
working with files
Hi,
The most significant UI bloopers of the sort that Marcel mentioned I have seen
in dialogs which validate input fields to actually be a file on every keystroke.
This really hurts if the path you’re trying to enter is a Windows UNC path
(\\myserver\myshare\path\to\file.c file:///\\myserver\myshare\path\to\file.c
) and you make the beginner’s mistake of just starting to type … trying to
validate \\m file:///\\m and then \\my file:///\\my and then \\mys
file:///\\mys will cost an average time of 2-5 seconds per keystroke which
is really painful. The workaround is typing your path in an external editor and
then “pasting” in one shot, or typing a relative path first (which is obviously
no file) and then inserting the \\ at the beginning as your last action.
I would love to see some sort of common infrastructure, which can be applied on
arbitrary folders (not just IResource) and would return answers like isFile()
asynchronously via callback in order to validate or invalidate dialogs … of
course any new keystroke would need to cancel any pending asynchronous
request(s) in order to just validate the new request.
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of John Arthorne
Sent: Thursday, December 11, 2014 7:54 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Observation: Frequent UI freezes when
working with files
The IResource/IWorkspace API is backed by a completely in-memory skeleton of
your file system structure. So any time you can query the resource model
instead of the file system, you will see orders of magnitude performance
improvement over direct java.io.File access. The IResource API (and EFS)
encourage a batch-style interaction for the rare thing that is not in memory.
For example IResource#getResourceAttributes or IFileStore#fetchInfo returns a
struct of all the attributes in a single native call, which is vastly more
efficient than doing many calls such as if (file.exists() file.isFile()
file.canRead()) {... }.
For the IResource API and much of the rest of the platform API, the best
indicator is whether there is an IProgressMonitor in the API method. If the
method takes a progress monitor, you probably don't want to call it from the UI
thread. If there is no progress monitor, then for the most part you are ok.
There are a few embarrassing exceptions to this (e.g.,, Job#join), but it's a
useful rule of thumb.
John
From:Lars Vogel lars.vo...@gmail.com
To:Cross project issues cross-project-issues-dev@eclipse.org
Date:12/11/2014 01:38 PM
Subject:Re: [cross-project-issues-dev] Observation: Frequent UI freezes
when working with files
Sent by:cross-project-issues-dev-boun...@eclipse.org
_
I would guess that java.nio.file.Files.exists() [1] improves this access
performance. Do you see these freezes cause by
org.eclipse.core.resources.IResources or by directly using the Java File API?
[1]
http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#exists(java.nio.file.Path,%20java.nio.file.LinkOption...))
2014-12-10 14:53 GMT+01:00 Marcel Bruch marcel.br...@codetrails.com:
Hi,
I just want to share an insight I got from reviewing several ui freezes. One
common cause for UI freezes are operations that touch the filesystem. For
instance, File.isFile, File.lastModified, or
WinNTFileSystem.getBooleanAttributes seem to be very expensive. From what I
read on the internet it seems that some of these methods (e.g. getAttributes)
may even take up to several seconds to return on windows systems.
This has been discussed elsewhere in the internet [1] and seems to be a
long-standing issue in Java.
With this mail I’d like to make you aware of this (in case you did not know
this before) and would like to encourage you to actually not execute file
operations in
Re: [cross-project-issues-dev] Observation: Frequent UI freezes when working with files
Marcel, This seems to be very low level detail. Do you know or can you see if this relates to some higher level operation being performed from within in the UI thread which shouldn't? -Gunnar Am 10.12.2014 um 14:53 schrieb Marcel Bruch marcel.br...@codetrails.com: Hi, I just want to share an insight I got from reviewing several ui freezes. One common cause for UI freezes are operations that touch the filesystem. For instance, File.isFile, File.lastModified, or WinNTFileSystem.getBooleanAttributes seem to be very expensive. From what I read on the internet it seems that some of these methods (e.g. getAttributes) may even take up to several seconds to return on windows systems. This has been discussed elsewhere in the internet [1] and seems to be a long-standing issue in Java. With this mail I’d like to make you aware of this (in case you did not know this before) and would like to encourage you to actually not execute file operations in the ui thread. We may also consider doing some kind of caching but such a discussion would by far be over my knowledge, and thus, should be left to discuss with the platform team. For now, I think we would benefit very much if every project that accesses files/resources would review their code and think about refactoring some part of the FileSystem work (even if it’s only checking a file’s attributes) into background processes. Best, Marcel [1] http://stackoverflow.com/questions/20546676/webstart-winntfilesystem-getbooleanattributes-performance -- Codetrails GmbH The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt Phone: +49-6151-276-7092 Mobile: +49-179-131-7721 http://www.codetrails.com/ Managing Director: Dr. Marcel Bruch Handelsregister: Darmstadt HRB 91940 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Gunnar Wagenknecht gun...@wagenknecht.org ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Projects missing from Mars
No need to be violent :). This came out of a conversation with Greg, the TM project lead. We’re just questioning finally what TCF is trying to do with the terminal, why it couldn’t be done in it’s proper home in tm-dev, and why it has to be so different. This has been part of my out-reach out to the projects to make sure we have a target management system that meets all our needs. I need to do some digging to understand more. We can discuss more on the tm-dev list. Doug. From: Oberhuber, Martin martin.oberhu...@windriver.commailto:martin.oberhu...@windriver.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Thursday, December 11, 2014 at 3:07 PM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Projects missing from Mars Doug, As a committer on TM and a project lead on TCF I am violently opposed against keeping the TM terminal alive. If you still believe that TCF terminal does not support multiple views, you are 1.5 years or more late with your assessment. As of today, the TCF Terminals view is at 100% feature parity compared to TM Terminal, and offers MUCH more (like drag-and-drop rearrangement of its multiple views for example, local terminal support, proper detection of target encoding and more). I’ve documented the feature parity on a bugzilla bug long ago if you want details (just don’t have time digging that out now). Please, don’t make announcements like this without talking to the committers on the projects that you are talking about. Thanks, Martin -- Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River direct +43.662.457915.85 fax +43.662.457915.6 From: cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Doug Schaefer Sent: Thursday, December 11, 2014 9:03 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] Projects missing from Mars BTW, I am going to take another look at the TM Terminal. Dropping should be considered on hold at the moment. It might have a place with our o.e.remote strategy and has some UX features that are actually better than the TCF Terminal, like multiple views. Again no commitments but I should have a good understanding of where we need this to go by end of Jan. BTW2, my biggest problem is that I’m releasing the LaunchBar in Luna SR-2 with CDT 8.6 and it has dependencies on all this stuff. So I’m walking a bit of a tight rope on this at the moment. Doug. From: Oberhuber, Martin martin.oberhu...@windriver.commailto:martin.oberhu...@windriver.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Thursday, December 11, 2014 at 2:55 PM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Projects missing from Mars Hi Wayne, all – Target Communication Framework (TCF) intends to participate in Mars with an 1.3 release (or probably 1.4 in case we end up releasing 1.3 sooner – at any rate it’ll be backward compatible). Key things we’re working on include - Improve the TCF Terminals View and have it picked up as the default terminal by EPP packages (instead of TM Terminal which drops from Mars) - Symbol resolver improvements for C++11 and ADA Debugging - Improve documentation for new adopters and extenders of TCF Our release record is here: https://projects.eclipse.org/projects/tools.cdt.tcf/releases/1.3.0 Our offset will be +2 (since we depend on CDT) And I couldn’t figure out where to “flip the flag” on the PMI to show Mars participation, so please let me know if anything is still missing. Thanks, Martin -- Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River direct +43.662.457915.85 fax +43.662.457915.6 From:cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Wayne Beaton Sent: Thursday, December 11, 2014 8:29 PM To: Cross project issues Subject: [cross-project-issues-dev] Projects missing from Mars Greetings folks. I believe that I'm caught up with the opt-in. The following projects are on the dropped list: ? Intent ? Target Management ? Data Tools Platform ? Java Workflow Tooling ? Marketplace Client ? Koneki ? Target Communication Framework Both Intent and Target Management have informed the community that they've dropped out (though there is still some ongoing discussion regarding TM). The rest have not yet created a release record. I'm expecting that least two of them (Data Tools and Marketplace Client) really do want to participate. I'll
