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:

Status badges

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 mabshoff

  • Milestone set to sage-2.9

Looks like a duplicate of #527.

Cheers,

Michael

comment:2 Changed 14 years ago by was

  • Status changed from new to assigned

comment:3 Changed 13 years ago by mabshoff

  • Milestone changed from sage-2.9.1 to sage-2.9

comment:4 Changed 13 years ago by was

  • 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.