Re: Bug in crm114 parser? Or is it me again?

On Thu, May 22, 2008 at 10:02 PM, Bill Yerazunis <[email protected]> wrote:
> Something is seriously wrong; I get:
[...]
>  crm: *ERROR*
[...]
>  This happened at line 9 of file ger.crm

YESSSSS!

Sorry for the arm punching the air there, but that at least assures me
my 'vanilla' setup is in sync with yours in this regard. Same here
with vanilla CRM114 on Linux/AMD64.


> which looks like it means that it wasn't happy with all the backslashes
> in your regex.
[...]
> However, that's not the problem you're asking about.

People who know me longer will laugh now. When I'm in a wicked mood,
there's all kinds of questions loaded in another one.


Will you do me a favour?

Have a look at that script I sent you (and which you just tested);
this is not about pulling it through crm114 again, but see with your
own eyes and then tell me:
do you consider this script 'legal' in the sense that it should
THEORETICALLY be accepted and executed by CRM114?

If the answer is yes, good.
If the answer is no: please point me to the bit(s) where I goofed.

(Because this is another Q-in-Q-in-Q-in...: under water this is about
the crm114 compiler internals - way too complex and interrelated for a
bit of quick email on a Thursday night, but your answer to the simple
SCRIPT REVIEW question above is good enough for me, so that I know my
script compiler code does the 'proper' thing at least. What comes
after that, should be part of another discussion: code merge,
etc.etc.etc..)



> If I re-edit the regex to lessen the confusion (there is perhaps
> some nastyness in the code that does backslash expansion)
> from:
>
>  match [:spam:] (:: :spamdir: :spamwildcard:) /^(.*[\\\/])([^\\\/]*)/
>
> to:
>
>  match [:spam:] (:: :spamdir: :spamwildcard:) /^(.*[\/\\])([^\/\\]*)/
>
> which _should_ be identical in behavior, but they aren't, because
> the first one gets an error and the second one works, yielding:
>
>  # crm ger.crm
>  spam source: /dir1/dir2/dir3/ --  -- /dir1/dir2/dir3/
>  OK 1
>  spam source: /dir1/dir2/dir3/* -- * -- /dir1/dir2/dir3/*
>  OK 2
>  #
>
> which is very counterintuitive, and almost *certainly* means we've
> got a subtle bug in backslash expansion.

Wow. You've got better feel for patching scripts than I do. Hadn't
thought of that one.
And, no, I do not consider it a bug per se. Just a subtlety caused by
the language specification.

Anyway: your OK1+OK2 is the _intended_ answer; at least the answer I
intended for the script.

The issue is with OK2: the fact that crm114 says it's OK is due to this:

given the initial path string against which the first regex was
matched, the two subexpressions produced what they should:

\1: a [back]slash terminated path part
\2: an empty filename - as there wasn't any in the input.

I didn't check if it's TRE or CRM internals, but the fact of the
matter is this: the END marker of the variable pointing at the 1
subexpr once we're done with that match statement is _same_ index into
the original string space as START+END for the second (\2) sub
expression carrying variable.

Since, by definition, CRM variables can point to overlapping data
space UNLESS ISOLATED - which I did NOT do - any editing such a
NON-isolated variable will influence the common data space and any
variables pointing at it.

Thus, ALTER-ing the \2 variable to contain '*' will EDIT the common
data space to become extended with '*' as the variable itself will NOT
become isolated due to an ALTER operation - no 'copy-on-write' logic
in crm). As the END marker of the \1 subexpr variable is identical to
the END marker for the \2 variable, which was just ALTER-ed, the \1
var END marker will be shifted to ensure it 'sticks' to its original
spot.

Hence this counter-intuitive result.


In other words: this is a fringe case (that's why the crm test file
was called that too :-) ) of the example of crm code where two wars
point at a common store:

(forgive code errors next: this is off the top of my head)

isolate (:a:) /buggaboo/
match [:a:] (:: :b:) /boo/
# 'b' now points INTO 'a' space
alter [:b:] /FARRR/
# ^ will alter 'a' too as 'b' points into 'a' space
output /:*:a:/
# expected output: "buggaFARRR"


I can't point at a test script which verifies this behaviour right
now, but I'm sure there was at least one in the megatest collection.
Just not for a fringe case like this - which I had the 'luck' to run
into when trying to port mail*.crm to Windows.


-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web: http://www.hobbelt.com/
 http://www.hebbut.net/
mail: [email protected]
mobile: +31-6-11 120 978
--------------------------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/