Please ignore. Restarting Emacs fixed the problem. For some reason,
re-loading org was not enough. I can export without error again.
--
: Eric S Fraga, with org release_9.5.4-613-gb3b17c in Emacs 29.0.50
"Fraga, Eric" writes:
> I updated org recently (and again just now) and am getting the error
> shown in the attached file. This is related to your patch, I think
> given that it fails in accessing the "stable-file", but haven't verified
> it. Before I investigate further, I thought I would
Hi Ihor,
On Monday, 4 Jul 2022 at 21:06, Ihor Radchenko wrote:
> Ihor Radchenko writes:
>
>> The patch introduces a new functionality to ob-core.el allowing more
>> stable temporary file names. I am not sure if my implementation is the
>> best way to solve the problem, so comments are welcome.
Ihor Radchenko writes:
> The patch introduces a new functionality to ob-core.el allowing more
> stable temporary file names. I am not sure if my implementation is the
> best way to solve the problem, so comments are welcome.
Applied onto main via 080462198.
Best,
Ihor
On Thursday, 9 Jun 2022 at 21:35, Ihor Radchenko wrote:
> Did you have a chance to test the patch?
No. Sorry. Got busy with other things and had temporarily
(well, permanently) solved the problem (for me) by adding :eval
no-export to all of my gnuplot blocks.
--
: Eric S Fraga, with org
Hi Eric,
Eric S Fraga writes:
> I will try your patch later this week (busy with end of term teaching
> aspects at the moment).
Did you have a chance to test the patch?
Best,
Ihor
Dear Ihor,
> The reason why caching does not work is related to the way :var
> assignments work in ob-gnuplot. We dump the table data into temporary
> files and refer to those files in generated gnuplot script body. The
> temporary files names change on every execution and the gnuplot script
>
Eric S Fraga writes:
> in the paper I am writing, I have a number of gnuplot src blocks, some
> of which process a significant amount of data so take some time to
> generate the actual plots. The data are static so caching the results
> make sense. However, even though I have ":cache yes" on
On Sunday, 24 Oct 2021 at 13:49, Emmanuel Charpentier wrote:
> Workaround : cache the computations,not the plotting itself (which
> should be fast,and must be made on every table, anyway...) :
actually, the problem in my case is that the plotting *is* the expensive
part! In case, problem
Workaround : cache the computations,not the plotting itself (which
should be fast,and must be made on every table, anyway...) :
#+options: toc:nil author:nil
* Main text
Use of a static table:
#+call: timeit()
#+call: testplot[:file test0.pdf](data=table0)
#+call: timeit()
Use of a slow
Hello all,
So, following the code: every time I ask to evaluate the gnuplot src
block in the minimal example I posted yesterday, the new-hash that is
calculated is different so the cache setting is ignored.
Digging deeper leads to me getting lost. The hash does depend on the
incorporation of
On Saturday, 23 Oct 2021 at 11:13, Emmanuel Charpentier wrote:
> You may find this John Kitchin's blog
> post [...] illuminating.
Unfortunately not but thank you. It is a very useful blog post but
doesn't cover my case, where I use a :var header to refer to a
table. The table is static so I
You may find this John Kitchin's blog post illuminating.
HTH,
--
Emmanuel Charpentier
Hello all (again!),
in the paper I am writing, I have a number of gnuplot src blocks, some
of which process a significant amount of data so take some time to
generate the actual plots. The data are static so caching the results
make sense. However, even though I have ":cache yes" on each of
14 matches
Mail list logo
