On Mon, Mar 23, 2009 at 11:54 PM, Laurent Gautier <lgaut...@gmail.com> 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 reimplementing IPython :-). > That's definitely something going beyond the use of rnumpy vs robjects. It > seems possible to have "switch to R" magic that would be independent of the > high-level interface (you know, today robjects and rnumpy, but tomorrow > people will come up with robjects_like_it_should_be and > rnumpy_extra_super_plus ;-) ). On the one hand, that'd be nice. On the other... eh. It's easy to get dizzy worrying about things people might want someday, but it doesn't accomplish much. When people want it, we can just change the code then. (Or they can, if they really want it...) Really, it's not like there's been a big problem historically with *too many* people building Python/R interfaces :-). And if anyone invents rnumpy_extra_super_plus, I hope they call it "rnumpy" (maybe with a version number bump). Really, the goal should be to have a single "best of breed" interface that we can all focus our efforts on, and have a single recommendation for new users. I'm just not sure how we get there. >>> I think that the problem listed in the "limitation" can be worked around >>> by >>> wrapping calls in "withVisible()" (see the tip in rpy2/demos/radmin.py) >> >> Yeah, that's part of a solution, but see my other email. > > It currently is a low-energy way to get it working (see my answer to your > other email). ...I don't see any replies to it (yet)? >> My main wishlist from rpy2 right now is: >> -- that call interface, to fix both the visibility and verboseness >> problems > > On the radar. > >> -- some way for ProcessEvents to get called while blocked in the >> consoleRead callback (this is tricky!) > > May be less than it seems. The consoleRead callback has a C-level wrapper in > rpy2/rinterface/rinterface.c, where a flag can be set upon entering. > ProcessEvents has a wrapper in rinterface.c, and the flag previously defined > can be checked when entering. > (This is does protect people hitting directly ProcessEvents through ctypes, > but well...). I'm not sure what you're saying here, but on further thought, I think the answer is basically just that there need to be two locks -- one that prevents *all* access to R, and one that prevents all access to R except ProcessEvents. Most code takes both, but callbacks can release the latter while processing, and ProcessEvents only takes the latter. The latter lock is taken before the former. >> -- R->Python calls, so I can provide a magic 'py' object in R mode, >> that lets one access the Python workspace :-). > > There is semi-dead code from Alexander I keep in the source. From a visual > inspection, the code looked like it would work... but that was before the > locking/threading parts. It may require some thoughts, but I am hoping to > have it for rpy2-2.1.x Locking/threading really isn't that big a deal...? -- Nathaniel ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ rpy-list mailing list rpy-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rpy-list
