Hi Jürgen,
it was mtx .. not xml.
*)copy BUGGY_1853* *mtx**
*The )copy of the variable still fails with 1853M.
However,
it can be fixed by )LOADing / )COPYing the WS and )SAVEing it..
*)load BUGGY_CLOSE.xml*
NOTE: this workspaces was )SAVEd with syntax version 1.7.1
but is now )LOADed wi
Hi Jürgen,
1853M is by far better in )loading a )dumped WS.
big←100?100
)save WS / )load WS time is barely measurable.
)dump WS / )load WS takes less than 10 seconds.
10 x more:
Having *big ← 1000⍴big*
*
*)DUMPing takes about 37 seconds.
*
** ⎕TS*
2025 3 8 21 16 37 859
* )DUMP BIG
Hi Hans-Peter,
thanks. See *SVN 1853* for a faster version. Frequent expands of a
big matrix was apparently not such a good idea.
Best Regards,
Jürgen
On 3/6/25 00:56, Hans-Peter Sorge wrote:
Hi Jürgen,
I tested
*big←10?10*
)save WS / )load WS.xml happens in almost no time.
)dump
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
