emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* plantuml, png and caching
@ 2021-04-13 21:54 CS Suehs
  2021-04-14  0:16 ` Nick Daly
  0 siblings, 1 reply; 5+ messages in thread
From: CS Suehs @ 2021-04-13 21:54 UTC (permalink / raw)
  To: emacs-orgmode

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: plantuml, png and caching
  2021-04-13 21:54 plantuml, png and caching CS Suehs
@ 2021-04-14  0:16 ` Nick Daly
  2021-04-15 17:46   ` CS Suehs
  0 siblings, 1 reply; 5+ messages in thread
From: Nick Daly @ 2021-04-14  0:16 UTC (permalink / raw)
  To: CS Suehs; +Cc: emacs-orgmode

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: plantuml, png and caching
  2021-04-14  0:16 ` Nick Daly
@ 2021-04-15 17:46   ` CS Suehs
  2021-04-15 18:33     ` George Mauer
  0 siblings, 1 reply; 5+ messages in thread
From: CS Suehs @ 2021-04-15 17:46 UTC (permalink / raw)
  To: Nick Daly; +Cc: emacs-orgmode

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: plantuml, png and caching
  2021-04-15 17:46   ` CS Suehs
@ 2021-04-15 18:33     ` George Mauer
  2021-04-18 18:10       ` Nick Daly
  0 siblings, 1 reply; 5+ messages in thread
From: George Mauer @ 2021-04-15 18:33 UTC (permalink / raw)
  To: emacs-orgmode

[-- 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 --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: plantuml, png and caching
  2021-04-15 18:33     ` George Mauer
@ 2021-04-18 18:10       ` Nick Daly
  0 siblings, 0 replies; 5+ messages in thread
From: Nick Daly @ 2021-04-18 18:10 UTC (permalink / raw)
  To: gmauer, CS Suehs; +Cc: emacs-orgmode

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-04-18 18:29 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-13 21:54 plantuml, png and caching CS Suehs
2021-04-14  0:16 ` Nick Daly
2021-04-15 17:46   ` CS Suehs
2021-04-15 18:33     ` George Mauer
2021-04-18 18:10       ` Nick Daly

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).