> > When I last looked, I think the rpy2 interface happens entirely at the C > library level, and there is only one process involved. >
Yes, that is true. Working at the C level has a lot of advantages, but there is only one process involved. It may be possible to work around this either by introducing multiple R processes upstream or by doing some multiprocessing hackery. > It's really unfortunately if somebody just deleted the pexpect interface > and replaced it with rpy2. Instead, I would think both should be > supported, since they have complementary functionality (pros and cons to > each)... Oh well. > That is exactly what I did in https://trac.sagemath.org/ticket/26596. The reason for it was that the pexpect interface was very hard to maintain and near impossible to update to R 3.5. While implementing the rpy2 interface I also noticed that it was broken in various ways, e.g.: - `r('NaN').sage()`, `r('Inf').sage()`, `r('3i + 4').sage()` all threw errors because parsing failed - errors were ignored entirely due to faulty pattern matching (leading to some errors in sage code) - `r.help` would block indefinitely when multiple help pages are available And I would guess there are more. That is why I don't think "maintaining both" is a viable option. The repl isn't meant to be parsed and if we can get someone else to maintain the interface for us (rpy2), that is great. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
