Opened 14 years ago
Closed 13 years ago
#407 closed defect (duplicate)
improve how gap workspace caching works
Reported by: | was | Owned by: | was |
---|---|---|---|
Priority: | major | Milestone: | sage-2.8.12 |
Component: | packages: standard | Keywords: | |
Cc: | Merged in: | ||
Authors: | Reviewers: | ||
Report Upstream: | Work issues: | ||
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
On 7/26/07, Dan Christensen <jdc@uwo.ca> wrote: > > "David Joyner" <wdjoyner@gmail.com> writes: > > > Could you please try gap_reset_workspace() and then restart SAGE > > and see if the examples start? > > That fixed it! Thanks. Not sure what I did. The problem occurred on > two different systems, which my home directory is mirrored between. > If it happens again, I'll report any additional info I can think of. Very interesting. When you install the gap database, SAGE runs gap_reset_workspace() to update the cached workspace on the machine on which the database is installed. Because a single home directory could be used by multiple machines, there are potentially multiple gap workspace cache files, and for you only one was updated. This is an annoying design (due to me), since multiple users of a single SAGE install will all have to type gap_reset_workspace() to get the new gap libraries (when one installs, e.g., the small group database). I should change the implementation so when installing database_gap (or anything else that might invalidate the stored gap workspace, or more precisely make it not optimal), then *all* gap workspace cache files from all users of that SAGE install become invalid. They would then be regenerated (which takes only a few seconds) the next time any user starts GAP from a SAGE session. I could do this by assigning a sequence number, e.g., in a file like local/lib/gap-sequence-number, which is incremented any time gap is updated in some way. Then I could make the cached workspace (or another file with a similar name next to the gap workspace file) also store this sequence number (the cached workspaces are in ~/.sage/gap/). Then whenever a gap interpreter is first started in interface/gap.py, this sequence number is checked, and if it doesn't match, then the gap workspace is regenerated. This should completely eliminate all future gap_reset_workspace synchronization errors. I'll wait to see if anybody thinks the above idea is stupid, and if not, I'll implement it (which shouldn't take long). -- William
Change History (4)
comment:1 Changed 14 years ago by
- Milestone set to sage-2.9
comment:2 Changed 14 years ago by
- Status changed from new to assigned
comment:3 Changed 13 years ago by
- Milestone changed from sage-2.9.1 to sage-2.9
comment:4 Changed 13 years ago by
- Milestone changed from sage-2.9 to sage-2.8.12
- Resolution set to duplicate
- Status changed from assigned to closed
Note: See
TracTickets for help on using
tickets.
Looks like a duplicate of #527.
Cheers,
Michael