User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
Migration support is a big and important topic. When we are talking
about deletion of some API I assume that it should provide a way to
migrate the user data. I don't believe that fully automated
conversion is possible, in some cases it may require explicit action
- with "Quick Fix" wizard for example. However, "aliasing" approach
looks promising.
Regards,
AF
08.04.2020 17:21, Jonah Graham пишет:
Thank you Marc-André - I will keep an eye out for
plugin.xml changes that have the potential to break existing
projects and workspaces!
On Wed, 8 Apr 2020 at 00:39,
Marc-Andre Laperle <malaperle@xxxxxxxxx> wrote:
One thing to consider
with deleting the old parsers is that it breaks existing
projects and therefore existing workspaces, not just APIs.
Eclipse platform always supports upgrading a workspace, or
does the proper conversion under the hood.
If the old parser classes are dropped then the IDs have
to be preserved (but associated to the new classes) or
converted to the new ids. I don’t know of any hooks to do
that kind of conversion in MBS automatically but it might
not be difficult to make a basic one with those things
hardcoded. If neither of these are done (keeping the old
ids associated to the new class or converting the ids)
then they can’t really be removed.
This is great news that you are looking
into it. I really like the idea of API
refactoring being driven by actual
usecases - TraceCompass is a great usecase!
> I have questions about the API of that
file though, it has many public/protected
fields that kind of limit its modify-ability,
what would be the CDT friendly way to improve
it?
To re-iterate the above and what Alexander
said, we have the opportunity to move things
forward here without being tied too much to
existing API. While we want the big step
forward we are having to tread carefully to
make sure that any replacement we are
requiring other consumers to move to have
documented migration paths. There are
dependencies throughout CDT and the external
community on the existing parsers. What has
happened in the past with these types of
classes is they are copied-pasted and the old
ones are deprecated*. The big challenge with
that approach is actually deleting the
deprecated ones - but now that we intend to
announce deletions and delete API without
bumping Major version - like Eclipse Platform
does - at least we have a way forward.
Thanks a lot for sharing the result of your
work with community!
The idea to switch to "iterable" style is
definitely the right step forward. We
already started a discussion regarding
implementation details in Gerrit.
As for API - we have an opportunity to make
it much better, as we plan a major version
bump (to 10.0) in September.
I suggest to start working on the new API in
the (not yet created)
"org.eclipse.cdt.binutils" bundle - current
implementation may depend on it but not
vice-versa.
The idea of "org.eclipse.cdt.binutils" is to
focus on utilities for binaries itself
(.elf, .dwarf, others), without involving
CDT Core, UI and so on. Ideally it should
not have any dependency that requires OSGi
running. Yes, to be CLI-friendly. Then we
can add "org.eclipse.cdt.binutils.workspace"
to integrate with IWorkspace,
"org.eclipse.cdt.binutils.jface" - to
provide preferences, wizards and editors,
and so on.
Why? To keep our dependencies clear and to
avoid the fate of the current CDT Core/CDT
UI.
Regards,
AF
03.04.2020 6:28, Matthew Khouzam пишет:
Hello world,
I have been profiling CDT's elf parser,
and have found some opportunities. Now
please understand, I was torture testing
it to make sure it works with Trace
Compass for some upcoming feature ideas
I was going to pitch, I'm just hoping to
help more than myself with this effort.
I was testing an embedded system with a
1 GB executable. Why? in case someone
else does that. Elf parsing works well
and scaled OK. But the memory
requirements are a bit high.
Basically the parser loads every symbol
into an array then sorts it. See image
below for a "smaller" test with 60k
functions.
I have made a quick patch to allow
iteration through the elf file instead
of reading it all in one block. This
is useful when you want to make a map
of symbols to trace segments.
I have questions about the API of that
file though, it has many
public/protected fields that kind of
limit its modify-ability, what would
be the CDT friendly way to improve it?
My endgame would be to have an
iterator on the executable that gives
all the symbols, not necessarily in
order so an extender can use it with
more degrees of freedom.
Thanks!
Matthew
Ericsson
Matthew Khouzam
Software Developer
Ericsson
8275 Route Transcanadienne
H4S 0B6,Saint-Laurent, Quebec
Canada
Our commitment to Technology for
Good and Diversity and Inclusion
contributes to positive change.
Follow us on: Facebook LinkedIn
Twitter