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 <Ravel vid=...> ... </Ravel> tag.
2. remove all references to the vid (value ID) of the ravel in the .xml file (search for *vid=*) 3. If a variable removed this way is on the )SI stack then remove all (!) )SI stack entries.

BTW I am missing any printouts like

*    read_Value() vid=XXX*

in your post. They should tell you the offending *vid* that is currently being processed.

Best Regards,
Jürgen


On 3/1/25 23:21, Hans-Peter Sorge wrote:
Hi,

I would like eliminate some content from the )Saved WS file to locate the offending content,
as it still takes a couple of minutes to )LOAD the )DUMPed WS.

How can I relate the trace to the xml? Thoughts further down.

     ]log 24
   Logging facility 24: commands )LOAD, )SAVE, )IN, and )OUT is now ON
     )load DEBUG_trc.xml
LOADING DEBUG_trc.xml from file '/home/joy/workspaces/DEBUG_trc.xml' ...
Value 0x20008e20 SET complete (0x400) at Value.cc:2231 now = 0x400 (changed) Value 0x20008b60 SET complete (0x400) at Value.cc:2231 now = 0x400 (changed) Value 0x20008940 SET complete (0x400) at Value.cc:2231 now = 0x400 (changed)
...... a total of 190 records
Value 0x2007d160 SET complete (0x400) at Value.cc:*/2231/*now = 0x400 (changed) Value 0x2007d340 SET complete (0x400) at Value.cc:2231 now = 0x400 (changed) Value 0x2007d520 SET complete (0x400) at Value.cc:2231 now = 0x400 (changed)

==============================================================================
Assertion failed: 0 && "Cell::init_other() called on base class"
in Function:      init_other
in file:          Cell.hh:67

C/C++ call stack:
*** useless apl.lines (no CXXFLAGS=-rdynamic -gdwarf-2)

----------------------------------------
-- Stack trace at Assert.cc:75
----------------------------------------
0x7f6a6ac1030b __libc_start_main
0x7f6a6ac10248
0x403f10   main
0x5e654b    Workspace::immediate_execution(bool)
0x461af5     Command::process_line()
0x461cd1      Command::process_line(UCS_string&, std::ostream*)
0x4626af       Command::do_APL_command(std::ostream&, UCS_string&)
0x46f7cd        Command::cmd_LOAD(std::ostream&, UCS_string_vector&, UCS_string&, bool) 0x5ea203         Workspace::load_WS(std::ostream&, LibRef, UCS_string const&, UCS_string&, bool)
0x415762          XML_Loading_Archive::read_Workspace(bool)
0x4172d1           XML_Loading_Archive::read_Ravel()
0x41cd82            Value::set_default(Value const&, char const*)
0x456ef6             Cell::init_type(Cell const&, Value&, char const*)
0x5de69b              Value::clone(char const*) const
0x42a5d0               Value::next_ravel_Cell(Cell const&)
0x457deb
0x4241c9                 do_Assert(char const*, char const*, char const*, int)
========================================
========================================

SI stack:


==============================================================================
*** immediate_execution() caught other exception ***



My thoughts:

Would it be sufficient enough to remove  the <Symbol ... </Symbol> block to reduce the WS? Or could it be already the offending variable anyhow because of */2231/* in the trace?

     <Symbol  name="not_2"  stack-size="1">
       <Variable  vid="*/2220/*"/>
     </Symbol>
256 Entries - OK:
   <Ravel  vid="*/2220/*"  cells="⁶1958⁶1897⁶2002⁶1994⁶2009⁶2011⁶1815⁶2013⁶2000
⁶1898⁶2010⁶2003⁶2023⁶2022⁶2008⁶1999⁶2027⁶2026⁶2004⁶2028⁶2024⁶2005
⁶2033⁶2034⁶2001⁶2012⁶2007⁶2025⁶2040⁶2035⁶2039⁶2041⁶2038⁶2047⁶2036
⁶2032⁶2045⁶2044⁶2043⁶2031⁶2042⁶2006⁶2037⁶2060⁶2029⁶2063⁶2053⁶2049
⁶2030⁶2051⁶2054⁶2058⁶2050⁶2048⁶2052⁶2062⁶2059⁶2066⁶2068⁶2055⁶2067
⁶2046⁶2057⁶2071⁶2074⁶2072⁶2064⁶2069⁶2083⁶2079⁶2070⁶2080⁶2082⁶2087
⁶2061⁶2088⁶2073⁶2086⁶2081⁶2089⁶2085⁶2090⁶2091⁶2065⁶2077⁶2056⁶2095
⁶2094⁶2102⁶2092⁶2075⁶2101⁶2096⁶2107⁶2108⁶2076⁶2103⁶2084⁶2106⁶2097
⁶2105⁶2100⁶2104⁶2109⁶2110⁶2111⁶2098⁶2122⁶2093⁶2124⁶2118⁶2078⁶2116
⁶2117⁶2099⁶2125⁶2120⁶2119⁶2123⁶2121⁶2129⁶2126⁶2132⁶2112⁶2138⁶2128
⁶2115⁶2136⁶2142⁶2143⁶2127⁶2139⁶2141⁶2137⁶2130⁶2135⁶2134⁶2133⁶2131
⁶2147⁶2113⁶2145⁶2148⁶2155⁶2156⁶2146⁶2158⁶2154⁶2144⁶2163⁶2164⁶2140
⁶2166⁶2114⁶2153⁶2161⁶2160⁶2149⁶2165⁶2157⁶2162⁶2167⁶2168⁶2178⁶2175
⁶2169⁶2152⁶2151⁶2174⁶2179⁶2177⁶2159⁶2181⁶2185⁶2170⁶2184⁶2180⁶2176
⁶2187⁶2191⁶2194⁶2150⁶2196⁶2182⁶2189⁶2192⁶2195⁶2199⁶2190⁶2197⁶2201
⁶2206⁶2207⁶2203⁶2200⁶2210⁶2211⁶2188⁶2198⁶2209⁶2208⁶2193⁶2213⁶2183
⁶2212⁶2202⁶2218⁶2217⁶2223⁶2216⁶2214⁶2205⁶2186⁶2224⁶2204⁶2221⁶2226
⁶2228⁶2219⁶2234⁶2230⁶2227⁶2225⁶2222⁶2232⁶2229⁶2238⁶2237⁶2233⁶*/2231/*
⁶2215⁶2245⁶2239⁶2236⁶2247⁶2242⁶2235⁶2246⁶2250⁶2240⁶2241⁶2249⁶2251
⁶2244⁶2253⁶2257⁶2254⁶2255⁶2263⁶2264⁶2248⁶2259⁶2261⁶2260⁶2252⁶2270"/>
<Value  flg="0x400"  vid="*/2220/*"  parent="-1"  rk="2"  sh-0="16"  
sh-1="16"/>  ...  256 correct
   <Value  flg="0x400"  vid="2229"  parent="2220"  rk="1"  sh-0="15"/>
   <Value  flg="0x400"  vid="2230"  parent="2220"  rk="1"  sh-0="15"/>
   <Value  flg="0x400"  vid="*/2231/*"  parent="*/2220/*"  rk="1"  sh-0="15"/>
   <Value  flg="0x400"  vid="2232"  parent="2220"  rk="1"  sh-0="15"/>
   <Value  flg="0x400"  vid="2233"  parent="2220"  rk="1"  sh-0="11"/>
   <Ravel  vid="2229"  cells="²012345679abcdef⁰"/>
   <Ravel  vid="2230"  cells="²012345689abcdef⁰"/>
   <Ravel  vid="*/2231/*"  cells="²0123456789bcdef⁰"/>
   <Ravel  vid="2232"  cells="²012456789abcdef⁰"/>
   <Ravel  vid="2233"  cells="²012346789af⁰"/>

Best Regards
Hans-Peter


Reply via email to