You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a bunch of internal GAP functions (and also functions from GAP packages, mostly the IO package) which potentially clashes with Julia. For an optimal experience of using "GAP-on-Julia", we should address these.
Foremost, GAP contains code for dealing with subprocesses, based on forking. This does not work when running with Julia integration (this also affects the IO package, via IO_fork; the worker pool code IO provides; and other packages building atop of this, e.g. the GAP Jupyter interface).
While I don't see what to do about IO_fork, we certainly can do something about subprocess launching in GAP. Indeed, I suggest that we re-implement all of that in pure Julia code, and ultimately disable the relevant GAP C kernel code completely. (For initial tests, this is not necessary, but on the long term, this will avoid "accidental" use of that code). I made a separate issue for this, #241 241
Then there is input/output; we already have several issues dealing with how to capture Julia output in GAP and GAP output in Julia. This could be a lot simpler if we could teach the GAP kernel to simply do its IO via Julia routines.
There is probably more (e.g. interrupt handling), but the above already is a good start.
The text was updated successfully, but these errors were encountered:
fingolfin
changed the title
Idea: provide more "Julia" implementations of functionality inside the GAP kernel
Provide more "Julia" implementations of functionality inside the GAP kernel
Dec 11, 2020
There is a bunch of internal GAP functions (and also functions from GAP packages, mostly the IO package) which potentially clashes with Julia. For an optimal experience of using "GAP-on-Julia", we should address these.
Foremost, GAP contains code for dealing with subprocesses, based on forking. This does not work when running with Julia integration (this also affects the IO package, via
IO_fork
; the worker pool code IO provides; and other packages building atop of this, e.g. the GAP Jupyter interface).While I don't see what to do about
IO_fork
, we certainly can do something about subprocess launching in GAP. Indeed, I suggest that we re-implement all of that in pure Julia code, and ultimately disable the relevant GAP C kernel code completely. (For initial tests, this is not necessary, but on the long term, this will avoid "accidental" use of that code). I made a separate issue for this, #241 241Then there is input/output; we already have several issues dealing with how to capture Julia output in GAP and GAP output in Julia. This could be a lot simpler if we could teach the GAP kernel to simply do its IO via Julia routines.
There is probably more (e.g. interrupt handling), but the above already is a good start.
The text was updated successfully, but these errors were encountered: