all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Daniel Drake <silophophe@gmail.com>
To: Eric Schulte <eric.schulte@gmx.com>
Cc: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: [0][babel][R] Undesired conversion of integers to floats in R code block output
Date: Sun, 19 Feb 2012 10:28:00 -0800	[thread overview]
Message-ID: <4F413F30.60302@gmail.com> (raw)
In-Reply-To: <4F413412.5050108@gmail.com>

On 02/19/2012 09:40 AM, Daniel Drake wrote:
> On 02/19/2012 08:48 AM, Eric Schulte wrote:
>>> Just to be safe, I nuked my org-mode directory and re-cloned from the
>>> git repository: I'm now at release_7.8.03.386.g2239d (I was at
>>> release_7.8.03-351-g47eb3 previously). Is there a more recent
>>> version? I also removed the org directory that came with the packaged
>>> version of emacs, just in case.
>>>
>>
>> This sounds just like my setup. I get the following from `org-version'
>> which should be equivalent.
>>
>> Org-mode version 7.8.03 (release_7.8.03.419.gdeb6e)
>>
>>>
>>> I start emacs with the following options:
>>> $ emacs -Q -eval '(setq load-path (cons
>>> "~/share/emacs/site-lisp/org-mode/lisp" load-path))' -eval "(require
>>> ob-R)" test.org
>>>
>>
>> I just did the same using the following command line to launch Emacs,
>> and I still get no decimal place in my results.
>>
>> $ emacs -Q -eval '(setq laod-path (cons "~/.emacs.d/src/org/lisp/"
>> load-path))' -eval "(require 'ob-R)" /tmp/dan.org
>>
>>>
>>> I get the same behavior as before. I was a little puzzled when I saw
>>> this happen, as I've been working on this study for over a year in org
>>> and it's the first time I've seen this behavior. I went back and
>>> tried previous versions (e.g., 7.4), and now I see the same thing.
>>>
>>> I wonder if Arch (a rolling release linux distribution that tries to
>>> be close to the leading edge) has updated an underlying library that
>>> impacts the babel code in some odd way. (Granted, I don't see how
>>> this could be, as the emacs environment seems pretty well insulated
>>> from the underlying OS; PEBKAC just as likely.)
>>>
>>
>> I doubt this is the case. I also use Arch (just ran pacman -Syu this
>> morning) so we likely have the largely same underlying versions of
>> libraries installed. Maybe the issue could lay somewhere in your R
>> config?
>>
>> Sorry I can't be of more help.
>>
>> Best,
>>
>
> At first I thought it was R as well, but the fact that there is no
> decimal point in the output file plus the fact that (outside of emacs) I
> can use read.table to pull in the table and the result has no decimal
> formatting makes me think otherwise. That you're running the same setup
> as me, though, gives me hope. I can backup, re-install Arch, and see if
> the problem goes away.
>
> Thanks for your help. I'm not certain when I'll have time to try this,
> but I'll follow up on this thread when I do.
>
> Best,
> Dan

I'm following up on my last post, just to have it in the record: I've 
boiled down the behavior to these two examples: output the results by 
value vs output.  R seems not to have anything to do with it.  Somehow 
the "by value" code is intervening.  I'll try to debug.

command line:
$ emacs -Q -eval '(setq load-path (cons 
"~/share/emacs/site-lisp/org-mode/lisp" load-path))' -eval "(require 
'ob-sh)" test.org

In the buffer:
*** by output
#+name: by-output
#+begin_src sh  :results output
   echo 987654321
#+end_src

#+RESULTS: by-output
: 987654321

*** by value
#+name: by-value
#+begin_src sh  :results value
   echo 987654321
#+end_src

#+RESULTS: by-value
: 987654321.0



>
>>>
>>> In any event, since you can't reproduce the behavior (thanks again for
>>> trying), I don't expect it's anything you can fix. Maybe it will show
>>> up in other distributions as they update to more current versions. In
>>> the mean time, I'll try to improve my elisp skills and figure out
>>> where the extraneous formatting occurs.
>>>
>>> Best,
>>> Dan
>>>
>>> - GNU Emacs 23.4.1 (i686-pc-linux-gnu, GTK+ Version 2.24.9) of
>>> 2012-02-01 on shirley.hoetzel.info
>>> - Org-mode version 7.8.03 (release_7.8.03.386.g2239d)
>>>
>>>

  reply	other threads:[~2012-02-19 18:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-16 19:07 [0][babel][R] Undesired conversion of integers to floats in R code block output Daniel Drake
2012-02-18 16:23 ` Eric Schulte
2012-02-19  7:02   ` Daniel Drake
2012-02-19 16:48     ` Eric Schulte
2012-02-19 17:40       ` Daniel Drake
2012-02-19 18:28         ` Daniel Drake [this message]
2012-02-19 19:27           ` Daniel Drake
2012-02-19 20:46             ` Eric Schulte
2012-02-19 21:19               ` Daniel Drake
2012-02-19 21:35               ` Achim Gratz
2012-02-20 17:36                 ` Achim Gratz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F413F30.60302@gmail.com \
    --to=silophophe@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=eric.schulte@gmx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.