How does Calc load file into memory and prepare the calculation to be presented

asked 2021-01-01 11:00:34 +0200

Archetype gravatar image

I hope to be guided to the most fundamental documentation about this topic. I may then be able to improve the question and get much more brief. The aim is to be able to improve (or even resolve here) six Bug reports, notably 86321 (charts not updating) yet several others. To do that, it's necessary to provide a method to reproduce, which (for some bugs) is almost (yet not quite) beyond the user. We generate spreadsheets using much copy and paste and find out later that cells are no longer calculating. I'm aware of about ten bug fixes for grouped formulae, triggers concerning autocalculate, hard recalculate and so forth. Also aware that more recent versions of Calc may be configured to not recalculate old files so as not to change the result seen by two different users with different Calc versions. Well, that's the context for the question.

Reason to ask. Investigating Calc 5, 6 and 7 versions it's evident that LO 7 incorporates quite a few fixes, yet as newbie 02 (b) observes, that seems to be masking something in the foundations that's not yet adressed. I have about ten files to investigate with different symptoms.

For example, one will load, as usual viewing the last sheet from the last Save. It opens with half the formula cells showing zero. The formats check out as correct, there are other cells with absolutely identical formulae showing the true result. The content.xml reveals two different conclusions about precisely the same formula. Recalculation (to update the cells in limbo) can be triggered by toggling a cell "early" in the sequence, one that has "data validity" criteria (1 or 0; supplying an IF choice on every sheet which simply fetches raw data or analysed data). Or, one can also trigger the calculation by toggling once Calc>Tools>Options>Libreoffice Calc>Calculate>Iterations to on then off. The file and content.xml actually contain no circular references yet can be stimulated to show the result. In this particular case, Hard Recalculate also works.

However, some bugs resist these methods, notably when charts are involved. Most odd (about the example) is that twin (identical) sheets not yet viewed are recalculated, yet only for cells that are outside the application window view area. After recalculate, clicking onto those sheet tabs, cells in the viewing area (often columns A to W) are still at zeroes. It seems recalculation depends on the sheet having already been viewed before (at least once, even if nothing is done on that sheet). Yet, surprise. Sliding the horizontal scroll bar reveals . . . . columns X, Y, Z, AA, AB etcetera have been done. Very odd. Not because they're in the view area - rather because they're out of it.

If the user doesn't notice, cells out of view are being processed differently than those in the application window. If the file is editted and saved several times, the "mix" of calculated or not-yet is cemented into the ods content.xml. When ... (plus)

edit retag flag offensive close merge delete


heyheyheyyyy!!! @Archetype: somebody thinking and investigating! like that!
probably you are overtaxing the scope and focus of this ask site and would better post in 'bugs', but you already know about and it's more a question than a bug report ... ok for me,
there was a very promising discussion started in with - imho - potential to explain 'all', as well recalculation issues as sporadic appearance as reproducibility issues as different behaviour on different systems,
but then somebody 'kicked out' the developers, i'd really like them to be aware of such possibilities ...
... continued ...

newbie-02 gravatar imagenewbie-02 ( 2021-02-26 01:48:49 +0200 )edit

... continued ...
I have the feeling that 'recalc issues' occur frequently with me, I use a 4k screen, if any property of a cell depends on the graphics equipment and is sometimes classified as 'update-necessary' and sometimes e.g. with other resolution as 'not-necessary' and then somehow 'loses the connection', but just only with certain systems ... maybe it's enough to draw the 'border' for the distinction between 'inside' and 'outside' a bit further ... ??? ??? ??? It would be a 'tennis' or 'John McEnroe problem' ... 'in'? or 'out'!
pls. keep going ...

newbie-02 gravatar imagenewbie-02 ( 2021-02-26 01:52:51 +0200 )edit

Good metaphor I think. Like a sports hall with lines for badminton, basketball, handball and five-a-side football all laid out on top of each other according to their rules. Here's an example of a programmer deliberately limiting an in/out rule.

The LibreOffice conference 2016 politely (and kindly) suggested that Software Interpreter would make user bug reporting difficult or nearly impossible. For example, in the tdf bug link, a step by step is given, one bug at file>open but another bug at the last step. To see it (that ghost bug) requires SI "on" and a certain view zoom (or 100% on a 4K monitor). Someone unable to reproduce (SI "off") had the crucial information but went off in a huff.

LO 7 Calc seems to have Software Interpreter always involved (without the option). It's understood that's to be kind to most ...(plus)

Archetype gravatar imageArchetype ( 2021-02-26 09:36:47 +0200 )edit

By the way, I'm also keeping an open mind about the need for User workarounds (now and in future). Limiting (programming) software attention using matrices/pages in RAM is often (but not always) about performance and economy. I may find a simple way for Users to to gain/force at least "whole sheet" attention when speed isn't an issue. A named expression or data range technique that can be stretched out to a cell in a far out column and row for example. That's a conjecture (for now).

Archetype gravatar imageArchetype ( 2021-02-26 09:53:40 +0200 )edit