building the standard on a branch seems to fail.

[kohlhase]

the run script in travis does not seem to work, see the messages in #50

[davidcarlisle]

that's odd, it doesn't actually show any error it just stops where it was expected to stop but then says it had a non zero status so flags as error. Perhaps my test for not pushing to the website on pull requests and branches isn't quite right, but it built for my uri-iri branch. I will look...

[davidcarlisle]

This fails in the pdf generation because

Package pdftex.def Info: Requested size: 244.91438pt x 91.34102pt on input line
 588.
! Undefined control sequence.
l.608 \xxxxxx
             \textcolor)

So there are two issues one why is it failing (either an error in the markup or in the transformation, I'll check later)

The other issue is why didn't travis show something more helpful.

The reason for second issue is that latex gets run 4 times (to sort out cross refs etc) and the log is rather noisy so I run it in batch mode so it only goes to the log not the terminal. that's OK locally as the log is there but on travis of course it is discarded along with the VM.

I'll experiment to find a compromise, I could just cat the log at the end (so you always get one, not 4) or perhaps it will be enough to just grep the log for [Ee]rror or lines beginning with ! then in general you won't get anything.

But either way travis wasn't lying, it said the build failed because the build failed:-)

[davidcarlisle]

Oh the input is not valid, which does not help:-)

rxp -sxV omstd20.xml 
Warning: Start tag for undeclared element mover
 in unnamed entity at line 633 char 11 of file:///home/OMSTD/omstd20.xml

Perhaps I should get travis to validate the input as first thing and stop there. (I always use a validating editor so its not an issue in that case as I know even before trying to save the file if it's valid or not)

the dtd uses a very constrained version of docbook and mathml, restricted in particular to the elements handled by the transformation. I can add <mover> but it is not handled yet (and declared invalid on input)

[kohlhase]

Oh, I did extend omstd20.rnc, but I did not run trang I must confess.

[kohlhase]

sorry.

I guess the run script could do that.

[kohlhase]

that's what you get for using nxml-mode in emacs. Everything looks valid.

[davidcarlisle]

that's what you get for using nxml-mode in emacs.

Is there any other editor?

Everything looks valid.

well only because you extended the schema so making it look valid:-)

The schema is intentionally constrained to elements that work through the entire pipeline if you extend it you have to extend the processing to cope with the new elements.

Oh, I did extend omstd20.rnc, but I did not run trang I must confess.

You can't run trang over the schema as is because I used too many relax features with fancy & combinations so you need to simplify the schema so trang works then edit back in the dtd features that you over-simplified for trang and edit back in any entity definitions for entities used in the source, so in practice it means that starting from where we are now it is easier just to hand edit the dtd and relax to keep them in sync, that's why they are both checked in not made on the fly in the build script.

[kohlhase]

oh wow, can't we just rxp with the rng? Ah, we need the DTD for the entities,.... can't we do without? would it help if I reverted the changes and used <mi mathvariant="bold"> instead the <mover>?

[davidcarlisle]

if we want to drop the entities then we don't need a dtd at all currently its just OM , exml and longrightarrow (and zsp which does nothing useful) I considered doing those but I set myself a constraint of changing the underlying dtd from stock dockbook without changing the content of the document markup and possibly getting merge conflicts etc.

It's not really a big issue now it's there, adding mover to the dtd and relax in sync is less effort than discussing it and less effort than actually making it work in the tex transformation:-)

There's no need to revert the changes I'll fix up <mover> to work later (this evening possibly)

[kohlhase]

thanks.

[davidcarlisle]

As a test can you merge the run script that I checked in to master into your alpha-conversion branch and see if you get the log file in travis now after a tex error I think you should but it's a bit hard to test locally.

On 5 October 2017 at 10:25, Michael Kohlhase notifications@github.com wrote:

thanks.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/OpenMath/OMSTD/issues/52#issuecomment-334410472, or mute the thread https://github.com/notifications/unsubscribe-auth/ABNcAlwpwskJntkAPyVKH3l5-I4Iht0Fks5spKCmgaJpZM4Puj8q .

[kohlhase]

indeed, I am getting the error you described above. How can I fix that?

[davidcarlisle]

indeed, I am getting the error you described above. How can I fix that?

Just wait for me to fix the transformation so it doesn't generate errors on <mover> and then it should make a clean build.

On 5 October 2017 at 10:59, Michael Kohlhase notifications@github.com wrote:

indeed, I am getting the error you described above. How can I fix that?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/OpenMath/OMSTD/issues/52#issuecomment-334418496, or mute the thread https://github.com/notifications/unsubscribe-auth/ABNcAhoDLlzvKOVgQaSfPlqoOG0ZnBRcks5spKhngaJpZM4Puj8q .

[kohlhase]

great, will do.

[davidcarlisle]

This should work now but note I only support <mover>...<mo>&#x2192;</mo></mover> as it ends up as \vec{,...} in TeX other alignments wouldn't be possible so it is best not to allow them. also <math>&longrigharrow; needs to be used (since yesterday) as <math><mo>&longrightarrow;</mo></math> as the entity (now) just maps to the correct unicode character so needs explicit <mo>.

git merge will probably sort that out for you, but I thought I'd mention it:-)

[kohlhase]

indeed, it did. Thanks.