This week:
I continue working on Rewriting the logger messages with the new DSL grammar:

    1)EditUIObject
        It wasn't finished last week but this week it's finished with the new garmmar and can log select and write actions.

    2)Uno Commands
        some small changes to be understandable with the new grammar
        ** a missing part here that we want to ignore logging message if the parameters of the UNO command are empty as they will be logged twice which is not good.

    3)Dialog Commands
        **Sometimes we have empty dialog names I don't know now how to handle this.
   
    4)Special Commands of (writer and Calc)
        In this part we know that we use EventDescription Object to transfere what we need to the logger for example in the GOTO command we put this parameters:
            aDescription.aAction = "GOTO";
            aDescription.aParameters = {{"PAGE", aPage}};
            aDescription.aID = "writer_edit";
            aDescription.aKeyWord = "SwEditWinUIObject";
            aDescription.aParent = "MainWindow";
            UITestLogger::getInstance().logEvent(aDescription);

So in the logger we will use these parameter to construct the log statement that we need and ignore having same construction as old logger which made it not friendly in reading.

    5)Also Type Command handled alone wherever you type.

I create 2 new functions that will help in getting data from the EventDescription Object and Use it to log all available actions of Calc and writer.
Now if we want to log new action in any application after sending its parameters to logger we will need to receive these parameters and use it to make sentences that match our grammar.

You can find the patch that make all of this here.

The next step is to finish some missing parts in the Uno Commands and fix problem of Dialog Commands and add new feature helpful statements in the ObjectUI commands.Then I will start write the compiler that will make code generation.


           

This week I start implementation of the grammar of the new DSL language:

I add this project files in core/uitest/ui_logger_dsl/
 
The new DSL language consist of some commands with diffrent types:
   
    1) UNOCommand
        finished the commands that don't take parameters

    2) StarterCommand
        done
   
    3) UIObjectCommand
        this command logs all these objects actions:

•             ButtonUIObject
•             CheckBoxUIObject
•             EditUIObject
•             RadioButtonUIObject
•             ListBoxUIObject
•             ComboBoxUIObject
•             SpinUIObject
•             SpinFieldUIObject
•             TabControlUIObject

        all of these types are done

    4) DialogCommand
        done 

    5) SpecialCommand
        this command consist of any other action that related to special application   like actions for writer as (set zoom - GOTO page)
        I will work on this next week.


You can see example of expected logged file otput here : uitest/ui_logger_dsl/example.ul
as .ul mean uiLogger

also this example with the old logger will be like:


This has same output as you can find in the example.ul here


Also TextX works with metamodels in python so you can run this grammer to check that it's right by this command :

        >>python uitest/ui_logger_dsl/dsl_core.py
 
to see how the example file is handled and the command is understood well.

Also this image show the structure of the current grammar structure:



the patch that shows all these work can be found here

your comments is most welcomed.

This week

I continue working on the DSL grammar I added:

    1)UNOCommand

        I addded the parameters option.

    2) SpecialCommand

        I added the writer and calc commands as a start and I think it will be enough for now to start with this 2 applications and in the future we can add other applications and also we can add more features for the logger in this application easily.

This is the new statements for logging writer events:
    Type on writer {"TEXT": "s"}
    Select from Pos 5 to Pos 7
    Set Zoom to be 100
    GOTO page number 2

This is the new statements for logging calc events:
    Type on current cell {"TEXT": "a"}
    Switch to sheet number 2
    Select from calc {"CELL": "A1"}
    Lanuch AutoFilter from Col 2 and Row 1

I added all of this here: https://gerrit.libreoffice.org/#/c/73241/

Also Start to update the log statements for this UI objects:
(note that: this patch can't be merged now it should wait for the compiler to be done first)
I have finished :

    a) ButtonUIObject
    b) CheckBoxUIObject
    c) TabControlUIObject
    d) RadioButtonUIObject
    e) ComboBoxUIObject
    f) SpinFieldUIObject
    g) ListBoxUIObject

Also part of the EditUIObject is finished but still have something missing.

you can find this changes in this commit : https://gerrit.libreoffice.org/#/c/73743/

The LibreOffice Conference is the annual gathering of the community, our end-users, and everyone interested in free office software. Every year, it takes place in a different country and is supported by members of the LibreOffice commercial ecosystem. In 2018, the conference was organized by the young and dynamic Albanian community at Oficina in Tirana, from Wednesday, September 26, to Friday, September 28, the eight anniversary of the LibreOffice project. Here’s a quick video recap – read on for more details…

On Monday, September 24, there were the internal meetings of TDF’s Board of Directors and Membership Committee, followed on Tuesday, September 25, by a meeting of the TDF Team in the morning and by the traditional community meeting in the afternoon. This is a unique opportunity for representatives of native language projects and community members to meet face-to-face and discuss localization and other topics.

Over 150 people from across the globe attended the conference, including LibreOffice developers, community volunteers and Google Summer of Code students. For several people, it was their first LibreOffice Conference and therefore the first time they had met other community members in-person.

Conference

The conference started officially on the morning of Wednesday, September 26, with an address by Erion Veliaj, Mayor of Tirana, followed by the “State of the Project” – a talk which outlined some project statistics since the Rome conference – and a Q&A session with TDF’s Board of Directors. The morning track ended with sponsors’ keynotes.

In total, there were around 80 presentations, covering all aspects of LibreOffice, from development to QA, from localization to design, from documentation to marketing, and to broader subjects such as building communities and making the LibreOffice project more inclusive.

The Development Track was the richest one in terms of the number of presentations, in two different rooms, and included the usual face-to-face meeting of the Engineering Steering Committee, the Google Summer of Code Panel and a Lightning Talk Session.

In the second room there were talks about ODF, reports about migrations to LibreOffice and the adoption of the Open Document Format in Israel, Hungary, Taiwan and Turkey, and presentations about the community and other specific topics.

In the third room there was a meeting of the Open Source Business Alliance (OSBA) and workshops about inclusiveness, documentation and certification. Finally, the conference wrapped up on the 28th of September with a celebration of the eight anniversary of the LibreOffice project.

Oficina was a great conference location, thanks to the availability of a large garden where people could relax between talks, enjoy the sunny weather, discuss with other community members about LibreOffice and take a large number of pictures.

Additional Events

In the evening of Wednesday, September 26, all conference participants met for the social dinner to better know each other and discuss – mostly informally – about their activity in the community. The event was also an opportunity to sample some local beer.

During the evening of Thursday, September 27, most conference participants met at Destil for the HackNight, to work and discuss while having some food. This was a good opportunity for people to get to know core developers, and get their opinion about the future development of LibreOffice.

The full program the 2018 LibreOffice Conference in Tirana is still available online. The Document Foundation and the LibreOffice community are now looking forward to the upcoming 2019 event, which is due to take place in Almeria, Spain.

The LibreOffice Quality Assurance ( QA ) Team is happy to announce the bisect repository from libreoffice-6-3-branch-point to latest master is available for cloning from Gerrit. As a novelty, this repository adds support for KDE5 environment.

What is a bisect repository ?

it’s a git repository populated with hundreds of builds of LibreOffice. Added to the repository in chronological order, each build represents each commit in the LibreOffice core repository, allowing the QA Team to easily identify at which point a regression was introduced. Watch Effective Bisection and Bibisection (Matthew Francis’s talk at LibOCon 2015 on YouTube) for both an introduction, and practical details.…

• B&B Hotel - lots of traffic noise through the closed window, ambulances to dream of; up lateish, train, Eurostar, train and so on. Reasonable connectivity - built ESC agenda a tad late while on the train encouraging using Collabora Online rather effectively; good.

A quick video inviting you to the LibreOffice Latin America Conference 2019! (English subtitles are available.) It will be held at the Facultad Politécnica de Universidad Nactional de Asunción (FPUNA) in Asunción, Paraguay on July 19th (Friday) and 20th (Sat). For more information about the conference please visit the website.

• Up early, a couple of dismal, late trains to Kings Cross, and the Eurostar to OW2Con / Paris. Dodgy taxi ride, arrived somewhat late for the session. Gave a talk on LibreOffice Online and then C'bras role in it briefly.
• Caught up with Sigmund, Philippe from Arawa, Simon, and enjoyed a fine evening together with friends old & new.

(This post was originally written in Hungarian by Adam Kovacs for his blog. Thanks Adam!)

In the previous part of this tutorial series, we showed how to register with Git and Gerrit, to prepare your setup for building LibreOffice and submitting patches.

Today, we describe the steps you need to download and compile the LibreOffice source code on Linux. You can, of course, modify the source code you have downloaded and, if you compile it, you can make sure your changes are working well after the compilation.

In this guide, we are using GNU/Linux distributions (typically Debian and Ubuntu-based distributions) with the apt package management frontend. Those who do not use these distributions need to run apt-get install and similar commands instead.

(In you see errors when trying to compile, checking these wiki pages might help: Linux Build Dependencies and Building on Linux. Note: an internet connection is required during the compilation, after the build-nocheck command.)

---

Step 1: Install some required programs and packages

Open a terminal (In Ubuntu, Ctrl+Alt+t) and run this command:

sudo apt-get install git gstreamer1.0-libav libkrb5-dev nasm graphviz ccache

Then enter the password for your username. (If you do not have administrator privileges, you cannot do these steps.)

---

Step 2: Specify update manager sources

In the file /etc/apt/sources.list, add one of the following lines depending on your distribution:

• Debian 9:

  deb-src http://http.debian.net/debian/ stretch main

• Ubuntu 16.04:

  deb-src http://archive.ubuntu.com/ubuntu/ xenial main

• Ubuntu 18.04:

  deb-src http://archive.ubuntu.com/ubuntu/ bionic main

• Ubuntu 18.10:

  deb-src http://archive.ubuntu.com/ubuntu/ cosmic main

• Ubuntu 19.04:

  deb-src http://archive.ubuntu.com/ubuntu/ disco main

You can edit the file using:

sudo nano /etc/apt/sources.list
sudo gedit /etc/apt/sources.list

In Nano, to exit and save: Ctrl+x, then y, then enter. The exact version and codename of the Linux distribution can be found by running the uname -a and lsb_release -a commands.

---

Step 3: Download available updates and build dependencies

Enter these commands to ensure you get the latest packages, and everything required to build LibreOffice from the source code:

sudo apt-get update
sudo apt-get build-dep libreoffice

---

Step 4: Download the LibreOffice source code

Create a new directory somewhere for LibreOffice. For example, in your own directory:

cd ~
mkdir libreoffice
cd libreoffice

Go to this directory and run this command there:

git clone git://gerrit.libreoffice.org/core libreoffice

---

Step 5: Setting up the autogen.input file

Create an autogen.input file in the LibreOffice directory, with this content:

--without-system-postgresql
--without-junit
--without-java
--without-help
--without-doxygen
--disable-gtk3
--disable-odk
--disable-gstreamer-1-0
--disable-firebird-sdbc
--with-lang=hu en-US
--with-myspell-dicts
--enable-debug
--with-referenced-git=/home/linuxosfelhasznalonev/libreoffice/core
--with-external-tar=/home/linuxosfelhasznalonev/libreoffice/core/external/tarballs

You may also need these:

--without-krb5
--without-gssapi

If you still need some settings in autogen.input, you can use the ./autogen.sh –help command to list all possible settings.

For multi-core processors, you might want to add:

--with-parallelism=4

Note: if you start compiling and miss any of these options, eg the –enable-debug line, and then add the missing line to autogen.input, the next compilation process will not replace the existing files. If you want the newly inserted line in autogen.input to be valid for the newer compilation, you must delete the results of the old compilation using the make clean command.

---

Step 6: Build the code

Run these commands:

./autogen.sh
make

If you would like to compile without unit tests (for example, if you don’t want to check that what you have changed in the source code will cause regressions), use the build-nocheck parameter instead:

make build-nocheck

---

Step 7: Run the new build

When the code is compiled, you can start it from the LibreOffice directory:

./instdir/program/soffice
./instdir/program/soffice --writer
./instdir/program/soffice --calc

At this point, a lot of information is written to the command line while running LibreOffice. We can turn them off like this:

SAL_LOG=-INFO instdir/program/soffice

Now only SAL_DEBUG type values will be written to the command line (if they are already placed in the code somewhere).

If you just want to convert a file (for example, to fix export errors), you can do so. The converted file is then created in the LibreOffice directory (it is therefore advisable not to place the files to be converted in the LibreOffice directory, to avoid confusing them with the files that have already been converted). For instance:

SAL_LOG=-INFO instdir/program/soffice --convert-to docx ../chart_borderline.docx

---

Additional information

When the compilation is finished, and we modify the contents of one of the source files, we will start the compilation again. But this will not compile the entire codebase from scratch (unless we run the make clean command), but it only compiles the files we modified, which is a significant time saving.

If we forget to include a setting in autogen.input, but the compilation has already been done, then it is not enough to add the setting and start the compilation again – we also need to run make clean before.

For example, if we compiled without –enable-debug, add –enable-debug to the autogen.input file, then run make clean, followed by make or make build-nocheck.

You can also compile specific modules of LibreOffice:

make sw

Or:

make build-nocheck sw

These are the names of the modules:

• sw: Writer (formerly StarWriter)
• sc: the spreadsheet (Calc)
• sd: Impress and Draw
• dbaccess: database manager (Base)
• starmath: formula editor
• oox: source code files for importing and exporting Office Open XML files (docx, xlsx, pptx, …)
• chart2: source code files for managing charts

For more modules, see here.

---

Keep watching the blog for more guides and tips for LibreOffice development!

• More admin, project planning, prototype acceptance criteria construction. Three lots of maths revision in the evening. Worked late putting documentation together with Kendy.

• Mail chew, worked away at project planning and acceptance criteria. Couple of project calls and sync with Kendy.

Our wiki is currently down for maintenance.

• All Saints, band in the morning. Back for a fine lunch, and out for another, much less used stretch of walk along the nearby ancient, defensive Dyke.
• Slept while H. did Organ practice, encouraging progres with the quartet. Slugged in front of a movie in the evening.

Here at The Document Foundation, we’re always encouraging people to join our projects and community. Contributing to a well-known open source project is a great way to meet new people, have fun, build up skills and experience, and help to make the world a better place!

However, large FOSS projects can be daunting too. Our Get involved page aims to make the on-boarding process for newcomers easier, by breaking the process down into smaller steps, and we plan other improvements to that page.

But today, we’re announcing a new website targeted at potential contributors: What can I do for LibreOffice. This is inspired by What can I do for Mozilla, and much of the work was done by our awesome contributors from Albania – read their blog post about it here.

In “What can I do for LibreOffice”, visitors are asked what they’re interested in, and pointed to resources to get started. So instead of large web pages with walls of text, visitors can click around and find something that catches their eyes. The website source is on Gerrit if anyone has suggestions for updates or additions, and the site can be translated too.

Anyway, click here to check it out – and let us know what you think!

Following the availability of LibreOffice 6.3 Beta, there have been speculations about 32-bit compatibility based on a the missing 32-bit binaries for Linux.

We have prepared a short and a long statement to clarify the situation.

TL;DR

1. The Document Foundation is ending the provision of 32-bit binaries, and NOT 32-bit compatibility as a whole.

2. Distro vendors or anyone running a more current 32-bit Linux system can still create 32-bit versions of LibreOffice, as developers have not in any way removed 32-bit compatibility from the source code. Additionally, we are not removing any 32-bit builds that were previously created.

3. Most Linux users are sourcing LibreOffice from their distro repositories, which are usually compiled against the distro’s version of the various external libraries. We do not anticipate distros dropping 32-bit LibreOffice packages.

4. TDF does not anticipate the same decision happening for LibreOffice 32-bit binaries for Windows any time soon.

LONG

1. During the last two years, the number of downloads of the 32-bit Linux distribution-neutral binaries provided by The Document Foundation have decreased to a very low number. Today, the time needed to compile, test, maintain and distribute those binaries is not worth the effort, based on current download numbers. So, TDF is ending the provision of 32-bit binaries, and NOT 32-bit compatibility as a whole.

2. Today, 32-bit packages are very much the domain of specific Linux distros rather than a general user need. So, we are leaving them to distros, who will upstream fixes. Indeed, distro vendors or anyone running a more current 32-bit Linux system can still create 32-bit versions of LibreOffice, as developers have not in any way removed 32-bit compatibility from the source code. Additionally, TDF is not removing any 32-bit binaries that were previously created.

3. Most Linux users are sourcing LibreOffice from their distro repositories, which are usually compiled against the distro’s version of the various external libraries. LibreOffice by itself ships a number of external components to avoid dependencies, while distros link against the versions of those components which are part of the distro anyway. TDF does not anticipate distros dropping 32-bit LibreOffice packages.

4. The Document Foundation does not anticipate the same decision happening for Windows 32-bit binaries any time soon. Of course, if downloads of Windows 32-bit binaries from TDF mirror servers drop to the same very low number as Linux 32-bit packages, TDF will reconsider the situation.

Following the availability of LibreOffice 6.3 Beta, there have been speculations about 32-bit compatibility based on a the missing 32-bit binaries for Linux.

We have prepared a short and a long statement to clarify the situation.

TL;DR

1. The Document Foundation is ending the provision of 32-bit binaries, and NOT 32-bit compatibility as a whole.

2. Distro vendors or anyone running a more current 32-bit Linux system can still create 32-bit versions of LibreOffice, as developers have not in any way removed 32-bit compatibility from the source code. Additionally, we are not removing any 32-bit builds that were previously created.

3. Most Linux users are sourcing LibreOffice from their distro repositories, which are usually compiled against the distro’s version of the various external libraries. We do not anticipate distros dropping 32-bit LibreOffice packages.

4. TDF does not anticipate the same decision happening for LibreOffice 32-bit binaries for Windows any time soon.

LONG

1. During the last two years, the number of downloads of the 32-bit Linux distribution-neutral binaries provided by The Document Foundation have decreased to a very low number. Today, the time needed to compile, test, maintain and distribute those binaries is not worth the effort, based on current download numbers. So, TDF is ending the provision of 32-bit binaries, and NOT 32-bit compatibility as a whole.

2. Today, 32-bit packages are very much the domain of specific Linux distros rather than a general user need. So, we are leaving them to distros, who will upstream fixes. Indeed, distro vendors or anyone running a more current 32-bit Linux system can still create 32-bit versions of LibreOffice, as developers have not in any way removed 32-bit compatibility from the source code. Additionally, TDF is not removing any 32-bit binaries that were previously created.

3. Most Linux users are sourcing LibreOffice from their distro repositories, which are usually compiled against the distro’s version of the various external libraries. LibreOffice by itself ships a number of external components to avoid dependencies, while distros link against the versions of those components which are part of the distro anyway. TDF does not anticipate distros dropping 32-bit LibreOffice packages.

4. The Document Foundation does not anticipate the same decision happening for Windows 32-bit binaries any time soon. Of course, if downloads of Windows 32-bit binaries from TDF mirror servers drop to the same very low number as Linux 32-bit packages, TDF will reconsider the situation.…

General Activities

1. LibreOffice 6.1.6.3 was released on May, 7
2. LibreOffice 6.2.4.2 was released on May, 22
3. Jan-Marek Glogowski keeps fixing and improving QT5 bugs
4. Luboš Luňák and Dennis Francis (Collabora) fixed the multi_type_vector regressions affecting performance in Calc
5. Gülşah Köse (Collabora) added new customize and position merged dialog
6. Grzegorz Araminowicz (Collabora) continues his SmartArt interoperability work
7. Tamás Zolnai (Collabora) has fixed some PPTX import/export problems
8. Noel Grandin (Collabora) did a great job on improving the import/export performance of Writer and Calc files
9. Andreas Keinz continues improving the Notebookbar
10. László Németh (NISZ Team) has fixed some DOCX import and track changes interoperability problems
11. Luboš Luňák (Collabora) wrote a nice blogpost about compiling times in LibreOffice
12. Rizal Muttaqin added Karasa Jaga SVG icons and made some updating for Elementary icon theme
13. Miklos Vajna (Collabora) has fixed some flickering UI bugs on Windows
14. Heiko Tietze added a new ‘What’s New?’ infobar pointing to the release notes when a new version is started for the first time
15. Muhammet Kara (Collabora) added all the information regarding the new feature ‘Redaction’ to the release notes
16. Muhammet Kara (Collabora) killed Mozilla Personas support
17. Michael Stahl (CIB) fixed all the regressions introduced by bug 114306
18. Michael Weghorn (City of Munich) and Katarina Behrens (CIB) keeps fixing bugs affecting KDE5, backporting them to LibreOffice 6.2 branch
19. Tor Lillqvist and Tomaž Vajngerl (Collabora) keep working on LibreOffice support for iOS
20. Tomaž Vajngerl (Collabora) made it possible to build LibreOffice with xcode 10 on macOS
21. Dennis Francis (Collabora) added a new checkbox in Data ▸ Statistics ▸ Moving Average dialog that allows trimming of the input range to the actual data content before computing moving-average
22. Balazs Varga (NISZ team) keeps fixing XLSX chart issues
23. Regina Henschel fixed many problems with handle-movements of OOXML preset shapes used by PowerPoint or SoftMaker
24. Xisco Fauli automated some actions in Bugzilla to improve the triage process
25. 6 students has been accepted for the Google Summer of Code Program
• Shubham Goyal – Generating QR Code in LibreOffice
• Gagandeep Singh – Implement Chart Styles
• Ahmed Elshreif – Improve the UI testing DSL and the log files for UI actions
• Sumit Chauhan – Improvement to Notebookbar
• Rasmus Jonsson – LibreOffice Appliances
• Kaishu Sahu – LibreOffice for Android(Online)
•  

Reported Bugs

547 bugs, 54 of which are enhancements, have been reported by 300 people.

Top 10 Reporters

1. Xisco Faulí ( 24 )
2. Nicolas Christener ( 22 )
3. NISZ LibreOffice Team ( 21 )
4. Thorsten Wagner ( 19 )
5. Telesto ( 12 )
6. Regina Henschel ( 11 )
7. andreas_k ( 10 )
8. Roman Kuznetsov ( 9 )
9. Mike Kaganski ( 7 )
10. Aron Budea ( 7 )

Triaged Bugs

636 bugs have been triaged by 72 people.

Top 10 Triagers

1. Xisco Faulí ( 209 )
2. Dieter Praas ( 57 )
3. raal ( 38 )
4. Heiko Tietze ( 31 )
5. Roman Kuznetsov ( 31 )
6. V Stuart Foote ( 25 )
7. Julien Nabet ( 21 )
8. Usama ( 20 )
9. Timur ( 19 )
10. Oliver Brinzing ( 18 )

Resolution of resolved bugs

608 bugs have been set to RESOLVED.

Check the following sections for more information about bugs resolved as FIXED, WORKSFORME and DUPLICATE.

Fixed Bugs

227 bugs have been fixed by 44 people.

Top 10 Fixers

1. Caolán McNamara ( 33 )
2. Noel Grandin ( 11 )
3. Miklos Vajna ( 9 )
4. László Németh ( 9 )
5. Michael Stahl ( 9 )
6. Katarina Behrens ( 8 )
7. Xisco Fauli ( 7 )
8. Tor Lillqvist ( 7 )
9. Jan-Marek Glogowski ( 7 )
10. Eike Rathke ( 7 )

List of critical bugs fixed

1. tdf#124829 CRASH: cutting and undoing a sheet with external links ( Thanks to Serge Krot )
2. tdf#125054 Font changed when typing into cell, in edit mode, with redline ( Thanks to Armin Le Grand )
3. tdf#125080 LibreOffice crashes when adding icons to Gallery ( Thanks to Caolán McNamara )
4. tdf#125339 Table is deleted after acceding the table ( Thanks to Noel Grandin )
5. tdf#125370 crash: on open basic editor to edit macros ( Thanks to Samuel Mehrbrodt )

List of crashes fixed

1. tdf#115092 crash report screen keeps popping up ( Thanks to Xisco Fauli )
2. tdf#122056 kde5: Impress crashes when at presentation end when Orca is enabled ( Thanks to Katarina Behrens )
3. tdf#124484 Impress crashes on slide show using “All displays” ( Thanks to Katarina Behrens )
4. tdf#124675 CRASH: after moving the content down and undoing ( Thanks to Michael Stahl )
5. tdf#124927 Crash when adding more than one object to the animated images dialog ( Thanks to Caolán McNamara )
6. tdf#124937 crash when trying to open a .doc file ( Thanks to Mark Hung )
7. tdf#124942 CRASH – 3D Slide Transitions in Impress ( Thanks to Caolán McNamara )
8. tdf#124962 CRASH: closing a document that previously crash at import time (gtk3/gtk) ( Thanks to Stephan Bergmann )
9. tdf#125051 EDITING: CRASH when start SpellCheck ( Thanks to Noel Grandin )
10. tdf#125104 Changing page numbering to “1st, 2nd, 3rd,…” causes crashes when trying to change Page settings later ( see comment 26 ) ( Thanks to Caolán McNamara )
11. tdf#125131 CRASH closing LibreOffice with the tip of the day dialog open ( gen/gtk) ( Thanks to Xisco Fauli )
12. tdf#125132 CRASH: closing Digital Signature dialog ( gen/gtk ) ( Thanks to Caolán McNamara )
13. tdf#125164 CRASH: After editing the index and undoing ( Thanks to Michael Stahl )
14. tdf#125229 CRASH when trying to modify a frame style in a ODT document ( Thanks to Caolán McNamara )
15. tdf#125271 Inserting this .mp4 file in impress leads to a CRASH ( Thanks to Caolán McNamara )
16. tdf#125325 Crash when changing assignments between Table indexes and Free indexes for DBase ( Thanks to Julien Nabet )
17. tdf#125392 CRASH: if Select Address List dialog has more than 1 element (gtk3) ( Thanks to Caolán McNamara )
18. tdf#125394 CRASH: closing mail merge dialog ( Thanks to Caolán McNamara )
19. tdf#125397 iOS App: Template URL – Crash when Opening From Template ( Thanks to Tor Lillqvist )
20. tdf#125424 CRASH: Renaming template ( Thanks to Mike Kaganski )
21. tdf#125472 Crash vcllo!OutputDevice::RemoveTransparenciesFromMetaFile+0xa68: ( Thanks to Julien Nabet )

List of old bugs ( more than 4 years old ) fixed

1. tdf#38889 Make macro editing easier ( Thanks to Jens Carl )
2. tdf#56738 Wrong encoding in comments for file edited by Mac OS MS Word ( Thanks to Julien Nabet )
3. tdf#63640 FILEOPEN/FILESAVE: particular .odt loads/saves very slow ( Thanks to Noel Grandin )
4. tdf#65587 Elements pane: Items not reachable without mouse ( Thanks to Jan-Marek Glogowski )
5. tdf#66765 FILESAVE: saving sheet with some queries in it takes forever (~5 minutes) ( Thanks to Noel Grandin )
6. tdf#68339 Other: BASIC Syntax error ( Thanks to Jens Carl )
7. tdf#69042 Add a “Release Notes/What’s New” window to be shown upon first run ( Thanks to heiko tietze )
8. tdf#79972 FILEOPEN: XLS/XLSX – Hyperlink document path not imported correctly for numeric content cells ( Thanks to Tünde Tóth )
9. tdf#80853 Calc freezes while filtering large data ( Thanks to Luboš Luňák )
10. tdf#83722 Untitled document from template is closed when opening additional existing document ( Thanks to Katarina Behrens )
11. tdf#85470 FILESAVE Very long time spent saving XLSX as XLS ( Thanks to Noel Grandin )
12. tdf#87965 Make ‘Search Results’ dialog optional from Find & Replace dialog ( Thanks to heiko tietze )
13. tdf#90297 LibreOffice Math dark theme > dark text and background ( Thanks to Jan-Marek Glogowski )

WORKSFORME bugs

105 bugs have been retested by 40 people.

Top 10 testers

1. Xisco Faulí ( 24 )
2. Buovjaga ( 9 )
3. Thomas Lendo ( 6 )
4. Heiko Tietze ( 6 )
5. Dieter Praas ( 6 )
6. raal ( 5 )
7. Timur ( 5 )
8. Julien Nabet ( 4 )
9. Telesto ( 3 )
10. Cor Nouws ( 3 )

DUPLICATED bugs

98 bugs have been duplicated by 25 people.

Top 10 testers

1. Xisco Faulí ( 19 )
2. raal ( 9 )
3. Timur ( 8 )
4. Gabor Kelemen ( 6 )
5. Heiko Tietze ( 6 )
6. Alex Thurgood ( 6 )
7. V Stuart Foote ( 6 )
8. Buovjaga ( 5 )
9. Dieter Praas ( 5 )
10. Oliver Brinzing ( 5 )

Verified bug fixes

115 bugs have been verified by 21 people.

Top 10 Verifiers

1. Xisco Faulí ( 76 )
2. Vera Blagoveschenskaya ( 7 )
3. Timur ( 5 )
4. Aron Budea ( 4 )
5. BogdanB ( 3 )
6. Julien Nabet ( 3 )
7. Buovjaga ( 2 )
8. Roman Kuznetsov ( 2 )
9. Cor Nouws ( 2 )
10. Samuel Thibault ( 1 )

Categorized Bugs

320 bugs have been categorized with a metabug by 30 people.

Top 10 Categorizers

1. Roman Kuznetsov ( 108 )
2. Dieter Praas ( 54 )
3. Thomas Lendo ( 25 )
4. Gabor Kelemen ( 22 )
5. Aron Budea ( 22 )
6. Xisco Faulí ( 16 )
7. V Stuart Foote ( 12 )
8. Heiko Tietze ( 11 )
9. DaeHyun Sung ( 7 )
10. NISZ LibreOffice Team ( 7 )

Regression Bugs

105 bugs have been set as regressions by 24 people.

Top 10

1. Xisco Faulí ( 56 )
2. raal ( 8 )
3. Roman Kuznetsov ( 5 )
4. Aron Budea ( 4 )
5. Alex Thurgood ( 4 )
6. Buovjaga ( 3 )
7. Timur ( 3 )
8. Gabor Kelemen ( 3 )
9. Cor Nouws ( 2 )
10. Oliver Brinzing ( 2 )

Bisected Bugs

80 bugs have been bisected by 13 people.

Top 10 Bisecters

1. Xisco Faulí ( 49 )
2. raal ( 10 )
3. Aron Budea ( 6 )
4. Kevin Suo ( 3 )
5. Buovjaga ( 2 )
6. Gabor Kelemen ( 2 )
7. Oliver Brinzing ( 2 )
8. Maxim Monastirsky ( 1 )
9. Justin L ( 1 )
10. Michael Stahl (CIB) ( 1 )

Evolution of Unconfirmed Bugs

Check the current list of unconfirmed bugs here

Evolution of Open Regressions

Check the current list of open regressions here

Evolution of Open bibisectRequests

Check the current list of open bibisectrequests here

Evolution of Highest Priority Bugs

Check the current list of highest priority bugs here

Evolution of High Priority Bugs

Check the current list of high priority bugs here

Thank you all for making Libreoffice rock!
Join us and help to keep LibreOffice super reliable!
Check the Get Involved page out now!…

The LibreOffice Quality Assurance ( QA ) Team is happy to announce LibreOffice 6.3 Beta1 is ready for testing!

LibreOffice 6.3 will be released as final in mid August, 2019, being LibreOffice 6.3 Beta1 the second pre-release since the development of version 6.3 started in mid November, 2018 ( See the release plan ). Since LibreOffice 6.3 Alpha1, 683 commits have been submitted to the code repository and 141 bugs have been set to FIXED in Bugzilla. Check the release notes to find the new features included in this version of LibreOffice.

LibreOffice 6.3 Beta1 can be downloaded from here, it’s available for Linux, MacOS and Windows. Besides, and it can be installed along with your actual installation.

In case you find any problem in this pre-release, please report it in Bugzilla ( You just need a legit email account in order to create a new account ) so it can get fixed before LibreOffice 6.3 final is released.

For help, you can contact us directly in our IRC channel.

Happy testing!!

…

If you occassionally do performance profiling as I do, you probably know Valgrind's Callgrind and the related UI KCachegrind. While Callgrind is a pretty powerful tool, running it takes quite a while (not exactly fun to do with something as big as e.g. LibreOffice).

Recently I finally gave Linux perf a try. Not quite sure why I didn't use it before, IIRC when I tried it somewhen long ago, it was probably difficult to set up or something. Using perf record has very little overhead, but I wasn't exactly thrilled by perf report. I mean, it's text UI, and it just gives a list of functions, so if I want to see anything close to a call graph, I have to manually expand one function, expand another function inside it, expand yet another function inside that, and so on. Not that it wouldn't work, but compared to just looking at what KCachegrind shows and seeing ...

When figuring out how to use perf, while watching a talk from Milian Wolff, on one slide I noticed a mention of a Callgrind script. Of course I had to try it. It was a bit slow, but hey, I could finally look at perf results without feeling like that's an effort. Well, and then I improved the part of the script that was slow, so I guess I've just put the effort elsewhere :).

And I thought this little script might be useful for others. After mailing Milian, it turns out he just created the script as a proof of concept and wasn't interested in it anymore, instead developing Hotspot as UI for perf. Fair enough, but I think I still prefer KCachegrind, I'm used to this, and I don't have to switch the UI when switching between perf and callgrind. So, with his agreement, I've submitted the script to KCachegrind. If you would find it useful, just download this do something like:

$ perf record -g ...
$ perf script -s perf2calltree.py > perf.out
$ kcachegrind perf.out

Would you like your C++ code to compile twice as fast (or more)?

Yeah, so would I. Who wouldn't. C++ is notorious for taking its sweet time to get compiled. I never really cared about PCHs when I worked on KDE, I think I might have tried them once for something and it didn't seem to do a thing. In 2012, while working on LibreOffice, I noticed its build system used to have PCH support, but it had been nuked, with the usual poor OOo/LO style of a commit message stating the obvious (what) without bothering to state the useful (why). For whatever reason, that caught my attention, reportedly PCHs saved a lot of build time with MSVC, so I tried it and it did. And me having brought the PCH support back from the graveyard means that e.g. the Calc module does not take 5:30m to build on a (very) powerful machine, but only 1:45m. That's only one third of the time.

In line with my previous experience, on Linux that did nothing. I made the build system support also PCH with GCC and Clang, because it was there and it was simple to support it too, but there was no point. I don't think anybody has ever used that for real.

Then, about a year ago, I happened to be working on a relatively small C++ project that used some kind of an obscure build system called Premake I had never heard of before. While fixing something in it I noticed it also had PCH support, so guess what, I of course enabled it for the project. It again made the project build faster on Windows. And, on Linux, it did too. Color me surprised.

The idea must have stuck with me, because a couple weeks back I got the idea to look at LO's PCH support again and see if it can be made to improve things. See, the point is, PCHs for that small project were rather small, it just included all the std stuff like <vector> and <string>, which seemed like it shouldn't make much of a difference, but it did. Those standard C++ headers aren't exactly small or simple. So I thought that maybe if LO on Linux used PCHs just for those, it would also make a difference. And it does. It's not breath-taking, but passing --enable-pch=system to configure reduces Calc module build time from 17:15m to 15:15m (that's a less powerful machine than the Windows one). Adding LO base headers containing stuff like OUString makes it go down to 13:44m and adding more LO headers except for Calc's own leads to 12:50m. And, adding even Calc's headers, results in 15:15m again. WTH?

It turns out, there's some limit when PCHs stop making things faster and either don't change anything, or even make things worse. Trying with the Math module, --enable-pch=system and then --enable-pch=base again improve things in a similar fashion, and then --enable-pch=normal or --enable-pch=full just doesn't do a thing. Where it that 2/3 time reduction --enable-pch=full does with MSVC?

Clang has recently received a new option, -ftime-trace, which shows in a really nice and simple way where the compiler spends the time (take that, -ftime-report). And since things related to performance simply do catch my attention, I ended up building the latest unstable Clang just to see what it does. And it does:
So, this is bcaslots.cxx, a smaller .cxx file in Calc. The first graph is without PCH, the second one is with --enable-pch=base, the third one is --enable-pch=full. This exactly confirms what I can see. Making the PCH bigger should result in something like the 4th graph, as it does with MSVC, but it results in things actually taking longer. And it can be seen why. The compiler does spend less and less time parsing the code, so the PCH works, but it spends more time in this 'PerformPendingInstantiations', which is handling templates. So, yeah, in case you've been living under a rock, templates make compiling C++ slow. Every C++ developer feeling really proud about themselves after having written a complicated template, raise your hand (... that includes me too, so let's put them back down, typing with one hand is not much fun). The bigger the PCH the more headers each C++ file ends up including, so it ends up having to cope with more templates. With the largest PCH, the compiler needs to spend only one second parsing code, but then it spends 3 seconds sorting out all kinds of templates, most of which the small source file does not need.

This one is column2.cxx, a larger .cxx file in Calc. Here, the biggest PCH mode leads to some improvement, because this file includes pretty much everything under the sun and then some more, so less parsing makes some savings, while the compiler has to deal with a load of templates again, PCH or not. And again, one second for parsing code, 4 seconds for templates. And, if you look carefully, 4 seconds more to generate code, most of it for those templates. And after the compiler spends all this time on templates in all the source files, it gets all passed to the linker, which will shrug and then throw most of it away (and that will too take a load of time, if you still happen to use the BFD linker instead of gold/lld with -gsplit-dwarf -Wl,--gdb-index). What a marvel.

Now, in case there seems to be something fishy about the graphs, the last graph indeed isn't from MSVC (after all, its reporting options are as "useful" as -ftime-report). It is from Clang. I still know how to do performance magic ...

The LibreOffice Quality Assurance ( QA ) Team is happy to announce LibreOffice 6.3 Alpha1 is ready for testing!

LibreOffice 6.3 will be released as final in mid August ( Check the Release Plan ) being LibreOffice 6.3 Alpha1 the first pre-release since the development of version 6.3 started in mid November, 2018. Since then, 6390 commits have been submitted to the code repository and more than 1050 bugs have been set to FIXED in Bugzilla. Check the release notes to find the new features included in this version of LibreOffice.

LibreOffice 6.3 Alpha1 is already available for downloading here, for Linux, MacOS and Windows.

In case you find any problem in this pre-release, please report it in Bugzilla ( You just need a legit email account in order to create a new account ).

For help, you can contact the QA Team directly in the QA IRC channel or via Telegram.

Happy testing!!

…

High packet loss ratio at the datacenter (or its upstream carriers) causes slowdown and service disruption. (Possibly depending on the IP protocol version and route taken.)

This year’s FOSDEM (Free and Open source Software Developers’ European Meeting) has been held in in the beautiful city of Brussels (Belgium), as usual, on February 2 & 3, 2019. It was organised by volunteers to promote the widespread use of free and open source software..

This was my first FOSDEM as a deputy member of the MC, and a fresh member of the Collabora team.

I will try to give some information about my talks, and share my experience.

TDF Meetings, LibreOffice Hackfest & LibreOffice Dinner…

The first 2 days was spent on the LibreOffice Hackfest, MC & BoD joint meetings. Seeing all friends face to face was a pleasure. We discussed some important matters face to face, and had a great time together.

Did some work on the LibreOffice themes, and discovered the ugly truth of major Mozilla API change.

We also had a community night/dinner with the LibreOffice community members on Saturday. Had pleasant chats with many friends, and a nice ‘kosher/halaal’ meal with Lior (thank you again!).

It was also a nice adventure, chasing Indian/Eastern/Asian tastes with Mike. :)

The Hotel

This year, I stayed with the pack in Bedford. Its location is perfect, but you may feel the building’s age. (In good & bad ways.) I had the first night with a semi-functional heater in the room. Not very pleasant, considering the winter of Brussels. Next day they gave a second portable heater -yay! :)-, and I survived with those.

The Talks

Talk 1: Resurrecting Mozilla Themes for LibreOffice

Past, present, and the future of LibreOffice’s Personalization dialog.

LibreOffice has had the ability to use Mozilla Themes (Personas) for some time (Tools > Options > Personalization); but it kept breaking all the time, and never had an acceptable UX. Also tons of errors/warnings, and very slow search and apply processes almost brought it to the point of being killed for good. But I couldn’t let it die, started looking into the related code and the bug reports. Now it has a better UX/UI, and got most annoying bugs/crashers fixed, and is much faster.

I tried to present a summary about the journey so far, and the plans for the future.

• Presentation video on YouTube
• The slides of the presentation on Speaker Deck

Talk 2: Document Redaction with LibreOffice

Redaction in its sanitization sense (as distinguished from its other editing sense) is the blacking out or deletion of text in a document, or the result of such an effort. It is intended to allow the selective disclosure of information in a document while keeping other parts of the document secret. Typically the result is a document that is suitable for publication or for dissemination to others than the intended audience of the original document. For example, when a document is subpoenaed in a court case, information not specifically relevant to the case at hand is often redacted. Another example is patient information of hospitals, which is distributed to be used for research purposes.

A new document redaction feature for Collabora Office is being developed, and it will also be available on the next major version of LibreOffice. This new feature will provide a much more efficient means than the traditional print-redact-scan process, and will try to prevent also the accidental leakage of redacted information by completely removing them in the resulting PDF document, rather than just hiding.

• Presentation video on YouTube
• The slides of the presentation on Speaker Deck

Overall

Again a good use of time, full of experience sharing with fellow FLOSS developers, and community members.

Looking forward to the next FOSDEM! :)

Our provider is experiencing connectivity hiccups, affecting the reachability of our services (depending on the route taken).

The work around user experience often requires to create a minimal working example. Either users report an issue or request enhancements, the comparison with the current situation is necessary. LibreOffice has a built-in feature to create dummy text (type dt and press F3) but this function inserts only unformatted text.…

On vecation I ordinary have the best ideas. So this time I made an single line contextual toolbar for writer.

It’s how the single line toolbar should look like. One toolbar which is fully contextual. As one toolbar didn’t have that much space, you have the menubar for all available commands in LibreOffice.

It’s the most compact LibreOffice UI done on my smal Laptop screen (1366 x 768 px). But Contextual single work not only on small screens it’s flexible and suites all screen sizes.

Context Standard, Table, Image, Shape

If you’d like to test contextual single download the daily master build, enable experimental features (Menubar -> Tools -> Configure -> Advanced -> Enable experimental features) and change in Writer Menubar -> View -> User Interface -> Contextual Single.

To test download the daily build
https://dev-builds.libreoffice.org/daily/master/Win-x86@39/current

I broke the linux builds but now daily build for linux is available to check out the context single layout

https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86@87-TDF/current

The next release for LibreOffice will have a small but handy improvement for every macro developer, either experienced or beginner.

Hover the mouse on BASIC and Python code in the new Help pages and a tip shows that when you click your mouse, the code exerpt is copied in the system clipboard. You can paste in the BASIC IDE (Integrated Development environment) or any other text application in your system.



With this little feature, you save time of typing the exerpt to test in your IDE or document. Another alternative was to use a collateral file, however, collateral files with embedded macros is likely to trigger security warnings in most LibreOffice installations. Just copying the fragment is easier.

Happy Basic macro programming!
Happy Python macro programming!

Recently we at Collabora Productivity have made some substantial improvements to XLSX interoperability related to pivot tables, fixing many issues existed in Calc.

Personally I have committed these patches:

• 4a524379548c916d304a71980f6911231768018 – fixes a case when pivot tables exported by LibreOffice were considered broken and discarded by Excel
• 577b95f4d0cc1cf8836ff35fc30189c64fefb508 – workarounds a standard non-compliance of Excel 2016, which introduced a requirement directly contradicting MS OOXML standard
• b082998401e37e6c7534906601bc481423a6ded0 – introduced saving pivot table group fields to XLSX – an important feature missing up to that moment, without which there was no grouping by e.g. years/months in pivot tables resulting from export
• 0871804bab38e1b2fdc19ff176189356e155f367 – fixed order of items in group fields, without which selecting October in an exported pivot table filter could give November’s results in Excel
• 26e85974a0287ab5869e7ff0145a66b853d66a02 – introduced saving number formats of data fields to XLSX, without which results like $12 345 could become plain 12345 after pivot table refresh in Excel
• 323ac4c2338dde36c10b9889e4b656dc685ba1ed – introduced round-tripping of pivot table style as defined in original XLSX, so that the pivot table would have original look in Excel (may need refresh though) after being edited in Calc
• e913727c7ee3af0bb4031c6829abfb3373306492 – fixed a problem introduced in the second commit in this list, when data field name arrived empty in Excel
• 7f6a6664a1f3a37a97d02d5f0894300aff0d8db5 – allows LibreOffice to import data field names as defined in Excel, thus preserving the names when round-tripping XLSX pivot tables.

These changes allow our customers, and the whole LibreOffice user community, to enjoy better interoperability when using XLSX format. They will be available in LibreOffice version 6.3 later this summer; and they are immediately available for our customers in this week’s Collabora Office 6.0 update 28.

Thanks to our valuable customers who make these improvements possible funding the work!

Great Icon bugs get fixed!

LibreOffice do organize the bugs into [META] bugs, which is great cause when you link the bug to different [META] bugs you can organize bugfixing over different groups. I care about BUG 106228 which is the Icon meta bug and as you can see most of the icon bugs need developer work. Everything I could fix myself is nearly done.

There are two bigger tasks, but with great effort open

1. svg support for icons bug 124940

All main icon themes are available in svg, but the svg2png libreoffice renderer give bad quality, so we have to ship the png icons. If we could use the svg icons instead of the png, it mean less work for the designers and the posibility to have color scheme support for icons. 100% dark icon theme support and full color support. What a great improvement.

2. language support bug bug 124956

We have colibre, elementary, breeze, sifr, tango icon theme therefore the design group did the icons, some icons like bold, italic, strickout, underline, overline, … have letters which work fine for english users but had to be drawen for other languages. But to know which letter should be used we need the translation team so translation team please submit an bug report for each language and add at depends on 124956, than we will do the icon work.

Result

Colibre, elementary, sifr, breeze will be in an good shape for the 6.3 release, but to fix the last bugs, we need developers, translation team, documentation team, … everybody in one team.

The LibreOffice guidelines say that you should show icons on the most important items https://wiki.documentfoundation.org/Design/MenuBar

Now the menubar show only the most important items so the user didn’t flash with icons, the user get an better overview of the menubars.

happy hacking.

Xubuntu 19.04: The Exhaustive Update #Xubuntu #Xfce #DiscoDingo https://bluesabre.org/2019/04/18/xubuntu-19-04-the-exhaustive-update/

Every powerfull text editor like, kate, sublime, notepad++, VS Code, … has it the menubar. Now even better in LibreOffice.

Items with subgroups were arranged at the end of groups , so it’s faster to read the menubar and the groups are between 3-4 items. Tiny changes with big effort.

If you like my work, become a

All items in the menubar have now an icon. Some items are missing tdf#124200 but in general all commands will show an icon in the menubar.

For 6.3 all supported icon themes will have the new icons. Now you can check them out in Sifr (which is complete new for 6.3 release).

If you like my work, become a

Recently I implemented FOURIER() formula for LibreOffice Calc that computes Discrete Fourier Transform [DFT] of a real/complex data sequence. Computation is done using a couple of Fast Fourier Transform algorithms (all implemented from scratch). I’d like to thank Collabora Productivity for a fully funded hack week and lots of encouragement that enabled me to work on this feature.

The syntax of the formula is :

FOURIER(Array, GroupedByColumns, Inverse, Polar, MinimumMagnitude)

First and second arguments : First argument is the data array range. There are some restrictions on its shape. If the array is grouped by columns(rows), you need to indicate that by setting the second argument GroupedByColumns = TRUE(FALSE). In case of grouped by columns(rows) the “Array” can contain 1 or 2 columns(rows), where the first column(row) should contain the real part of the input sequence and second column(row) if present should contain the imaginary part of the input sequence. If there is only 1 column(row), the input sequence is assumed to be purely real. There is no restriction on the length of the input sequence. For example the length need not be an exact power of 2 like MS Excel’s Fourier analysis tool requires. The DFT computed by FOURIER formula is exact for the given length of the input sequence meaning it does not pad zeroes to the end of the input sequence to make the length an even power of 2.

The third argument “Inverse” is a boolean flag to indicate whether an inverse DFT needs to be computed. This argument is optional and the default value is FALSE.

The fourth argument “Polar” is a boolean flag to indicate whether the final output needs to be in polar coordinates. This argument is optional and the default value is FALSE.

The fifth argument “MinimumMagnitude” is a numeric argument and is used only if Polar=TRUE. All output components(frequency components if Inverse=FALSE) with magnitude less than MinimumMagnitude will be suppressed by a zero magnitude-phase entry. This is very useful when looking at the magnitude-phase spectrum of a signal (especially when its spectrum is sparse) because there is always some very tiny amount of rounding error when doing FFT algorithms and results in incorrect non-zero phase for some non-existent frequencies. By providing a suitable value to this parameter, these non-existent frequency components can be suppressed. The default value of this parameter is 0.0, so no suppression is done by default.

The result of this formula consists of two columns – first column contains the real parts (or the magnitudes if Polar=TRUE) and second column contains the imaginary parts (or the phases if Polar=TRUE).

Below is a screenshot of a sample usage of FOURIER() formula.

The data x[n] column was generated by the formula “=10*COS(2*PI()*COS(2*PI()*A2:A257/128))” (a typical frequency modulation example). Here a Phase-Magnitude spectrum is computed using FOURIER formula

=FOURIER(B2:B257,1,0,1, 1E-10)

Note that the Polar argument is set to 1, and MinimumMagnitude is set to 1E-10, to suppress the non-existent frequency components due to rounding errors. The plots here just visualize the data. The top plot shows the time-domain waveform and the next two plots represent the magnitude and phase spectra.

Fourier Analysis Tool

A Fourier analysis tool is also added to Statistics menu. All features of FOURIER formula are available graphically in this tool. Here is a screenshot of Fourier Analysis tool in action.

Implementation details of FOURIER formula

Basically two different Fast Fourier Transform (FFT) algorithms are implemented.

1. Radix-2 Decimation in Time FFT :    This  is used when the length of input sequence is an even power of 2.
2. Bluestein’s algorithm : This algorithm is used when the length of data sequence is not an even power of 2.

Both algorithms have asymptotic time complexity of O(N lgN), but Bluestein’s algorithm is much slower in practice. However many optimizations are in place to make the computation faster, especially when the input sequence is purely real.

Below are the patches that shows the evolution of the implementation of FOURIER formula over time.

1. tdf#74664 : Adds FOURIER() formula
2. tdf#74664 : Compute the phase correctly using atan2
3. tdf#74664 : optimize the computation of twiddle factors.
4. tdf#74664 : Unit test for FOURIER formula
5. FOURIER : use Bluestein’s algorithm for N != 2^k
6. More test cases for FOURIER formula
7. tdf#74664: FOURIER: add 5th optional parameter MinimumMagnitude

Performance

Below are some perf measurements for various input cases. These numbers are only for the DFT computation part and does not include the time for writing data to the spreadsheet model. We don’t use multi-threading yet for FOURIER, so these are numbers for just one cpu-core.

Case#1 :  Data length is a power of 2

Real Input length	Time (ms)
32768	2
65536	4
262144	21
1048576	185

Complex Input length	Time (ms)
32768	2
65536	5
262144	30
1048576	400

Case#2 : Data length is even but not a power of 2

Real Input length	Time (ms)
32766	8
65534	20
262142	105
1048574	1440

Complex Input length	Time (ms)
32766	15
65534	36
262142	313
1048574	3332

Case#3 : Data length is odd but not a power of 2

Real Input length	Time (ms)
32767	16
65535	39
262143	313
1048575	2729

Complex Input length	Time (ms)
32767	16
65535	38
262143	309
1048575	2703

 

 

After one of our hypervisors went down, one of the gluster filesystems that stores the VM disk images went into a bad state where it wouldn't heal files and thus some files got out of sync (split-brain) that was not fixed/prevented by gluster's self-heal-deamon.

We're manually fixing the split-brain/inconsistencies and bringing services back up, but before bringing back the critical services like bugzilla and askbot, we of course want to make sure the images are in a consistent state to avoid additional complications further down the road.

Update: bugzilla and askbot are up again. Unfortunately we had to restore bugzilla's from backup, so we "lost" some entries between time of last backup (March 25th 22:56 UTC) until beginning of outage (Mar 26 10:04 UTC) - the lost is in quotes, since the comments and assignments that were done in the meantime are not completely lost, but can be restored from the mail notifications/archive.