Slides for my talk at LibreOffice conference in Bern

I’d like to share the slides I used for my talk at LibreOffice Conference 2014 in Bern, Switzerland.

slides preview

During my talk, I hinted that the number of unit tests for Calc have dramatically increased during the 4.2 bug fix cycle alone. Since I did not have the opportunity to count the actual number of unit test cases to include in my slides, let me give you the numbers now.

ucalc filters subsequent-filters subsequent-export total
4.1 65 10 49 9 133
4.2 107 13 54 15 189
master 176 15 67 34 292

unit-test-count

The numbers represent the number of top level test functions in each test category. Since sometimes we add assertions to existing test case rather than adding a new function when testing a new bug fix, these numbers are somewhat conservative representation of how much test case we’ve accumulated for Calc. Even then, it is clear from this data set that the number has spiked since the branch-off of the 4.2 stable branch.

Now, I’ll be the first to admit that the 4.2 releases were quite rough in terms of Calc due to the huge refactoring done in the cell storage structure. That said, I’m quite confident that as long as we diligently add tests for the fixes we do, we can recover from this sooner rather than later, and eventually come out stronger than ever before.

8 thoughts on “Slides for my talk at LibreOffice conference in Bern”

  1. It is exciting to see the enormous Calc core changes done and those in progress. In my opinion, Calc is already very competitive with other spreadsheet software around.

    One limitation of Calc is the maximum of 1024 columns. I often crash this limit when juggling (import,changing,export…) around with big data matrices/tables, so I have to divert to other software (e.g. Gnumeric). What kind of Calc refactoring is concerned with increasing this limit?

    Thanks a lot for Calc! I use it everyday.

    1. Increasing the column limit itself is quite easy since all it takes is to change the internal column size from the current value to 1024. But simply increasing the column size would also increase the memory footprint even for empty documents, so we would need to do a bit more work to make the column storage a bit more efficient before we can increase the column size limit.

      1. Thanks, Kohei, for your reply. I am looking forward to this change.

        Do I understand correctly that the memory usage is the only problem. If so, wouldn’t it make sense to have an interim solution like in Gnumeric? There, 256 columns is the default, but one can increase the column limit to 16384 via “Edit”->”Sheet”->”Change size of table”. I assume that the Gnumeric guys have a similar memory usage problem so that they go for such a solution.
        Thanks again for great Calc.

        1. The only thing that’s holding us back is nothing technical i.e. we have a pretty good idea how we want to get it done. It’s just a matter of getting the effort funded.

          1. Interested in having this functionality. How much funding is required to have this done, and is two months enough time?

          2. Hi Jeff,

            I think 2 months is a reasonable time frame for this particular feature, to cover both the core change, UI change, and adjustment of affected feature implementation code that currently expect the column / row sizes to be static.

            I’m not in a position to directly sell consultancy to you, but if you are really interested, I can hook you up with someone who can get the ball rolling. Just let me know.

  2. I am wondering if the core calc developpers had a look at gnumeric’s core. It seems very solid. Would it be possible to use the core of gnumeric instead of re-inventing the wheel? Or just get some inspiration from it?

    1. > Would it be possible to use the core of gnumeric

      The short answer is no, both because of technical and licensing reasons.

Comments are closed.