mdds 1.0.0

Share Button

A new version of mdds is out, and this time, we’ve decided to bump up the version to 1.0.0. As always, you can download it from the project’s main page.

Here is the highlight of this release.

First off, C++11 is now a hard requirement starting with this release. It’s been four years since the C++11 standard was finalized. It’s about time we made this a new baseline.

Secondly, we now have an official API documentation. It’s programatically generated from the source code documentation via Doxygen, Sphinx and Breathe. Huge thanks to the contributors of the aforementioned projects. You guys make publishing API documentation such a breathe (no pun intended).

This release has finally dropped mixed_type_matrix which has been deprecated for quite some time now in favor of multi_type_matrix.

The multi_type_vector data structure has received some performance optimization thanks to patches from William Bonnet.

Aside from that, there is one important bug fix in sorted_string_map, to fix false positives due to incorrect key matching.

API versioning

One thing I need to note with this release is the introduction of API versioning. Starting with this release, we’ll use API versions to flag any API-incompatible releases. Going forward, anytime we introduce an API-incompatible change, we’ll use the version of that release as the new API version. The API version will only contain major and minor components i.e. API versions can be 1.0, 1.2, 2.1 etc. but never 1.0.6, for instance. That also implies that we will never introduce API-incompatible changes in the micro releases.

The API version will be a part of the package name. For example, this release will have a package name of mdds-1.0 so that, when using tools like pkg-config to query for compiler/linker flags, you’ll need to query for mdds-1.0 instead of simply mdds. The package name will stay that way until we have another release with an API-incompatible change.

mdds 0.12.1

Share Button

I’m happy to announce that mdds 0.12.1 is now out. You can download it from the project’s README page.

There are primarily two major changes from the previous release of 0.12.0 as explained below.


One is that multi_type_vector now has a new static method advance_position to increment or decrement the logical position of a position_type object by an arbitrary distance.

static position_type advance_position(const position_type& pos, int steps);

The implementation of this method has been contributed by Markus Mohrhard.


Another major change in this release is with flat_segment_tree. Previously, flat_segment_tree had an unintentional constraint that the value_type must be of numeric type. In this release, that constraint has been officially lifted so that the user of this data structure can now store values of arbitrary types with this data structure. The credit goes to David Tardon for adding this nice improvement.

Other than that, there are no other changes from 0.12.0.

mdds on GitLab

Incidentally, the mdds project now has a new home at The new URL for the project page is now

If you need to include a project URL, be sure to use the new one.

Thank you, ladies and gentlemen!

Ixion 0.9.1 and its move to GitLab

Share Button

Today I have two announcements to make.

First, the version 0.9.1 of the Ixion library is now available. You can download the 0.9.1 source package from the project’s main page.

This is purely a maintenance release to address portability problems in the python bindings as well as other minor build and packaging issues. Many thanks to David Tardon for single-handedly addressing these issues.

Now, here is the second announcement. We are officially moving the project’s home from the previous Gitorious one to the GitLab’s, following the announcement of the acquisition of Gitorious by GitLab and the imminent shutdown of the Gitorious hosting site resulted from the acquisition. The new official URL for the Ixion project will be If you need to include an URL to the project, please use the new one from this point forward.

Thank you, ladies and gentlemen.

Orcus 0.7.1 is out

Share Button

After more than a year since the release of 0.7.0, I’m once again very happy to announce that the version 0.7.1 of the Orcus library is now available for download. You can download the package from the project’s download page.

This is a maintenance release. It primarily includes bug fixes and build fixes since the 0.7.0 release with no new features. That said, the most notable aspect of this release is that it is buildable with the version 0.9.0 of the Ixion library which was just released a week ago. So, if you are trying to package and distribute the newly-released Ixion library but are unable to do so because of Orcus not being buildable with it, you might be interested in this release.

The next major upgrade will be 0.9.0 whose development is on-going on the current master branch. Hopefully that release won’t be too far away.

Ixion 0.9.0 is out

Share Button

After a somewhat long hiatus, I’m very happy to announce that the version 0.9.0 of the Ixion library has just been released. You can download the source package from the project’s download page.

The highlight of this release is the new Python binding. Though still somewhat experimental, Ixion’s Python API is considered equally important to the C++ counterpart, and it is my intention to make both Python and C++ API my priority from this point on.

I have made the documentation for the Python API available here. This documentation is still rough around the edges, but hopefully it will improve over time.

mdds 0.12.0 is now out

Share Button

I’m happy to announce that mdds 0.12.0 is now out. You can download it from the project’s download page

The highlight of this release is mostly with the segment_tree data structure, where its value type previously only supported pointer types. Markus Mohrhard worked on removing that constraint from segment_tree so that you can now store values of arbitrary types just like you would expect from a template container.

Aside from that, there are some minor bug and build fixes. Users of the previous versions are encouraged to update to this version.

Last day

Share Button

Today is my last day with Collabora, and also my last day as a full-time engineer working on the LibreOffice (and formerly code base. It’s been 8 long years of adventure. Lots of things happened, and we’ve achieved great many things. I’m certainly very proud of having been a part of it.

From this point on, I’ll participate the project purely as a volunteer. I have not yet figured out what I want to do nor how much I can do, and figuring that out will probably be my first task as a newly volunteer contributor.

Thank you for being patient with me in the last 8 years. You guys have been great, and, even though I’ll have much less time to devote to LibreOffice going forward, I still hope to see you guys around from time to time!

Seattle LibreFest

Share Button

Today I’d like to talk about the LibreOffice Hackfest (LibreFest) that we did in Seattle on October 26th. This hackfest happens to be the very first hackfest event that I have participated outside of those held at the annual LibreOffice conferences, and the first one ever in the United States. Quite frankly, I didn’t really know what to expect going into this event. But despite that, I’m pleased to say that the event went quite well, with 32 participants joining the event in total, which was much more than what we had anticipated.

Hackfest took place inside the Communications Building at University of Washington, located in downtown Seattle. We borrowed a small-size class room to host the event, and later brought in extra chairs to accommodate everyone.


Four of us were there from the LibreOffice project – Robinson Tryon, Norbert Thiebaud, Bjoern Michaelsen and myself, though Bjoern had to leave early to catch his flight. Some of us came to the venue around 9 AM to set things up, and people started showing up around 9:30. Once the event officially started at 10 AM, we split into 2 tracks: the hackfest track where people work on building LibreOffice from the git repository & making changes, and the QA track where people test LibreOffice to report bugs. Robinson assisted those in the QA track, and the rest of us helped those in the hackfest track.

We spent much of the morning setting people up and getting their builds going, which was quite a challenge in and of itself. We eventually got everyone building one way or another, and the availability of a virtual machine environment was quite helpful for some of the participants. Others opted to use their own machines to build it on.


Some participants came late and joined in the afternoon session, while others only joined the morning session and had to leave in the afternoon. About half of us stayed there until late evening. Overall, it was great to see so much interest in our project, and pleased to see that many decided to stay until late to get things done.


Overall, we had a very successful hackfest event. I would like to thank Robinson for working hard to organize this hackfest, and Lee Fisher who was very helpful in organizing the event especially in handling matters on the Seattle side.

Two things I’ve learned from this event are: 1) access to a very fast virtual build environment can be quite helpful, and 2) Slackware is still very much alive! With regard to the first one, I feel that we should put more emphasis on having the participants use virtual machines to build LibreOffice for future hackfest events, and have mentors adequately trained to set it up for them. With regard to the popularity of Slackware, well, we need to encourage more participation from Slackware users and encourage them to share tips on building LibreOffice on Slackware in our wiki.

I hope those who came to the event learned something worthwhile (I certainly did), and I hope to see them again in the LibreOffice project!

OpenCL test documents for Calc

Share Button


Some of you have asked me previously whether or not we can share any test documents to demonstrate Calc’s new OpenCL-based formula engine. Thanks to AMD, we can now make available 3 test documents that showcase the performance of the new engine, and how it compares to Calc’s existing engine as well as Excel’s.

Download Platform Excel (64-bit) Calc (Windows, 32-bit)
Calc (Linux, 32-bit)
Calc (Linux, 64-bit)
Excel (32-bit)

These files are intentionally in Excel format so that they can be used both in Calc and Excel. They also contain VBA script to automate the execution of formula cell recalculation and measure the recalculation time with a single button click.

All you have to do is to open one of these files, click “Recalculate” and wait for it to finish. It should give you the number that represents the duration of the recalculation in milliseconds.

Note that the 64-bit version of Excel requires different VBA syntax for calling native function in DLL, which is why we have a separate set of documents just for that version. You should not use these documents unless you want to test them specifically in the 64-bit version of Excel. Use the other one for all the rest.

On Linux, you need to use a reasonably recent build from the master branch in order for the VBA macro to be able to call the native DLL function. If you decide to run them on Linux, make sure your build is recent enough to contain this commit.

Once again, huge thanks to AMD for allowing us to share these documents with everyone!

Slides for my talk at LibreOffice conference in Bern

Share Button

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


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.