Re: [Bug-apl] incompatible workspace 1.4 vs 1.5

[Fausto Saporito]

Thanks Jürgen.


2015-03-31 16:18 GMT+02:00 Juergen Sauermann <address@hidden>:
> Hi Fausto,
>
> the bug should be fixed in SVN 582. It was an old ⎕-function (⎕PT) that was
> removed in the meantime.
>
> /// Jürgen
>
>
> On 03/31/2015 11:22 AM, Fausto Saporito wrote:
>
> Hello Jürgen,
>
> thanks for the clarification. Yes I did as you wrote. I created the
> saved workspace with APL 1.4, then I dumped with that version and
> read-back in APL 1.5 without any problem.
>
> Attached, by the way, there's the problematic workspace.
>
> regards,
> Fausto
>
>
> 2015-03-30 18:19 GMT+02:00 Juergen Sauermann
> <address@hidden>:
>
> Hi Fausto,
>
> I would need the workspace in order to reproduce this.
>
> In GNU APL there are two commands (and two file formats) for saving
> workspaces: )SAVE and )DUMP.
> The )LOAD command understands both formats.
>
> The "classical" )SAVE command saves (serializes) the internal data
> structures of the interpreter into an .xml file.
> That normally works unless these data structures change. In other words,
> )LOAD is only expected to work with the
> same (SVN version of the) interpreter. Since the saved data structures do
> not change that often, sometimes )LOADing
> a workspace from a different interpreter version works. The text format of
> the .xml file makes it possible to fix
> minor incompatibilities.
>
> The newer )DUMP command uses a completely different approach. Instead of
> serializing the internal data structures
> of the interpreter, it writes APL code that, when executed, bring the
> interpreter into the same state that it had when the
> )DUMP command was issued. The file produced is also a text file hat can be
> edited with a normal text editor (read: vi)
> if needed if the )LOAD should fail. The only disadvantage of the )DUMP
> command is that the )SI stack is not saved
> (which is kind of impossible to reconstruct with APL code). An advantage is
> that it is fairly straightforward to read or
> write this format even with APL interpreters of other vendors. Therefore it
> is the preferred format of choice for archiving
> and documentation purposes.
>
> If you have )SAVEd an old workspace, then you can do this:
>
> 1. figure the SVN version used to )SAVE it. Unless  the SVN version is very
> old, it is written in the <Workspace> tag
> of the .xml file like this:
>
> <Workspace wsid="./x" year="2015" month="3" day="30"
>            hour="16" minute="8" second="8" timezone="7200"
>            saving_SVN="9479">
>
> 2. If you don't have a working GNU APL with that SVN revision then check it
> out and build it.
> Look at file buildtag.hh which should have the following line:
>
> #define ARCHIVE_SVN  9479
>
> 3. )LOAD the workspace file with that interpreter and )DUMP it. This creates
> an .apl text file
> that should be loadable by the latest GNU APL version. Note that up to
> recently there were
> bugs in the interpreter preventing this.
>
> /// Jürgen
>
>
> On 03/30/2015 10:37 AM, Fausto Saporito wrote:
>
> Hello,
>
> I found a strange bug loading a workspace previously saved with apl 1.4
>
> ==============================================================================
> Assertion failed: !Avec::is_quad(sym_name[0])
> in Function:      lookup_symbol
> in file:          SymbolTable.cc:83
>
> Call stack:
>
> ----------------------------------------
> -- Stack trace at SymbolTable.cc:83
> ----------------------------------------
> ========================================
>
> SI stack:
>
>
> ==============================================================================
> *** immediate_execution() caught other exception ***
>
> The workspace is ok, I tried again to load it with 1.4 and it works.
>
> Is this an expected incompatibility ?
>
> regards,
> Fausto
>
>
>
>