User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
my 2cent
I'm not so fond of "quick Fix" wizards if they are part of the
gui. The problem here is "When do you remove them". To avoid
clutter that would be with the next release.
Due to this approach I once had to upgrade from (say) version 1 to
(say)version 5, one by one. This because the quick fix from n-1 to
n was removed in n+1.
So I had to install version 2,3 and 4 just to run the quick fixes
so version 5 could quick fix version 4. This is not something I
want to do again nor want to advice someone to do.
Best regards
Jantje
PS covid19 and Sloeber got me all caught up. Hoping to get back
to future MBS soon
Op 8/04/2020 om 16:43 schreef Alexander
Fedorov:
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