A lack of inteligence is obvious and not just from the ChatBOT

What a waste of a day! Yesterday morning I was already to crack on with digging into the remaining problems on the upgrade to the latest versions of the web stack components. Only problem, when adding some limitations to the eclipse 'build path' to reduce it's error list eclipse froze. At first I just thought it was due to the rebuild of the error database, but then it actually crashed. Because I was doing something new I failed to ask myself "What has changed?" and had THAT been the 'context' in the next few hours, then perhaps Mistral would have pointed out the inteligent answer 'WHY' ... Instead we went through all the eclipse based checks including re-installing, and I now have the last two base builds along with the next beta versions installed, and all basically crash in the same way. It has not been all a waste of time as I now understand a lot better just how java is managed on Tumbleweed and the fact that eclipse carries it's own version of that anyway. Mistral has made no connection with the context I did include such as 'this was workinh 4 hours ago'. It had included making sure that 'system files are up to date', but in reality THAT was the key element I had missed. The change to Tumbleweed was made becuase I was overriding the system files in Leap15.6 to later versions simply to get my prefered suite of programs working, but it does have the risk that newer versions are uploaded in the background and there had been such an update yesterday. So the real question I now need to solve is "Which system library update has broken Java?"

While trying to fix a side issue in relation to an error the 2025-03 build of eclipse I added more to the history of updates changing the onboard java and trying to fix "Please ensure that WebKit with its GTK 3.x/4.x bindings is installed.". Had Mistral been more efficient it would have understood that eclipse was using it's own on board build of java so going through the various 'system' version of java was a red herring. That the crash relates to opening the PHP Projects window in PDT on eclipse might suggest that there is a problem with the WebKit system libraries but that is just speculation. The task today is to establish just which system library IS a problem. I have a long list of updates in the zypper history log, but I do not think that the automatic updates handled by discover get logged there. That we have two paths to manage 'automatic updates' in the latest openSUSE operating method is perhaps part of the problem. So NOW I need to understand if the java crash logs actually contain any information on just what is causing the problem.

I need to add to my own documentation on all the things I HAVE learnt over the last 24 hours, as well as updating the previous insights into my mistakes in debugging the PHP code. At least the ChatBOT history while full of a substantial amount of waffle, has the key element I need to syphon off. That PDT eclispe still only has an experimental version of PHP8.3 checking may be reason to look for an alternative to it anyway since the bugs I am trying to address is PHP8.4. This was just where I had got, and the 'experimental' tag may have delayed my realisation that it was not actually that which was the fundamental problem.