bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Juergen Sauermann
Subject: Re: [Bug-apl] incompatible workspace 1.4 vs 1.5
Date: Tue, 31 Mar 2015 16:18:49 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]