Hello all, as I recently updated org, I seem to have run into a bug with ob-gnuplot (or ob more generally) where data from a table are not interpreted correctly. Specifically, if the first column entry in a row is a negative number, the data file created for use by gnuplot consists of only - signs, not the actual numbers. This table, for instance, #+begin_src org ,#+name: data | x | y | |----+----| | -4 | 16 | | -3 | 9 | | -2 | 4 | | -1 | 1 | | 0 | 0 | | 1 | 1 | | 2 | 4 | | 3 | 9 | | 4 | 16 | ,#+TBLFM: $2=$1^2 #+end_src when converted into a file for use by gnuplot for the following script #+begin_src org ,#+begin_src gnuplot :var d=data :file t.png :results file plot d ,#+end_src #+end_src looks like this: ,---- | -------------- | -------------- | -------------- | -------------- | 0 0 | 1 1 | 2 4 | 3 9 | 4 16 `---- I've not yet had a chance to track down why this might be. Thank you, eric -- : Eric S Fraga, with org release_9.5.2-298-g1f48d2 in Emacs 29.0.50
By the way, adding an empty column to front of the table fixes the problem so at least I am not panicking (I have a presentation to give with the data in a table etc.). There must be a problem with a regex looking for dividing lines maybe? -- : Eric S Fraga, with org release_9.5.2-304-g1537bb in Emacs 29.0.50
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> Hello all,
>
> as I recently updated org, I seem to have run into a bug with ob-gnuplot
> (or ob more generally) where data from a table are not interpreted
> correctly. Specifically, if the first column entry in a row is a
> negative number, the data file created for use by gnuplot consists of
> only - signs, not the actual numbers.
> ...
> looks like this:
>
> ,----
> | --------------
> | --------------
> | --------------
> | --------------
> | 0 0
> | 1 1
> | 2 4
> | 3 9
> | 4 16
> `----
Ouch. Sorry for this. This was introduced by fixing another bug.
Should be fixed on main now.
Best,
Ihor
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> By the way, adding an empty column to front of the table fixes the
> problem so at least I am not panicking (I have a presentation to give
> with the data in a table etc.). There must be a problem with a regex
> looking for dividing lines maybe?
Sorry for causing this issue. The problem was very obscure. It was
related to table conversion during export. When using ox-ascii to export
Org table to Gnuplot-readable text file, ox-ascii sometimes threw an
error because of wrong calculation of cell width. So, I tried to use
ox-org instead. Apparently, ox-org cannot be used in that context (no
idea what went wrong though).
Now, I just put a quick (and incomplete) fix to ox-ascii and reverted
back to the old export approach.
Best,
Ihor
On Friday, 14 Jan 2022 at 22:01, Ihor Radchenko wrote:
> Ouch. Sorry for this. This was introduced by fixing another bug.
> Should be fixed on main now.
Thank you for such a quick response and no worries! Yes, it seems to
work now.
--
: Eric S Fraga, with org release_9.5.2-306-g9623da in Emacs 29.0.50