rules missing

[epageperron]

Using https://cdli-dev.mpiwg-berlin.mpg.de/inscriptions/add
When changing the line 2. mu-kux(DU) to 2. mu-kux (DU) with ATF from P123456, it doesn't give an error.

• signs with x should be followed by a sign in parenthesis
• there shouldn't be stuff in parethesis preceded by a space.

Also

&P123456 = OIP 115, 164
#atf: lang sux
2. mu-kux(DU)

Also goes through, no declaration of object or surface

[darth-cheney]

@epageperron:

Regarding this part of the issue:

Also goes through, no declaration of object or surface

I can't replicate this at a low level in jtf-lib. In other words, I am indeed getting a parser error with that example.

The following little script:

const { ATF2JTF } = require("./src/Converters/ATF2JTF.js");

const example = `&P123456 = OIP 115, 164
#atf: lang sux
2. mu-kux(DU)`;

ATF2JTF(example, '', false);

Produces this output in the terminal:

!!!!!!!! Syntax error at line 3 col 1:

  2. 
  ^
Unexpected LINE token: "2. ". Instead, I was expecting to see one of the following:

A HASH token based on:
    startP →  ● %HASH %protocolStart startP$subexpression$1 endtext
    start$ebnf$1$subexpression$1 →  ● startP NL
    start$ebnf$1 → start$ebnf$1 ● start$ebnf$1$subexpression$1
    start → ampStatement NL ● start$ebnf$1
    main → main$ebnf$1 ● start inter main$ebnf$2 END
A HASH token based on:
    comment →  ● %HASH %comment
    start$ebnf$1$subexpression$1 →  ● comment NL
    start$ebnf$1 → start$ebnf$1 ● start$ebnf$1$subexpression$1
    start → ampStatement NL ● start$ebnf$1
    main → main$ebnf$1 ● start inter main$ebnf$2 END
A AT token based on:
    object →  ● %AT %object
    OBJECT$subexpression$1 →  ● object NL object_tail
    OBJECT →  ● OBJECT$subexpression$1
    inter$ebnf$1 →  ● OBJECT
    inter →  ● inter$ebnf$1
    main → main$ebnf$1 start ● inter main$ebnf$2 END
A AT token based on:
    object →  ● %AT %object_cont object$ebnf$1 endtext
    OBJECT$subexpression$1 →  ● object NL object_tail
    OBJECT →  ● OBJECT$subexpression$1
    inter$ebnf$1 →  ● OBJECT
    inter →  ● inter$ebnf$1
    main → main$ebnf$1 start ● inter main$ebnf$2 END
A AT token based on:
    seal_object →  ● %AT %seal_object endtext
    OBJECT$subexpression$1 →  ● seal_object NL seal_object_tail
    OBJECT →  ● OBJECT$subexpression$1
    inter$ebnf$1 →  ● OBJECT
    inter →  ● inter$ebnf$1
    main → main$ebnf$1 start ● inter main$ebnf$2 END

Unless I have misunderstood something, it might be the case that this error is being swallowed higher up in the application stack?

[darth-cheney]

@epageperron I can also now confirm that the second error you are reporting (space between qualified sign reading and its name) is also giving an error at the low level of the library.

Here is a quick scripted example:

const { ATF2JTF } = require("./src/Converters/ATF2JTF");

// NOTE: I've added the object and surface type
// so that the parser doesn't error on those
const example2 = `&P123456 = OIP 115, 164
#atf: lang sux
@tablet
@obverse
2. mu-kux (DU)`; // Space added here

ATF2JTF(example2);

The terminal output is catching the error as far as I can tell:

!!!!!!!! Syntax error at line 1 col 11:

  mu-kux (DU)
            ^
Unexpected prtC token: ")". Instead, I was expecting to see one of the following:

A num_s token based on:
    index_num →  ● %num_s
    index →  ● index_num
    VAL$ebnf$1 →  ● index
    VAL → %VAL ● VAL$ebnf$1
    VALUE →  ● VAL
    anyValue$subexpression$1 →  ● VALUE
    [... etc ...]

I suspect as with the object/surface declarations that something higher up is swallowing these errors.

[larsgw]

Errors are put in a field in the returned JTF I think, so they would always be caught (and the logging isn't necessary, I think).

[darth-cheney]

Errors are put in a field in the returned JTF I think, so they would always be caught (and the logging isn't necessary, I think).

Sounds like this must be an issue at the web application level then, right? (I can't access the original link in provided in the first post of this issue) jtf-lib itself doesn't seem to be doing the wrong thing here.

[epageperron]

I'll open an issue on the framework side, we can keep this open until the other one is resolved I think