Re: [Rd] CHAR () and Rmpi
Thank all for your quick reply. I am wrong to say Rmpi does not modify
CHARSXP at C level. In fact as Martin points out, the receive buff must be
modified. Last night I started the modification of c codes.
For send buffer (no modification), I used
//copy from R 2.6.0 (not in previous versions)
char *acopy_string2(const char *in)
{
char *out;
int len = strlen(in);
if (len > 0) {
out = (char *) R_alloc(strlen(in), sizeof(char));
strcpy(out, in);
} else
out = "";
return out;
}
char *charsxp2char(SEXP x)
{
return acopy_string2(CHAR(x));
}
// I may combine above two functions together
SEXP mpi_info_set(SEXP sexp_info, SEXP sexp_key, SEXP sexp_value){
char *key, *value;
key = charsxp2char( STRING_ELT (sexp_key,0));
value = charsxp2char (STRING_ELT (sexp_value,0));
return
AsInt(erreturn(mpi_errhandler(MPI_Info_set(info[INTEGER(sexp_info)[0]],
key, value;
}
//For modified buffer. Need to use R_alloc for better memory managment
SEXP mpi_info_get(SEXP sexp_info, SEXP sexp_key, SEXP sexp_valuelen){
int flag;
char *key, *value;
SEXP sexp_value;
key=charsxp2char( STRING_ELT (sexp_key,0));
PROTECT (sexp_value = allocVector (STRSXP, 1));
value = (char *)Calloc(INTEGER(sexp_valuelen)[0], char);
mpi_errhandler(MPI_Info_get(info[INTEGER(sexp_info)[0]], key,
INTEGER(sexp_valuelen)[0], value, &flag));
SET_STRING_ELT(sexp_value, 0, mkChar(value));
UNPROTECT(1);
Free(value);
return sexp_value;
}
This works well. However, for nonblock calls, there is no way to receive a
char vector.
I am going to tidy up the codes and remove some redundant codes.
To Prof. Ripley. I am rewriting configure.ac (from configure.in) and put
lib64 in the search path. I am working on Debian 4.0 64bit and the
original configure.ac works well. The new configure.ac can be used for
OpenMPI so Rmpi can be used under OpenMPI (many request it). In addition,
Rmpi can be compiled and run under Mac OS X. I do not know if r-project
will put lam into OS X and make Rmpi officially available to Mac. I need
to fully test Rmpi before submitting next version.
Thanks all and have nice weekend days.
Hao
Martin Morgan wrote:
> Hao Yu,
>
> I spot two types of problematic code. Certainly the memcpy in
> conversions.c:54 and 56 will cause problems, but I'm not sure whether
> those functions are actually used?
>
> The second paradigm is, e.g., Rmpi.c:561
>
> MPI_Recv(CHAR(STRING_ELT(sexp_data,i)),
> slen,MPI_CHAR,source,tag, comm[commn],&status[statusn]);
>
> where the first argument to MPI_Recv is a buffer that MPI_Recv will
> fill. sexp_data is a user-supplied character vector. A not-clever
> solution creates a temporary buffer via R_alloc (for garbage-collected
> memory) or R_Calloc (for user-managed memory, probably appropriate in
> a loop where you'd like to reuse the buffer), passes the buffer to
> MPI_Recv, and then SET_STRING_ELT with the now filled temporary buffer
> converted to a CHARSXP with mkChar. I think this is backward
> compatible. The user-supplied character vector has gone to waste, used
> only to pass in the length of the expected string. mkChar will copy
> the temporary buffer (unless an identical CHARSXP already exists), so
> that there are potentially three memory allocations per string! I
> suspect most users rely on higher-level access (mpi.par*Apply,
> mpi.*.Robj, etc) where this inefficiency is not important or can be
> addressed without modifying the public interface.
>
> Martin
>
> Prof Brian Ripley <[EMAIL PROTECTED]> writes:
>
>> I'm not sure what your sticking point here is. If mpi does not modify
>> data in a (char *) pointer, then that really is a (const char *) pointer
>> and the headers are being unhelpful in not telling the compiler that
>> the data are constant.
>>
>> If that is the case you need to use casts to (char *) and the following
>> private define may be useful to you:
>>
>> #define CHAR_RW(x) ((char *) CHAR(x))
>>
>>
>> However, you ask
>>
>>> Is there an easy way to get a char pointer to
>>> STRING_ELT((sexp_rdata),0)
>>> and is also backward compatible to old R versions.
>>
>> and the answer is that there is no such way, since (const char *) and
>> (char *) are not the same thing and any package that wants to alter the
>> contents of a string element needs to create a new CHARSXP to be that
>> element.
>>
>>
>> BTW, you still have not changed Rmpi to remove the configure problems on
>> 64-bit systems (including assuming libs are in /usr/lib not /usr/lib64)
>> I
>> pointed out a long time ago.
>>
>>
>> On Fri, 28 Sep 2007, Hao Yu wrote:
>>
>>> Hi. I am the maintainer of Rmpi package. Now I have a problem regarding
>>> the change of CHAR () in R 2.6.0. According to R 2.6.0 NEWS:
>>> ***
>>> CHAR() now returns (const char *) since CHARSXPs should no
>>>longer be modified in place. This change allows compilers to
>>
[Rd] R-Server remotecontrolled via browser-GUI
hi jeff, i have read your paper from 2005 and your rapache solution sounds good. i was wondering if u did sth about the state problem... you should put a changelog on your website. what changes will come with 1.0? and what is brew exactly for? it is like a tuned "cat", mixing r-output and text, right? so if i build a gui, brew could generate the html. but i dont'have to use brew, do i? what are the advantages of using brew with rapache? what do you think of openstatserver btw? i think there are lots of interesting and promising approaches around in R-community. but as with all OSS, same here. many people working on slightly different solutions for the same problem. and none of the solutions is feature complete, some are not even actively developed and only a few are to be seen as stable or beyond beta stadium. well, i work almost only with OSS, so i got used to it :-) it's just difficult to navigate thru the possibilities without spending too much time on recherche. have a nice day, Josuah __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Aggregate factor names
On Thursday 27 September 2007 (17:57:55), Mike Lawrence wrote: > ex. it is annoying to type > > with( > my.data > ,aggregate( > my.dv > ,list( > one.iv = one.iv > ,another.iv = another.iv > ,yet.another.iv = yet.another.iv > ) > ,some.function > ) > ) If you use my package 'memisc' you can write aggregate(some.function(my.dv)~one.iv+another.iv+yet.another.iv, data=my.data) Best, Martin -- "Dealing with failure is easy: work hard to improve. Success is also easy to handle: you've solved the wrong problem. Work hard to improve." fortune 1.0 - Dr. Martin Elff Dept. of Social Sciences University of Mannheim Block A5, Room A 328 (NEW) 68131 Mannheim Germany Phone: +49-621-181-2093 Fax: +49-621-181-2099 E-Mail: [EMAIL PROTECTED] Web: http://webrum.uni-mannheim.de/sowi/elff/ http://www.sowi.uni-mannheim.de/lspwivs/ - __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R "capabilities" on a cluster node
The double '//' is harmless. What you are failing at is that your R-build-host has the system X11 runtime libraries (libSM.so.6 and friends) while your execution hosts don't have them, and R_X11.so depends on the system X11 libraries which R cannot find on the execution hosts. So - ask your grid engine administrator to install the X11 runtime libraries on the grid nodes, or ask him/her to build a special version of R which doesn't depend on X11. (the former is the recommended approach, but your admins may think the latter suit their policies). Yes, pdf/ps are always available. (they are just save-to-file devices using R's own pdf/ps writing code). The png/jpeg situation are similar to but separate from X11. On the R build host, you need both the development headers (libpng-devel, libjpeg-devel, libX11-devel & other libX*-devel packages for redhat systems) as well as the runtime libraries (libpng, libjpeg, libX*) to build R with each of the support for these 3. On the execution hosts, you need just the runtime libraries. The reason why you are missing jpeg/png is probably because your build host doesn't have the headers. (it is relatively rare not to have jpeg/png runtime, but the headers are normally not installed). We (used to?) have a similiar situation on our sun grid - my desktop R can do png but our cluster grid R cannot. (ghostscript and a few other software can convert ps/pdf to png so it is not a big loss, just a minor inconvenience). Earl F. Glynn wrote: > R version 2.5.1 (2007-06-27) > > I' running some simple R jobs via the Sun Grid Engine on our Linux cluster > in preparation for some bigger ones. > > I checked R's capabilities on the cluster nodes (after failing to create a > png file) and am getting the following warning message: > [Run on a cluster node using qrsh:] > > > >> capabilities() > > jpeg pngtcltk X11 http/ftp sockets libxml fifo > >FALSEFALSEFALSEFALSE TRUE TRUE TRUE TRUE > > clediticonv NLS profmem > > TRUE TRUE TRUEFALSE > > Warning message: > > unable to load shared library > '/n/site/inst/Linux-i686/bioinfo/R/2.5.1/lib/R/modules//R_X11.so': > > libSM.so.6: cannot open shared object file: No such file or directory in: > capabilities() > > > > > > Is the double slash (//) in the path above a bug in how we've configured R > here (the /n/site/inst/ directory is shared but is platform specific), or a > bug in how the capabilities command works? The file does exist if the > double slash in the path had not caused the warning above. > > > > > > > How can one programmatically get the info from ?Devices, which appears to be > dynamic based on one's system? Is it safe to assume that pdf's or > postscript files are always available in R since they're not listed in > capabilities and seem to be shown everywhere under ?Devices ? > > > > > > Part of the ?Devices output on a cluster node says this: > > > >The following devices will be available if R was compiled to use > > them: > > > > * 'X11' The graphics driver for the X11 Window system > > > > * 'png' PNG bitmap device > > > > * 'jpeg' JPEG bitmap device > > > > We can just recompile to get png or jpeg support? Are X11 libraries used on > cluster nodes while running "headless"? Can I create pngs or jpegs without > X11? > > > > Thanks for any advice about this. > > > > efg > > > > Earl F. Glynn > > Scientific Programmer > Stowers Institute for Medical Research > > __ > 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] pairlist objects
Hi,
?pairlist gives no explanation about what exactly is the difference
between a pairlist and a list (except that a pairlist of length 0
is 'NULL'). So, what's a pairlist?
class(.Options)
[1] "pairlist"
Some strange things about the "pairlist" type:
> showClass("pairlist")
Error in getClass(Class) : "pairlist" is not a defined class
Why the above doesn't work? It works for "list":
> showClass("list")
No Slots, prototype of class "list"
Extends: "vector"
> is.list(.Options)
[1] TRUE
> is.vector(.Options)
[1] FALSE
This doesn't make sense! If 'x' is a list, then it should be considered
a vector too.
Subsetting a pairlist with [] doesn't produce a pairlist:
> class(.Options[1:3])
[1] "list"
Yes, this one is documented, but still...
Cheers,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
