<div><div dir="auto">further toward perfection in the LKB interfaces :-).</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">regarding LUI communication, i am inclined to suggest that this is a bug in the #D[...] reader ... woodley, how could you not agree?</div></div><div dir="auto"><br></div><div dir="auto">cheers, oe</div><div dir="auto"><br></div><div dir="auto">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?</div><div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 13 Nov 2020 at 12:36 Guy Emerson <<a href="mailto:gete2@cam.ac.uk" target="_blank">gete2@cam.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi John, Woodley, and Stephan,</div><div><br></div><div>Thank you all for your fast responses! This has been really helpful.<br></div><div><br></div><div>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:</div><div><br></div><div>(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.)<br></div><div><br></div><div>(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):</div><div><br></div>process_complete_command(): `<br>avm 3 #D[null-with-push-1-here RESULT: #D[1 REST: NULL]] "null-with-push-1-here - expanded"<br> '<br><br>Type of dag was not a symbol or string (type 2)<br><div><br></div><div><br></div><div>Best,</div><div>Guy</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mi., 11. Nov. 2020 um 21:52 Uhr schrieb Stephan Oepen <<a href="mailto:oe@ifi.uio.no" target="_blank">oe@ifi.uio.no</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">hi john:<br>
<br>
> 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<br>
<br>
many thanks for the quick diagnostics and fixes! i looked over both<br>
your patches, and they seem like just the right fix to two genuine<br>
bugs that have been lurking (for the past sixteen or so years :-) in<br>
the interactive unifier behind the LUI drag-and-drop interface. i<br>
have just picked them up (and added my own fix for the LUI display of<br>
atomic dags) and committed these changes to both the LOGON and FOS<br>
repositories.<br>
<br>
best wishes, oe<br>
</blockquote></div>
</blockquote></div></div>
</div>