plantuml, png and caching

plantuml, png and caching

[CS Suehs]

Should I expect PlantUML source blocks and their resulting images to
be cached and respect `:cache true` ?
In my experience they regenerate every export, even with :cache true.

Thank you
-s

Re: plantuml, png and caching

[Nick Daly]

CS Suehs <skelter.net@gmail.com> writes:

> Should I expect PlantUML source blocks and their resulting images to
> be cached and respect `:cache true` ?

Yes.

> In my experience they regenerate every export, even with :cache true.

Can you provide an example?

This example caches correctly for me on v9.1.14.

    #+name: helloworld
    #+header: :cache yes
    #+BEGIN_SRC plantuml :file helloworld.png
      @startuml
      Hello --> World
      @enduml
    #+END_SRC

    #+RESULTS[f29ead8751dde1b4c4ee1b8fcb97e133c75eed0d]: helloworld
    [[file:helloworld.png]]

The only time I've seen caching break is if the diagram imports an
external file.  In that case, the diagram doesn't regenerate often
enough, because org doesn't notice that the external file changed.  The
fix to that is to include the hash of the external file as a dependent
var.

    #+name: md5
    #+BEGIN_SRC shell :cache no :var afile="PLACEHOLDER"
      md5sum $afile
    #+END_SRC

    #+name: cache-correctly
    #+header: :var md5input=md5("data.txt")
    #+BEGIN_SRC R :exports results :results output graphics :file data.svg
      aData <- read.csv("data.txt")
      ggplot(data = aData,
             mapping = aes(x = aData$id, y = aData$value))
    #+END_SRC

Thanks,
Nick

Re: plantuml, png and caching

[CS Suehs]

Nick,
I had the :cache yes on the same line with #+BEGIN like
#+BEGIN_SRC plantuml :file helloworld.png :cache yes

When I change to your method, caching seems to work.
It looks like setting it as a section property also works.

Thank you.
Should I expect the setting on the BEGIN_SRC line to work?

On Tue, Apr 13, 2021 at 7:16 PM Nick Daly
<nick+orgmode@despisinggravity.com> wrote:
>
> CS Suehs <skelter.net@gmail.com> writes:
>
> > Should I expect PlantUML source blocks and their resulting images to
> > be cached and respect `:cache true` ?
>
> Yes.
>
> > In my experience they regenerate every export, even with :cache true.
>
> Can you provide an example?
>
> This example caches correctly for me on v9.1.14.
>
>     #+name: helloworld
>     #+header: :cache yes
>     #+BEGIN_SRC plantuml :file helloworld.png
>       @startuml
>       Hello --> World
>       @enduml
>     #+END_SRC
>
>     #+RESULTS[f29ead8751dde1b4c4ee1b8fcb97e133c75eed0d]: helloworld
>     [[file:helloworld.png]]
>
> The only time I've seen caching break is if the diagram imports an
> external file.  In that case, the diagram doesn't regenerate often
> enough, because org doesn't notice that the external file changed.  The
> fix to that is to include the hash of the external file as a dependent
> var.
>
>     #+name: md5
>     #+BEGIN_SRC shell :cache no :var afile="PLACEHOLDER"
>       md5sum $afile
>     #+END_SRC
>
>     #+name: cache-correctly
>     #+header: :var md5input=md5("data.txt")
>     #+BEGIN_SRC R :exports results :results output graphics :file data.svg
>       aData <- read.csv("data.txt")
>       ggplot(data = aData,
>              mapping = aes(x = aData$id, y = aData$value))
>     #+END_SRC
>
> Thanks,
> Nick

Re: plantuml, png and caching

[George Mauer]

[-- Attachment #1: Type: text/plain, Size: 2054 bytes --]

I would expect it to work. After all, it could be incredibly useful to bump
that up to a :header-args:plantuml: property on the heading

On Thu, Apr 15, 2021 at 12:48 PM CS Suehs <skelter.net@gmail.com> wrote:

> Nick,
> I had the :cache yes on the same line with #+BEGIN like
> #+BEGIN_SRC plantuml :file helloworld.png :cache yes
>
> When I change to your method, caching seems to work.
> It looks like setting it as a section property also works.
>
> Thank you.
> Should I expect the setting on the BEGIN_SRC line to work?
>
> On Tue, Apr 13, 2021 at 7:16 PM Nick Daly
> <nick+orgmode@despisinggravity.com> wrote:
> >
> > CS Suehs <skelter.net@gmail.com> writes:
> >
> > > Should I expect PlantUML source blocks and their resulting images to
> > > be cached and respect `:cache true` ?
> >
> > Yes.
> >
> > > In my experience they regenerate every export, even with :cache true.
> >
> > Can you provide an example?
> >
> > This example caches correctly for me on v9.1.14.
> >
> >     #+name: helloworld
> >     #+header: :cache yes
> >     #+BEGIN_SRC plantuml :file helloworld.png
> >       @startuml
> >       Hello --> World
> >       @enduml
> >     #+END_SRC
> >
> >     #+RESULTS[f29ead8751dde1b4c4ee1b8fcb97e133c75eed0d]: helloworld
> >     [[file:helloworld.png]]
> >
> > The only time I've seen caching break is if the diagram imports an
> > external file.  In that case, the diagram doesn't regenerate often
> > enough, because org doesn't notice that the external file changed.  The
> > fix to that is to include the hash of the external file as a dependent
> > var.
> >
> >     #+name: md5
> >     #+BEGIN_SRC shell :cache no :var afile="PLACEHOLDER"
> >       md5sum $afile
> >     #+END_SRC
> >
> >     #+name: cache-correctly
> >     #+header: :var md5input=md5("data.txt")
> >     #+BEGIN_SRC R :exports results :results output graphics :file
> data.svg
> >       aData <- read.csv("data.txt")
> >       ggplot(data = aData,
> >              mapping = aes(x = aData$id, y = aData$value))
> >     #+END_SRC
> >
> > Thanks,
> > Nick
>
>

[-- Attachment #2: Type: text/html, Size: 2923 bytes --]

Re: plantuml, png and caching

[Nick Daly]

CS Suehs <skelter.net@gmail.com> wrote:

> Should I expect the setting on the BEGIN_SRC line to work?

On v9.1.14, this works for me as expected:

    #+name: helloworld2-works-fine-on-9-1-14
    #+BEGIN_SRC plantuml :cache yes :file helloworld2.png
      @startuml
      Hello --> World
      @enduml
    #+END_SRC

It may be a bug introduced between 9.1.14 and your version.  Could you
report it with your broken and working examples, using
`org-submit-bug-report'?  That'll include configuration context we
might've missed on this email chain that more qualified folks than I can
review.

Thanks,
Nick