Hi Hans-Peter,
the problem seems to be in the ravel of the value. Removing only the
symbol (= APL variable)
would leave the problem with the ravel in the .xml file. The proper way
to fix the .xml is
roughly:
1. remove the offending ... tag.
2. remove all references to the vid (value ID) of
Hi Jürgen,
a huge thank you.
My bigger WS causing some long load times with )DUMP / )LOAD and
stack traces with )SAVE / )LOAD can now be LOADed w/o problems.
Then )SAVE / )LOAD is OK too.
Best Regards
Hans-Peter
Am 07.03.25 um 16:20 schrieb Dr. Jürgen Sauermann:
Hi Hans-Peter,
I believe th
Hi again,
thanks, that helps. I will look into it.
Best Regards,
Jürgen
On 3/3/25 00:26, Hans-Peter Sorge via Bugs and suggestions for GNU APL
wrote:
Hi,
I nailed it down...
The attached WS*BUG-HUNTER.xml *is in bug-condition.
How to reproduce the bug (two sessions just for ease of analys
Hi Hans-Peter,
I believe that I have found the problem. Supposedly fixed in *SVN 1851.*
Unfortunately it does not fix the problem in existing workspaces, you
have to )SAVE them again. Sometimes )COPY might work to recover
precious variables.
The error occurs if a (nested) ravel with, say, *vid=x
Hi Jürgen,
the previous log was w/o *]LOG 39.
*
There is no apparent reason to fail at vid 274.
Just an excerpt from the xml:
and the log:
Value 0x3211b2b0 SET complete (0x400) at Value.cc:2231 now = 0x400 (changed)
read_Ravel() vid=270, XML line 4823 - YES (2 items)
Value 0x3
Hi,
I did not mention when this stack trace happens.
The WS is being *⍎')SAVE ',WSNAME,'.xml'* and *⍎')DUMP ',WSNAME,'.apl'*
directly one after an other.
That happens several times (a day...).
Then )LOAD *WSNAME.xml* stack traces.
The steps )LOAD *WSNAME.apl*, )SAVE *WSNAME.xml *and )LOAD *WS
