From what I can see, there is some discussion on moving all packages to Mason, but some packages require integration into the Chapel run-time itself, and maybe in the future the compiler.
One example is VisualDebug
(which may or may not be possible to implement in Chapel: issue #10619) Prefetch
, Buffer
, etc.
If packages require low-level use of the run-time, how do you move them to Mason? Should you remove their code from the runtime and instead couple them to the library itself? Should there be an API for interfacing with Chapel's run-time such that they are not needed to be inside the actual run-time itself?
Should there be an API for interfacing with Chapel's run-time such that they are not needed to be inside the actual run-time itself?
This might be the long-term solution to this problem, but I'm not sure - maybe @ronawho or @gbtitus have a more concrete vision.
I would consider packages that require modifications to the compiler or runtime are outside of the scope of Mason.
Personally I've always viewed the runtime as a low-level service bureau for the rest of the Chapel stack which should not to be exposed to users. That helps us runtime developers be more nimble in terms of both supporting new Chapel needs and supporting new hardware, because we don't have to worry about any users depending directly on the runtime interface. I'd strongly prefer that we support new packages, such as the VisualDebug
example, by adapting general runtime interfaces that already exist or adding new general interfaces, rather than making specific runtime changes.
I don't have much to add here beyond what others have said. I think the short answer to the question in the issue title is "you don't (that's not part of our intended design)" or "you get the runtime/compiler changes merged to master and then add your package to mason". Given that there hasn't been much opposing viewpoint on this issue and Louis gave Greg's response a thumbs-up, I'm wondering if we can close this issue on that basis?
Most helpful comment
Personally I've always viewed the runtime as a low-level service bureau for the rest of the Chapel stack which should not to be exposed to users. That helps us runtime developers be more nimble in terms of both supporting new Chapel needs and supporting new hardware, because we don't have to worry about any users depending directly on the runtime interface. I'd strongly prefer that we support new packages, such as the
VisualDebug
example, by adapting general runtime interfaces that already exist or adding new general interfaces, rather than making specific runtime changes.