Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


Hi Kevin,

On Thu, 2011-10-20 at 02:00 -0400, Kevin Hunter wrote:
I'm hesitant to ask this because I cannot personally promise time toward 
LO (only on an as-can basis, which is dismally small ATM), but hey, you 
can easily so no.  :-)  You mention "really need[ing] a whiteboard" to 
elaborate properly.

        That really helps; having said that - I sat down with Eike & Kohei to
discuss this in Paris, and (I hope) managed to communicate the essence
of the idea.

  I submit that putting your thoughts together, perhaps in picture
form and available on the LO wiki, or put together as a small video
to Youtube, would be extremely useful to casual LO coders 
like myself.

        Sure - so first off, since I'm not actively hacking on calc (as of
now), this is really not my call. I tried to persuade Kohei & Eike of
the intrinsic improvements possible with the new design - if I'm lucky
then they agree that I'm not mad & might think about that. Of course - I
can create a video too, but ... ;-)

  As an individual volunteer without a face-to-face LO team 
member against whom to bounce ideas, I'd thoroughly love an 
actual-paid-engineer's thoughts on how best to proceed on this front.

        So - the very essence of what I'd like to see happen in calc, and the
foundation for it - is to remove the idea that a spreadsheet is a
collection of 'Cell' objects. This seems (to me) to be the foundation of
our scalability problems.

I'm personally motivated for Calc because in my science career, I really 
have to bend over backwards to make Calc work effectively for my needs 
where Excel works just plain better/faster/smaller, yet I 
philosophically have stuck myself with Free software.  To me, one of the 
biggest areas of weakness for LO, after the various random crashes 
(which are getting better!), is the memory bloat, and speed.  It's not 
features.

        Right. So the biggest piece (I see) that need tackling here before we
can take advantage of the new code is to start restricting the scope of
'ScBaseCell' pointers in LibreOffice calc. Last I looked (which was a
while ago) we use ScBaseCell pointers all around the place for things
like undo/redo, change tracking, copy/paste, document construction etc.

        If you wanted to re-start the effort to remove ScBaseCell's mpNote
pointer (which is very infrequently used) - that'd be a great place to
see some of the problems: ultimately I think we want to remove
ScBaseCell (and it's derivatives) entirely - leaving a (numeric) cell as
a single 'double' inside a fixed column-array of entries of the same
type.

        Of course, even without the grand vision coming to fruition, saving 4
(or 8) bytes per cell would be worthwhile, and improving the above areas
to handle storage of ranges of cell contents in a better encapsulated
way would be rather valuable - I think.

        But of course, you really want to talk to Eike / Kohei / Markus.

I'm happy to mess with Ixion (and indeed have poked at it some already)

        Right - IMHO, the real problem we have is not so much Ixion (which is
great), but massaging the existing code into a good shape to be ready
for it's heart transplant ;-) The above would be a great step in that
direction.

        Of course, if the calc developers don't object, I'm happy to create a
video of me making a fool of myself with a whiteboard too if you think
it helps :-)

        All the best,

                Michael.

-- 
michael.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.