Announcement of refactoring/enhancements

[w31t1]

Hello,
based on this approach, I create currently a tool with various more feature/extensions especially for other platforms in the frame of an ESA contract which will also be open source. There is already an extensive refactoring which I will added to the open fork in my github fork.

The status of the tool is that it works for SPARC and fulfills several architecture/design/code quality metrics, but there is still no automated tests, valid documentation nor production ready output.

I will continue with my work from the current status of the main branch (commit 193a071) and there will be an MR at the end of the project, but I will not spent effort on comments, changes or discussions.

[Kazhuu]

Hello!

Yes contributions and refactoring are very welcome! What you mean by ESA contract and MR? Also it would be nice if you could make a PR before the changes get too big. If you possible have chunks that could be separated.For example one for refactoring and one for adding new features. This would make PR review easier for me to digest 👍

[w31t1]

Hi,

ESA contract means a study financed by the European Space Agency
MR is Merge Request. Sorry, we using internally Gitlab, that's the term on this platform.

As I already started the refactoring the changes are already very big, you can see the current changes in my fork, especially the first commit: w31t1/asm2cfg.

A separation into chunks is not feasible as of several points:

• The present architecture/design and code quality was perhaps usable for your use cases, but I have to adapt it for a much broader scope (multiple architectures, multiple disassemblers, easy extensibility, simple configuration, ...).
• The study goal is clear but not the tools itself. Their utilization is changing during and therefore the design/architecture as well.
• The study will concentrate firstly on SPARC architecture. x86, ARM, RISC V and PowerPC will following afterwards.
• The git history will not telling the development story but shall show a feature story at the end and will continuously interactively rebased during the development.

As you see, wether the architecture/design nor the git history is fixed until the end of the study a step by step contribution is out of scope of my working hours. I cannot spent time for discussions in a PR nor fixing issues with the existing code to pass some pipelines in this repo. Also at the beginning, there will be a lot of work to fix the existing pipelines, tests and issues with the existing architectures.

But as the result is Open Source, therefore I can provide this announcement now and again the status about the fork and a big PR at the end. But your proposed approach is too time-expensive.

[Kazhuu]

I understand and thank you for clarification. Do you know when your project is ending and you will provide the PR? If you don't have time, it's okay to do a big PR at the end as well. I'll take look at it and do what I can with it when I've time. Hopefully I get it merged or some parts of it, so others can also benefit from the work. I'd really appreciate if there were at least some time allocated for open source work at the end, but I understand your tight schedule as well. Either way thank you for contributing!