Re: [Rd] R-Cocoa Bridge
>>> I had seen old posts on the list (circa 2002) regarding a Cocoa-R >>> bridge that was under development, but I can't find anything recent >>> about it. Does anyone know if this is available somewhere? If not, >>> does anyone have any experience/pointers calling R functions from >>> Cocoa? >> >> The R builds on OSX build an R.Framework; you can probably bootstrap >> off of that without too much trouble. [I haven't done much with it; >> wish I had time.] > > Unfortunately the R/ObjC bridge is not part of the framework yet. We're > working on it, but we need some more cleanup of the old code. The > current plan is to have it ready for R 2.7.0 (but you never know ...). Good to know - looking forward to it. Thanks, Simon! --elijah __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-Cocoa Bridge
> I had seen old posts on the list (circa 2002) regarding a Cocoa-R bridge > that was under development, but I can't find anything recent about it. > Does anyone know if this is available somewhere? If not, does anyone > have any experience/pointers calling R functions from Cocoa? The R builds on OSX build an R.Framework; you can probably bootstrap off of that without too much trouble. [I haven't done much with it; wish I had time.] --elijah __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Advice on parsing / overriding function calls
> The issue is more about whether he wants to limit *all* file system
> access or just limiting to certain areas. For the former,
> I would set up a chroot jail and run R from within; for the latter,
> I would probably do something with LD_LIBRARY_PRELOAD to override
> all the file system accessing functions in libc directly, really.
> That would fix the problem with system(rm) and some such, I think,
> because if your entire R process and any sub-process R launches has no
> access to the genuine libc fwrite/fread/etc functions you cannot do
> any demage, right?
> Both are tricky and take time to do (the chroot jail a bit easier,
> actually...), but quite do-able.
a sneaky trick:
for each compute session, automate setting up a zone ("solaris
containers") on a solaris 10+ box. if you have a
preinstalled/preconfigured zone template, snapshotted with zfs, you can
roll out a new compute zone in literally seconds. you can quota it, limit
the amount of CPU it gets, etc. really not very difficult at all to set
up. sun's tools are *great* for this nowadays.
this is substantially safer than chroot() or LD_PRELOAD tricks, and lets
you do this stuff without having to invent the wheel.
it also reduces overhead to the point where you really *can* set up a
naked compute (well, with R in it...) environment for every compute
session getting instantiated. in way, way, way less time than it takes
for the computations to actually run.
if someone does system(rm) in a container... who cares? they just trashed
their own session, and nothing else. just blow the trashed ones away
periodically.
--e
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Compiling R for the Sony Playstation 3?
> I bought a Wiimote and a Nunchuck (which has a couple extra buttons, > trigger, a 'hat'-style analog joystick, and a few more accelerometers) a > couple months ago with the intent of eventually doing some experimenting > with them. No time available, yet. (for folks who don't already know this - the wiimotes are bluetooth devices. there are also bits available to use them as mice with windows or a macintosh) --e __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Compiling R for the Sony Playstation 3?
>> Beyond that, there may be a few more things that can be done to make R >> run "stupidly fast" on ps3 or IBM Cell blades. > Wouldn't the right way to go here be to make it use the PS3 graphics > hardware, in a http://www.gpgpu.org/ kind of way? Or are the Cell > processors on the PS3 graphics processors too? The accelerated-graphics bits in the ps3 are not exposed to the linux kernel, due to NDA/licensing/SuperSekritTypeStuff at Sony. But, yes, post-reverse engineering, that would be nice. :-) My understanding is that Sony expects to be able to make games for the PS3 hardware for the next decade or so. This seems fairly reasonable, given that they only stopped making games for the PS**ONE** two or three years ago. I still occasionally see them in stores, even. > Of course if you are doing this for fun I'd like to see a Nintendo Wii > port, just so I can play Super Mario Generalised Linear Modelling by > waving the controller around. There is a python script available to make the wiimotes act as a standard X11 mouse device (on linux, via /dev/input/mice); I hear that this works just fine. The link to instructions is here: http://www.wiili.org/index.php/WMD I bought a Wiimote and a Nunchuck (which has a couple extra buttons, trigger, a 'hat'-style analog joystick, and a few more accelerometers) a couple months ago with the intent of eventually doing some experimenting with them. No time available, yet. [What I want is to be able to fly through large social network graphs in R... rendered in OpenGL. Is that too much to ask? :-)] --e __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Compiling R for the Sony Playstation 3?
I've been working off-and-on for a few months on devising some patches to
R to make it much happier with a Cell processor; to be honest I've not
had much time to work at it lately.
Douglas is right that it is mostly a PPC64 sort of architecture; taking
real advantage of the hardware is going to require support for a different
BLAS (that knows how to handle the SPUs...) be patched into R's configure
scripts.
Beyond that, there may be a few more things that can be done to make R run
"stupidly fast" on ps3 or IBM Cell blades.
--e
On Fri, 3 Aug 2007, Douglas Bates wrote:
> Date: Fri, 3 Aug 2007 08:52:35 -0500
> From: Douglas Bates <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: R-devel List
> Subject: Re: [Rd] Compiling R for the Sony Playstation 3?
>
> On 8/1/07, Marc Schwartz <[EMAIL PROTECTED]> wrote:
>> On Wed, 2007-08-01 at 11:13 -0500, Douglas Bates wrote:
>>> Has anyone installed Linux on a Sony Playstation 3 and compiled R for it?
>
>> Doug,
>>
>> I don't have any personal experience with both Linux and R on the PS3,
>> but do know folks who have run Linux successfully on that platform.
>>
>> Here are some links that you might find helpful to at least cover the
>> first part:
>>
>> http://www.playstation.com/ps3-openplatform/manual.html
>>
>> http://en.wikipedia.org/wiki/Linux_for_PlayStation_3
>>
>> http://www.engadget.com/2006/11/19/fedora-linux-up-and-running-on-playstation-3-with-video/
>>
>>
>> There are additional links, as usual, on the Wikipedia page.
>
> I did successfully install Ubuntu 7.04 ("feisty") on a Playstation 3.
> Once you have Ubuntu installed you can use the standard package
> management tools for Debian/Ubuntu to install the r-base-core,
> r-recommended and r-base-dev packages. Those packages are for R-2.4.1
> but I had no trouble installing and checking the most recent versions of
> R from the SVN site.
>
> Essentially the Playstation 3 becomes a typical Ubuntu system with all
> the tools from Ubuntu. At present X11 uses the framebuffer device so
> the graphics is poor by X11 standards and very poor by gamer's
> standards.
>
> Overall it is quite amazing given that the PS3 with a 60GB hard drive is
> now being sold in the U.S. for $500 and that includes a Blu-ray DVD
> drive and full 1080p HDMI interface. At $500 it is one of the cheapest
> Blu-ray DVD players, which is what I bought it for. It's great to be
> able to run R on my DVD player.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Planet R - a weblog aggregator for statistical computing
Announcing... Planet R - a weblog aggregator for statistical computing Q: What is it? A: An aggregator for weblog posts about statistical computing topics, focused primarily around the R community. Q2: Where is it? A2: For now, at http://planetr.stderr.org Q3: What's it good for? A3: Hopefully, collecting resources and weblog posts from people who might otherwise not know about each other. Community-building, you see? Q4: How do I get my stuff on there? A4: Send mail to [EMAIL PROTECTED], with a representative subject line (e.g. 'please add to planet r' will be fine..); I'll need the link to the RSS feed of your blog or other resource. If you'd like a personal icon in the style of Planet Debian or Planet Gnome (or one of those other planetplanet-based sites..) feel free to send along a smallish picture or icon as well. (Think 80-by-80 pixels...) Q5: What sort of things are there? A5: A selection of weblogs about statistical computing, a feed from omegahat, some bioconductor-related content, feeds from a couple of journals (including JoSS content, as a subset of the J Computational and Graphical Statistics, as well as Royal Statistical Society content sourced from IngentaConnect...), the changes feed from the R Wiki, and a few other things of great utility to the R community. Please feel free to contact me directly with further content, media, suggestions, et cetera, that you think would enhance the utility of this site as a resource to the community. thanks, --elijah wright indiana university bloomington school of library and information science __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building R on Solaris
> Sun Studio 11 compilers (which are now a free download). > A set of Open Source tools from www.sunfreeware.com in /usr/sfw. > A large set of Open Source tools in /opt/csw. > > The latter was new to me, and uses a repository at www.blastwave.org and > a nifty tool called 'pkg-get'. My sysadmin (who has an HP-UX and Debian > bias) thought this was the best he had seen, ahead of apt-get and yum, > for example. This box already had everything I needed to build R, > including Your sysadmin will change his mind the first time that blastwave packages totally f*ck one of his machines. They're usually a bit stale. Building your own kit is much more reliable... --elijah __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] IDE for R C++ package writing ?
Ya, copy/paste from .Rhistory is pretty common. Especially among newbies and oldsters who dislike IDEs. :) [I got burned by Borland, way back when, and basically can't stand "wizards" and the like now...] Looks like someone wrote a "send-to-R" plugin for vim last year: http://www.vim.org/scripts/script.php?script_id=1048 --e On Mon, 26 Feb 2007, Ramon Diaz-Uriarte wrote: > Date: Mon, 26 Feb 2007 16:19:54 +0100 > From: Ramon Diaz-Uriarte <[EMAIL PROTECTED]> > To: r-devel@r-project.org > Cc: [EMAIL PROTECTED], mel <[EMAIL PROTECTED]> > Subject: Re: [Rd] IDE for R C++ package writing ? > > On Monday 26 February 2007 16:51, [EMAIL PROTECTED] wrote: >>> First, great thanks to all for all the answers. I confess i was a bit >>> scared about (re)learning a possible tomorrow obsolete tool. >>> >>> I'm however quite astonished nobody proposes another tool. Do 100% R >>> package developers use emacs ? >> >> Plenty of folks don't use an IDE at all. Copy/pasting working bits of >> code from your .Rhistory into a working file is a very useful tactic... > > You kidding, right? (I mean, maybe lots of people do that, but maybe that > ain't such a good idea :-). > > R. > > P.S. Whether or not emacs + ess + ecb + a whole bunch of other things is or > not a "real IDE" (whatever that means) I think is tangential to the original > question. The issue, if I understand, are editing tools that will make the > editing et al. simpler. So > >>> I'm however quite astonished nobody proposes another tool. Do 100% R >>> package developers use emacs ? >> > > No. Not 100%. But you said you'll be using Windows but want to move to > GNU/Linux. Then, you might want to use the very same tool over a range of > OSs, or regardless of whether you are in front of your workstation, or > accessing it over a slow modem connection, etc. In such cases, Emacs is an > excellent choice. Or one of the very, very few. In addition, I think you are > seeing an example of "once you try emacs, you often realize that other > choices do not really offer you all that much, but you loose a lot". > > HTH, > > R. > > >> >> --e >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] IDE for R C++ package writing ?
> First, great thanks to all for all the answers. I confess i was a bit > scared about (re)learning a possible tomorrow obsolete tool. > > I'm however quite astonished nobody proposes another tool. Do 100% R > package developers use emacs ? Plenty of folks don't use an IDE at all. Copy/pasting working bits of code from your .Rhistory into a working file is a very useful tactic... --e __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rscript on Windows
> Surely R has higher standards than that. How about quality and > completeness of implementation? > > Every other major scripting language has implemented this for good > reason and its a glaring omission. Gabor, can we get a URL from you to a patch that implements this functionality? Thanks! --elijah __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Whine in dual core Windows PC if R uses full CPU capacity
> I think I've only come across it a couple of times, and didn't have any > replication, so I don't know if they were unusual individuals or a > design problem. From your description of replacing the mb, it sounds as > though it's a design problem -- unless as Uwe suggested, it's a power > supply or some other part that you didn't replace. I've seen this kind of resonance problem before, in a couple of different computers with a couple of different mixes of hardware. What usually comes out, eventually, is that some part in your system is very poorly shielded and ends up reacting badly to other sorts of activity in the system. I've seen both video cards and audio boards involved in this kind of problem, as well as the more sterotypical "dirty" power supply or third-rate motherboard design. I've also seen spurious current applied to the expansion bus [by a functional, but marginal card] cause very similar issues. The only way to *really* trace down the problem is to swap the parts in the machine for other, known-non-problematic parts. This is expensive, and takes a lot of time. --elijah __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
