<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""> Stephan, yes, my fix avoids the need to type in the vertical bars. It should apply to all dialogs that ask for an identifier. <div class=""><br class=""> </div> <div class="">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).</div> <div class=""><br class=""> </div> <div class="">John <div class=""> <div><br class=""> <blockquote type="cite" class=""> <div class="">On 15 Nov 2020, at 15:58, Stephan Oepen <<a href="mailto:oe@ifi.uio.no" class="">oe@ifi.uio.no</a>> wrote:</div> <br class="Apple-interchange-newline"> <div class=""> <div class=""> <div dir="auto" class="">further toward perfection in the LKB interfaces :-).</div> <div dir="auto" class=""><br class=""> </div> <div dir="auto" class="">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" class=""><br class=""> </div> <div dir="auto" class="">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" class=""><br class=""> </div> <div dir="auto" class="">cheers, oe</div> <div dir="auto" class=""><br class=""> </div> <div dir="auto" class="">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 class=""> <div dir="auto" class=""><br class=""> </div> <div class=""><br class=""> <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" class="">gete2@cam.ac.uk</a>> wrote:<br class=""> </div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir="ltr" class=""> <div class="">Hi John, Woodley, and Stephan,</div> <div class=""><br class=""> </div> <div class="">Thank you all for your fast responses!  This has been really helpful.<br class=""> </div> <div class=""><br class=""> </div> <div class="">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 class=""><br class=""> </div> <div class="">(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 class=""> </div> <div class=""><br class=""> </div> <div class="">(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 class=""><br class=""> </div> process_complete_command(): `<br class=""> avm 3 #D[null-with-push-1-here RESULT: #D[1 REST: NULL]] "null-with-push-1-here - expanded"<br class="">  '<br class=""> <br class=""> Type of dag was not a symbol or string (type 2)<br class=""> <div class=""><br class=""> </div> <div class=""><br class=""> </div> <div class="">Best,</div> <div class="">Guy</div> <div class=""><br class=""> </div> </div> <br class=""> <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" class="">oe@ifi.uio.no</a>>:<br class=""> </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 class=""> <br class=""> > 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 class=""> <br class=""> many thanks for the quick diagnostics and fixes!  i looked over both<br class=""> your patches, and they seem like just the right fix to two genuine<br class=""> bugs that have been lurking (for the past sixteen or so years :-) in<br class=""> the interactive unifier behind the LUI drag-and-drop interface.  i<br class=""> have just picked them up (and added my own fix for the LUI display of<br class=""> atomic dags) and committed these changes to both the LOGON and FOS<br class=""> repositories.<br class=""> <br class=""> best wishes, oe<br class=""> </blockquote> </div> </blockquote> </div> </div> </div> </div> </blockquote> </div> <br class=""> </div> </div> </body> </html>