| Re: [platform-ui-dev] Changes to the Editors preference page |
The fix for https://bugs.eclipse.org/bugs/show_bug.cgi?id=467499 would
need to significantly improve performance if there are many opened
editors in an Eclipse workspace (at least on Linux and Mac).
Snjeza
On 3/18/2016 11:00 AM, Lars Vogel wrote:
>> What about the other changes I proposed to the preference page?
> +1 to https://bugs.eclipse.org/bugs/show_bug.cgi?id=489891
>
> On Thu, Mar 17, 2016 at 4:04 PM, Stefan Xenos <sxenos@xxxxxxxxx> wrote:
>> Yes. I suppose an info pop-up would solve the problem, too.
>>
>> -Stefan
>>
>>
>> On Thu, Mar 17, 2016, 6:24 AM Lars Vogel <lars.vogel@xxxxxxxxxxx> wrote:
>>> @Stefan, can you open a bug report for the O(n^2) performance in creating
>>> N tabs? This sounds definitely wrong. If you already have some tracing data
>>> why this happens, please attach it to the bug (or even better upload a fix
>>> for this behavior). Maybe more issues like Bug 467499, or maybe also solved
>>> with this bug.
>>>
>>> I personally switch on auto-close of editors whenever I notice a UI delay
>>> with my >99+ editors but I agree to the general discussion that setting auto
>>> close as default might be distracting for the user.
>>>
>>> Maybe we could bring up a small info popup the first time we hit more then
>>> 99 editors and inform the user about the auto-close performance advantage
>>> and allow to activate the setting via this popup?
>>>
>>> Best regards, Lars
>>>
>>> Am 15.03.2016 1:32 vorm. schrieb "Stefan Xenos" <sxenos@xxxxxxxxx>:
>>>>> the number of apparently open tabs can grow to hundreds with little to
>>>>> no performance penalty as there are no SWT controls or listeners.
>>>> Actually, some of the performance problems occur even with just tabs --
>>>> for example, incrementing the number of tabs requires instantiating a
>>>> CTabItem, and creating n CTabItems takes O(n^2) time. It has a low constant,
>>>> but if you create enough tabs (even without realized editors), it gets very
>>>> slow.
>>>>
>>>> - Stefan
>>>>
>>>> On Mon, Mar 14, 2016 at 6:15 PM, Jonah Graham <jonah@xxxxxxxxxxxxxxxx>
>>>> wrote:
>>>>> Hi Stefan,
>>>>>
>>>>> (I am pleased that you are pursuing trying to solve this performance
>>>>> issue! Solving this kind of bigger problem in Eclipse always seems
>>>>> like an uphill battle.)
>>>>>
>>>>> Perhaps there is a heuristic that can be used to determined when to
>>>>> close editors earlier before we worry about the "critical" number of
>>>>> active editors. e.g. Only close editors that are AbstractTextEditors
>>>>> with no undo buffers?
>>>>>
>>>>> Also, instead of closing the editor completely, how about replace it
>>>>> on the editor stack with an unrestored Editor? That way all the editor
>>>>> tabs are preserved, the number of apparently open tabs can grow to
>>>>> hundreds with little to no performance penalty as there are no SWT
>>>>> controls or listeners. This method also preserves cursor
>>>>> location/selection. Specifically I am referring to functionality
>>>>> org.eclipse.ui.IPersistableEditor adds to an editor.
>>>>>
>>>>> Doing the the two things above may allow you to free most editor
>>>>> resources after only a handful (your 20 number comes to mind) of
>>>>> editors are opened.
>>>>>
>>>>>
>>>>> The other approach to dealing with the undo buffer is of course to
>>>>> persist it to disk. I think that would be a good feature on its own
>>>>> and if you add in autosave to the mix you get better preserved state
>>>>> and a more complete restoration of your exact workbench when you close
>>>>> it. Similar to local history you could have an expiration time / size
>>>>> / entries. Slightly OT.
>>>>>
>>>>> Jonah
>>>>> ~~~
>>>>> Jonah Graham
>>>>> Kichwa Coders Ltd.
>>>>> www.kichwacoders.com
>>>>>
>>>>>
>>>>> On 15 March 2016 at 00:25, Stefan Xenos <sxenos@xxxxxxxxx> wrote:
>>>>>> Jonah, that's a pretty compelling use-case. You've convinced me that
>>>>>> it's a
>>>>>> place where auto-closing editors will produce a bad user experience.
>>>>>>
>>>>>> However, clearly we can't retain full editor states for an unlimited
>>>>>> number
>>>>>> of editors. At a certain point, performance degrades intolerably...
>>>>>> and at a
>>>>>> certain point beyond that, Eclipse crashes due to running out of SWT
>>>>>> handles
>>>>>> or heap space. If you reach that point you'd also lose your undo
>>>>>> stack.
>>>>>>
>>>>>> Why don't we do some performance measurements, and pick the largest
>>>>>> number
>>>>>> of editors we possibly can before the performance becomes unbearably
>>>>>> slow or
>>>>>> anything crashes on a 32-bit VM -- and only close editors at that
>>>>>> point.
>>>>>>
>>>>>> So we could turn on auto-close editors but make the number of editors
>>>>>> as big
>>>>>> at we can before performance degrades too much, and we can
>>>>>> collectively
>>>>>> decide what we feel to be "too much". That way you'd normally be able
>>>>>> to
>>>>>> keep your undo stack, but Eclipse could still resort to discarding an
>>>>>> undo
>>>>>> stack if it has no other alternatives but to freeze up or crash.
>>>>>>
>>>>>> - Stefan
>>>>>>
>>>>>> On Mon, Mar 14, 2016 at 2:39 PM, Jonah Graham <jonah@xxxxxxxxxxxxxxxx>
>>>>>> wrote:
>>>>>>> Personally I think auto-closing editors is a bad idea. The simple
>>>>>>> reason is that if you do that you dump the Undo stack of that editor.
>>>>>>> That means this flow (which is pretty normal for me) would be broken:
>>>>>>>
>>>>>>> 1) Make an edit
>>>>>>> 2) Explore around 20+ files trying to figure out exactly which method
>>>>>>> did what in what call hierarchy, etc.
>>>>>>> 3) Press Ctrl-Q (last edit position)
>>>>>>> 4) Press Ctrl-Z because at step 2 I realized the very last thing I
>>>>>>> typed in Step 1 was wrong.
>>>>>>>
>>>>>>> Dumping of my Undo buffer is not a good user experience.
>>>>>>>
>>>>>>> In addition, for graphical editors, the state is not restored well
>>>>>>> when using Alt-Left / Alt-Right. i.e. you may end up back in the
>>>>>>> correct editor, but not the correct scroll bar position, zoom level,
>>>>>>> etc depending on the editor.
>>>>>>>
>>>>>>> Jonah
>>>>>>> ~~~
>>>>>>> Jonah Graham
>>>>>>> Kichwa Coders Ltd.
>>>>>>> www.kichwacoders.com
>>>>>>>
>>>>>>>
>>>>>>> On 14 March 2016 at 20:52, Stefan Xenos <sxenos@xxxxxxxxx> wrote:
>>>>>>>>> 4. Auto closing editors is highly distracting during a complex
>>>>>>>>> debig
>>>>>>>>> session, because the
>>>>>>>>> important context / knowledge gets lost.
>>>>>>>> What is it about the behavior that is distracting and what specific
>>>>>>>> knowledge is lost?
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Mar 14, 2016 at 1:08 PM, Andrey Loskutov <loskutov@xxxxxx>
>>>>>>>> wrote:
>>>>>>>>> See my answers inlined
>>>>>>>>>
>>>>>>>>> Am 14. März 2016 19:59:08 MEZ, schrieb Stefan Xenos
>>>>>>>>> <sxenos@xxxxxxxxx>:
>>>>>>>>>>> FYI, I pretty often end up with "99+" (mostly Java) editors in
>>>>>>>>>>> my
>>>>>>>>>> IDE,
>>>>>>>>>> and indeed it
>>>>>>>>>>> consumes some memory, but never to a point that prevents me
>>>>>>>>>>> from
>>>>>>>>>> closing
>>>>>>>>>> them
>>>>>>>>>>> and getting back into a good performance state.
>>>>>>>>>> Okay, so you've discovered the "close all editors" action and
>>>>>>>>>> understand
>>>>>>>>>> that you can use it to correct Eclipse slowness when you
>>>>>>>>>> encounter it.
>>>>>>>>>> New
>>>>>>>>>> users haven't discovered the action yet and almost certainly
>>>>>>>>>> haven't
>>>>>>>>>> made
>>>>>>>>>> the connection between the slow performance they're seeing and
>>>>>>>>>> the
>>>>>>>>>> number
>>>>>>>>>> shown in their editor chevron. The defaults should be appropriate
>>>>>>>>>> for
>>>>>>>>>> new
>>>>>>>>>> users.
>>>>>>>>> I'm not sure if this is the right way to solve the performance
>>>>>>>>> issue.
>>>>>>>>> We should identify, report and address each problem causing
>>>>>>>>> performance
>>>>>>>>> degradation for many opened editors case.
>>>>>>>>> If you have identified some hotspots, please open bugs for them.
>>>>>>>>> Simply
>>>>>>>>> auto-closing editors because we are unable to manage performance
>>>>>>>>> is not
>>>>>>>>> a
>>>>>>>>> solution.
>>>>>>>>>
>>>>>>>>>> I've received a bunch of support tickets from users reporting
>>>>>>>>>> sluggish
>>>>>>>>>> performance and who just had too many editors open. The "fix" is
>>>>>>>>>> to
>>>>>>>>>> ask
>>>>>>>>>> them to close all editors and enable the preference. They often
>>>>>>>>>> respond
>>>>>>>>>> with comments like "why doesn't Eclipse just do this by
>>>>>>>>>> default?"...
>>>>>>>>>> and
>>>>>>>>>> it's a legitimate complaint. Changing the default would both
>>>>>>>>>> improve
>>>>>>>>>> the
>>>>>>>>>> user experience and reduce the support costs for folks who need
>>>>>>>>>> to
>>>>>>>>>> answer
>>>>>>>>>> this question over and over.
>>>>>>>>> This is a wrong conclusion - the users don't want that Eclipse
>>>>>>>>> closes
>>>>>>>>> editors automatically (I'm unaware about any editor which does
>>>>>>>>> this by
>>>>>>>>> default) - the users want that performance is not related to the
>>>>>>>>> opened
>>>>>>>>> editors count.
>>>>>>>>>
>>>>>>>>> BTW one possible problem with many opened editors performance
>>>>>>>>> could be
>>>>>>>>> that editor rulers for all editors are repainted on each
>>>>>>>>> annotation
>>>>>>>>> model
>>>>>>>>> change (see
>>>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=467499#c20).
>>>>>>>>>
>>>>>>>>>>> What I'd miss with editors closing up automatically is that I
>>>>>>>>>> actually
>>>>>>>>>> use the order of editors
>>>>>>>>>>> as a breadcrumb or a stack current context(s)
>>>>>>>>>> The preference I'm talking about has nothing to do with the
>>>>>>>>>> history
>>>>>>>>>> stack
>>>>>>>>>> and the back button. The history stack is based on editor inputs
>>>>>>>>>> and
>>>>>>>>>> it
>>>>>>>>>> works just as well even if you enable the "close automatically"
>>>>>>>>>> preference
>>>>>>>>>> and set the number of editors to 1.
>>>>>>>>>>
>>>>>>>>>> It really sounds like you're confusing the "close editors
>>>>>>>>>> automatically"
>>>>>>>>>> preference in the editors page with the "reuse editors"
>>>>>>>>>> preference in
>>>>>>>>>> the
>>>>>>>>>> search page. That one does interfere with the history stack.
>>>>>>>>> Same as Mickael, I do not confuse the preference, I use editor
>>>>>>>>> tabs
>>>>>>>>> list
>>>>>>>>> on the top right side of the tab area.
>>>>>>>>>
>>>>>>>>>> So far you've raised three objections to the preference change:
>>>>>>>>>>
>>>>>>>>>> 1. That it would cause editors to disappear unexpectedly.
>>>>>>>>>> Response:
>>>>>>>>>> The
>>>>>>>>>> editors we're talking about have already disappeared from the
>>>>>>>>>> tabs. If
>>>>>>>>>> you're not referring to the tabs, please state specifically which
>>>>>>>>>> part
>>>>>>>>>> of
>>>>>>>>>> the UI you expected to see the editor in but could not find it.
>>>>>>>>> The editor tab schevron with the editor list. It is useful and
>>>>>>>>> exists
>>>>>>>>> exact dor tha purpose of visualisation of opened but not visible
>>>>>>>>> editors.
>>>>>>>>>
>>>>>>>>>> 2. That it would interfere with the editor navigation history.
>>>>>>>>>> Response: It
>>>>>>>>>> wouldn't.
>>>>>>>>> Sure it would. I use editors list to navigate between opened
>>>>>>>>> editors,
>>>>>>>>> and
>>>>>>>>> since MRU can be switched off, my editors are always in exact same
>>>>>>>>> order
>>>>>>>>> I've opened them. Automatically closing the editors will break the
>>>>>>>>> opening
>>>>>>>>> order again and make me crazy searching for them.
>>>>>>>>>
>>>>>>>>>> 3. That there is actually no performance problem if you have a
>>>>>>>>>> large
>>>>>>>>>> number
>>>>>>>>>> of realized editors. Response: Confirmed via profiler output,
>>>>>>>>>> end-user
>>>>>>>>>> reports, and static analysis of the code involved.
>>>>>>>>>>
>>>>>>>>> You mean you confirm that *there IS* a performance problem?
>>>>>>>>> No doubt, but I personally doubt that the auto-close preference is
>>>>>>>>> the
>>>>>>>>> way
>>>>>>>>> to go.
>>>>>>>>>
>>>>>>>>>> I believe I've addressed 1 and 2 quite well. However, if you're
>>>>>>>>>> still
>>>>>>>>>> unconvinced about 3 I would be happy to offer some data to back
>>>>>>>>>> up my
>>>>>>>>>> claim. Unfortunately, I can't share my support tickets with you,
>>>>>>>>>> but I
>>>>>>>>>> could offer profiler output and code references to code which
>>>>>>>>>> performs
>>>>>>>>>> linear operations on the number of editors. What would you find
>>>>>>>>>> most
>>>>>>>>>> compelling?
>>>>>>>>> I think you should jave identified some "top five" performance
>>>>>>>>> issues -
>>>>>>>>> please open bugs for them.
>>>>>>>>>
>>>>>>>>> There is point 4. which you do not have yet on the list.
>>>>>>>>>
>>>>>>>>> 4. Auto closing editors is highly distracting during a complex
>>>>>>>>> debig
>>>>>>>>> session, because the important context / knowledge gets lost.
>>>>>>>>>
>>>>>>>>> IMHO auto closing the editors is one of the reasons why Mylin is
>>>>>>>>> not
>>>>>>>>> activated/used by default. This os one of the highly polarizing
>>>>>>>>> preferences
>>>>>>>>> where people either love or hate it. It happened to me ro be Mylyn
>>>>>>>>> incompatible too, and in our lab I don't know anyone using it even
>>>>>>>>> if
>>>>>>>>> we
>>>>>>>>> pre-install Mylyn because of Jira connector.
>>>>>>>>>
>>>>>>>>> I found really interesting Mickael's proposal to dispose inactive
>>>>>>>>> hidden
>>>>>>>>> editors but let them be on the opened edotor list - so that they
>>>>>>>>> are
>>>>>>>>> automatically restored if user clicks the tab again.
>>>>>>>>> I've filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=489593
>>>>>>>>>
>>>>>>>>>> - Stefan
>>>>>>>>>>
>>>>>>>>>> On Mon, Mar 14, 2016 at 4:35 AM, Mickael Istria
>>>>>>>>>> <mistria@xxxxxxxxxx>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 03/14/2016 09:17 AM, Stefan Xenos wrote:
>>>>>>>>>>>
>>>>>>>>>>>> If we have known performance issues with many editors, we
>>>>>>>>>>>> should
>>>>>>>>>> better
>>>>>>>>>>> investigate and fix them one by one.
>>>>>>>>>>>
>>>>>>>>>>> I'm not sure how you would fix it. How would you keep an
>>>>>>>>>>> unbounded
>>>>>>>>>> number
>>>>>>>>>>> of realized editors in memory without consuming an unbounded
>>>>>>>>>>> amount
>>>>>>>>>> of
>>>>>>>>>>> memory?
>>>>>>>>>>> You could lazily destroy editors, remember their inputs, and
>>>>>>>>>>> recreate
>>>>>>>>>> the
>>>>>>>>>>> actual widgets the next time it's brought to foreground... but
>>>>>>>>>>> that's
>>>>>>>>>>> pretty much what "close editors automatically" does.
>>>>>>>>>>> The performance problems are all over the place. Editors
>>>>>>>>>>> contain a
>>>>>>>>>> ton of
>>>>>>>>>>> widgets, and most stuff in SWT gets slower with more widgets
>>>>>>>>>>> since
>>>>>>>>>> it's
>>>>>>>>>>> filled with depth-first-searches over the widget hierarchy.
>>>>>>>>>>> Editors
>>>>>>>>>>> register lots of listeners, and sending events to listeners is
>>>>>>>>>>> linear
>>>>>>>>>> in
>>>>>>>>>>> terms of number of listeners. Many editors also allocate SWT
>>>>>>>>>> resources
>>>>>>>>>>> which eventually results in the SWT out of handles error. Then
>>>>>>>>>> there's the
>>>>>>>>>>> working copies, workbench activation history, and tons of other
>>>>>>>>>>> stuff
>>>>>>>>>>> editors do that scales linearly (in runtime and memory) with
>>>>>>>>>>> the
>>>>>>>>>> number of
>>>>>>>>>>> editors.
>>>>>>>>>>>
>>>>>>>>>>> FYI, I pretty often end up with "99+" (mostly Java) editors in
>>>>>>>>>>> my
>>>>>>>>>> IDE, and
>>>>>>>>>>> indeed it consumes some memory, but never to a point that
>>>>>>>>>>> prevents
>>>>>>>>>>> me
>>>>>>>>>> from
>>>>>>>>>>> closing them and getting back into a good performance state. So
>>>>>>>>>>> I do
>>>>>>>>>> not
>>>>>>>>>>> believe there is a performance problem with the simple amount
>>>>>>>>>>> of
>>>>>>>>>>> open
>>>>>>>>>>> editors growing. However, there are definitely some editors
>>>>>>>>>>> that
>>>>>>>>>> consume a
>>>>>>>>>>> lot of resource when open and that it's better to close
>>>>>>>>>>> whenever
>>>>>>>>>> they're
>>>>>>>>>>> not used, but I don't believe it's a problem that requires
>>>>>>>>>>> Platform's
>>>>>>>>>>> attention nor that is strong enough to introduce a new
>>>>>>>>>>> behaviour.
>>>>>>>>>>> Also, I wouldn't like editors to close automatically by
>>>>>>>>>>> default,
>>>>>>>>>> since
>>>>>>>>>>> some actions such as debugging often require to open a lot of
>>>>>>>>>>> files
>>>>>>>>>>> (debugging some complex things can request to open more that 20
>>>>>>>>>>> files
>>>>>>>>>>> sometimes).
>>>>>>>>>>>
>>>>>>>>>>> Sure, there probably ARE users that would miss the old
>>>>>>>>>>> behavior, are
>>>>>>>>>>> willing to pay the performance penalties, and don't mind
>>>>>>>>>>> restarting
>>>>>>>>>> due to
>>>>>>>>>>> the occasional OOME.
>>>>>>>>>>>
>>>>>>>>>>> As I mentioned above, I never face the need to restart because
>>>>>>>>>>> of an
>>>>>>>>>> OOME
>>>>>>>>>>> caused by too many open editors. Is there a bug report on this
>>>>>>>>>>> topic?
>>>>>>>>>> Am I
>>>>>>>>>>> the only lucky one to not suffer from it?
>>>>>>>>>>>
>>>>>>>>>>> What I'd miss with editors closing up automatically is that I
>>>>>>>>>> actually use
>>>>>>>>>>> the order of editors as a breadcrumb or a stack current
>>>>>>>>>>> context(s),
>>>>>>>>>> and I
>>>>>>>>>>> find it very important to keep this organization as I take very
>>>>>>>>>>> often
>>>>>>>>>>> advantage of it. I guess many developers do the same thing.
>>>>>>>>>>> Closing
>>>>>>>>>> some
>>>>>>>>>>> editors randomly would make this usage not fully possible.
>>>>>>>>>>> --
>>>>>>>>>>> Mickael Istria
>>>>>>>>>>> Eclipse developer at JBoss, by Red Hat
>>>>>>>>>>> <http://www.jboss.org/tools>
>>>>>>>>>>> My blog <http://mickaelistria.wordpress.com> - My Tweets
>>>>>>>>>>> <http://twitter.com/mickaelistria>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> platform-ui-dev mailing list
>>>>>>>>>>> platform-ui-dev@xxxxxxxxxxx
>>>>>>>>>>> To change your delivery options, retrieve your password, or
>>>>>>>>>> unsubscribe
>>>>>>>>>>> from this list, visit
>>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>> _______________________________________________
>>>>>>>>>> platform-ui-dev mailing list
>>>>>>>>>> platform-ui-dev@xxxxxxxxxxx
>>>>>>>>>> To change your delivery options, retrieve your password, or
>>>>>>>>>> unsubscribe
>>>>>>>>> >from this list, visit
>>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>>>>>>>>> --
>>>>>>>>> Kind regards,
>>>>>>>>> Andrey Loskutov
>>>>>>>>>
>>>>>>>>> http://google.com/+AndreyLoskutov
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> platform-ui-dev mailing list
>>>>>>>> platform-ui-dev@xxxxxxxxxxx
>>>>>>>> To change your delivery options, retrieve your password, or
>>>>>>>> unsubscribe
>>>>>>>> from
>>>>>>>> this list, visit
>>>>>>>> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>>>>>>> _______________________________________________
>>>>>>> platform-ui-dev mailing list
>>>>>>> platform-ui-dev@xxxxxxxxxxx
>>>>>>> To change your delivery options, retrieve your password, or
>>>>>>> unsubscribe
>>>>>>> from this list, visit
>>>>>>> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> platform-ui-dev mailing list
>>>>>> platform-ui-dev@xxxxxxxxxxx
>>>>>> To change your delivery options, retrieve your password, or
>>>>>> unsubscribe from
>>>>>> this list, visit
>>>>>> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>>>>> _______________________________________________
>>>>> platform-ui-dev mailing list
>>>>> platform-ui-dev@xxxxxxxxxxx
>>>>> To change your delivery options, retrieve your password, or unsubscribe
>>>>> from this list, visit
>>>>> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> platform-ui-dev mailing list
>>>> platform-ui-dev@xxxxxxxxxxx
>>>> To change your delivery options, retrieve your password, or unsubscribe
>>>> from this list, visit
>>>> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>>> _______________________________________________
>>> platform-ui-dev mailing list
>>> platform-ui-dev@xxxxxxxxxxx
>>> To change your delivery options, retrieve your password, or unsubscribe
>>> from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>>
>> _______________________________________________
>> platform-ui-dev mailing list
>> platform-ui-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from
>> this list, visit
>> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>
>
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev