Skip to content
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

Remove DEBUG_LOADING, InfoRead1, and InfoRead2 #2237

Merged
merged 3 commits into from
Nov 14, 2018

Conversation

markuspf
Copy link
Member

@markuspf markuspf commented Mar 4, 2018

They are a leftover of a legacy debugging mechanism. InfoRead1 and InfoRead2 are moved into obsoletes.gd.

Unfortunately the following packages still refer to InfoRead1 or InfoRead2:

These packages will break with this PR if GAP is started without obsoletes.

@markuspf markuspf added the do not merge PRs which are not yet ready to be merged (e.g. submitted for discussion, or test results) label Mar 4, 2018
@codecov
Copy link

codecov bot commented Mar 4, 2018

Codecov Report

Merging #2237 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #2237      +/-   ##
==========================================
- Coverage   85.13%   85.12%   -0.01%     
==========================================
  Files         110      110              
  Lines       56964    56960       -4     
==========================================
- Hits        48494    48489       -5     
- Misses       8470     8471       +1
Impacted Files Coverage Δ
src/gap.c 83.81% <ø> (-0.1%) ⬇️
src/stats.c 95.07% <0%> (-0.21%) ⬇️

Copy link
Member

@fingolfin fingolfin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good in general to me, but of course it breaks packages using InfoRead1 and InfoRead2, as you pointed out yourself. But there's a quick solution to that, too: We can just defined them in lib/obsolete.{gi,gd} for now, with a list of packages still using them (as we do with lots of other functions).

Although this would break the "Toggle Library Read Mesg" menu entry" in xgap when used together with the -D option, but I think that's not something to worry about (I guess it could be changed to just toggle GAPInfo.CommandLineOptions.D).

lib/files.gi Outdated Show resolved Hide resolved
InfoRead1( "#I reading ", name, "\n" );
if GAPInfo.CommandLineOptions.D then
Print( "#I reading ", name, "\n" );
fi;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I briefly thought "hmm, why not introduce an InfoRead info class, and use that here, as Info(InfoRead, 1, "reading ", name"); but I suppose the answer for that is that at this point, we are still far away from loading lib/info.gi, so we can't really use Info yet. OK.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried introducing an InfoClass for this purpose, but as you say the infrastructure is not initialised when we'd want to use it.

One could (independently of this PR) try moving the info infrastructure as early as possible in startup.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is fine to leave this with a Print statement, but perhaps add a comment like

We cannot use Info yet, because info.gi has not yet been read

lib/files.gi Outdated Show resolved Hide resolved
@fingolfin
Copy link
Member

hecke, guava and xgap are on GitHub, so we can send pull requests. For atlasrep, we need to talk to @ThomasBreuer -- it seems indent logical to use Info there, but then an info class is needed. Perhaps we should define an InfoRead class after all, and set it based on the initial value of GAPInfo.CommandLineOptions.D (we still couldn't use it in the early library initialization; also, it should probably be reset in a PostRestore method)

This leaves gbnp, which "only" uses this in test/testall.g -- but note: This is not the TestFile in PackageInfo.g -- that's test/test-all.tst. Nothing seems to reference test/testall.g, so I think that file can just be removed; and we don't need to worry about breaking gbnp with this change (though we should still notify its maintainers about this)

@markuspf
Copy link
Member Author

markuspf commented Mar 4, 2018

Re-added InfoRead1 and InfoRead2 to obsoletes.gd to prevent packages from breaking should we decide to merge this PR.

@markuspf markuspf force-pushed the remove-info-read branch 2 times, most recently from ae9bbb5 to 9600511 Compare March 4, 2018 22:46
@ThomasBreuer
Copy link
Contributor

Concerning the use of InfoRead1 in the AtlasRep package,
I will replace this by a mechanism of its own inside the package.
From this point of view, there is no need to introduce a new Info class.

fingolfin
fingolfin previously approved these changes Mar 10, 2018
InfoRead1( "#I reading ", name, "\n" );
if GAPInfo.CommandLineOptions.D then
Print( "#I reading ", name, "\n" );
fi;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is fine to leave this with a Print statement, but perhaps add a comment like

We cannot use Info yet, because info.gi has not yet been read

lib/files.gd Outdated Show resolved Hide resolved
lib/files.gd Outdated Show resolved Hide resolved
@fingolfin
Copy link
Member

I anybody working on PRs for the affected packages, resp. emailing the GBNP maintainer?

@markuspf
Copy link
Member Author

markuspf commented Jun 6, 2018

I will email the GBNP people. I think it's best to then remove InfoRead as its not used anymore.

@fingolfin
Copy link
Member

@markuspf did you already do that? One of the authors, Arjeh Cohen, is retired; the other is Jan-Willem Knopper, and I am not sure how interested he is in maintaining GBNP he is. Perhaps we can convince them to let us maintain GBNP for them, and move it to GitHub etc. I know both authors, as well as GBNP, and could also talk to them.

@fingolfin
Copy link
Member

Just for reference, I emailed Arjeh and Jan Willem, and JW replied and promised to work on an update.

@fingolfin fingolfin dismissed their stale review June 11, 2018 20:19

While I approve in general, clearly we need to wait till packages are adjusted. Also, this PR is not mergeable right now.

@markuspf markuspf force-pushed the remove-info-read branch 2 times, most recently from 25fb1f3 to 47f9551 Compare June 18, 2018 14:09
@olexandr-konovalov
Copy link
Member

I cross-referenced this in #2804 under "PRs blocked by packages".

Copy link
Member

@fingolfin fingolfin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, is there any reason not to merge this? Sure, a few packages are broken if GAP is started w/o obsoletes -- but that's already now the case, and in a sense, the very reason we have an "obsoletes" mechanism, no?
Of course we should still keep an open issue tracking the status of this in various packages.

Thoughts? Of course it would be best to rebase this PR one more time, to make sure it's still working fine with latest master.

@markuspf
Copy link
Member Author

Rebased, waiting for AppVeyor to get its act together.

I agree this should then be merged.

lib/obsolete.gd Outdated
## InfoRead used to be used to print when a file is read using `Read()`
##
## These variables are still referred to by atlasrep, gbnp, guava, hecke
## and xgap.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@markuspf please update this comment - only atlasrep and gbnp remain (hecke and xgap were done today by @fingolfin).

Copy link
Member

@olexandr-konovalov olexandr-konovalov Nov 14, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@markuspf I see that the last sentence in this comment has been deleted completely - why? It should say These variables are still referred to by atlasrep, gbnp. @fingolfin spent some time on updating these comments recently, and made sure that they provide the actual list of packages that still use obsoletes.

@markuspf markuspf added release notes: to be added PRs introducing changes that should be (but have not yet been) mentioned in the release notes and removed do not merge PRs which are not yet ready to be merged (e.g. submitted for discussion, or test results) labels Nov 14, 2018
@markuspf markuspf merged commit 48047f3 into gap-system:master Nov 14, 2018
@fingolfin fingolfin added release notes: added PRs introducing changes that have since been mentioned in the release notes topic: library and removed release notes: to be added PRs introducing changes that should be (but have not yet been) mentioned in the release notes labels Apr 15, 2019
@olexandr-konovalov olexandr-konovalov added this to the GAP 4.11.0 milestone Feb 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release notes: added PRs introducing changes that have since been mentioned in the release notes topic: library
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants