Thursday, May 29, 2014

Detail window doesn’t open after insert in slave table

After yesterdays production upgrade, Gerd reported the following problem report (original formulation by an end-user):

Wenn man eine Notiz eingibt, kann man nur noch erstellen. Und nicht mehr erstellen und bearbeiten. Praktisch müssen wir es also erstellen und dann wieder öffnen bevor wir was im Inhalt eintragen können. Lästig…

This was a genuine bug. It is again our well-known situation after a dd.SubmitInsert action. This action calls ar.goto_instance (to display the new record) and ar.close_window (to close the insert window).

Lino.handle_action_result() uses a variable panel for “the current panel”. Ater closing a window, panel points to the main item of the previous window. We got already that far, but here we had the case of an insert window that has been invoked by double-clicking on the phantom row of a slave table in a detail window. This wasn’t yet handled correctly. In that case we want panel to become the slave table grid panel who opened the insert window, and not the main panel of the master’s detail window. That’s why Lino.close_window() now returns the requesting_panel of the window which was closed.

More about tagging

This is a first bug in Lino 1.6.13, and I am tempted to change the v1.6.13 tag because:

  • it has not yet been officially released on PyPI

  • I can update Gerd’s production site without a need for data migration.

One can say that Gerd’s production site serves as guinea pig, and that my first v1.6.13 tag should rather have been v1.6.13rc1.

Simply overwriting the existing tag doesn’t work:

$ git tag -a v1.6.13 -m "after first bugfix"
fatal: tag 'v1.6.13' already exists

So I try by deleting it first:

$ git tag -d v1.6.13
Deleted tag 'v1.6.13' (was ce2ebd3)
$ git tag -a v1.6.13 -m "after first bugfix"

But oops, when I try to push my changed vision of what v1.6.13 should mean, I get:

$ git push origin v1.6.13
To git@github.com:lsaffre/lino.git
 ! [rejected]        v1.6.13 -> v1.6.13 (already exists)
error: failed to push some refs to 'git@github.com:lsaffre/lino.git'
hint: Updates were rejected because the tag already exists in the remote.

It seems that we must accept the fact that v1.6.13 will always be a buggy version because we cannot change an annotated tag once it has been published.

So I undo my attempt:

$ git tag -d v1.6.13
Deleted tag 'v1.6.13' (was bebb5c5)

$ git pull origin v1.6.13
From github.com:lsaffre/lino
 * tag               v1.6.13    -> FETCH_HEAD
Already up-to-date.

Using the GPL for documentation

I read on http://www.gnu.org/licenses/licenses.en.html:

Documentation for free software should be free documentation, so that people can redistribute it and improve it along with the software it describes. To make it free documentation, you need to release it under a free documentation license. We normally use the GNU Free Documentation License (GNU FDL), but occasionally we use other free documentation licenses.

And then asked on <fsfe-de@fsfeurope.org>:

Heißt das, dass meine Verfahrensweise nicht ganz korrekt ist? Ist meine Dokumentation nicht automatisch auch frei, wenn sie unter der GPL steht? Was kann ich tun, damit es korrekt ist?

Answer is: don’t worry. The GPL is okay for documentation, and the FDL has numerous problems.

Online demos updated

I made a pull and an initdb on the Online demo sites.

For example the Lino Così demo (at http://demo4.lino-framework.org/) now shows the cool new lino.moxlib.export_excel module contributed by Joe: just open some table and click on the Excel icon in the button toolbar.

Ta-daa, I finally worked on lino.utils.ajax.AjaxExceptionResponse which had the problem of working only when DEBUG was true. Yes, on a production server it is not wise to publish the traceback, but our nice HTML formatted “Congratulations, you found a problem” page was not the right answer to an AJAX call.

This helped me to fix a bug which I introduced myself into Joe’s code.

How to reach the host machine from a virtual client

Worked on docs/tickets/106.

Trying to reproduce it myself. In my case the problematic client is under Windows in a VirtualBox.

I had the problem that I didnt figure out myself how to have that virtual machine connect to the development server running on my host. Pointing the browser in that virtual machine to http://127.0.0.1:8000 did not get there.

Thanks here to Naftuli Tzvi Kay who asked exactly my question in Juli 2011 and then answered it himself the next day:

Q: I’d essentially like to access my host computer from the guest in VirtualBox. Is there an IP address given for my host which I can use from the guest? Are there extra steps required to set this up? I’d like to access my host’s Apache, FTP, and SSH services.

A: In the default setup, you should be able to reach your host through your default gateway, in my case 10.0.2.2. You can easily determine this IP address in Windows via ipconfig. (…)

(Source: Connect to the host machine from a VirtualBox guest OS?)

Aha. The default gateway on my virtual client machine is:

C:\Documents and Settings\Luc Saffre>ipconfig

Windows IP Configuration

Ethernet adapter Local Area Connection 3:

        Connection-specific DNS Suffix  . : lan
        IP Address. . . . . . . . . . . . : 192.168.1.65
        Subnet Mask . . . . . . . . . . . : 255.255.0.0
        Default Gateway . . . . . . . . . : 192.168.0.2

So on my virtual browser, instead of pointing it to http://127.0.0.1:8000 I must point it to:

Finally! One long lasting problem solved.

Now the next problem is: I still can’t reproduce it! Both DavLink and eidreader work perfectly under Windows XP using Oracle Java:

Java Plug-in 10.60.2.19
Using JRE version 1.7.0_60-b19 Java HotSpot(TM) Client VM