[Rd] IPC
Hi, I need to somehow make R communicate with another remote JAVA process which provides compute services. I have control over the communications protocol, but I would like to keep it to a standardised protocol, such as SOAP, CORBA, etc. What I would like to know is, what do other people use to do this? The nature of the communications will be low bandwidth procedure calls, with little data. (The data is stored in a DBMS). To date I have tried the RCORBA and SSOAP packages. Corba I couldn't get to compile, and soap I couldn't get to talk properly to soapanywhere (the embedded soap implementation I am trialing). I'm sure with persistence I can get both working, but I would like to hear others experiences before I invest the time. Thank you for your time. -- Nigel Sim PhD Candidate School of Mathematics and Physical Sciences James Cook University +61 7 4781 4247 +61 409 277 641 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] IPC
for very low bandwidth IPC I'd just use a standard web page form using a GET... so all you have to do is call a URL with the parameters embedded in the URL, e.g. http://silly.name.for.server.com/javaServlet?a=42&b=394&c=1982&d=complex If your bandwidth requirements are a bit higher then you have to start using POST which is a bit more complicated though... so at that stage I might use SOAP. cheers! Sean On 21/08/05, Nigel Sim <[EMAIL PROTECTED]> wrote: > Hi, I need to somehow make R communicate with another remote JAVA > process which provides compute services. I have control over the > communications protocol, but I would like to keep it to a standardised > protocol, such as SOAP, CORBA, etc. > > What I would like to know is, what do other people use to do this? The > nature of the communications will be low bandwidth procedure calls, with > little data. (The data is stored in a DBMS). To date I have tried the > RCORBA and SSOAP packages. Corba I couldn't get to compile, and soap I > couldn't get to talk properly to soapanywhere (the embedded soap > implementation I am trialing). > > I'm sure with persistence I can get both working, but I would like to > hear others experiences before I invest the time. > > Thank you for your time. > -- > Nigel Sim > > PhD Candidate > School of Mathematics and Physical Sciences > James Cook University > +61 7 4781 4247 > +61 409 277 641 > > __ > [EMAIL PROTECTED] mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] IPC
Absolutely - only the simplest of requests with the lowest of bandwidth requirements should use plain GET requests. Beyond that you must use some form of detail encapsulation. SOAP is layer ontop of HTTP POST requests which is semi-standardized - ie how a number is encoded is standardized, you still have to code what parameters are going across the gap at both ends. There is a lot of hype about how standard SOAP is... you are still left with a lot of work to do! :-) Sometimes it is useful not to have too many dependancies on other packages or outside software, ie, if you can get away with a simple GET request in plain R, go for it, but as Duncan says, you need to beware of character encoding. s/ On 21/08/05, Duncan Temple Lang <[EMAIL PROTECTED]> wrote: > Sean O'Riordain wrote: > > for very low bandwidth IPC I'd just use a standard web page form using > > a GET... so all you have to do is call a URL with the parameters > > embedded in the URL, e.g. > > > > http://silly.name.for.server.com/javaServlet?a=42&b=394&c=1982&d=complex > > > > If your bandwidth requirements are a bit higher then you have to start > > using POST which is a bit more complicated though... so at that stage > > I might use SOAP. > > POST is not equivalent to SOAP. SOAP uses POST. > > In order to avoid all the details dealing with HTTP requests > such as escaping characters, SSL, passwords, POST/GET, etc., it is simplest > to use something that already takes care of these. > The RCurl package (www.omegahat.org/RCurl) is in interface libcurl which > takes care of > so many of these details. httpRequest (regular CRAN package) is implemented > entirely > within R, but doesn't handle as many of these extra details. > > D. > > > > > cheers! > > Sean > > > > On 21/08/05, Nigel Sim <[EMAIL PROTECTED]> wrote: > > > Hi, I need to somehow make R communicate with another remote JAVA > > > process which provides compute services. I have control over the > > > communications protocol, but I would like to keep it to a standardised > > > protocol, such as SOAP, CORBA, etc. > > > > > > What I would like to know is, what do other people use to do this? The > > > nature of the communications will be low bandwidth procedure calls, with > > > little data. (The data is stored in a DBMS). To date I have tried the > > > RCORBA and SSOAP packages. Corba I couldn't get to compile, and soap I > > > couldn't get to talk properly to soapanywhere (the embedded soap > > > implementation I am trialing). > > > > > > I'm sure with persistence I can get both working, but I would like to > > > hear others experiences before I invest the time. > > > > > > Thank you for your time. > > > -- > > > Nigel Sim > > > > > > PhD Candidate > > > School of Mathematics and Physical Sciences > > > James Cook University > > > +61 7 4781 4247 > > > +61 409 277 641 > > > > > > __ > > > [EMAIL PROTECTED] mailing list > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > > __ > > [EMAIL PROTECTED] mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- > Duncan Temple Lang[EMAIL PROTECTED] > Department of Statistics work: (530) 752-4782 > 371 Kerr Hall fax: (530) 752-7099 > One Shields Ave. > University of California at Davis > Davis, CA 95616, USA > > > > > > __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] weigths in boxplot
In R 2.2.0 density now can work with weighted obesrvations. It would be nice if boxplot also would accept a weight parameter, then one could produce consistent density estimators and boxplots. Could the developers consider adding this feature? -- Erich Neuwirth, Didactic Center for Computer Science University of Vienna Visit our SunSITE at http://sunsite.univie.ac.at Phone: +43-1-4277-39902 Fax: +43-1-4277-9399 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] segmentation fault in R-patched-2005-08-21 (PR#8081)
This report describes two similar, but different scripts causing segmentation fault in R-2.1.1 and R-patched_2005-08-21. The first is a script that causes segmentation fault in R-2.1.1. Although the script runs correctly under R-patched_2005-08-12 and R-patched_2005-08-21, there is still a reason to investigate the bug in more detail. The second is a slightly different script that causes segmentation fault in R-patched_2005-08-12 and R-patched_2005-08-21 (I did not try the intermediate versions). Both bugs were observed under two different installations of RedHat: 1. Fedora Core release 2 (Tettnang) with gcc (GCC) 3.3.3 20040412 (Red Hat Linux 3.3.3-7), 2. Red Hat Linux release 9 (Shrike) with gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5) In both cases, the compilation used the default settings. If the compilation used ./configure --with-readline=no --with-x=no then the bugs did not appear. I did not succeed to reproduce any of the bugs under SuSE 8.2 with gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux). In the installations, where the bugs occur, they are reproducible deterministically. More information including the discussed scripts and the data (36M), which they require are in http://www.cs.cas.cz/~savicky/archive/r_segfault-0.tar.gz Petr Savicky __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] IPC
Firstly, thanks for all the quick replies. > Can you let me know what went wrong with SSOAP? It would be > good to fix this and I am about to turn my attention to it anyway. Well, I could not get SSOAP to pass the xmlns which specifies the set of services being requested in the place where soapanywhere expected it. SSOAP namespaced the actual function call while soapanywhere wanted it declared in the envelope namespace declarations. SO, I don't really think it is a problem with the SSOAP implementation, rather it is probably an incomplete implementation of soap in soapanywhere. If anyone knows of a more complete, embedded java soap implementation please let me know. AXIS would be nice, but I've not found how to deploy it without a tomcat style container. > > As for the "RCORBA" package - what precisely are you referring to? > I don't think there is a package named RCORBA, perhaps you mean > RSCORBA. If so, yes it is quite old. It can be updated > and indeed I have a plan that I might connect it to Orbit. > But if RSCORBA didn't compile, you might want to mention which > CORBA implementation you were trying to use: it was setup to use > 3. And yes, RSCORBA is what I was referring to, and I was trying to compile it against orbit (a la Gnome). > > > > As for what people typically use to connect to Java. > There is Rserve. There is RSJava. > I think your desire to use a standard protocol is a very > good one. There are far too many ad hoc solutions that don't > do have limited functionality, such as callbacks. > On Windows, DCOM client and server and event packages are available. > And there are MPI or PVM packages which implement a form of IPC. > > Do you absolutely need to have a middle-tier of going through > the server to get to the DBMS? It is often a good design, > but if you can go straight to the DBMS, then that would be > esier and more efficient. The architecture is that both R and Java directly access the DB for data storage and retrieval. R calls to Java are simply to invoke some datamining function (from the WEKA package), and to query where execution is up to. There is no proxying of data. R -> Java \ / _\/ |/_ DBMS > > Please let me know what went wrong with the SSOAP package. > > D. > > > > > > I'm sure with persistence I can get both working, but I would like to > > hear others experiences before I invest the time. > > > > Thank you for your time. > > -- > > Nigel Sim > > > > PhD Candidate > > School of Mathematics and Physical Sciences > > James Cook University > > +61 7 4781 4247 > > +61 409 277 641 > > > > __ > > [EMAIL PROTECTED] mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Nigel Sim PhD Candidate School of Mathematics and Physical Sciences James Cook University +61 7 4781 4247 +61 409 277 641 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bizarre signif stars in Sweave latex
OK. I give up. I'll ask a stupid question. How do I get the [EMAIL PROTECTED] signif stars line printed by summaries to not look extremely bizarre in the latex produced by Sweave? For example, see p. 7 of http://www.stat.umn.edu/geyer/aster/library/aster/doc/tutor.pdf I can see what the problem is. R emits non-ascii characters (as it is supposed to do), Sweave puts them in the tex file, and latex can't handle them. But I don't see the solution. H. Well I just discovered a kludge <>= Sys.setlocale(category = "LC_ALL", locale = "C") @ at the beginning of the Rnw file. But is that TRT (the Right Thing)? -- Charles Geyer Professor, School of Statistics University of Minnesota [EMAIL PROTECTED] __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Internationalization questions
Dear R-devel list members:
I have two internationalization questions, related to questions that I posed
previously. These pertain to Windows (I've tried under Win XP but assume the
issue is more general) and R 2.1.1 patched and 2.2.0 devel.
(1) I've noticed that the standard Windows dialogs in R -- whether initiated
from the Rgui menus, from winDialog(), or from tcltk functions such as
tkmessageBox() -- do not have button labels translated when running in a
non-English locale. For example, when running in a French locale, the
command
winDialog(type="yesnocancel", message=gettext("Save workspace image?",
domain="RGui"))
produces a dialog box with the message translated to "Sauver une image de la
session?", but the buttons still read "Yes", "No", and "Cancel".
Is this the intended behaviour? Is there any way to get the button text
translated? I've implemented a partial solution that uses a substitute for
tkmessageBox(), but it is a bit awkward.
(2) I'm still looking for a reliable way to determine whether R is using
English. Currently, I have the function
English <- function() {
env <- Sys.getenv()
names(env) <- toupper(names(env))
LANG <- env["LANGUAGE"]
LC_CTYPE <- Sys.getlocale("LC_CTYPE")
if (!is.na(LANG)) length(grep("^en", LANG, ignore.case=TRUE)) > 0
else LC_CTYPE == "C" || length(grep("^en", LC_CTYPE, ignore.case=TRUE))
> 0
}
(adapting and extending a suggestion by Simon Urbanek) which checks not just
the locale but also for an environment variable named LANGUAGE. Is this
sufficient?
Any help would be appreciated.
John
John Fox
Department of Sociology
McMaster University
Hamilton, Ontario
Canada L8S 4M4
905-525-9140x23604
http://socserv.mcmaster.ca/jfox
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bizarre signif stars in Sweave latex
What locale is this?
My guess is that this is a UTF-8 locale. If so, you need to tell latex
the input is in UTF-8, which you can do in the current LaTeX release
(you need 2003/12/01). As I recall you do this by
\usepackage[utf8]{inputenc}
On Sun, 21 Aug 2005, Charles Geyer wrote:
> OK. I give up. I'll ask a stupid question.
> How do I get the [EMAIL PROTECTED] signif stars line printed by summaries
> to not look extremely bizarre in the latex produced by Sweave?
> For example, see p. 7 of
>
>http://www.stat.umn.edu/geyer/aster/library/aster/doc/tutor.pdf
>
> I can see what the problem is. R emits non-ascii characters (as it
> is supposed to do), Sweave puts them in the tex file, and latex can't
> handle them. But I don't see the solution.
>
> H. Well I just discovered a kludge
>
> <>=
> Sys.setlocale(category = "LC_ALL", locale = "C")
> @
>
> at the beginning of the Rnw file. But is that TRT (the Right Thing)?
>
> --
> Charles Geyer
> Professor, School of Statistics
> University of Minnesota
> [EMAIL PROTECTED]
>
> __
> [EMAIL PROTECTED] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Internationalization questions
On Sun, 21 Aug 2005, John Fox wrote:
> Dear R-devel list members:
>
> I have two internationalization questions, related to questions that I posed
> previously. These pertain to Windows (I've tried under Win XP but assume the
> issue is more general) and R 2.1.1 patched and 2.2.0 devel.
>
> (1) I've noticed that the standard Windows dialogs in R -- whether initiated
> from the Rgui menus, from winDialog(), or from tcltk functions such as
> tkmessageBox() -- do not have button labels translated when running in a
> non-English locale. For example, when running in a French locale, the
> command
>
> winDialog(type="yesnocancel", message=gettext("Save workspace image?",
> domain="RGui"))
>
> produces a dialog box with the message translated to "Sauver une image de la
> session?", but the buttons still read "Yes", "No", and "Cancel".
>
> Is this the intended behaviour? Is there any way to get the button text
> translated? I've implemented a partial solution that uses a substitute for
> tkmessageBox(), but it is a bit awkward.
You need to have Windows set to be in French dialogs, not just the locale
set to French. This is on the second page of the Regional settings
doalogs in WinXP. It is intended, as it makes all Windows dialogs work
consistently. (You can have different settings on the three pages, but
not all combinations work successfully -- the current rw-FAQ has some
comments.)
> (2) I'm still looking for a reliable way to determine whether R is using
> English. Currently, I have the function
>
> English <- function() {
>env <- Sys.getenv()
>names(env) <- toupper(names(env))
>LANG <- env["LANGUAGE"]
>LC_CTYPE <- Sys.getlocale("LC_CTYPE")
>if (!is.na(LANG)) length(grep("^en", LANG, ignore.case=TRUE)) > 0
>else LC_CTYPE == "C" || length(grep("^en", LC_CTYPE, ignore.case=TRUE))
>> 0
>}
>
>
> (adapting and extending a suggestion by Simon Urbanek) which checks not just
> the locale but also for an environment variable named LANGUAGE. Is this
> sufficient?
Using English for what? (See my comments above.) For messages, yes, it
covers all the quirks we know about in the major OSes.
Brian
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
