[Solved] Porting Extension for LibO3.6 to 4.0, & others

[twohot]

[1] I decided to update the extension I packaged last year (or two) to LibreOffice4.0. The tool derives much from Hanya's snippets. In the meantime, the extension has registered after updating some Print statements to Python3 syntax; ... but LibreOffice seems to crash while in FrameKeeper(obj) class. Has the API changed that much? So ... how does LibreOffice handle frames? Is implementing a dispatcher still proper?

[2] After the crash, LibreOffice hangs after recovering the last active file. This is cyclic in nature so something must be terribly wrong somewhere.

[Hagar Delest]

This is a rather LibreOffice specific question. You should ask them directly.

It seems that they have implemented many changes without really warning their community.

[hanya]

Few weeks ago, I migrate my extensions MRI and BookmarksMenu to LibreOffice 4 and they worked well. Except for reflection based workaround on using script provider for basic.

Do you have your tool as open source? If so, I want to look into the migration problem.

[twohot]

Do you have your tool as open source? If so, I want to look into the migration problem.

Although the scripting is basic, the tool is not open-source because of conditions surrounding its usage. I, and some of my colleagues at school, use it while working on student's results gradesheet. What I might do is to strip it down to its core. If there are issues then we can start from there. One thing I have discovered, for sure, is that the Extension makes LibreOffice-4.0 very unstable. Running LibO while the extension is installed makes it crash whenever I close a spreadsheet document. LibO then attempts a recovery when starting the next time (even when nothing was done on the sheet). So, I suspect the issue is around the listener part of the Extension.

Here is what part of the Extension does:

• 1. It checks for DOCUMENTEVENT in libO and confirms that a particular template has been loaded (XJob)
  2. If the right template/or is loaded, it attaches a listener to a specific cell (XModifyListener)
  3. Depending on the value of that cell, the listener code either duplicates a reference sheet or deletes excess sheets

Above list describes the listener part of the extension. The other part manages the added toolbars and menus. The toolbar still performs as expected although there may be errors I am not seeing ...but at least LibO doesnt crash ...not until I run something that involves the listener part or closes a spreadsheet. Every other calculation is handled by the spreadsheet template itself.

[twohot]

Hanya, where can I find the updated MRI extension for LibO 4.0? Would like to do some preliminary checks. Perhaps there are more things I need to adapt to the recent API

[twohot]

Wow! Found some clumsy mistakes. I wonder how 3.x.x series was able to parse the extension in the first place. Now I see a fresh issue.
The extension registers partially via the Extension Manager. The registration does not conclude as expected. Attempting to remove the entry from the Extension Manager throws the following error:

Code: Select all

(com.sun.star.lang.IllegalArgumentException) { { { Message = "Cannot detect media-type: file:///home/twohot/.config/libreoffice/4/user/uno_packages/cache/uno_packages/luzg0jvq.tmp_/myExtension-beta-0.8.1.oxt", Context = (com.sun.star.uno.XInterface) @7fabfd284828 } }, ArgumentPosition = (short) -1 }

Did something change in the way extensions are registered because I didnt touch the manifest and xcu files

[hanya]

Hanya, where can I find the updated MRI extension for LibO 4.0? Would like to do some preliminary checks. Perhaps there are more things I need to adapt to the recent API

Version 1.1.4 supports LO 4.0.

Did something change in the way extensions are registered because I didnt touch the manifest and xcu files

The mechanism of registration database has been replaced with the same implementation from AOO 3.4. But I am not sure it causes the problem.

[twohot]

The mechanism of registration database has been replaced with the same implementation from AOO 3.4. But I am not sure it causes the problem.

Can't seem to find documentation on that mechanism. Its worth a look, just in case.

[hanya]

Can't seem to find documentation on that mechanism. Its worth a look, just in case.

It seems there is no entry in the release note in the version 4. But they have rebased the code to AL2 based one and the change could be included.
But the change should not affected to your user's profile even by you have migrate your user's profile automatically. But I do not know there is the automatic migration mechanism of the user's profile in the LO 4.

[twohot]

It creates a folder at /home/user/.config/libreoffice/4. So you have .../3 and .../4 side-by-side. That means they are isolated from each other. However, I had uninstalled Lib0.3.6 before installing 4.0. I think this is an isolated case.

[twohot]

Peeked into description.xml and manifest.xml in Hanya's MRI tool out of curiosity. A quick comparison shows no major difference except for the MRI.py context. What is that? The implementation approach is intriguing for hobbyists like me. The manifest points to same file ... so I wonder how all the rest of the python module in pythonpath comes into play. ... in which case, what does the defined function create(ctx, *args): blah blah actually do?

Found few notes on the API documentation stating that things got obsolete at OOO3.3. The docs don't seem much different to me. Still clueless as to why I get the error message but it message suggests that LibO is having problems at registration level. The Extension manager also displays the Filename of the extension package instead of the defined "Display name" in description.xml. I think I read somewhere in the docs that that should only happen when the Display name is unspecified. What is really going on?

[hanya]

The manifest points to same file ... so I wonder how all the rest of the python module in pythonpath comes into play. ... in which case, what does the defined function create(ctx, *args): blah blah actually do?

addImplementation method of the implementation helper takes callable object at first argument. The create method wraps its real function, that is imported in the funcion. Nothing special.

What is really going on?

I have no more idea without testing my environment.

[twohot]

Okay, I have stripped the extension down to its bare minimum, which is essentially your snippets (Hanya). It still causes the error/crash. So this is really a registration problem or perhaps we were using a deprecated function or class. In any case, its all here for testing and confirmation.

[hanya]

Is your attached zip archive is just renaming from oxt? If so, structure of the package is wrong. The contents of the package should be placed in the top directory of the zip archive, this causes the extension manager failed to find description.xml file and the package name of the installed extension is shown in the extension manager.

[hanya]

And I met max recursive error in the FrameKeeper.__eq__ method. Should be something like:

Code: Select all

class FrameKeeper(object):
  # ...
    def __eq__(self, other):
        try:
            return self.frame == other.frame
        except:
            return False

[twohot]

Is your attached zip archive is just renaming from oxt? If so, structure of the package is wrong.

You are right, I forgot that requirement

Apart from that, I was right to suspect framekeeper() from the beginning (see first post). However, there were more issues as I later discovered (due to migration to python 3.3). I was doing byte dumps on the pages with Str.encode('utf-8') and reading them with unicode(). The syntax for those has changed. More so, JAVA had its own issues:

Code: Select all

Listening
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000003a47874d13, pid=3271, tid=139991618856960
#
# JRE version: 7.0_09
# Java VM: OpenJDK 64-Bit Server VM (23.7-b01 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libstdc++.so.6+0x74d13]  std::_Rb_tree_increment(std::_Rb_tree_node_base const*)+0x13
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/twohot/hs_err_pid3271.log
#
# If you would like to submit a bug report, please include
# instructions on how to reproduce the bug and visit:
#   http://icedtea.classpath.org/bugzilla
#

I get those errors just prior to a crash in LibO. Its not consistent, sometimes it just works smoothly. I have updated JAVA and I'm monitoring performance. So far, it looks like the case is solved

[hanya]

Sometimes this kind of fatal error cased by Java runtime is shown, but it seems it is produced by the other error.
Maybe such randomly shown error cased by disposing somethings. But it is difficult to find the reason without debug build of the office.