Hi Juergen, I see your point, and it makes sense. One caviet though, I don't know if this is the case or not but, I hope that when a )DUMP occurs the functions and variables are sorted. )DUMP makes more sense to use in a SCCS. If I change one function, I wouldn't want a different sort of the )DUMP file to make the SCCS think more changed. Does )DUMP sort its output?
Thanks! Blake On Sat, Sep 12, 2015 at 4:55 AM, Juergen Sauermann < [email protected]> wrote: > Hi Blake, > > yes, the discussion was to change *⎕TZ *on *)LOAD*. The general strategy > of GNU APL to save > as much information as possible because some information that looks like > not being used today > may become relevant at a later point in time. > > Removing *⎕TZ *would not help with source control system, because there > is another timestamp > in the workspace file that changes as well when the workspace is *)DUMP*ed > or *)SAV**E*d. Also, > the order of objects in a workspace file may change when a workspace is* > )LOAD*ed and then > *)SAVE*d again. > > Therefore a source control system would detect a change in the file even > if we would not store *⎕TZ*. > And I believe that is good because the state of the workspace has in fact > changed, even though the > variables or functions inside the workspace have not. > > /// Jürgen > > > > > On 09/10/2015 04:48 AM, Blake McBride wrote: > > Sorry. I now remember this is a topic we covered before and a change was > made so the )LOAD ignored ⎕TZ. That works. > > The thing that brought the problem up is because a garbage/unused ⎕TZ, > although not loaded, is saved. This creates problems with source code > control systems because ⎕TZ may keep changing artificially when two > developers are working on the same code but in different time zones. > > Bottom line - ⎕TZ should not be saved. > > Thanks. > > Blake > > > On Wed, Sep 9, 2015 at 9:10 PM, Blake McBride <[email protected]> wrote: > >> Greetings, >> >> ⎕TZ should not be saved with SAVE or DUMP. I should be able to count on >> ⎕TZ containing the locally applicable time zone - not the one the developer >> had! If, for some reason the developer wants to change ⎕TZ, it should be >> done explicitly in a function. A global value should never be saved. >> >> Blake >> >> > >
