Community
Participate
Working Groups
Current implementation of the register grouping feature (see http://eclip.se/235747) works only with the MIRegisters service. It should be made more generic to support other implementations of IRegisters.
New Gerrit change created: https://git.eclipse.org/r/44533 WARNING: this patchset contains 1363 new lines of code and may require a Contribution Questionnaire (CQ) if the author is not a committer on the project. Please see:https://wiki.eclipse.org/Project_Management_Infrastructure/Creating_A_Contribution_Questionnaire
Pushed a draft patch to Gerrit: https://git.eclipse.org/r/44533. The patch adds a new interface IMIRegisters and a new implementation of the IRegisters2 service - GDBManagedRegisterGroups which is a modification of GDBRegisters. We should probably come up with a better name than GDBManagedRegisterGroups. Unfortunately, because of API reasons, I can't use or modify GDBRegisters directly because it extends MIRegisters and the new service doesn't. I will update the tests if the patch is approved.
(In reply to Mikhail Khodjaiants from comment #2) > Unfortunately, because of API reasons, I can't use > or modify GDBRegisters directly because it extends MIRegisters and the new > service doesn't. I tried and replaced the entire content of GDBRegisters with the content of GDBManagedRegisterGroups I got no compilation errors i.e., keeping the declarations as before: public class GDBRegisters extends MIRegisters implements IRegisters2 { but the rest is what was in GDBManagedRegisterGroups. I haven't tested though. This would allow to modify GDBRegisters to do what Mikhail wants and still use the delegate pattern. The extending of MIRegisters would not be necessary but we'd keep it for API compatibility. This may also fit well with the suggestion I made in the review to use a single register-service and a delegate (like GDBPatternMatchingExpressions) instead of two register services.
(In reply to Marc Khouzam from comment #3) > (In reply to Mikhail Khodjaiants from comment #2) > > Unfortunately, because of API reasons, I can't use > > or modify GDBRegisters directly because it extends MIRegisters and the new > > service doesn't. > > I tried and replaced the entire content of GDBRegisters with the content of > GDBManagedRegisterGroups I got no compilation errors i.e., keeping the > declarations as before: > > public class GDBRegisters extends MIRegisters implements IRegisters2 { > > but the rest is what was in GDBManagedRegisterGroups. > > I haven't tested though. > I just realized that extending MIRegisters would work. I thought it would cause problems when initializing the delegate. GDBManagedRegisterGroups is not registered at the moment when the delegate is initialized and the services tracker will return the proper service. > This would allow to modify GDBRegisters to do what Mikhail wants and still > use the delegate pattern. The extending of MIRegisters would not be > necessary but we'd keep it for API compatibility. > > This may also fit well with the suggestion I made in the review to use a > single register-service and a delegate (like GDBPatternMatchingExpressions) > instead of two register services. Thanks, I'll take a look at the way GDBPatternMatchingExpressions is implemented.
(In reply to Mikhail Khodjaiants from comment #4) > I just realized that extending MIRegisters would work. I thought it would > cause problems when initializing the delegate. GDBManagedRegisterGroups is > not registered at the moment when the delegate is initialized and the > services tracker will return the proper service. I had to play around a little bit to make this work for GDBPatternMatchingExpressions. The important points are: - GDBPatternMatchingExpressions gets MIExpressions as a parameter not through a tracker (because there is not way to unregister a service easily) - MIExpressions.initialize() is called by GDBPatternMatchingExpressions _after_ GDBPatternMatchingExpressions is registered, and MIExpressions won't register if there is already a service registered for IExpressions.
(In reply to Marc Khouzam from comment #5) > I had to play around a little bit to make this work for > GDBPatternMatchingExpressions. The important points are: > > - GDBPatternMatchingExpressions gets MIExpressions as a parameter not > through a tracker (because there is not way to unregister a service easily) > - MIExpressions.initialize() is called by GDBPatternMatchingExpressions > _after_ GDBPatternMatchingExpressions is registered, and MIExpressions won't > register if there is already a service registered for IExpressions. Thanks Marc, hopefully I'll have time to work on it.
