Chapel: How do you add a package to Mason that requires changes to the Chapel run-time/compiler?

Created on 1 Aug 2018  路  3Comments  路  Source: chapel-lang/chapel

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?

Libraries / Modules Runtime Design user issue

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.

All 3 comments

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?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

BryantLam picture BryantLam  路  3Comments

buddha314 picture buddha314  路  3Comments

lydia-duncan picture lydia-duncan  路  3Comments

BryantLam picture BryantLam  路  3Comments

bradcray picture bradcray  路  3Comments