[logon] Mysterious problem with regexps in transfer rules

[Berthold Crysmann]

According to my impression, CONTEXT is unaffected by this, right?

B

On Sun, 2008-11-16 at 23:57 +0900, Francis Bond wrote:
> G'day,
> 
> I'm glad you copied us all on this.
> 
> > i am impressed you do consider "~(de:_jed_q_rel|de:_fast[+]jed_q_rel)"
> > concise :-).  but i am afraid the behaviour you report is `correct': at
> > the start of transfer, for rule sets that were loaded with `:filter t',
> > all input predicates are compared (as strings) against the `dictionary'
> > of known INPUT predicates in that rule set.  that test, currently, does
> > not take into account regular expressions (though it probably should).
> >
> > a way of working around this limitation could be to normalize predicate
> > names in the first (GG accomoation) phase, and turn off filtering there
> > (relatively few rules, not much of a loss).  this is what we have been
> > doing for the NoEn LOGON system, so i never noticed the limitation :-).
> >
> > but for this to work, `_jed_q' and `_fast+jed_q' have to be considered
> > equivalent, at least for transfer purposes (if you can translate both
> > to `every', you might be willing to make that assumption).  otherwise,
> > i see no alternative currently to breaking the rule into two.
> 
> So that was why the following (in my snug) doesn't match.
> 
> _d_ditch_ef := elision_mtr &
> [ INPUT.RELS < [ PRED "~^ja:.*_d_" ] > ].
> 
> I need to move it into the non-filtered, post-transfer accommodation,
> where it works.
> 
> If only I could commit (^_^).
> 
-- 
PD Dr. Berthold Crysmann <crysmann at ifk.uni-bonn.de>
U Bonn - IfK - Abteilung Sprache und Kommunikation
Poppelsdorfer Allee 47
D-53115 Bonn