-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Turn off GAP loading banner by default #334
Comments
ThomasBreuer
added a commit
to ThomasBreuer/GAP.jl
that referenced
this issue
Feb 13, 2020
This pull request addresses issue oscar-system#334. - By default, `using GAP` will not show the banner. - If Julia's `ENV[ "GAP_SHOW_BANNER" ]` is set to `"true"` then the GAP banner is shown on `using GAP`. - When the user loads GAP packages, it depends on the `LoadPackage` call whether a package banner is shown. This is the standard GAP behaviour in the situation that banners are in principle enabled: If there is a second argument `false` then the banner is not shown, otherwise it is shown. (The idea is to set the command line option `-b` when GAP shall be started without banner, and to reset this option after the start of GAP.) I think we should wait until issue oscar-system#333 gets resolved before switching off the GAP banner by default.
ThomasBreuer
added a commit
to ThomasBreuer/GAP.jl
that referenced
this issue
Feb 13, 2020
This pull request addresses issue oscar-system#334. - By default, `using GAP` will not show the banner. - If Julia's `ENV[ "GAP_SHOW_BANNER" ]` is set to `"true"` then the GAP banner is shown on `using GAP`. - When the user loads GAP packages, it depends on the `LoadPackage` call whether a package banner is shown. This is the standard GAP behaviour in the situation that banners are in principle enabled: If there is a second argument `false` then the banner is not shown, otherwise it is shown. (The idea is to set the command line option `-b` when GAP shall be started without banner, and to reset this option after the start of GAP.) I think we should wait until issue oscar-system#333 gets resolved before switching off the GAP banner by default.
ThomasBreuer
added a commit
to ThomasBreuer/GAP.jl
that referenced
this issue
Mar 11, 2020
This pull request addresses issue oscar-system#334. - By default, `using GAP` will not show the banner. - If Julia's `ENV[ "GAP_SHOW_BANNER" ]` is set to `"true"` then the GAP banner is shown on `using GAP`. - When the user loads GAP packages, it depends on the `LoadPackage` call whether a package banner is shown. This is the standard GAP behaviour in the situation that banners are in principle enabled: If there is a second argument `false` then the banner is not shown, otherwise it is shown. (The idea is to set the command line option `-b` when GAP shall be started without banner, and to reset this option after the start of GAP.) I think we should wait until issue oscar-system#333 gets resolved before switching off the GAP banner by default.
ThomasBreuer
added a commit
that referenced
this issue
Mar 11, 2020
This pull request addresses issue #334. - By default, `using GAP` will not show the banner. - If Julia's `ENV[ "GAP_SHOW_BANNER" ]` is set to `"true"` then the GAP banner is shown on `using GAP`. - When the user loads GAP packages, it depends on the `LoadPackage` call whether a package banner is shown. This is the standard GAP behaviour in the situation that banners are in principle enabled: If there is a second argument `false` then the banner is not shown, otherwise it is shown. (The idea is to set the command line option `-b` when GAP shall be started without banner, and to reset this option after the start of GAP.) I think we should wait until issue #333 gets resolved before switching off the GAP banner by default.
This has been done via #342 . |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While it has been (and still is) useful for debugging while working on GAP, I think the convention for Julia packages is to not show that. Perhaps we can make it optional somehow.
That said, without this, I wouldn't have noticed issue #333.
The text was updated successfully, but these errors were encountered: