Eric Schulte writes:
> This looks great. Please go ahead and apply this patch to ob-sh.
I just see that this was still sitting in my local branch… pushed to
master.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Waldorf MIDI Implementation & additional
> I agree that it is easier and more clear to include "set datafile
> missing..." in the body of a gnuplot code block. I *do* think that the
> :missing header argument has value specifically as a way to replace
> missing values in the original table data.
>
> I've changed the behavior of the :miss
>
> Maybe I'm missing the point of the :missing header, but I find it
> easier and clearer to include the datafile missing command in the
> gnuplot code block. I don't really see a need for the :missing
> header. Maybe the need stems from wanting to be able to use different
> plotting packages to
Hi Eric,
> Currently the :missing header argument for gnuplot code blocks does two
> things. It adds the "set datafile missing..." line to the code block
> body *and* it binds `*org-babel-gnuplot-missing*' to the value of the
> :missing header argument when the datafile is written, so empty table
Paul Stansell writes:
> Hi Eric,
>
> There appears to be a slight bug in the way gnuplot handles blocked
> data with missing entries.
>
> An example is provided in the org script at then end of this note.
>
> In the code block gnuplot_1 the use of ':missing "?"' seems to cause
> the exported data
Hi Eric,
There appears to be a slight bug in the way gnuplot handles blocked
data with missing entries.
An example is provided in the org script at then end of this note.
In the code block gnuplot_1 the use of ':missing "?"' seems to cause
the exported data file to lack the blanks lines that are
Paul Stansell writes:
> I've just noticed that your changes are not yet present on
> http://orgmode.org/elpa/. Do you know if it's just because the latter
> lags the former by 3 months or more?
ELPA doesn't lag anything like three months. However, it is tracking
maint, not master.
Regards,
Ach
Dear Eric,
Recently you made some nice changes to the way gnuplot plots surface
data from org tables. Your changes are present on
git://orgmode.org/org-mode.git, but I switched to using ELPA recently
and I've just noticed that your changes are not yet present on
http://orgmode.org/elpa/. Do you
Achim Gratz writes:
[...]
> I've implemented "calculation separators" that register as hlines for
> table formulas, but are ignored when row groups are constructed for
> export. Your example table would then look like this:
Achim,
just to apologise for not getting back to you earlier on this.
Hi Eric,
That's seems perfect now; I can't see any other issues. Thanks!
Kind regards,
Paul
Paul Stansell writes:
> Hi Eric,
>
> Thanks for your work on this. I've tried your latest changes and I
> think they're a big improvement.
>
> I've attached another org-mode file for you to try. It illustrates
> the use of double blank lines in the first table (called block_data)
> to inform gn
Hi Eric,
Thanks for your work on this. I've tried your latest changes and I
think they're a big improvement.
I've attached another org-mode file for you to try. It illustrates
the use of double blank lines in the first table (called block_data)
to inform gnuplot that there're two separate data
>
> I would consider this breaking the plot, in that gnuplot no longer lines
> up the two columns of data.
>
My fault, gnuplot does indeed still line up the data as appropriate when
missing values are simply replaced with blank space rather than "".
I've just pushed up changes to gnuplot code blo
Eric Schulte writes:
> This looks great. Please go ahead and apply this patch to ob-sh.
I've applied the bugfix part to maint and master.
I'm holding back on the :hline-string for now since I want to avoid
introducing yet another header arg for that. Instead I'll investigate
whether this can be
Paul Stansell writes:
> Hi Eric,
>
> In your last example are you illustrating the case of a data file with
> missing data?
Yes.
> Replacing ""s with blank space in your example doesn't really break
> the plot, it's just that gnuplot interprets the first column of data
> as
>
> 1
> 2
> 3
> 16
>
Achim Gratz writes:
> Eric Schulte writes:
>> This does look like a bug to me. Can you isolate "where" the value of
>> data in your example is first assigned the wrong value?
>
> The error lies in how ob-sh tries to determine if it needs to process a
> table or a vector and then forgets to check
Eric Schulte writes:
> This does look like a bug to me. Can you isolate "where" the value of
> data in your example is first assigned the wrong value?
The error lies in how ob-sh tries to determine if it needs to process a
table or a vector and then forgets to check for 'hline, thus ending up
in
On Sat, May 11, 2013 at 12:39:55PM +0200, Achim Gratz wrote:
> Eric S Fraga writes:
> >> We should keep "---" as lines to be exported and perhaps use ":::" for
> >> those that are just introducing convenience for table calculations as
> >> "===" looks far too heavy to me for that purpose.
> >
> > S
Eric Schulte writes:
> While I can't claim to fully follow your gnuplot examples, i would
> recommend using an intervening shell code block to parse the Org-mode
> table data into something that gnuplot will ingest.
Implementing something just for gnuplot seems to miss the mark. I can
see utility
Eric S Fraga writes:
>> We should keep "---" as lines to be exported and perhaps use ":::" for
>> those that are just introducing convenience for table calculations as
>> "===" looks far too heavy to me for that purpose.
>
> Sure, I can see how === may be too heavy.
If you want to play around with
Achim Gratz writes:
> Eric S Fraga writes:
>> At present, there is no mechanism for selective deletion of these line
>> separators upon export (that I know of: I would be happy to be corrected
>
>> on this!). For the paper I submitted last week for publication, the
>> only post-org editing I had
Eric S Fraga writes:
> At present, there is no mechanism for selective deletion of these line
> separators upon export (that I know of: I would be happy to be corrected
> on this!). For the paper I submitted last week for publication, the
> only post-org editing I had to do was delete a number \hl
Achim Gratz writes:
> Eric Schulte writes:
>> If you really wanted to be fancy, gnuplot will let you specify shell
>> transformations as part of the plotting command which would allow you to
>> forego the intermediate code block.
>
> As a side-note, if we'd drop the convention that the first sepa
Hi Eric,
In your last example are you illustrating the case of a data file with
missing data? Replacing ""s with blank space in your example doesn't
really break the plot, it's just that gnuplot interprets the first
column of data as
1
2
3
16
6
7
4
9
and the second as
2
4
8
16
8
4
2
Gnuplo
Hi Eric,
It seems to be the first "hline" that causes the problem. For
example, if the table data in splot.org is replaced by
#+name: data
|| x |
|+---|
| r1 | 1 |
it gets exported correctly as
x
r1 1
by both the shell and gnuplot commands.
However, if the data is repla
Paul Stansell writes:
> Hi Eric,
>
> My view is that the removal of '""'s will always be preferable for
> gnuplot as it uses what it calls datablocks which are delimited by
> blank lines (see, for example,
> http://gnuplot.sourceforge.net/docs_4.2/node121.html and
> http://gnuplot.sourceforge.net
Paul Stansell writes:
> Hi Eric,
>
> If I change your example org file a little by adding row and column
> names to the table as in the attached file I get the following
> behaviour that I don't understand: if I execute C-c on the shell
> function the file /tmp/data.gnuplot has the format that g
Hi Eric,
My view is that the removal of '""'s will always be preferable for
gnuplot as it uses what it calls datablocks which are delimited by
blank lines (see, for example,
http://gnuplot.sourceforge.net/docs_4.2/node121.html and
http://gnuplot.sourceforge.net/docs_4.2/node61.html).
Paul
If the removal of ""'s will *always* be preferable for gnuplot, then we
should be able make that conversion the default behavior. However,
before such a conversion we'd need to ensure that the new format is more
generally useful than the existing export format.
Both `org-babel-gnuplot-quote-tsv-f
Hi Eric,
If I change your example org file a little by adding row and column
names to the table as in the attached file I get the following
behaviour that I don't understand: if I execute C-c on the shell
function the file /tmp/data.gnuplot has the format that gnuplot can
plot; however, if I exe
Eric,
What you suggest is indeed a good solution, so thank you very much for that!
I think it would still be nice, however, if someday the blank lines in
the org table would be exported as blank lines in the temporary text
file instead of as "" (which seems to be the root of the problem).
Kind r
Eric Schulte writes:
> If you really wanted to be fancy, gnuplot will let you specify shell
> transformations as part of the plotting command which would allow you to
> forego the intermediate code block.
As a side-note, if we'd drop the convention that the first separator
defines the heading of t
Paul Stansell writes:
> Hello everyone,
>
> I'd be grateful if someone would offer me advice on using gnuplot's
> "splot" and "every" commands when plotting data from a table within
> org-mode.
>
> As far as I can tell, these gnuplot commands do not work properly
> because org-mode exports empty
Hello everyone,
I'd be grateful if someone would offer me advice on using gnuplot's
"splot" and "every" commands when plotting data from a table within
org-mode.
As far as I can tell, these gnuplot commands do not work properly
because org-mode exports empty fields in tables as "" and gnuplot's
"
34 matches
Mail list logo
