[developers] Bug in interactive unification

[John Carroll]

Stephan, yes, my fix avoids the need to type in the vertical bars. It should apply to all dialogs that ask for an identifier.

The same problem occurred with type names starting with a decimal digit but also containing non-numeric characters, such as １０_j in Zhong (where the first two characters are Unicode fullwidth digits).

John

On 15 Nov 2020, at 15:58, Stephan Oepen <oe at ifi.uio.no<mailto:oe at ifi.uio.no>> wrote:

further toward perfection in the LKB interfaces :-).

guy, can you try asking for the type display by typing in |1| (including the vertical bars).  i suspect the prompt windows just uses the lisp read() function, which will interpret a string of digits as a number, rather than as a symbol.  in TDL parsing, however, all (unquoted) type names are interpreted as symbols.  the |...| syntax will force symbol interpretation.  this would be easy to fix, and likely applies in other input routines that prompt for type or grammar entity names.

regarding LUI communication, i am inclined to suggest that this is a bug in the #D[...] reader ... woodley, how could you not agree?

cheers, oe

ps: i had originally drafted this message  yesterday; i suspect the LKB input fix that john has in mind is likely along the lines above?


On Fri, 13 Nov 2020 at 12:36 Guy Emerson <gete2 at cam.ac.uk<mailto:gete2 at cam.ac.uk>> wrote:
Hi John, Woodley, and Stephan,

Thank you all for your fast responses!  This has been really helpful.

I have come across two further small bugs, both to do with type names consisting entirely of numeric characters.  Such names are allowed internally in the LKB, and in terms of unification, they seem to behave exactly as I expect them to.  I couldn't find documentation suggesting that numeric characters should be treated differently.  However:

(1) in the View>Expanded type pop-up window, a string of numeric characters gives the message "Not defined - try again.", even if the type is defined.  (When the pop-up window shows a drop-down instead of a text box, such types appear in the list.)

(2) Displaying such a type causes LUI to crash.  For example, a type named "1" causes a crash, with the following in the log file (where the value of RESULT is 1):

process_complete_command(): `
avm 3 #D[null-with-push-1-here RESULT: #D[1 REST: NULL]] "null-with-push-1-here - expanded"
 '

Type of dag was not a symbol or string (type 2)


Best,
Guy


Am Mi., 11. Nov. 2020 um 21:52 Uhr schrieb Stephan Oepen <oe at ifi.uio.no<mailto:oe at ifi.uio.no>>:
hi john:

> Aha, the constraint object in your LUI log has unbalanced brackets. Guessing which bracket is wrong, I've changed another LKB robust unifier function, and attach a new version of the file debug-unify2-patch.lsp

many thanks for the quick diagnostics and fixes!  i looked over both
your patches, and they seem like just the right fix to two genuine
bugs that have been lurking (for the past sixteen or so years :-) in
the interactive unifier behind the LUI drag-and-drop interface.  i
have just picked them up (and added my own fix for the LUI display of
atomic dags) and committed these changes to both the LOGON and FOS
repositories.

best wishes, oe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20201115/e95ba695/attachment-0001.html>