add memoize-ext

[cfr42]

I'm not sure if it would be better to just refuse to use memoize if tagging but I have documents which can't be realistically compiled at all in that case. Moreover, the tagging is actually more reliable for forest and prooftrees, in the sense that the bounding box is (I hope) correct if the are memoized, whereas it is merely approximated otherwise. For prooftrees, this is not so bad, but for forest it is more likely to be significantly wrong.

But, anyway, I am even less sure about this request ...

[cfr42]

I realise that these tests will never pass with your configuration. So probably I should close this since it isn't really possible to write useful tests which will pass for your setup?

[mbertucci47]

@cfr42 We would need to install the PDF::API2 perl module for the github CI (not sure how to do that). Doesn't memoize also have a TeX-based extraction method?

[cfr42]

@cfr42 We would need to install the PDF::API2 perl module for the github CI (not sure how to do that).

That is easy enough.

Doesn't memoize also have a TeX-based extraction method?

You do not want to allow that 😄. It requires shell-escape.

[mbertucci47]

@cfr42 perhaps open a PR to add it to the CI?

[mbertucci47]

@cfr42 Could you merge the main branch so the tests run with the perl library?

[cfr42]

As far as I can tell, the test failures are Not My Fault ....

[mbertucci47]

The tagging looks reasonable to me but @u-fischer may want to take a look before merging.

[cfr42]

The tagging looks reasonable to me but @u-fischer may want to take a look before merging.

As I said originally, I am really not sure about externalisation tools here. On the other hand, there are certainly cases where it seems unobjectionable.

[cfr42]

S.E.P. field:

zhnumber-01 (20/20)
          --> failed


  Check failed with difference files
  - ./build/test-config-compatible-luatex/zhnumber-01.luatex.diff

  To regenerate the test files, run

    l3build save -c config-compatible-luatex zhnumber-01

  Afterwards test for engine specific changes using

    l3build check --show-saves -c config-compatible-luatex zhnumber-01

[cfr42]

@mbertucci47 @u-fischer @davidcarlisle should I delete this?

only I would like to know if there is something wrong with the tagging before I do that. because I do not much want to help somebody else do the same wrong thing, if wrong it is.

[davidcarlisle]

personally I'd merge now, holding the PR open just creates work keeping the branches in sync (eg the current unrelated issue it's flagging with epic) If issues come up with the tests later it wouldn't be the first package that has needed adjustment, but it's easier to test locally after a merge rather than having to pull your repo here

[cfr42]

@davidcarlisle OK, thanks. That is partly why I was going to delete it.

[cfr42]

@davidcarlisle any objection if I just delete this? there does not seem much point in updating it, frankly. stuff which uses it is marked as compatible, even if this isn't, and I think that will have to do.

I hoped it would either get approved or rejected because that would be useful in terms of what might or might not work for memoize, but I don't want to try tangling with git following a 2e release ;).

[davidcarlisle]

@cfr42 can't we simply merge, there are no git conflicts and the test failures are unrelated and being addressed elsewhere, But if you want to delete i don't object as such but I'm not sure why you want to delete? If you delete it just stays as "unknown" and will come up later.

[cfr42]

@cfr42 can't we simply merge, there are no git conflicts and the test failures are unrelated and being addressed elsewhere, But if you want to delete i don't object as such but I'm not sure why you want to delete? If you delete it just stays as "unknown" and will come up later.

I am happy if you merge it. I want to delete it because I don't think that is at all likely to happen and I would rather be done with it in that case rather than having it in limbo. (I was going to say 'perpetual limbo' but I am pretty sure that limbo was perpetual by definition, until they abolished it.) And I am afraid that somebody will ask me to update the branch again at some point, which I suspect will far exceed my limited git skills.