Finally getting the LanguageTool Grammar-Checker to work under Debian.

One of the software products which Linux has traditionally been lacking in, is grammar-checking software, that runs off-line. And one such package that I’ve been keen on getting to work, under Debian / Stretch as well as under the older Debian / Jessie, is LanguageTool. Why this LibreOffice extension? Because I would mainly want German and English support, while the product also offers some French support, the last of which can always come in handy in a Canadian province, which is officially French-speaking. The need can always arise, to write some letter in French, and a letter in which the grammar will need to be correct.

There do exist other proprietary solutions, but none which add full support for German.

When I write that I’ve been ‘keen on getting (this) to work’ , I’m referring to the fact that this extension can be a bit temperamental. As I was activating version 4.3 on my Debian / Jessie laptop ‘Klystron’ , I noticed that I had versions 2.3 and 3.8 already-downloaded there, that were left on my hard drive from past, forgotten failures. So, what I learned while installing v4.3 on ‘Plato’ , my main, Debian / Stretch computer, would be put to the test. If the attempt to install v4.3 on ‘Klystron’ also, worked on my first try, then these would be valid observations made, when previously working to get the same version working on ‘Plato’ . And my result was, that I could get v4.3 to work on ‘Klystron’ as well, on the first try!

( Screen-Shot from the computer ‘Plato’ . )

During my recently-failed attempt to get this extension working on ‘Plato’ , I had gotten to a series of error-messages while clicking on ‘Tools -> LanguageTool -> Options…’ , that amounted to Java Null-Pointer Exceptions. Usually, such exceptions would indicate some serious programming error. But what I found was that I could get the extension to work, if I followed 4 basic guidelines:

(Updated 12/25/2018, 14h20 … )

Integrating Sage with LyX

I have been interested in the LaTeX typesetting system, but not in actually learning the extra syntax. And so I’ve been using a WYSIWYM GUI named ‘LyX‘. The .TEX-Files LyX exports are suitable to creating HTML Files, which in turn can contain typeset Math, by way of scripts, that provide MathJax code.

But then one compromise this has meant for me was, that I could either typeset Math which I had written myself, or that I could do Computer Algebra, the latter through the use of ‘wxMaxima’, which has its own system of exporting to HTML. But so far, I could not do both in one document.

Well, now that I have ‘SageMath’ and ‘SageTeX’ installed, I can do both within the same document. It’s possible to integrate SageTeX into LyX. The following is an article which explains how to do that, under the assumption that the user has both SageTeX and LyX installed:

https://wiki.lyx.org/Layouts/Modules#toc7

There is an important way in which I needed to modify the instructions however, to get the two working. First of all, there is a list of files to download – LyX does not support SageTeX out of the box – that the article above links to. Out of those files, ‘setup.sh’ is absolutely useless on a modern Linux computer. The following files from the repository above are essential:

1. sage.module
2. preferences
3. compile-pdf-sage.sh
4. example.lyx

The file ‘preferences’ needs to be edited, in that its last line needs to be uncommented.

The file ‘compile-pdf-sage.sh’ needs to be edited, in that the first two lines need to be commented out, and the next three lines which are commented by default, need to be uncommented. Then:


(As user:)

$mkdir -p ~/.lyx/layouts$ cp sage.module ~/.lyx/layouts
\$ cat preferences >> ~/.lyx/preferences

(As root:)

# cp compile-pdf-sage.sh /usr/local/bin
# chmod a+x /usr/local/bin/compile-pdf-sage.sh




Then, within the GUI of LyX, one gives the command ‘Tools -> Reconfigure’. One shuts down and restarts LyX. Next, one opens ‘example.lyx’ to test the setup. The following is the document which I finally obtained (successfully), which was provided by the Web-site above (not written by me):

http://dirkmittler.homeip.net/sg_lyx_1.pdf

(Update 2/22/2019, 2h05 : )

I suppose that I should warn other users, that, even when one has ‘installed’ this extension to LyX properly, it will not cause SageMath figures to appear in the editing view. Instead, the editing view will contain the actual SageTex code. But, when one clicks on ‘File -> Export -> PDF (pdflatex+sagetex)’, then, a PDF-File will be output that contains the figures, such as the PDF File above.

(Update 2/24/2019, 15h15 : )

I can also elaborate that, the editing of the two text files which I recommended above, merely has as purpose, to enable the use of the module in a single-step process, which is by default written to work in a two-stage process.

The way in which the author of the module intended for it to be used was that users should click on ‘File -> Export -> SageTex’, and obtain a LaTeX File, which they’d need to compile from the command-line, to arrive at an actual document. The way to do that would have been, to run the ‘pdflatex’ command on it, then, to run the ‘sage’ command on the .sage File that results, and then, to run the ‘pdflatex’ command on the original .tex File again. The supposed advantage of that would have been, that users could also edit the SageTex File output, before compiling it, ?

But the way the module was originally written – by the same author – allows for a PDF File to be output, with a single click from within LyX, when those two text files are edited as he recommended, and as I wrote above. I felt that it would be more satisfying both for me, and perhaps for readers of this blog, to be able to obtain a document in one click. And when the two files have been edited like that, the option still exists within the GUI, to export to SageTex format, which can still be compiled from the command-line…

I should add that, if the goal was to compile this sort of file from the command-line, then, it becomes necessary to obtain a Sage-File, if need be from the .TEX-File, and then actually to run ‘sage’ on the Sage-File, at which point Sage is performing its Math. Only after that, can the corresponding .TEX-File be compiled for a second time, into a document that displays correctly. If the step was omitted, to run Sage on the Sage-File, then at no point will the final document actually contain solved Math.

I suppose that a further question could be asked which would be:

‘In the one-step process, “pdflatex” is used twice, as it should be. But if we wanted output in some other format, would it be possible to Export the document from LyX as a SageTex document, and then merely to run “latex” on it, where appropriate?’

And the short answer is, ‘Only if the .TEX-File is edited accordingly.’ The slightly longer answer would be:

As it stands, the .TEX-File will export images into a separate folder, as .PDF-Files, that contain the plots. The simpler ‘latex’ command cannot use anything other than .EPS-Files as images. So the .TEX-File would need to be modified, to generate the .EPS-File (by deleting any occurrences of ‘[pdf]’), and then in principle, EPS Images should be generated, alongside PDF Images, and the .EPS-Files used.

Just to make the above exercise more confusing, a .DVI-File will be output, which ‘xdvi’ might not preview correctly, in that it will seem to contain a blank rectangle where the plot should be. The error message is then output by ‘xdvi’, that ‘gs’ doesn’t recognize the output device ‘x11′. Yet, when ‘dvips’ is next run on the .DVI-File, a correct .PS-File results, that contains the plot.

This modern problem with ‘xdvi’ can be solved, by installing the package ‘ghostscript-x’, which enhances the way ‘gs’ works, and also allows ‘xdvi’ to preview the .DVI-File properly.

Further, a plausible question could be:

‘What will happen if I simply click on “File -> Export -> Sage” ?’

And AFAIK the answer would be, that the file output only contains the Math for Sage to solve. The rest of the LyX Document, with text etc., will not be contained in that file.

AFAIK, That export option is ultimately only useful, if ‘File -> Export -> SageTex’ is also used.

(Update 2/24/2019, 16h20 : )

I suppose that yet another plausible question to ask might be, ‘What advantage did the author see, in a two-step process, that requires manual compilation?’

The best answer I can think of would be:

The actual step of running ‘sage’ on the Sage-File, is also the slowest. A situation is conceivable in which the actual Math to solve is very complex, but in which minor editing of the document is needed, after which to recompile would not require that the Math be redone.

For the purposes of this posting, the computer is fast, the Math is still straightforward, and the reader needs an easy-to-follow guide on how to get the integration of ‘SageTex’ into ‘LyX’ working.

(Update 2/25/2019, 8h45 : )

Since some of my readers may want to obtain a preview of their document, before actually exporting the final PDF, if the configuration files have been edited as I wrote, the way to do that is ‘Document -> View (Other Formats) -> PDF (pdflatex+sagetex)’.

(Update 6/09/2019, 18h05 : )

I suppose that one idea users might get would be, that SageTex integration into LyX can make LyX a good, graphical front-end to Sage. And I suppose that this idea will be true, as long as the user never makes any syntax errors, in the Sage commands, either in the ‘sageblock’ or the ‘sagedisplay’ paragraphs.   When using the actual ‘sage’ program either from a text-command-console, or from within ‘Jupyter‘, then a benefit will be that SageMath will output error messages, whenever it was unable to evaluate an expression for any reason.

If some such error takes place within LyX, then, the value to be displayed, finally, will simply consist of two question marks. This situation is not to be confused with the result, of two question-marks with a yellow background, which indicate an error in the SageTex integration into LyX, or just, in the encoding of the final document. But simply given two question marks, the user would need to ‘guess’ at where his error was, within the actual Sage code, that Sage could not evaluate. Further, SageTex has the quirk, that it can sometimes generate final documents, in which some but not all the Sage outputs seem to be displayed, even though Sage crashed at some point, when the LyX document was being processed. In short, this can be visualized as partial outputs being stored, from a previous attempt to render the entire document.

LyX remains a convenient way to typeset Sage output – especially plots – as parts of a complex document, on the assumption that the commands given to SageMath contain no errors.

Enjoy,

Dirk

Update to ‘polkit’ and ‘libpolkit’ today.

Modern Linux computers, that have a considerable GUI, also have a feature called ‘polkit’. The purpose of this feature is not hard to understand. There exist certain operations which require ‘root’ privileges on a Linux computer, but actual users run Graphical User Interfaces, in ‘user mode’, i.e, without elevated privileges. Usually, Linux users want to be able to do such things as to install and update packages, which requires ‘root’ privileges, but want to be able to do so using the GUI. And so the way the feature ‘polkit’ is organized, there exists a daemon running as user ‘root’, which can among other things update packages, and there exists another daemon running as the specific user, which makes requests to the ‘root’ polkit daemon, to update packages. The root daemon carries out the requested action.

This arrangement may seem to make more sense for Ubuntu, where there is no such thing in a pronounced way, as ‘root’, as there is under Debian. But even some Debian setups have partial Ubuntu installs running, and many Debian users also like the ease, of being able to install a package, just by clicking on it, and then, by convincing the ‘root’ polkit daemon, that the user in question is privileged enough to do so.

Well today, my two Debian / Jessie systems, which I name ‘Phoenix’ and ‘Klystron’, have received routine updates to the polkit packages themselves. But the rather unbalanced, immediate result of this is, that on both these computers, the user-space daemon is still running the old binary, from before the update, while a new ‘root’ daemon has been launched, as part of the update. The two versions of ‘polkit’ running on both these computers, may or may not continue to be compatible with each other.

If they should turn out to be incompatible, then in the very near future I’ll need to reboot both computers as well, which could therefore also lead to brief downtime for this blog.

I’m keeping my fingers crossed, that the new service may be running in a way that remained compatible, with the old client.

Dirk