Re: [O] was this intentional with the default header :results value

[Eric Luo]

t...@tsdye.com (Thomas S. Dye) writes:

 Or, fiddling a bit more.

 #+name: luo
 #+BEGIN_SRC R :results output raw
   library(ascii)
   df - data.frame(c1=123456789123456789000,c2=2)
   df$c1 - as.vector(df$c1)
   print(ascii(df,digits=c(0,0),include.rownames=F),type=org)
 #+END_SRC

 #+RESULTS: luo
 |c1 | c2 |
 |---+|
 | 123456789123456789000 |  2 |


Thanks for your help in time, it works like in a charm.

[O] was this intentional with the default header :results value

[Eric Luo]

Hi, 
Why in the following code block, c1 was printed as scientific notation
rather then characters.
,
| 
| #+BEGIN_SRC R :results value
|   df - data.frame(c1=123456789123456789,c2=2)
| #+END_SRC
| 
| #+RESULTS:
| | 1.2345678912345678e+17 | 2 |
`
But if the header :results output, the result was expected.
,
| 
| #+BEGIN_SRC R :results output 
|   df - data.frame(c1=123456789123456789,c2=2)
|   df
| #+END_SRC
| 
| #+RESULTS:
| :   c1 c2
| : 1 123456789123456789  2
`

Thanks

Re: [O] was this intentional with the default header :results value

[Eric Luo]

t...@tsdye.com (Thomas S. Dye) writes:

Thanks, it's clear to me with the difference between value and
output now.

whether there is a way to tell emacs-lisp that 123456789123456789 is a
string rather than a number.

emacs-lisp handles the output as expected if the c1 has any character
other than numbers as the following.
,
| #+BEGIN_SRC R
|   df - data.frame(c1=c123456789123456789,c2=2)
|   df$c1 - as.vector(df$c1)
|   df
| #+END_SRC
| 
| #+RESULTS:
| | c123456789123456789 | 2 |
| 
`

 Aloha Eric,

 Eric Luo eric.we...@gmail.com writes:

 Hi, 
 Why in the following code block, c1 was printed as scientific notation
 rather then characters.
 ,
 | 
 | #+BEGIN_SRC R :results value
 |   df - data.frame(c1=123456789123456789,c2=2)
 | #+END_SRC
 | 
 | #+RESULTS:
 | | 1.2345678912345678e+17 | 2 |
 `

 With :results value the results are passed from the source language into
 emacs-lisp and then displayed in the buffer.  So, the representation of
 things like very large numbers depends on how that was done in
 emacs-lisp, independent of the source language conventions.  In this
 case, I suspect the number was written with a formatting string and ‘%g’
 which uses scientific notation if that is a shorter representation.


 But if the header :results output, the result was expected.
 ,
 | 
 | #+BEGIN_SRC R :results output 
 |   df - data.frame(c1=123456789123456789,c2=2)
 |   df
 | #+END_SRC
 | 
 | #+RESULTS:
 | :   c1 c2
 | : 1 123456789123456789  2
 `


 With :results output the results aren't translated into emacs-lisp.
 Instead, the output from the source language is collected and displayed
 in the buffer.  Thus, the output conventions of the source language are
 respected. 

 hth,

[O] Re: [Babel] why did ob-ditaa generate image file fail in orgmode?

[Eric Luo]

Thanks for your reminder, I updated the orgmode to the lastest, now it's ok

[O][Babel] why did ob-ditaa generate image file fail in orgmode?

[Eric Luo]

Hi, I have the following snippet in one of my org files, and have the
babel settings as following:

,
| (setq org-ditaa-jar-path
| ~/.emacs.d/org-mode/contrib/scripts/ditaa.jar)
| (org-babel-do-load-languages
|  'org-babel-load-languages (quote ((emacs-lisp . t)
|(dot . t)
|(ditaa . t)
|(R . t
`

  when I evaluated the snippet,
,
| 
| executing Ditaa code block... java -jar
| /Users/eric/.emacs.d/org-mode/contrib/scripts/ditaa.jar
| /var/folders/7x/7x730t2UEpec6mgk8rHiyk\+\+\+TI/-Tmp-/babel-777G0f/ditaa-777shg
| /Users/eric/test.png
| 
| ditaa version 0.9, Copyright (C) 2004--2009 Efstathios (Stathis) Sideris
| 
| Running with options: Reading file:
| /var/folders/7x/7x730t2UEpec6mgk8rHiyk+++TI/-Tmp-/babel-777G0f/ditaa-777shg
| Locale: zh_CN Dialog Rendering to file: /Users/eric/test.png Done in
| 1sec Code block evaluation complete.
`

It seems successed, but when I open the test.png, it is said that this
file is corrupted.

It's ok if I execute the commandline(java -jar ...) in the shell. It's
very strange, and tested in ubuntu and Mac OSX.

Any clues, thanks

[O] Re: [Babel] why did ob-ditaa generate image file fail in orgmode?

[Eric Luo]

Eric S Fraga e.fr...@ucl.ac.uk writes:

 What was the snippet?  (or at least a minimal version of one that
 exhibits the problem)

Sorry for my mistake, I've forgotten the snippet, actually no matter
what i put in the block, the image couldn't be opened if the
generated it in orgmode.

Anyway, what the snippet is:

#+begin_src ditaa :file ~/test.png
  test
#+end_src

[O] please ignore it, sorry for the test

[Eric Luo]

for test