On Fri, Nov 29, 2013 at 2:12 PM, Alan G Isaac wrote:
>> On Wed, Nov 27, 2013 at 2:14 PM, Alan G Isaac wrote:
>>> http://www.law.washington.edu/lta/swp/law/derivative.html
>
> On 11/28/2013 5:58 PM, Nathaniel Smith wrote:
>> There's no meaningful legal distin
Minor but important point: if switching to GPL please make it GPLv2+ (I.e.,
use the "or any later version as published by..." language), not just
GPLv2. This allows compatibility with GPLv3 code...
On 29 Nov 2013 13:44, "Laurent Gautier" wrote:
> Hi,
>
> Thanks to all for the participation, opin
On Wed, Nov 27, 2013 at 2:14 PM, Alan G Isaac wrote:
> On 11/27/2013 3:43 PM, Dirk Eddelbuettel wrote:
>> This is_embedding_ as RPy2 embeds R from an outer Python application (just
>> like my RInside project does for C++).
>
> I don't think introducing a new, undefined term helps clarify things.
I believe R is dual licensed GPLv2 and GPLv3. So it is legally possible to
take the GPLv3 option and then license rpy2 as AGPLv3, because GPLv3 has an
exception to make it compatible with AGPLv3. But just releasing rpy2 with
the same (dual) license as R seems simpler...
On 26 Nov 2013 19:45, "Laure
On Thu, Jun 21, 2012 at 8:54 AM, Uwe Schmitt wrote:
>
> Hi,
>
> how does mingw build extensions modules play with an official cpython
> interpreter ?
AFAICT numpy's official win32 installers are built with mingw, using
wine on OS X, and are linked against third-party compiled libraries
(BLAS/LAPA
As a general note, if you want to do R-like manipulation of data in
Python, you should look into 'numpy'. It's very standard, and provides
an array type that works like R vectors, plus functions like 'log' and
'sum' that apply to all elements quickly. rpy2 also has some code to
make it easy to inte
On Tue, Mar 30, 2010 at 5:02 PM, Carson Farmer wrote:
> 1) As expected, if a plot is generated in a separate process, it is
> immediately destroyed once the process completes. I have tested this,
> and basically I get a plot for about half a second, then it
> disappears. Does anyone know of a way
On Sun, Feb 14, 2010 at 12:14 AM, Laurent Gautier wrote:
>> Can you elaborate on what cool new features we'll see as a result of
>> this?
>
> By exporting the buffer protocol, all Python tools that make use of (so
> obviously numpy among them) will be able to access efficiently the data in R
> vec
On Sat, Feb 13, 2010 at 9:55 PM, Laurent Gautier wrote:
> Hi,
>
> rpy2-2.1.x will be dropping the "__array_struct__" way to export array
> information from R arrays to numpy arrays, and use instead the new
> buffer protocol in Python.
>
> This likely means that all numpy-related features in rpy2 w
On Tue, Oct 20, 2009 at 5:01 AM, Nick Schurch wrote:
> I have a dataframe called 'genedata' with columns like '$R', '$G' and
> '$Genes' and I want to be able to pass a specific column as a
> parameter to a new R function. I've had a look at the manual and I
> think I should be using something like
On Fri, Oct 2, 2009 at 6:38 AM, Warnes, Gregory R.
wrote:
> The current approach effectively blocks users from access data objects named
> 'dollar' via the r.dollar syntax. If dollar was a function defined as
>
> dollar <- .Primitive("$")
>
> Then the current syntax would continue to work
On Thu, Oct 1, 2009 at 10:48 AM, Warnes, Gregory R.
wrote:
> These are the longstanding rpy rules (where 'x' represents any sequence
> of valid name character in *python*, including A-Z, a-Z anywhere and 0-9
> anywhere except in the first position):
>
> python R Example
> x_x
On Wed, Sep 30, 2009 at 8:41 AM, Peter wrote:
> Can you do something like check if example_name is a valid argument
> for the function at run time, and if not, check example.name instead?
> Would this impose too high a performance cost?
Unfortunately, there is no reliable way to work out what arg
On Wed, Sep 30, 2009 at 8:08 AM, Laurent Gautier wrote:
> Nathaniel Smith wrote:
>> IMHO, if you're wondering about the case where *both* are valid, then
>> you've already lost. If you're wondering that, then it means you're
>> trying to handle the
On Wed, Sep 30, 2009 at 1:15 AM, Laurent Gautier wrote:
>
> Rewriting function signatures in order to replace '.' with '_' is something
> that is ichting me, but which I would like to happen a safe way. For
> example, what if a function signature has both 'foo.bar' and 'foo_bar' in
> its list of p
On Tue, Sep 29, 2009 at 5:28 PM, Gary Strangman
wrote:
rpy2.robjects.r.lm(f,myframe, na.action=NULL) # fails; "keyword can't be
an expression"
rpy2.robjects.r.lm(f,myframe, na_action=NULL) # fails; "extra arguments
na_action are just disregarded"
The underscore version wor
On Tue, Sep 29, 2009 at 4:21 AM, Gary Strangman
wrote:
> Without benchmarking, that seems mighty inefficient. Nathaniel Smith's
> rnumpy mostly allows the following:
>
> df = rnumpy.r.data_frame(numpy.array(d,np.object))
>
> ... which is 2 conversions (rather than 4), but I haven't been able to ge
On Sun, Jul 5, 2009 at 10:18 AM, Daniel Yuan wrote:
> Looking a little deeper, I actually do *not* find an R subprocess when
> I initialize rpy2. I guess I do not understand exactly how rpy2 is
> initializing R without a subprocess.
Ah. Yeah, no subprocess here :-).
The normal R command line is j
On Sun, Jul 5, 2009 at 2:04 AM, Laurent Gautier wrote:
> (''' q <- function(...) { } ''' is only adding a function q()
> in the globalenv; baseenv['q']() would still call the original function).
Okay, append 'assign("q", q, envir=.BaseEnv)' to that line (if it
really matters; the goal would be to
Can I butt in for a moment and ask why we'd even want q() not to exit?
There is (unfortunately) no way to create and destroy multiple R
sessions, because R doesn't have such a capability. Even if there
were, I don't see what q() would have to do with it -- the right API
for creating and destroying
which should probably be looked at.
On Thu, Apr 23, 2009 at 10:15 PM, Nathaniel Smith wrote:
> I just noticed that
> import rpy2.rinterface as ri
> s_int = ri.SexpVector([1], ri.INTSXP) # works
> s_list = ri.SexpVector([s_int], ri.LISTSXP) # appears to work, but
> the R object
I just noticed that
import rpy2.rinterface as ri
s_int = ri.SexpVector([1], ri.INTSXP) # works
s_list = ri.SexpVector([s_int], ri.LISTSXP) # appears to work, but
the R object is NULL/Nil
Two issues here:
1) It looks like rinterface.c:newSEXP is trying to throw an exception
rather than sil
On Thu, Apr 9, 2009 at 10:08 AM, Warnes, Gregory R.
wrote:
> Instead of
> oneway = robjects.r['oneway.test']
> test = oneway("values ~ ind, data=d, var.equal=TRUE")
> try this:
> test = robjects.r['oneway.test(values ~ ind, data=d, var.equal=TRUE)']
Typo: should use () here, not []:
test = r
On Mon, Mar 23, 2009 at 11:54 PM, Laurent Gautier wrote:
> I have not been using ipython for quite some time, and therefore did not
> think of using its features (I was expecting to have a complete
> implementation to do).
Yeah, there are probably more interesting ways to spend time than
reimplem
On Mon, Mar 23, 2009 at 5:31 PM, Brandon Invergo
wrote:
> The data is loaded as expected, but when I try to
> print the output to the console, only a portion of the data.frame is
> printed (~65000 characters), presumably because it reached the maximum
> string size, and then a seemingly-unrelated
On Mon, Mar 23, 2009 at 5:43 AM, Laurent Gautier wrote:
> The magic "R" for ipython (among others) is a very nice idea. Having a way
> to switch between Python and R in interactive mode was one of the cool
> things I wished to have.
I find it ridiculously handy in practice. (It also made my advis
I'd like to propose that we add a new low-level API to R_tryEval to
rpy2.rinterface. This would be lower-level than the existing
.__call__, .rcall methods, and have the following parts:
* rpy2.rinterface.tryEval (or whatever): a function that takes an
expression rinterface.Sexp, and an environment
On Mon, Mar 23, 2009 at 4:59 AM, Gary Strangman
wrote:
>
> The rnumpy concept looks great, and addresses some annoyances I've
> encountered working at the interface between R and numpy.
Great!
> I hope to test
> rnumpy this week, but in the meantime ... the text suggests that R data
> frames can
I finally had a chance to write up some quick documentation, so I
pushed out a copy of my enhanced Python->R API for feedback.
This is an alternative to the rpy2.robjects API (it still depends on
rpy2.rinterface version 2.0.3, plus it needs numpy to be installed),
and is subject to change. But I'v
On Thu, Mar 12, 2009 at 9:51 AM, Mark Larsen wrote:
> I took your advice and implemented using "Parallel Python". Can you comment
> on your choice of pyprocessing? It seems like a simple re-write to switch
> over.
I use pyprocessing partly because it gave me the impression that it
was more tune
cts import r
pool = processing.Pool() # automatically spawns one worker per cpu
r.library("robustbase")
def do_lmrob(formula_frame):
return r.coef(r.lmrob(formula_frame[0], formula_frame[1]))
pool.map(do_regress, [(formula1, frame1), (formula2, frame2), ...]
> I see that Nathani
On Tue, Mar 10, 2009 at 4:19 PM, Laurent Gautier wrote:
> Since we are at it, I'd be interested in hearing how Python 2.6's
> multiprocessing module behaves w/ rpy2.
It's worked fine when I've used it, though I haven't done any
systematic torture tests or anything... (well, inasmuch as my ordinar
On Tue, Mar 10, 2009 at 11:47 AM, Ryan Kroiss wrote:
> I'm trying to develop a web site written in python that uses rpy2. The
> site has some HTML input forms. The data from these forms is then
> passed to R using rpy2. I've run into a problem with this though. If I
> try to run more than one
On Tue, Mar 3, 2009 at 4:12 AM, Laurent Gautier wrote:
> but my concern is over possible object duplication when returning from
> 'function(*args, **kwargs)' (not necessarily the case, but if something is
> invisible and I can't get rid of copying this is annoying - I need more
> thinking about th
On Mon, Mar 2, 2009 at 5:06 PM, Carson Farmer wrote:
>> This has been annoying me too, so I had a quick look... apparently the
>> (totally awesome) API for this is that you set the global variable
>> R_Visible to FALSE before calling Rf_eval, and then you check it
>> afterwards to see if the retur
On Thu, Feb 26, 2009 at 12:30 AM, Laurent Gautier wrote:
> As you noted, the GTK R console in the demos/ directory outputs a little too
> much (when doing 'x <- rnorm(100)', the content of 'x' will be returned to
> the console).
This has been annoying me too, so I had a quick look... apparently t
On Sun, Feb 22, 2009 at 5:19 AM, Carson J.Q. Farmer
wrote:
> Now using Rpy2, I am having trouble reproducing this functionality. I
> have used rinterface.setWriteConsole() to catch the console output, but
> this does not appear to be all console output, as I get (for example)
> messages from packa
On Tue, Feb 17, 2009 at 7:56 AM, Paul Geeleher wrote:
> I've got a series of python cgi scripts that do various operations on
> data in an r session via rpy. The only problem is that when each
> script finishes, it has to save the manipulated r session to disk and
> the next script has to load the
On Tue, Feb 10, 2009 at 1:51 PM, Laurent Gautier wrote:
> The callbacks are biting back with this bug as well: an exception should
> have been raised when an error occurred (it became obvious while I was
> experimenting with rpy_device).
> Before devising my own solution I'd be keen on seeing how
On Tue, Feb 10, 2009 at 11:39 AM, Laurent Gautier wrote:
> Dismantling R_runHandlers is indeed opening interesting perspectives.
Quite so. Obviously someone should rewrite R's event loop. Someone else.
> Callbacks are the Achilles tendon, I suspect.
> I had an independent locking mechanism for f
Currently, calls into R via rpy2 are *mostly* protected by the Python
global interpreter lock. That means that calling rpy2 functions from
different threads *almost* just works (even though R is not itself
re-entrant). However, it happens from time to time that R calls back
into Python (most common
It turns out that the new definition of consolePrint (that I wrote,
*cough*) is totally broken -- it tries to write to sys.stdout, and
it's in a module that imports sys, but... there's some code in the
middle that does 'del sys'. So console output just doesn't work right
now.
Fix:
https://bitbucke
On Mon, Feb 9, 2009 at 3:46 PM, Dirk Eddelbuettel wrote:
> See http://cran.r-project.org/bin/linux/ubuntu/ -- see the detailed
> README. New versions are typically available within days of R releases as
> properly built and maintained .deb packages for the different Ubuntu flavours
> in both x86 (
On Mon, Feb 9, 2009 at 1:06 PM, Laurent Gautier wrote:
> I suppose that your have strong arguments for not moving from R-2.7 to R-2.8
> ? NewDevDesc was a transition entity and has gone away with R-2.8.
> (It's still a moving target, but the target R for rpy2-2.1 by the time it
> gets ready will l
On Mon, Feb 9, 2009 at 2:45 PM, Laurent Gautier wrote:
>
> I couldn't find that one incantation when I looked for it:
> R_runHandlers(R_InputHandlers, R_checkActivity(1, 1));
>
> I change it to
> R_runHandlers(R_InputHandlers, R_checkActivity(0, 1));
> because of
> https://stat.ethz.ch/pipermail/
On Mon, Feb 9, 2009 at 11:07 AM, Laurent Gautier wrote:
> Yes. I would actually put at the rinterface/__init__.py level
> (still at the rinterface level, but this would cut down on C-level
> development time).
Yeah, IME python wrapping is all about writing the thinnest
barest-bones API possible i
Attached patch redoes process_revents (again); now it actually *works*
on Unix (and I believe OS X, though someone should check). Which is
nice.
To test:
>>> r("plot(1:10)")
# window will appear
# move the window around, resize it, etc.; it won't update
>>> ri.process_revents()
# window will redra
Currently, the following generates an exception:
>>> s = ri.SexpVector([1, 2, 3, 4], ri.INTSXP)
>>> s.do_slot_assign("dim", ri.SexpVector([2, 2], ri.INTSXP)
The issue is that s has no "dim" attribute to start off with, and
do_slot_assign's implementation checks R_has_slot and errors out if it
ret
I tracked down that build error I've mentioned a few times with the
new graphics device code -- it's an R 2.7 vs. R 2.8 compatibility bug.
In 2.8, pDevDesc is (DevDesc *), but in 2.7 it's (NewDevDesc *), and
so trying to malloc a DevDesc doesn't work in 2.7, you need to malloc
a NewDevDesc instead.
On Sun, Feb 8, 2009 at 2:01 PM, Laurent Gautier wrote:
> It turned out that a stale PYTHONPATH was getting an older version of rpy2
> when running it on my end.
> So much for the cross-platform unifying bit. :/
>
> Now the tip should build and run on Linux.
It does work for me, though my internal
On Sun, Feb 8, 2009 at 2:22 AM, Laurent Gautier wrote:
> In the case of extracting elements from a matrix, there is a way
> (working in R, as well as in rpy2):
>
> m[2, TRUE] # Note the TRUE !
> [1] 2 4
Ah, cute trick, thanks.
> I'd be more keen on defining the missing magic, as well as NULL and
On Sun, Feb 8, 2009 at 6:13 AM, Laurent Gautier wrote:
> Nice.
>
> What about calling the method __copy__ instead (so it fits other Python
> objects) ?
I don't really care either way. I guess calling it "duplicate" avoids
any question of whether it should be __copy__ or __deepcopy__, but
since it
This patch just cleans up a few things I noticed while hacking:
- The testSexp_sexp_destroyCobj test is a no-op. I'm not sure what
it's trying to test, but whatever it is, it isn't testing it.
- Fix most compile warnings that occur when building rinterface.c
The remaining build warning I get is:
On Sun, Feb 8, 2009 at 1:40 AM, Nathaniel Smith wrote:
> This patch just cleans up a few things I noticed while hacking:
> - The testSexp_sexp_destroyCobj test is a no-op. I'm not sure what
> it's trying to test, but whatever it is, it isn't testing it.
> - Fix most
The attached patch adds a method ".duplicate" to rinterface.Sexp
objects. When called, it returns a new Sexp that is identical to the
first, but shares no memory with the first. (Underlyingly, it just
calls Rf_duplicate.)
This is useful when you have an Sexp that you want to mutate, but you
also w
There are several times in R when it is valuable to explicitly leave
an argument missing. For example, when extracting a row from a matrix:
> m <- matrix(1:4, nrow=2)
> m[2] # Flat indexing
[1] 2
> m[2, ] # Note the comma!
[1] 2 4
However, there is currently no way to support this (rather
idios
I tracked down that strange "unresolved symbol" error I was getting.
It turns out that rpy2 tip includes a reference to R_ProcessEvents
unconditionally, but in fact R_ProcessEvents is not a portable API.
R_ProcessEvents only exists on Win32 and OS X/Aqua builds of R.
And on OS X, unless someone ha
On Tue, Feb 3, 2009 at 10:56 PM, laurent wrote:
> On Tue, 2009-02-03 at 13:30 -0800, Nathaniel Smith wrote:
>> why does EnvironmentSexp_ass_subscript (==
>> rpy2.rinterface.SexpEnvironment.__setitem__) copy the value it is
>> storing?
>>
>> PROT
Patch.
diff -r 78fbb8a3131a rpy/rinterface/array.c
--- a/rpy/rinterface/array.c Mon Feb 02 21:14:18 2009 +0100
+++ b/rpy/rinterface/array.c Tue Feb 03 20:46:37 2009 -0800
@@ -36,7 +36,12 @@
//case STRSXP: return 'S';
//FIXME: handle 'O' (as R list ?)
case CPLXSXP: return 'c';
- case LGLS
Currently one cannot coerce R "logical" vectors to a numpy vector:
>>> import rpy2.rinterface as ri
>>> np.asarray(ri.SexpVector([True, False], ri.LGLSXP))
[...]
ValueError: unsupported typestring
The problem is that rpy2 is describing that SEXP as containing an
array of 32-bit (!) booleans. That
why does EnvironmentSexp_ass_subscript (==
rpy2.rinterface.SexpEnvironment.__setitem__) copy the value it is
storing?:
PROTECT(sexp_copy = Rf_duplicate(sexp));
Rf_defineVar(sym, sexp_copy, rho_R);
I noticed this because I was trying to get dim<- to work on an
SexpVector -- r["dim<-"](mysexp,
I have some memory leak somewhere kicking my butt -- I'm running large
numbers of tests on a small cluster, and my slaves are falling over
and dying from the memory use -- and so my eye was caught by a
discussion on this list back in November about memory leak issues in
rpy2. I don't know yet wheth
On Tue, Jan 27, 2009 at 1:02 PM, Jeff Gentry wrote:
>> I am also getting:
>> >>> robjects.r('NA')[0]
>> True
>
> So does this imply that R's NA objects always evaluate as Python's True
> right now? What is (or should be) the equivalent to a NA value in Python?
Heh, I was just researching this l
On Mon, Jan 26, 2009 at 3:22 AM, Laurent Gautier wrote:
> Nathaniel Smith wrote:
>>
>> There are a number of callbacks in rinterface that one can set to
>> control R's console -- setWriteConsole, setReadConsole, etc. This
>> patch fixes to limitations with the cu
There are a number of callbacks in rinterface that one can set to
control R's console -- setWriteConsole, setReadConsole, etc. This
patch fixes to limitations with the current API:
1) It is impossible to read out the current callback. This would be
useful for switching another callback into place
Currently the default handler for R console output simply passes the
strings to 'print'. The problem with this is that 'print' adds a
newline at the end of each string it outputs. Since it turns out that
R functions like to trickle their output out over multiple calls, this
causes things to be ho
On Mon, Nov 17, 2008 at 1:11 PM, laurent <[EMAIL PROTECTED]> wrote:
> Yes, I have briefly seen that you are doing it at the rpy2.robjects
> level. That's certainly a good way to go when wanting to offer such
> capability.
>
> Regarding SexpVector accepting numpy's one-dimensional arrays, that's
> b
On Mon, Nov 17, 2008 at 8:01 AM, laurent <[EMAIL PROTECTED]> wrote:
> On Sun, 2008-11-16 at 22:25 -0800, Nathaniel Smith wrote:
>> rpy2 is awesome.
>>
>> But I was disconcerted to discover passing a numpy array to an R
>> function just makes things blow up (&quo
rpy2 is awesome.
But I was disconcerted to discover passing a numpy array to an R
function just makes things blow up ("Nothing can be done for that
type...") -- who uses rpy without numpy? :-) So I fixed it.
Strategy:
* most numpy arrays are mapped to R arrays (shape is preserved)
* a numpy ob
69 matches
Mail list logo
