Template language changes

[ownedbycats]

Also this: https://en.wikipedia.org/wiki/Time_f...26,596_problem

Certain problematic years occur so far in the future, well beyond the likely lifespan of the Earth, the Sun, humanity, and even past some predictions of the lifetime of the universe, that they are mainly referenced as matters of theoretical interest, jokes, or indications that a related problem is not truly solved for any reasonable definition of “solved”. The year 292,277,026,596 problem (about 2.9×1011 years in the future) will occur when the 64-bit Unix time overflows at UTC 15:30:08 on Sunday, 4 December, 292,277,026,596 AD.[53][54] A similar problem will occur with 128-bit Unix time stored as nanoseconds, which will overflow in the year 5,391,559,471,918,239,498,981 AD (2^127/1000000000 seconds after the Unix epoch in 1970).

[BetterRed]

https://www.slac.stanford.edu/~rkj/crazytime.txt

[ownedbycats]

Originally Posted by chaley

24 Mar 2021 (in calibre source)

• Addition of field references
  
  You can now use $lookup_key instead of field('lookup_key') and $$lookup_key instead of raw_field('lookup_key'). Examples:
  

    * $authors ==> field('authors')
    * $#genre ==> field('#genre')
    * $$pubdate ==> raw_field('pubdate')
    * $$#my_int ==> raw_field('#my_int')

I noticed that $lookupkey doesn't syntax highlight the same mustard colour as field('lookupkey'). I filed on the bug tracker (#1921674) though I probably should have asked here first.

[chaley]

Originally Posted by ownedbycats

I noticed that $lookupkey doesn't syntax highlight the same mustard colour as field('lookupkey'). I filed on the bug tracker (#1921674) though I probably should have asked here first.

No, because in the field() case it is a string constant, while a field reference is a (special) identifier.

As I said on the report, I will highlight identifiers. Currently (in development) it looks like this.

[chaley]

29 Mar 2021 (in calibre source)

• Add line-based breakpoints to the template tester
  
  The template tester now supports setting 'breakpoints' on lines. If a breakpoint is set then template evaluation pauses and a dialog is opened showing you the result of the expression, all the local variables, and a dropdown box that you can use to lookup metadata.
• Add syntax highlighting to identifiers and field references
• Add template file load/save to the context menu

You can see both in this screen capture

[ownedbycats]

The italics on the $lookupkey in source work.

[chaley]

Originally Posted by ownedbycats

The italics on the $lookupkey in source work.

Let me know if you can, or can't, figure out how to use the new breakpoints.

One problem: given how the template processor works internally there is a problem matching a line number to a particular 'thing'. I had to make 'if' statements work differently because it was difficult to put a breakpoint in the "else" clause (for example). Function calls split across multiple lines also are problematic. "Fixing" this is hard because during template execution line numbers are approximate.

It seems that after more than 40 years of developing programming languages I would be able to do this without thinking. But I don't. Sigh ...

[ownedbycats]

I am taking some of my existing templates and trying to figure it out. One thing I notice is that the breakpoints are not saved after pressing OK to save the template and close the tester. Is that intended?

[chaley]

Originally Posted by ownedbycats

One thing I notice is that the breakpoints are not saved after pressing OK to save the template and close the tester. Is that intended?

Yes. Transferring breakpoints between templates is problematic both from the user and the technical points of view.

Yes, it can make sense to try it on another book, but there is a "secret" feature to help with that. Select all the books you want to test, then open the tester. If you click on a book in the results list before clicking "Go" then that book will be used during breakpoint evaluation.

[ownedbycats]

I was testing it on the template I was having trouble with here (the one with the dates in the wrong order). I thought days_between would show up on the dialog. Did I misunderstand this?

[ownedbycats]

The issue I had with that template is probably what I would find breakpoints useful for, to make sure that when checking a value it actually is what I intended to check for (730 days instead of -730 days).

[chaley]

Originally Posted by ownedbycats

I was testing it on the template I was having trouble with here (the one with the dates in the wrong order). I thought days_between would show up on the dialog. Did I misunderstand this?

This is the problem I mentioned in post #37 -- sometimes the line numbers don't align with what the interpreter sees. In this case if you set the breakpoint on the if (line #6) you will probably see what you want. And no, I haven't yet found a way to deal with this. Sigh for the 25th time.

[capink]

Yes, it should make it easier to debug for all of us. I appreciate all the efforts chaley has put into this. Templates have made huge strides lately.

[ownedbycats]

I see the same results if I set the breakpoint to #6. Hmm.

If you want to test the code itself with your own columns to see if you can make it appear, #fanficstatus is enumerated, #fanficupdated is date, and #fanficerror can probably be any column as it only checks if it's defined.

[chaley]

Originally Posted by ownedbycats

I see the same results if I set the breakpoint to #6. Hmm.

If you want to test the code itself with your own columns to see if you can make it appear, #fanficstatus is enumerated, #fanficupdated is date, and #fanficerror can probably be any column as it only checks if it's defined.

I improved things. Perhaps too much.

Several changes:

• Breakpoint line numbers now more accurately line up with the line numbers attached to template expressions.
• If you breakpoint a line number you will see everything that happens on that line. For example, using your template (see image) and setting a breakpoint on line 17, you will see all of fetching d1, fetching d2, calling days_between(), fetching the constant 730, and doing the numeric comparison.
• I got rid of the context menu items to load and save templates, replacing them with small buttons. For me this is easier to use. The placement next to the font stuff is a bit strange but so be it.
• Improved the operation names.

These changes aren't yet in calibre master source. I will post again once they are.