LUI not displaying some feature structures

I’ve found a couple of edge cases where viewing a feature structure in LUI throws an error, but there’s no problem with LKB native graphics. (I don’t know whether it would be easier to fix these problems on the LUI side or the LKB side.)

One case is where the feature structure has no features, e.g. displaying the type null. (Viewing such a structure isn’t very informative in itself, but it makes it easy to use the type in interactive unification.)

A second case is where a type name (somewhere in the feature structure) only consists of numeric characters.

Representative examples from the log file (/tmp/pangolui.debug.ubuntu):

process_complete_command(): `
avm 54 #D[null] "null - expanded"
 '

YZLUI: Received unknown lkb-protocol top-level command: AVM
process_complete_command(): `
avm 93 #D[test TEST: 1] "test - expanded"
 '

Value dag for 'TEST' was not a dag (type 2)
YZLUI: Received unknown lkb-protocol top-level command: AVM

Do you have a minimal work example so we can try to reproduce the error? I am not saying I will be able to solve them ;-), but I can try check if I can reproduce in another environment… may it can help the developers…

A mimimal grammar which allows the two examples given above:

null := *top*.
1 := *top*.
test := *top* &
  [ TEST 1 ].

After compiling the grammar, you can try to view the expanded type constraints for the types null and test.

For me, LUI displays the type null fine. For type names that look like integers I get two different kinds of errors, depending on whether the type is embedded or not. Here are the 3 cases:

null → Expanded type: success

process_complete_command(): `avm 13 #D[null] “null - expanded”

1 → Expanded type: failure

process_complete_command(): `
avm 12 #D[1] “1 - expanded”

Type of dag was not a symbol or string (type 2)
Error: tried to browse a NULL avm structure!

test → Expanded type: failure

process_complete_command(): `avm 14 #D[test TEST: 1] “test - expanded”

Value dag for ‘TEST’ was not a dag (type 2)
YZLUI: Received unknown lkb-protocol top-level command: AVM

This is on Linux with the latest LKB-FOS binary and yzlui version 0.9:

$ which yzlui
/usr/local/bin/yzlui
$ /usr/local/bin/yzlui -v
pangolui version 0.9
$ ls -l /usr/local/bin/yzlui
-rwxr-xr-x 1 root root 586358 Aug 1 2013 /usr/local/bin/yzlui

The LKB / LUI interface doesn’t provide a way of indicating that a type name that looks like an integer should actually be treated as a symbol, so I can’t fix this on the LKB side; @sweaglesw , can you help?

I’m also on Linux (VirtualBox), with the latest release of LKB-FOS, and the same version of yzlui.

I’ve realised that actually the problem with null appears to be to do with some additional settings, which make it the type for empty lists. I was previously loading the Grammar Matrix’s globals.lsp. If I don’t load that file, then I get the same behaviour as @johnca.

So I’ve included the standard list types, and a couple of extra types to see the difference:

list := *top*.
null := list.
cons := list &
  [ FIRST *top*,
    REST list ].

sub-null := null.
what := *top*.
3 := *top*.
test := *top* &
  [ TEST 3 ].

I’m now using a script that loads just those two files:

(lkb-load-lisp (this-directory) "globals.lsp")
(read-tdl-type-file-aux (lkb-pathname (parent-directory) "mini.tdl"))

Then there is a different result for the types what and null:

process_complete_command(): `avm 2 #D[what] "what - expanded"
 '

process_complete_command(): `avm 2 #D[null] "null - expanded"
 '

YZLUI: Received unknown lkb-protocol top-level command: AVM

The types list and null fail to display. But the other featureless types what and sub-null display just fine.

For types that look like integers, I have the same two cases as @johnca.

OK, it’s clear now that LUI can’t display dags containing types that look like integers.

The other case of list and null in mini.tdl seems to be dependent on what information the LKB transmits to LUI about the names of the list type and the empty list type. Without the matrix globals.lsp file, the LKB transmits the (different) defaults for the names of these types, and LUI displays the types fine. When the information matches, LUI fails to display these types.

The 2018 ERG also provokes this bug. The following ERG types fail to display in LUI: *list*, *null* – and also *cons* and all descendants of *cons* (the latter apparently due to a related bug concerning the head and tail features in lists).

It seems that LUI can’t cope with these special types if they are the top level of a dag. @sweaglesw, can you verify this?

2 Likes

The issue with numbers is familiar from the past. My recollection is it was worked around by quoting the type names in some cases, but that is not optimal. LUI should be improved to accept bare numbers. I’m not sure when that will happen though.

Your report about list types sounds entirely believable. LUI tries to display lists using <x, y, z> notation, and it probably isn’t smart enough to disable that trick at the top level. A possible work around could be to change the list type parameters before invoking display. Again this will go on the LUI todo but I am not actively developing that software.

I’ve been experimenting, and even quoting numeric type names doesn’t work: LUI seems to strip the quote and then complains that what it’s left with is a number. A work around might be to use other unicode characters that look like decimal digits, e.g. those from the Halfwidth and Fullwidth Forms block. On the other hand, this might well uncover further bugs…

For the list types issue, I’ve got a very ugly LKB-side work around. @guyemerson, I’ll send it to you.

BTW, while investigating these problems, I noticed that the lkb/globals.lsp file of almost every major DELPH-IN grammar omit to set the parameter *non-empty-list-type* (Jacy seems to be the only exception). The default value for this parameter is *cons*, which is appropriate for the ERG but wrong for many other grammars, where it should be cons or ne-list.

To work around the numeric type names issue I was trying to single-quote them - as in the old TDL syntax - which didn’t work. Double-quoting them does work; this is because LUI does not make any distinction between string and non-string types. It took me a while to realise this. (An unfortunate consequence is that LUI pop-up menus on string types contain spurious commands).

I’ve now got happier-looking LKB-side work arounds for both of these issues. I’ll commit them very soon, and email the patch to @guyemerson and anyone else who asks.