LKB-FOS & Matrix incompatibilities?

LKB
#1

I’m playing with LKB-FOS (most current version) and this grammar (derived from @olzama’s Matrix sandbox + my standard choices file for Lab 1 for 567) and hitting various incompatibilities. The first is that there’s an empty trigger.mtr file, which LKB-FOS doesn’t like. Commenting out the call to load that from lkb/script then gives me this error when I try to load:

The value
NIL
is not of type
MT::SEMI
[Condition of type TYPE-ERROR]

In the LKB buffer, this is what I see:

  • (lkb::read-script-file-aux “~/567_english/lkb/script”)
    ; loading #P"~/567_english/lkb/script"
    ;; loading #P"/home/ubuntu/567_english/Version.lsp"
    ;; loading #P"/home/ubuntu/567_english/lkb/globals.lsp"
    set-coding-system(): activated UTF8.
    ;; loading #P"/home/ubuntu/567_english/lkb/user-fns.lsp"
    read-repp(): reading file `vanilla.rpp’.

Reading in type file matrix
Reading in type file head-types
Reading in type file 567_english
Reading in type file mtr
Checking type hierarchy
Checking for unique greatest lower bounds
Created 408 glb types
Expanding constraints
Making constraints well formed
Expanding defaults
Type file checked successfully
Computing display ordering
Reading in lexical entry file lexicon
Reading in rules file rules
Reading in lexical rules file lrules
Reading in lexical rules file irules
Reading in root file roots
Reading in parse node file labels
;; loading #P"/home/ubuntu/567_english/lkb/mrsglobals.lsp"
read-vpm(): reading file `semi.vpm’.
;; loading #P"/home/ubuntu/567_english/lkb/mt.lsp"
Indexing starting…
(recompiling semantic indices)While evaluating the form starting at line 123, column 0

@johnca do you have any suggestions as to what I might need to fix in my grammar so that it can load?

Thanks!

#2

@ebender The error is due to a change to predicate normalisation made by Stephan that I hadn’t spotted: since the last LKB-FOS release, the variable mrs::*normalize-predicates-p* is set to t by default (it used to be nil). Here’s the accompanying comment:

;;;
;;; finally, we are eliminating the symbol vs. string contrast on predicates;
;;; whereas a grammar might use either one (or both, even for the abstractly
;;; same predicate, e.g. _afterwards_p and “_afterwards_p” in the 1214 ERG),
;;; these shall be treated as equivalent in the MRS universe. also, we will
;;; now always strip the (optional) sem-relation-suffix (‘_rel’ in the ERG)
;;; from predicate names, as this is a mechanism on the TFS side only (to give
;;; the grammar something like a separate namespace for its predicates). in
;;; the past, some MRS serializations suppressed the symbol vs. type contrast,
;;; some exposed it; likewise, some stripped the suffix, and others kept it.
;;; see the discussion on the ‘developers’ list from january 2016 for details.
;;;
;;; to make moving into a better future less painful, we used to preserve the
;;; traditional behavior (by default) for at least a transition period. but ERG
;;; 1214 already shipped with predicate normalization enabled. in mid-2020
;;; (alongside the grand FOS and LOGON code merger), we finally turn the switch
;;; to enforce predicate normalization by default. however, it is possible the
;;; option needs to remain available for backwards compatibility, for example
;;; when working with grammars that lack a full-fledged SEM-I …
;;;

A solution to your problem would be to execute (setq mrs::*normalize-predicates-p* nil) at some point before attempting to index for generation.

I’ll take a look at the empty trigger.mtr file issue now.

#3

Thank you, @johnca!

My apologies for a million questions this week, but here’s another one: Do we expect LKB-FOS on Linux to get long with lui? (Just now, ace isn’t even working with lui on the current Ubuntu+LKB disk image and @bmgraves is looking into it, so the fact that (lui-initialize) just gives “[NIL] lsp-loop(): premature end of file (read 1 characters)” might be that I just don’t have lui in this set up yet…)

#4

@ebender @bmgraves Lui should work fine. The first thing to check is that yzlui is in the default PATH. This is what I see in my old Ubuntu+LKB image:

$ which yzlui
/opt/delphin/lkb/bin/linux.x86.32/yzlui
$ echo $PATH
/home/ubuntu/logon/bin:/home/ubuntu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/opt/delphin/lkb/bin/linux.x86.32:/opt/trollet/
#5

Thanks! That helps.

#6

I can only provoke an error if I create an “empty file” containing non-printing characters that are not in the ASCII whitespace set, e.g. non-breaking space (Option-Space on the Mac).

In Unicode there are a further 20 or so horizontal and vertical space characters. http://moin.delph-in.net/wiki/TdlRfc specifies whitespace via the character class \s, but it doesn’t say whether this is the ASCII or Unicode notion of whitespace. I’d rather stick to the former since I can’t see any reason to use the larger Unicode set.

#7

Interesting — with the fix above for normalize-predicates-p I can’t reproduce it either. So, all set on this one. Thanks!