Re: [sage-devel] Single instance of R only

2018-12-24 Thread William Stein
On Mon, Dec 24, 2018 at 2:01 PM Timo Kaufmann  wrote:
>>
>> 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.

Just to be clear, I fully support your choice.By "both should be
supported, since they have complementary functionality (pros and cons
to each)...  Oh well." I mean "I personally think both should be
supported.  However, since I do not have the time or resources right
now to do so, then whoever does have those resources (you) should
decide."   Thank you for taking the time to explain your choices
above, and more about the issues.

 -- William

-- 
William (http://wstein.org)

-- 
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.


Re: [sage-devel] Single instance of R only

2018-12-24 Thread Timo Kaufmann

>
> 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.


Re: [sage-devel] Single instance of R only

2018-12-24 Thread William Stein
On Mon, Dec 24, 2018, 7:21 AM Andrey Novoseltsev  On Sunday, 23 December 2018 19:23:27 UTC-7, William wrote:
>>
>> I didn't have anything to do with the change, but for what it is
>> worth, it was definitely not my intention that calling R() twice only
>> creates one interface.
>> When I designed and implemented the interfaces, my intention was that
>> it be possible to create multiple interfaces to multiple copies of R
>> (or to any
>> other pexpect interface).
>>
>>  -- William
>>
>>
> Well, that was also my impression given how Interface class starts:
>
> class Interface(WithEqualityById, ParentWithBase):
> """
> Interface interface object.
>
> .. NOTE::
>
> Two interfaces compare equal if and only if they are identical
> objects (this is a critical constraint so that caching of
> representations of objects in interfaces works
> correctly). Otherwise they are never equal.
> """
>
> The change for R() happened since it is no longer a pexpect interface, but
> rpy2 one. I have no idea how exactly it works and if it is possible to use
> it to create multiple instances or namespaces with it, but perhaps
> knowledgeable people should look into it.
>

When I last looked, I think the rpy2 interface happens entirely at the C
library level, and there is only one process involved.   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.

 -- William

>

-- 
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.


Re: [sage-devel] Single instance of R only

2018-12-24 Thread Andrey Novoseltsev
On Sunday, 23 December 2018 19:23:27 UTC-7, William wrote:
>
> I didn't have anything to do with the change, but for what it is 
> worth, it was definitely not my intention that calling R() twice only 
> creates one interface. 
> When I designed and implemented the interfaces, my intention was that 
> it be possible to create multiple interfaces to multiple copies of R 
> (or to any 
> other pexpect interface). 
>
>  -- William 
>
>
Well, that was also my impression given how Interface class starts:

class Interface(WithEqualityById, ParentWithBase):
"""
Interface interface object.

.. NOTE::

Two interfaces compare equal if and only if they are identical
objects (this is a critical constraint so that caching of
representations of objects in interfaces works
correctly). Otherwise they are never equal.
"""

The change for R() happened since it is no longer a pexpect interface, but 
rpy2 one. I have no idea how exactly it works and if it is possible to use 
it to create multiple instances or namespaces with it, but perhaps 
knowledgeable people should look into it.

-- 
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.