Bug Hunting Session
Bug 50916 - Allow more than 1024 columns in calc
Summary: Allow more than 1024 columns in calc
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: high enhancement
Assignee: Not Assigned
URL:
Whiteboard: target:5.2.0 target:5.3.0 target:5.4...
Keywords:
: 78255 117494 118788 119755 120914 128299 (view as bug list)
Depends on:
Blocks: Calc-Enhancements
  Show dependency treegraph
 
Reported: 2012-06-09 09:30 UTC by Gerry
Modified: 2019-11-27 12:12 UTC (History)
58 users (show)

See Also:
Crash report or crash signature:


Attachments
20190115 (744.94 KB, text/plain)
2019-01-23 05:35 UTC, adventyas
Details
A spreadsheet with 10 000 empty sheets (140.24 KB, application/vnd.oasis.opendocument.spreadsheet)
2019-04-27 20:05 UTC, Mike Kaganski
Details
Spreadsheet with 3201 columns for testing with previous LO versions (deleted)
2019-07-22 07:15 UTC, Bartosz
Details
LO spreadsheet with 3201 columns for testing with previous LO versions (26.55 KB, application/vnd.oasis.opendocument.spreadsheet)
2019-07-22 13:20 UTC, Bartosz
Details
Screenshot from Excel, while .xls file is opened. The 256 colums limitation is visible (74.55 KB, image/png)
2019-07-24 09:02 UTC, Bartosz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gerry 2012-06-09 09:30:46 UTC
Currently Calc is limited to 1024 columns.

This limitation causes problems for certain use cases:
* import of .xlsx files with more than 1024 columns (Excel 2007 allows 16384 columns)
* generally calculations with big matrices/tables

Please enable Calc to handle up to 16384 columns.
Comment 1 Robinson Tryon (qubit) 2012-07-15 13:24:56 UTC
See discussion on bug 43911 for more information.

The tl;dr is: "increasing the column limit will increase the the memory needed for every sheet extremelly" unless we "change the column container to a dynamic container," a change that "might take much more time" than a month.
Comment 2 Steffen Moeller 2012-11-02 09:32:35 UTC
I had a colleague of mine send her data twice, in different formats, assuming a file corruption. This was because LibreOffice Calc does not even warn when it encounters a file with more columns than it can deal with. This is a bit embarassing, not?

For your internal priorisation, please be aware that today, with many research lab are equipped with machines to perform high throughput analyses, files with >1500 columns (which typically host attributes in statistics) are no longer exceptional. Excel once was sucking badly with 256 columns, but they got that one fixed for a reason.

Together with this functionality of thousands of columns there will be new interfaces developing alongside for the filtering of such. Time will bring it. Just now, please fix this behaviour. I offer 100 Euros from my very private pocket for this feature. The missing notice of losing data I tend to see as a bug.

Concerning the "dynamic container" comment below I suggest to think about sparse formats. There is tons of sparse data out there in scientific data and to have a regular desktop tool prepared to handle that efficiently would be exciting.
Comment 3 Julien Nabet 2013-02-08 22:51:33 UTC
Kohei/Markus/Eike: I suppose there must be some reasons we still got this limit but could you tell/remind them? I think I must have read about this on IRC or dev mailing list but don't remember.
Comment 4 Robinson Tryon (qubit) 2013-02-08 23:26:55 UTC
(In reply to comment #3)
> Kohei/Markus/Eike: I suppose there must be some reasons we still got this
> limit but could you tell/remind them? I think I must have read about this on
> IRC or dev mailing list but don't remember.

Markus' comments on bug 43911 provide more details:

---
Markus Mohrhard 2012-01-05 14:21:03 UTC

No. We won't increase the column limit soon. First we would need to rework all internal cell datastructures like I did for sheets in 3.5. We still use fixed size containers for columns. That means that increasing the column limit will increase the the memory needed for every sheet extremelly. The column limit of 1024 is a design decision by us.

If you are really in need for LibO with a bigger column limit you can easily build one yourself and I tell you the line you need to change to increase the limit.
---

---
Markus Mohrhard 2012-01-05 15:30:04 UTC 
> So, our hopes is to convince developers to increase the "Max Column" limit, or
> that they switch to a dynamic size column container approach in order to use
> necessary memory.

This is not an easy switch. This is more like half a heart transplant and therefore is nothing that will be done just from today to tomorrow. I needed around one month for the change for the sheet change and I think that changing the column container might take much more time.

> Is it the final decision that the distributed official LibO version will have a
> "Max Column" limit of 1024 in the near future releases? And people like me will
> have to modify the "Max Column" limit and recompile/recreate a special LibO
> version for our needs?

It is not a final decision but I doubt that we will increase the column limit if we did not change the column container to a dynamic container. In my dev builds a empty sheet already needs around 150 KB. For the change we need someone who has enough time to work on it.

Feel free to step in here and help to improve the situation. You'll get as much help as possible by us and we will assist as much as we can.
---
Comment 5 Phil 2013-03-11 19:01:01 UTC
@Steffen Moeller
@Gerry

Consider http://www.r-project.org/
Comment 6 Gerry 2013-03-11 19:23:11 UTC
@Phil: Thanks for the nice suggestion. However, spreadsheets, databases and statistical software like R, Stata, ... have very different goals. Having said this, there is a clear need and usage for spreadsheets handling more than 1024 columns. People use it and I use it, too. 

Given the dynamic idea of cells in spreadsheets (dependencies on other cells, formulas in cells, fill-out features), they are very good at data processing and data generation. These are features which are not as good to handle in statistical software. Data analyis is, of course.

Independently from this, when receiving .xlsx files with more than 1024 columns, LibreOffice cannot be used. Gnumeric can serve as an alternative then.
Comment 7 hemmelig 2013-11-17 09:38:30 UTC
The question is then how to kick start/fundraise money to make the column container to a dynamic container? What will be needed in funds? 

The 1024 column limit is the simplest way to shoot down any suggestion for using Libreoffice in any organization. It MUST be fixed, and all I can offer is €.
Comment 8 retired 2013-11-17 12:52:22 UTC
The last column showing for me is column "AMJ". I don't see numbers so not sure what that is, guess you can figure that out by creating a crazy formula with the number of alphabet letters. Maybe the result is 1024 - not sure.

If that is not sufficient for your usage and would like to see this bug fixed and want to put in cash for that specific enhancement please create an account on http://freedomsponsors.org and setup a bounty. I'm aware of several LO bugs that got fixed that way.
Comment 9 Kalin KOZHUHAROV 2014-03-03 04:20:16 UTC
I recently hit that bug, i.e. RFE and came here...

I usually avoid using Calc for large datasets (CSV/Perl/gnuplot), but sometimes I use/make tools that output in columns instead of rows (e.g. few spectra in 4K columns). Since all machines around here have at least 16GB RAM, I don't think increased memory footprint is a problem for me. I also use Gentoo, so recompiling LibreOffice is the norm.

Has anyone identified what needs to be patched to increase max cols?
---
Markus Mohrhard 2012-01-05 14:21:03 UTC

If you are really in need for LibO with a bigger column limit you can easily build one yourself and I tell you the line you need to change to increase the limit.
---

I will try if I have some better pointer at where to look in the source (file/line, etc.) since I don't want to dive headfirst in the huge codebase.

Once a patch is available, distros (Gentoo at least) can easily choose to decide whether it cares for power (ab)users or not.
Comment 10 Gerry 2014-04-20 09:19:20 UTC
How likely will it be that the limitation of Calc to 1024 columns will be increased in the next LO release(s), 4.3 or 4.4? I have seen that lots of performance-related parts of Calc have been rewritten. Are these changes also related to this enhancement request?
Comment 11 Markus Mohrhard 2014-04-20 14:20:55 UTC
(In reply to comment #10)
> How likely will it be that the limitation of Calc to 1024 columns will be
> increased in the next LO release(s), 4.3 or 4.4? I have seen that lots of
> performance-related parts of Calc have been rewritten. Are these changes
> also related to this enhancement request?

No. Unless someone steps up and starts working on it the chances are not too big that it will be implemented for the next releases. This bug requires another not so small refactoring of calc core and therefore requires someone to invest the time in working on it.

If you want to see this enhancement request implemented the best way forward is to start working on it. You will get any help you need from the community but right now I think there is no Calc developer who has the time to implement it.
Comment 12 bfoman (inactive) 2014-06-04 22:49:51 UTC
*** Bug 78255 has been marked as a duplicate of this bug. ***
Comment 13 Miguel 2014-09-27 14:22:16 UTC
I suggest an importance increase.

I have also suggest adding a new tag - msoffice or compatibility. The goal of this tags is to group all bugs that, in my view, critically affect Libreoffice - compatibility with MS Office files.

I run a company that has, from day 1, used Libreoffice (and Openoffice before) exclusively. But as much as we care for this project and what it means, it is vital that the community understands that a lack of compatibility with what the majority of users (and companies) use it a hindrance in the adoption of Libreoffice. And a headache to those who use it but have to interact with people who use MS Office.
Comment 14 Gerry 2014-09-27 14:28:09 UTC
@Miguel: Please see the comments to Kohei's blog: http://kohei.us/2014/09/09/slides-for-my-talk-at-libreoffice-conference-in-bern/

I quote Kohei: "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."

I also wished to use >1024 columns in Calc (even 2048 would already help), but I understand the problem of funding this improvement, as it requires some deeper changes in Calc.
Comment 15 Miguel 2014-09-27 14:38:20 UTC
@Gerry - something like https://www.bountysource.com/ ?

Perhaps it would be a good idea to add a link there then.

I remember a (still open) Evolution Mail bug where, within the comments alone, people were pledging to add the ability to change email fonts used.


If the technical effort has been calculated, then the hard part is done and a funding process can be added?
Comment 16 Gerry 2014-09-27 14:43:26 UTC
@Miguel: I think for this, you need to ask the Calc developers directly: Kohei, Eike or Markus, for example. I think they are CCed in this bug.
Comment 17 Alex Thurgood 2015-01-03 17:39:13 UTC Comment hidden (no-value)
Comment 18 -- removed -- 2015-02-19 10:08:31 UTC
Just hit the limit myself and I'd like to see this implemented soon. How can I contribute to bounties, fundraising, etc.? Is there anything set up yet?
Comment 19 Eike Rathke 2015-02-19 11:09:55 UTC
Throwing money at it alone won't help. Dedicated developer resources to come up with a viable concept to change column allocation to dynamic containers that at the same time would not make sheet operations suffer from performance bottlenecks AND IMPLEMENT it would help.
Comment 20 Rob 2015-03-22 07:39:53 UTC
I used freedomsponsors.org for a small bugfix in Thunderbird recently and had a very quick result, I had added a realistic reward.  This feature sounds like a biggie!   Another I have seen is www.bountysource.com.  I haven't got clue if doing these is considered good, bad, or annoying but it does target what you want.
Comment 21 mszeliga 2015-04-15 05:30:14 UTC Comment hidden (me-too)
Comment 22 Gerry 2015-04-20 08:15:55 UTC
If 16384 columns in Calc require quite some refactoring, would this be also the case if the number of columns would be increased to 2048? 

I think 2048 columns would already solve many problems, but - of course - in the long run >= 16384 are required for Excel compatability.

Thanks!
Comment 23 pier andre 2015-04-24 07:50:39 UTC Comment hidden (no-value)
Comment 24 Dennis Francis 2015-04-27 21:08:50 UTC
Hi devs,

If no one is yet working on this, I would like to work on this. My motivation is to learn the Calc code-base in depth from the experts. Right now I will be able to spend one full day per week, but may increase depending on my work priorities. 
I am aware that this change will take quite some time at this rate, but I still want to work on it.
Comment 25 Robinson Tryon (qubit) 2015-04-29 22:05:41 UTC
(In reply to Dennis Francis (ldcs.co.in) from comment #24)
> If no one is yet working on this, I would like to work on this. My
> motivation is to learn the Calc code-base in depth from the experts.

Hi Dennis,
It's great to hear that you're going to join our merry band of LibreOffice developers! Please start by building LibreOffice from source and completing your first Easy Hack:
https://wiki.documentfoundation.org/Development/Easy_Hacks

Good luck!
--R
Comment 26 Markus Mohrhard 2015-04-29 22:20:11 UTC
(In reply to Dennis Francis (ldcs.co.in) from comment #24)
> Hi devs,
> 
> If no one is yet working on this, I would like to work on this. My
> motivation is to learn the Calc code-base in depth from the experts. Right
> now I will be able to spend one full day per week, but may increase
> depending on my work priorities. 
> I am aware that this change will take quite some time at this rate, but I
> still want to work on it.

Hey,

great to see you looking into that.

So the approach is to first understand the problem with increasing the number of columns in the current design.
For that you should read a bit in the table*.[ch]xx files and check where we use the maximum column number.

ONe of the biggest problems is replacing the static array of the number of columns with something dynamic. Finding a good data structure for that will be crucial for finding a design that does not suck performance wise.

If you need more information feel free to ask here or on the dev IRC channel. Kohei (kohei), Eike (erack) and I (moggi) -- (IRC nicks) -- can answer your questions if you need some input.
Comment 27 Dennis Francis 2015-04-30 03:07:20 UTC
From table.hxx, and column.[hc]xx, it looks like each column is set as a fixed sized mdds mtv of MAXROWCOUNT.

http://opengrok.libreoffice.org/xref/core/sc/source/core/data/column.cxx#83

hence every single column in the table costs us memory space proportional to MAXROWCOUNT irrespective of the number of non empty data cells in that column.

Can't we set the initial number of elements of mtv's like maCells, maBroadcasters etc.. to a smaller value say INITROWCOUNT=100 in the ScColumn constructor and call mtv resize() only when we get a request to set a new data at a logical location (say 120) which is beyond the current capacity of the mtv (100) ?

If calling mtv resize(old_size + additional_space_needed) for every new data addition is suboptimal, can we do resize(old_size + k*additional_space_needed) where k is some heuristic measure of "expected growth" in space for that column from the saved history of previous calls to resize() ?
Comment 28 Markus Mohrhard 2015-04-30 03:10:12 UTC
(In reply to Dennis Francis (ldcs.co.in) from comment #27)
> From table.hxx, and column.[hc]xx, it looks like each column is set as a
> fixed sized mdds mtv of MAXROWCOUNT.
> 
> http://opengrok.libreoffice.org/xref/core/sc/source/core/data/column.cxx#83
> 
> hence every single column in the table costs us memory space proportional to
> MAXROWCOUNT irrespective of the number of non empty data cells in that
> column.
> 
> Can't we set the initial number of elements of mtv's like maCells,
> maBroadcasters etc.. to a smaller value say INITROWCOUNT=100 in the ScColumn
> constructor and call mtv resize() only when we get a request to set a new
> data at a logical location (say 120) which is beyond the current capacity of
> the mtv (100) ?
> 
> If calling mtv resize(old_size + additional_space_needed) for every new data
> addition is suboptimal, can we do resize(old_size +
> k*additional_space_needed) where k is some heuristic measure of "expected
> growth" in space for that column from the saved history of previous calls to
> resize() ?

mdds is not the problem as mdds internally does not more or less what you mentioned. Actually increasing the row limit is not a problem.

The problem is all the places where we iterate through each column.
Comment 29 Jouni Järvinen 2015-08-03 18:31:34 UTC Comment hidden (no-value)
Comment 30 Gerry 2015-08-03 18:45:57 UTC
(In reply to Jouni Järvinen from comment #29)
> Start from something. If it has to be a §for§ loop, then make it a §for§
> loop. Improve when you get better ideas. Something as slow as §for§ is
> better than nothing at all. Someone like you should know it.

The developer team has a clear understanding of the problems and potential solutions for the 1024 columns limit. So, I don't understand your point. The problem is that the solution entails a refactoring of (old, pre-LibreOffice) code. Lots of work.

@Dennis Francis: Did you have time to look into the code related to the refactoring towards >1024 columns?
Comment 31 ERIC 2015-09-13 15:04:39 UTC Comment hidden (no-value)
Comment 32 Eike Rathke 2015-09-14 11:40:25 UTC
We know. And please don't mess around with the Version field.
Comment 33 Yogesh Desai 2016-01-18 13:01:55 UTC Comment hidden (me-too)
Comment 34 Dennis Francis 2016-01-20 08:10:23 UTC
Hi All

Me and my colleagues(Arul, Yogesh, Kumar and Sahas) are working on this bug
as per the discussion we had with LO devs at http://nabble.documentfoundation.org/tdf-50916-Calc-Dynamic-column-container-td4162663.html

The first of the many incremental patches to come is at https://gerrit.libreoffice.org/21620

--
Thanks.

www.ldcs.co.in
team@ldcs.co.in
Comment 35 Commit Notification 2016-02-04 19:41:19 UTC
Dennis Francis committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f14d271d31e75de09821cf1766c7ab2a9c6e0461

Patch#1 : Dynamic column container in the pursuit of tdf#50916

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 36 Commit Notification 2016-02-10 23:10:10 UTC
Dennis Francis committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bc20c6d0f397c0c1aef6ef7d6f750c2f81af8db6

Refactor ScMarkData for tdf#50916

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 37 Commit Notification 2016-03-19 15:16:30 UTC
Dennis Francis committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=187669de1096ebbf4347ec1126eb6b693f6c5a96

tdf#50916 : Unit tests for the refactored ScMarkData...

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 38 Dennis Francis 2016-08-04 04:55:33 UTC
Submitted a patch for refactoring ScAttrArray at https://gerrit.libreoffice.org/27828
Comment 39 Nasi Chassoulas 2016-10-12 06:44:29 UTC
Hi all,

After having reached the 1024 column limit myself, I am glad to see that a patch has been released. I use LibreOffice for business across many devices on both Linux and Windows systems. Is this patch implemented in the Windows 5.2 release or Linux only?

Thanks for all the hard work!
Comment 40 Dennis Francis 2016-10-12 14:37:49 UTC
(In reply to Nasi Chassoulas from comment #39)
> Hi all,
> 
> After having reached the 1024 column limit myself, I am glad to see that a
> patch has been released. I use LibreOffice for business across many devices
> on both Linux and Windows systems. Is this patch implemented in the Windows
> 5.2 release or Linux only?

We have not yet increased the column count from 1024. There is still a lot of work to do before we can increase that and there are many more patches to come in yet. We will keep this page updated on the progress. Thanks.
Comment 41 Commit Notification 2016-11-10 15:16:14 UTC
Dennis Francis committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=06d3294502413a231e5c5265609862c7f67a2f2b

Refactor ScAttrArray for tdf#50916

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 42 Commit Notification 2016-11-30 16:04:22 UTC
Dennis Francis committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ad2bc869bfe2d34bde7d42e10593db1c5ffccc2a

tdf#50916 : Refactor table1.cxx wherever there is column access

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 43 Commit Notification 2017-01-12 21:04:43 UTC
Bartosz Kosiorek committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=5e223be2102a171c857be8db1327f23faea0ef78

tdf#50916 Use aCol.size() instead of MAXCOL to increase max number of column

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 44 Commit Notification 2017-01-15 19:57:28 UTC
Bartosz Kosiorek committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=4f6d6d905ffe4e9962ea858d415273df4f5829fd

tdf#50916 Make sure that we don't access aCol out of range

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 45 Commit Notification 2017-01-19 21:29:02 UTC
Bartosz Kosiorek committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e15fd1371567fd4b78dab37d843562ff676c52b8

tdf#50916 Allow ScTable work on dynamic ScColContainer

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 46 Dennis Francis 2017-02-06 12:25:40 UTC
Hello All

I have compiled a writeup at https://niocs.github.io/LOBook/misc/16kcols.html to help new contributors to get started on working with this feature addition project.
I will try to keep it updated as more patches are added.

Thanks,
Dennis
Comment 47 Commit Notification 2017-02-08 20:07:29 UTC
Bartosz Kosiorek committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b78c6d8efd9531243e62a388bffc3f071d9a56eb

tdf#50916 Introduce new column validation function

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 48 Commit Notification 2017-02-08 23:13:34 UTC
Bartosz Kosiorek committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0e0fef10002b46965edad02b3f460a502d9f6595

tdf#50916 Allow proper updating, deleting and inserting tabs

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 49 Commit Notification 2017-02-24 23:17:00 UTC
Bartosz Kosiorek committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a1b1ed766d1110acf843b807d554f9375963234c

tdf#50916 Allow dynamically increase number of columns according to needs

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 50 Commit Notification 2017-03-07 22:00:12 UTC
Bartosz Kosiorek committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e1e2defb2cd9b572747b964e5ec97d289029af8c

tdf#50916 Simplify and refactor source code

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 51 Gerry 2017-04-18 07:42:28 UTC
Thank you very much for all the commits with regard to this enhancement request for Calc to handle more than 1024 columns. 

Will this feature be ready for the upcoming LibreOffice 5.4 release?
Comment 52 Bartosz 2017-04-24 12:18:02 UTC
Hi Gerry.
Unfortunately this feature (Allow more than 1024 columns in calc) will not be ready in 5.4.0 release.
Comment 53 Shunesburg69 2017-05-19 19:11:50 UTC
Why ?
If it's ready, you could add this feature in the 5.4 release.
Comment 54 Commit Notification 2017-06-10 05:10:35 UTC
Dennis Francis committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a680f6988482f13489d6c802b6078d43564ae934

tdf#50916 : More refactoring in table1.cxx

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 55 Commit Notification 2017-06-12 15:57:17 UTC
Dennis Francis committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=637f7b50e4e8fbb56b4c552e28058bbdfcf85d5a

tdf#50916 : Refactor table1.cxx ScTable::GetNext*() methods

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 56 Xisco Faulí 2017-07-14 13:58:37 UTC
Polite ping: is this bug fixed? if so, could you please close it as RESOLVED FIXED
Comment 57 Eike Rathke 2017-07-14 14:55:00 UTC
It's not fixed, it's ongoing longer term work.
Comment 58 Shunesburg69 2018-03-03 15:02:28 UTC
When this limit will be changed ?
The issue is old (2012) and a patch is apparently here.
Is it fix ? And if it's not why ? The patch is not complete ?
Comment 59 Eike Rathke 2018-03-06 16:44:15 UTC
It is not fixed and it is not just a matter of some patch(es) being applied. Bumping this bug doesn't help anyone. You will read in some future release notes that 16k columns are supported when it is ready.
Comment 60 Commit Notification 2018-03-15 17:21:56 UTC
Bartosz Kosiorek committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=45d5c18a9a643590b18e7cc48ab80076a31b75b3

tdf#50916 Refactor of the table7.cxx to allow dynamic column size

It will be available in 6.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 61 Gerry 2018-05-06 08:09:34 UTC
Hi Bartosz, Dennis and Eike,

with regard to ">1024 columns in Calc" I would like to ask you whether there is a chance that it will be ready for LibreOffice 6.1? Or whether there is still much more refactoring to be done? Thanks.
Comment 62 Eike Rathke 2018-05-07 09:29:12 UTC
As long as this hasn't its status set to RESOLVED FIXED it isn't ready.
Comment 63 Xavier Van Wijmeersch 2018-05-08 08:48:27 UTC
*** Bug 117494 has been marked as a duplicate of this bug. ***
Comment 64 raal 2018-07-16 20:23:51 UTC
*** Bug 118788 has been marked as a duplicate of this bug. ***
Comment 65 Andrzej 2018-07-16 20:34:50 UTC
The problem returned and what do we do with it?
Comment 66 Michael Meeks 2018-08-22 09:47:16 UTC
Noel also did a chunk of work on this - his commits (and fixes for various regressions) contain the 'dyncolcontainer' string.
Comment 67 V Stuart Foote 2018-09-08 05:59:36 UTC
*** Bug 119755 has been marked as a duplicate of this bug. ***
Comment 68 m.a.riosv 2018-10-25 20:43:05 UTC
*** Bug 120914 has been marked as a duplicate of this bug. ***
Comment 69 Bartosz 2018-10-26 08:06:36 UTC
Some useful information for developers which would like to continue working on this topic:

The very basic classes involved are : ScDocument - which represents the document, ScTable - which represents a sheet, ScColumn - represents a single column.
With below patches Dennis made a dynamic column container class called ScColContainer which represents the dynamic column container and this container gets instantiated in ScTable class as member aCol. Previously ScTable was having a static array of ScColumn's of size 1024.

The list of Dennis patches which created dynamic column container and further code refactoring is below in chronological order :

1. https://gerrit.libreoffice.org/21620  [ This is where the dynamic container got created but still uses fixed number of columns to initialize the datastructure. We can change this only after making changes to all places where columns are accessed like aCol[nColIdx].someMethod() or similar because in all these places it is assumed that there are always MAXCOL columns are available]

2. https://gerrit.libreoffice.org/22163 [ Refactors ScMarkData (to hold user selection) and supporting classes to work efficiently with dynamic column container ]

3. https://gerrit.libreoffice.org/27828 [ Addresses some issues with ScAttrArray class(stores the attributes like background color, number format etc..) when dynamic column container is used. This is discussed in the above mentioned mailing list thread ]

4. https://gerrit.libreoffice.org/31125 [ Changes all places in table1.cxx where there is naive column access to work correctly with the new dynamic column container We next need to complete the refactoring of table1.cxx and other files where column access is made which assumes there are MAXCOL columns.]
Comment 70 Noel Grandin 2019-01-22 09:21:49 UTC
At this point, most of the technical groundwork for this has been laid.

See discussion here:

   https://gerrit.libreoffice.org/#/c/44802/

Now some tricky bureaucratic/technical hard work needs to happen around modifying the ODF file format to handle the extra columns and figuring out backwards/forwards compatibility issues
Comment 71 adventyas 2019-01-23 05:35:13 UTC
Created attachment 148535 [details]
20190115

error when open file
Comment 72 Emily Mabrey 2019-02-21 07:00:40 UTC
Is making a truly dynamic sheet even needed? Excel only allows a static number of columns and a static number of rows and it seems like a massive undertaking for such a seemingly niche application. Excel 2016/ M365 supports 1,048,576 rows or 16,384 columns as that static limit.

Looking over the comments I can see that there may have already been an effort to produce a dynamically sized sheet. Has anyone done testing to see if the dynamic sheet comes with any performance penalty? If so it might be wise to use a large static value under most cases and allow the dynamic sizing as a niche option with an opt-in configuration. That would prevent constant allocation/frees around when adding and removing rows and cols if that does turn out to be a performance problem.

I would look into the performance consequences myself, but I am brand-new to this project and wholly unfamiliar with the code base and procedures for performance monitoring of this project. If anyone could point me to some guiding documentations I would be willing to make an effort at fulfilling my own request.
Comment 73 Michael Meeks 2019-02-21 13:01:02 UTC
Hi Emily; the dynamic sizing is mostly about compatibility while not blowing up our memory requirements. When it comes to performance - a dynamic size seems rather unlikely to be significant compared with many more significant algorithmic complexity issues =) but of course, if you can measure something there its always interesting to improve. There are a number of known performance issues that we should fix first I think - such as the O(log(log(N))) interpolation search we should re-introduce to mdds etc.
Comment 74 Shunesburg69 2019-03-27 01:06:23 UTC
The fix is it already in progress?
Comment 75 Commit Notification 2019-04-05 11:45:50 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/7282014e362a1529a36c88eb308df8ed359c2cfa%5E%21

tdf#50916 Makes numbers of columns dynamic.

It will be available in 6.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 76 Commit Notification 2019-04-06 14:45:00 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/6db38ca2cc9cafb353dd2ca2f4a617d5fa3eb51d%5E%21

ofz#14093 bunch of new ofz detected crashes related to tdf#50916

It will be available in 6.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 77 Commit Notification 2019-04-15 06:01:57 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/3c364f5d574515a257ba0bb84e199275fbea944f%5E%21

Related: tdf#50916 create valid empty ScHorizontalCellIterator when...

It will be available in 6.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 78 Commit Notification 2019-04-25 18:10:35 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/e056abae09796f2b3806e94e62cae7f0d262d4d5%5E%21

tdf#50916: XLS: make sure to set default widths to all columns

It will be available in 6.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 79 Mike Kaganski 2019-04-27 20:05:50 UTC
Created attachment 151048 [details]
A spreadsheet with 10 000 empty sheets

FYI: LO with attached file takes 4 170 000 KB RAM with Version: 6.2.3.2 (x64)
Build ID: aecc05fe267cc68dde00352a451aa867b3b546ac
CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: ru-RU (ru_RU); UI-Language: en-US
Calc: CL

Today's master (dbgutil buiild) takes 1 600 000 KB.
Comment 80 Gerry 2019-06-09 08:14:22 UTC
Hi, there were a number of commits in the past months addressing this bug/enhancement. 
How likely is it that Calc gets dynamic numbers of columns for LO 6.3? Thanks!
Comment 81 Mike Kaganski 2019-06-09 08:49:59 UTC
(In reply to Gerry from comment #80)

Since commit mentioned in comment 75, the number of columns in Calc *is* dynamic - and that's version 6.3. But that is inly the change of internal allocation mechanics; the maximum number of columns that can be dynamically allocated still remains 1024, so from end user's PoV, nothing changed.

Now what's remaining is iiuc (1) change one constant from 1k to 16k (a simple part), and (2) decide how to keep compatible with older implementations file-format-wise (including whole-row/whole-column references).
Comment 82 Noel Grandin 2019-06-09 10:06:36 UTC
See here for the concerns that still need to be addressed before we can raise the limit from 1024 columsn to something bigger:
https://lists.freedesktop.org/archives/libreoffice/2019-January/081909.html
Comment 83 tr00don 2019-06-22 15:28:14 UTC Comment hidden (me-too)
Comment 84 Lars Gärtner 2019-07-12 07:53:51 UTC Comment hidden (me-too)
Comment 85 Bartosz 2019-07-22 07:15:01 UTC
Created attachment 152897 [details]
Spreadsheet with 3201 columns for testing with previous LO versions

I have tested following document with 3201 columns on LibreOffice 5.4 and 6.3.
It's working as expected. Only 1024 columns are imported.

Could you please test this document with other version of LibreOffice, to confirm any regression?
Comment 86 Bartosz 2019-07-22 13:20:45 UTC
Created attachment 152939 [details]
LO spreadsheet with 3201 columns for testing with previous LO versions
Comment 87 Gerry 2019-07-22 20:24:41 UTC
As suggested by Bartosz, I opened the file attached to comment 86 in LibreOffice 6.1. 

It gives (as expected) the error message: "The data could not be loaded completely because the maximum number of columns per sheet was exceeded". Then Calc opens the file, but only shows (as expected) columns up to 1024.


Version: 6.1.6.3
Build ID: 1:6.1.6-0ubuntu0.18.10.3
CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: gtk3; 
Locale: en-GB (de_DE.UTF-8); Calc: group threaded
Comment 88 Bartosz 2019-07-24 09:02:59 UTC
Created attachment 152963 [details]
Screenshot from Excel, while .xls file is opened. The 256 colums limitation is visible

If excel is opening .xls file (which support only 256 columns), there is no possible to edit columns above 256 (see attached screenshot). To be able to edit columns above 256, document needs to be saved in another file format (like .xlsx).
Comment 89 Gerry 2019-07-24 18:03:04 UTC
Another test with the attachement to comment 86: 
I opened the file in the document viewer of UBPorts (Ubuntu Touch). The document viewer is based on LibreOffice 5.x Kit (is it version 5.4?).

The document loads fine. There is no error message. However, the application crashes when I scroll to column 1024. Actually, it crashes when I am in column 1019, because then 1024 would be visible, which seems to cause the crash.

System:
UBports with document viewer (LibreOfficeKit 5.x)
Comment 90 Gerry 2019-07-24 18:23:23 UTC
Test of the attachment to comment 86 with Gnumeric 1.12.43. Gnumeric loads the spreadsheet nicely up to column 3201. No problem.
Comment 91 titaniumtv download 2019-07-25 12:12:18 UTC Comment hidden (spam)
Comment 92 watkec 2019-09-13 04:49:38 UTC Comment hidden (no-value)
Comment 93 Michael Meeks 2019-09-13 07:27:20 UTC
> It is now more than 7 years later and a solution still has not been implemented.

This can be squarely blamed on all those who havn't implemented the feature: there are globe full of those slackers ;-)

Then again; Noel has been doing some good work here - we're even fixing the regressions from the re-factoring required. I would be amused to see how WPS scales with any significant volume of data. So there is progress, but it is not done yet. I imagine there are prolly some other regressions from the re-factoring to make this possible, do go give the latest LibreOffice 6.3.n or nightly snapshots a good hammering in calc in this area and see if you can find some.

Thanks.
Comment 94 tr00don 2019-10-07 22:55:23 UTC Comment hidden (me-too)
Comment 95 kevinpr 2019-10-15 09:26:03 UTC Comment hidden (no-value)
Comment 96 Noel Grandin 2019-10-15 09:28:56 UTC
As one of the libreoffice developers working on this feature, I would just like to say that every time I see another complaint about something I do in my space time with my own resources, means that I decide to work on something else for a while.
Comment 97 kevinpr 2019-10-15 09:36:59 UTC
(In reply to Noel Grandin from comment #96)
> As one of the libreoffice developers working on this feature, I would just
> like to say that every time I see another complaint about something I do in
> my space time with my own resources, means that I decide to work on
> something else for a while.

Well, it's not that I'm arguing against you or other devs, it's more for "Libreoffice people that assign bugs and importance of things to improve" that maybe it's better to finish this instead of improving other things that works

If I knew C++ as yours, I could help, but I not good at that at this level

Thanks for your work at free time in Libreoffice! I hope you don't take it the wrong way
Comment 98 Michael Meeks 2019-10-15 12:08:47 UTC
Hi Kevin,

> Well, it's not that I'm arguing against you or other devs, it's more for
> "Libreoffice people that assign bugs and importance of things to improve"
> that maybe it's better to finish this instead of improving other things
> that works

    Just to translate - there is no-one doing global prioritization for what our volunteers work on; so complaining in bugs does nothing good - except put off those who are interested in working on this; one of whom is Noel.

> If I knew C++ as yours, I could help, but I not good at that at this level

     All people start like this, if you want to get involved - this particular change is a matter of replacing 'MAXCOL' with pDoc->MaxCol() at a very large number of places and testing the result. It is something that a beginner can do (in many cases) as an easy-hack. If you'd like to get involved - I'd be happy to help you.

> Thanks for your work at free time in Libreoffice! I hope you don't take
> it the wrong way

     Thanks for saying thank-you ! =) much appreciated.
Comment 99 kevinpr 2019-10-16 19:12:17 UTC
(In reply to Michael Meeks from comment #98)

> 
> > If I knew C++ as yours, I could help, but I not good at that at this level
> 
>      All people start like this, if you want to get involved - this
> particular change is a matter of replacing 'MAXCOL' with pDoc->MaxCol() at a
> very large number of places and testing the result. It is something that a
> beginner can do (in many cases) as an easy-hack. If you'd like to get
> involved - I'd be happy to help you.

Well.. I downloaded source code and prepared a folder, but.. I don't know how to start, see, etc... For me is big project at "first see". Any help I will appreciate it much :)
Comment 100 Michael Meeks 2019-10-17 21:12:07 UTC
Hi Kevin,

> Well.. I downloaded source code and prepared a folder, but.. I don't know how
> to start, see, etc... For me is big project at "first see". Any help I will
> appreciate it much :)

Great attitude ! so - I just pushed another small sample patch like this:

https://gerrit.libreoffice.org/81000 sc: rowcol: tdf#50916

And remembered the commit id - which should help link it into this bug as/when it goes through gerrit.

In a nutshell, for each use of 'MAXCOL' we need to classify whether this is an 'easy' one - ie. we have a well defined use-case, and an in-range column (it seems we use MAXCOL+1 as an out-of-bound magic/invalid) state. And for all the easy ones we need to just replace the macro MAXCOL with pDoc->MaxCol() - for some value of pDoc [ we need a reliable pointer and/or reference to the document we are using that reference for ].

Hopefully that makes sense. I would submit these in small chunks (as above) to gerrit - and let our CI system compile and test the result; you could possibly even edit inside gerrit for this one - but best to get familiar with doing that on the real code.

Please do CC me or Noel for reviews,

Thanks ! =)
Comment 101 Commit Notification 2019-10-19 08:09:27 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/2b660f0bd0867bdd89f611e7ee60362b11be1874

sc: rowcol: tdf#50916 chip away at some more call sites.

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 102 Commit Notification 2019-10-19 19:13:40 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/2571a11aeb0bdca20242caa5c96f0a5b3ea5db90

sc: rowcol: tdf#50916 convert ucalc test, and docfunc.

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 103 Commit Notification 2019-10-21 11:58:35 UTC
Aron Budea committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f900c896697386fcc82b51f3f9ab3c8a84fdbb67

sc: rowcol: tdf#50916 convert ui/undo

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 104 Commit Notification 2019-10-21 16:14:34 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/c219bcdc1ef4972f67e994ce153e21c144e636e9

sc: rowcol: tdf#50916 convert viewfunc

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 105 Gabor Kelemen 2019-10-21 16:16:59 UTC
*** Bug 128299 has been marked as a duplicate of this bug. ***
Comment 106 Commit Notification 2019-10-21 17:33:33 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/ad3e00237f48c52dbd2833f21f5e2f5acfdd4167

sc: rowcol: tdf#50916 convert tabview

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 107 Commit Notification 2019-10-22 06:25:41 UTC
Aron Budea committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/4cee86a0ee1c2f2b35c59b13e708d9a6941d2730

sc: rowcol: tdf#50916 convert some in ui

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 108 Commit Notification 2019-10-22 16:14:08 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/25732d7f211ce51fcecbb15ce6d9c551c2715b6e

sc: rowcol: tdf#50916 convert output

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 109 Commit Notification 2019-10-22 16:14:39 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/bef71336399f1dc678eee16b5d6d7bf26a17f491

sc: rowcol: tdf#50916 convert gridwin

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 110 Commit Notification 2019-10-22 18:46:31 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/5d3b6e482e72451bd508b3a4db9f182ab4da388d

sc: rowcol: tdf#50916 convert cellsh

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 111 Commit Notification 2019-10-23 09:06:18 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/009e7a54f40ebacd9dd4a394504c277789699801

sc: rowcol: tdf#50916 convert unoobj

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 112 Commit Notification 2019-10-23 12:06:59 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/48ab1b2fbb3496cef478db11539ccd08b527656d

sc: rowcol: tdf#50916 convert miscdlgs

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 113 Commit Notification 2019-10-23 14:36:19 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/6055814a98a764117cd95adf2bbab91fa34456c2

sc: rowcol: tdf#50916 convert app

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 114 Commit Notification 2019-10-23 14:38:08 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/dbf02b8b6c34313affda860fc6c5bbc64839b2d9

sc: rowcol: tdf#50916 convert docshell

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 115 Oliver Brinzing 2019-10-23 17:40:40 UTC
with:

Version: 6.4.0.0.alpha1+ (x64)
Build ID: 1efe1f82fabb3b8566c0beca2ba5df21c54fa6d5
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded

- select cell AMJ1
- insert Columns after
-> crash

no crash with:

Version: 6.3.2.2 (x64)
Build-ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc:
Comment 116 Aron Budea 2019-10-23 19:51:28 UTC
(In reply to Oliver Brinzing from comment #115)
> - select cell AMJ1
> - insert Columns after
> -> crash
I can reproduce this, and it manifests as an assertion failure in a debug build:

soffice.bin: /.../libreoffice/sc/source/ui/docshell/docfunc.cxx:1706: bool ScDocFunc::InsertCells(const ScRange&, const ScMarkData*, InsCellCmd, bool, bool, bool): Assertion `!"can't move"' failed.

This is with a (debug) build from 1efe1f82fabb3b8566c0beca2ba5df21c54fa6d5.
What I can say is that there's no crash with the current latest linux bibisect (non-debug) build: de4839e66d3d195315729b95cc144cdab96b6e74. Considering most of the changes are from the past few days, this doesn't tell a lot either way.
Comment 117 Aron Budea 2019-10-23 20:36:48 UTC
(In reply to Aron Budea from comment #116)
> soffice.bin: /.../libreoffice/sc/source/ui/docshell/docfunc.cxx:1706: bool
> ScDocFunc::InsertCells(const ScRange&, const ScMarkData*, InsCellCmd, bool,
> bool, bool): Assertion `!"can't move"' failed.
So, this isn't a new thing, and could be checked with the old lo-linux-dbgutil-daily bibisect repos, and goes back to 5.2 (the assertion check was added then). Opened a new bug report on it: bug 128359.
Comment 118 Commit Notification 2019-10-24 09:28:32 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/6a45c9755293f0969b4c2081d6d602bac9986d16

sc: rowcol: tdf#50916 convert documen*

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 119 Commit Notification 2019-10-24 11:30:01 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/78f63c2b1cd4e185f11486a7b2bdf7fd89ef1b03

sc: rowcol: tdf#50916 convert column*

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 120 Commit Notification 2019-10-25 10:43:56 UTC
Aron Budea committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1bca91f086be08c41e51f5f7cc7616ce8c5cb799

sc: rowcol: tdf#50916 convert filter/excel for the most part

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 121 Alex Jacob 2019-10-28 09:54:01 UTC Comment hidden (spam)
Comment 122 Commit Notification 2019-10-29 13:23:44 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/0ef5c47547bec6319b853326603f3b807407fe78

sc: rowcol: tdf#50916 convert core/tool

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 123 Commit Notification 2019-10-31 06:13:37 UTC
Aron Budea committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/dc4a4c392944afac3d8cb02d0036b653b251efba

sc: rowcol: tdf#50916 convert filter/*

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 124 Commit Notification 2019-11-04 14:16:51 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/218db5faae9255247c6fc30ebe37f82764397161

cid#1455213 sc: rowcol: tdf#50916 check pDoc for MaxCol() or MAXCOL

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 125 Commit Notification 2019-11-11 08:39:48 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f7ccd0f546c7362ef9a19ce515ac1404866a8c82

sc: rowcol: tdf#50916 convert data/attrarray

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 126 Commit Notification 2019-11-11 16:25:44 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/a8a064d11c05feed83f05b0ce8209f7054afd804

sc: rowcol: tdf#50916 convert mark data structures

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 127 Commit Notification 2019-11-12 14:29:36 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f8641f0106ee45731449966f798957a8dc09cfb6

sc: rowcol: tdf#50916 convert core/data/table*

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 128 Commit Notification 2019-11-25 10:58:00 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/916746a5155a1a17225e85d2c30a1c2322aac589

sc: rowcol: tdf#50916 convert segmenttree

It will be available in 6.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 129 Commit Notification 2019-11-27 12:12:22 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1c8b8e97eb6127e430c1dc0fc3578cec94371fd7

sc: rowcol: tdf#50916 add UI to turn jumbo sheets on

It will be available in 6.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.