"Berry, Charles" writes:
> So if elisp lists are to be converted to R lists, ob-R will need to know
> whether the list came from a table to decide whether to render top level
> elements as list elements or as data.frame rows.
This information should be available: lists are passed as Elisp
"Berry, Charles" writes:
> The R `data.frame' type is a list with some added attributes. In
> that list each top level element is a *column* in the data.frame.
Thanks for the explanation.
> There might be some useful applications for converting org lists to R
> lists and vice versa. But it
So, based on Charles recent feedback:
>> If there are more complaints about that in the future, I'll
>> reconsider.
... let's do as Jeremie originally said: wait until someone complains.
> Note that my NEWS entry may not be accurate for ob-R then:
>
> ** List references in source block variable
Bastien et al,
> On Dec 29, 2022, at 8:00 AM, Bastien Guerry wrote:
>
> I think it would make sense to convert Elisp lists into R lists
> directly. Jeremie, would you be okay with this?
>
Perhaps there are some hiccups.
The R `data.frame' type is a list with some added attributes. In that
I think it would make sense to convert Elisp lists into R lists
directly. Jeremie, would you be okay with this?
Ihor Radchenko writes:
> Or I may need to put a special clause regarding ob-R into the NEWS
> item.
... that way we don't need such a special clause regarding ob-R.
2 cts,
--
Johan,
> Absolutely, I just wanted to clarify that there is no confusion as to
> what an R list is in the context of R itself (as far as I can
> tell). Your post made it sound like there is.
ah, indeed -- thanks!
cheers, Greg
Greg Minshall writes:
[snipped]
"Proper list" in the context of this discussion and pertaining
to R
would be a =list()=, not a vector which is what is usually
returned by
=c()=. A =data.frame()= is a special case of a =list()= where
every
column has to have the same length.
well, it's a
hi, Johan,
> "Proper list" in the context of this discussion and pertaining to R
> would be a =list()=, not a vector which is what is usually returned by
> =c()=. A =data.frame()= is a special case of a =list()= where every
> column has to have the same length.
well, it's a language mapping
Greg Minshall writes:
list(1,2,3)
[[1]]
[1] 1
[[2]]
[1] 2
[[3]]
[1] 3
c(1,2,3)
[1] 1 2 3
(where =c= is the "concatenation operator".)
so, to me, at least, "proper list" is not a well-defined term in
R.
cheers, Greg
=c= is "a generic function which combines its arguments"
Greg Minshall writes:
>> ** List references in source block variable assignments are now proper lists
>
> just for background, one oddity is that the meaning of a "list" in R is
> a bit loose.
> ...
> so, to me, at least, "proper list" is not a well-defined term in R.
Sounds reasonable.
I also
hi, Ihor,
> ** List references in source block variable assignments are now proper lists
just for background, one oddity is that the meaning of a "list" in R is
a bit loose.
> list(1,2,3)
[[1]]
[1] 1
[[2]]
[1] 2
[[3]]
[1] 3
> c(1,2,3)
[1] 1 2 3
(where =c= is the "concatenation
Jeremie Juste writes:
> On Thursday, 8 Dec 2022 at 09:07, Ihor Radchenko wrote:
>
>> I am not sure if I like the approach you used in the commit.
>>
>> -(unless (listp (car value)) (setq value (list value)))
>> +(unless (listp (car value)) (setq value (mapcar 'list value)))
>>
Hello Ihor
On Thursday, 8 Dec 2022 at 09:07, Ihor Radchenko wrote:
> I am not sure if I like the approach you used in the commit.
>
> -(unless (listp (car value)) (setq value (list value)))
> +(unless (listp (car value)) (setq value (mapcar 'list value)))
>
> In the above, you
Ihor Radchenko writes:
Greg Minshall writes:
[snipped]
The time span is years and I do not recall any related bug
reports.
So, nobody seems to care.
I do pass org plain lists to R source code blocks which is why I
found the current issue. It is easy enough for me to adapt my R
code
Ihor,
> The time span is years and I do not recall any related bug reports.
> So, nobody seems to care.
:)
Greg Minshall writes:
>> Does it make sense from the point of view of R code?
>> AFAIU, the current ob-R implementation converts lists into R tables,
>> which is not accurate? Would it make sense to convert Elisp lists into R
>> lists directly?
>
> my "barely half a cent" would be that backwards
Ihor,
> Does it make sense from the point of view of R code?
> AFAIU, the current ob-R implementation converts lists into R tables,
> which is not accurate? Would it make sense to convert Elisp lists into R
> lists directly?
my "barely half a cent" would be that backwards compatibility here
Jeremie Juste writes:
> Many thanks to you all for your feedback.
> From 1ad16ffb9, I have restored the expected output in R. that is.
>
>
> #+NAME: example-list
> - simple
> - not
> - nested
> - list
>
> #+BEGIN_SRC R :var x=example-list
> x
> #+END_SRC
>
> #+RESULTS:
> | simple |
> | list
Hello,
Many thanks to you all for your feedback.
>From 1ad16ffb9, I have restored the expected output in R. that is.
#+NAME: example-list
- simple
- not
- nested
- list
#+BEGIN_SRC R :var x=example-list
x
#+END_SRC
#+RESULTS:
| simple |
| list |
On Wednesday, 7 Dec 2022 at 12:16,
Jeremie Juste writes:
> Many thanks for the insights. I confess that I have never transferred
> list from org to R before. I've always use tables and as far as I
> understand they works fine in 9.6.
>
> So assuming this list
>
> #+name: alist
> - first item
> - second item
> - third item
> -
On 6 December 2022, Greg Minshall wrote:
given that, iiuc, 9.5 presented a list as (the equivalent of) multiple
rows of a table, i'd vote for staying with (going back to) that.
(i think that's what the two modifications in Chuck's e-mail give you.)
I agree: I've never used this, but if it
Jeremie,
i am neutral w.r.t. what the output should be. like you, i've always
sent in tables.
for me, i don't know that it makes much difference how lists are
presented to R code, as long as it is well-defined and stable over time.
given that, iiuc, 9.5 presented a list as (the equivalent of)
Hello,
Many thanks for the insights. I confess that I have never transferred
list from org to R before. I've always use tables and as far as I
understand they works fine in 9.6.
So assuming this list
#+name: alist
- first item
- second item
- third item
- 3.1 item
- fourth item
before
Chuck,
sorry, i didn't see the change you had added.
> So, isn't that what is wanted?
that's a policy question that i can't answer. :)
cheers, Greg
Hi Greg,
> On Dec 5, 2022, at 4:41 PM, Greg Minshall wrote:
>
> hi, Charles,
>
>> This makes a list like '("a" "b" "c") into a data.frame with one column.
>
> 1. which version of Org are you running?
> : Org mode version 9.6 (9.6-g60de19 @
> /home/minshall/.emacs.d/straight/build/org/):
>
hi, Charles,
> This makes a list like '("a" "b" "c") into a data.frame with one column.
1. which version of Org are you running?
: Org mode version 9.6 (9.6-g60de19 @
/home/minshall/.emacs.d/straight/build/org/):
2. is my below example yours?
i think i used to see the behavior you describe in
> On Dec 4, 2022, at 6:43 PM, Greg Minshall wrote:
>
> i see this same behavior. to me, (org-babel-R-assign-elisp) seems to be
> the problem, but it hasn't changed any time recently. (nor, if my =git
> blame= is done correctly, has anything else in ob-R.el.)
>
> i don't understand how
Hello Johan,
Many thanks for reporting the issue.
I'll investigate further and submit a patch next weekend at the latest.
Best regards,
Jeremie
On Mon, Dec 5, 2022 at 11:42 AM Johan Tolö wrote:
> Greg Minshall writes:
>
> > i see this same behavior. to me, (org-babel-R-assign-elisp)
> >
Greg Minshall writes:
i see this same behavior. to me, (org-babel-R-assign-elisp)
seems to be
the problem, but it hasn't changed any time recently. (nor, if
my =git
blame= is done correctly, has anything else in ob-R.el.)
[snipped]
Yeah, the problem is not a change to ob-R.el but the
for the record, these are the tests i ran with my off-the-cuff "fix"
(s/sequencep/listp/):
#+name: alist
- first item
- second item
- third item
#+begin_src R :var list=alist :session ss
list
#+end_src
#+RESULTS:
| first item | second item | third item |
#+begin_src R :var variable='(a
i see this same behavior. to me, (org-babel-R-assign-elisp) seems to be
the problem, but it hasn't changed any time recently. (nor, if my =git
blame= is done correctly, has anything else in ob-R.el.)
i don't understand how (org-babel-R-assign-elisp) thinks. it seems to
assign =max= and =min=
After the changes to ob-core.el introduced in commit:
b4e437f968771df9555f9306467846965857f632 plain lists passed to R
source code blocks are generated with extra (empty) items.
Example:
#+name: alist
- first item
- second item
- third item
#+begin_src R :var list=alist
list
#+end_src
32 matches
Mail list logo
