headers
muzenda80 | 1 Dec 2005 03:46
Picon
Favicon

[Rd] Geschäftliches Angebot (PR#8359)


This is a multi-part message in MIME format
--9b396eac-f0a5-492b-8e98-d4ee4e744c2e
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Gesch=E4ftliches Angebot

Sie m=F6gen =FCberrascht sein, diesen Brief von mir zu erhalten, da Sie
mich nicht pers=F6nlich kennen. Der Grund meiner Vorstellung ist, dass
ich Simon Muzenda der =E4lteste Sohn von Paul Muzenda bin , einem Farmer 
in Simbabwe, der k=FCrzlich im Landstreit in meinem Land ermordet wurde.
Ich bekam den Kontakt zu Ihnen =FCber das Internet, daher beschloss ich
Ihnen zu schreiben.
Vor dem Tod meines Vaters hatte er mich mit nach Johannesburg genommen,
um 20,5 Millionen US-$ in einer privaten Sicherheitsfirma zu
hinterlegen, da er die lauernde Gefahr in Simbabwe voraussah, legte er 
sein  Geld in Form von Edelsteinen an. Die Summe war gedacht zum Erwerb
neuer Maschinen und Chemikalien f=FCr die Farmen und zur Etablierung einer =
neuen Farm in
Swaziland.
Die Landprobleme begannen, als unser Pr=E4sident Robert Mugabe eine
Landreform einf=FChrte, die sich vorwiegend auf wei=DFe reiche Farmer und
einige wenige schwarze Farmer auswirkte und in der Ermordung und
=DCberf=E4llen durch Kriegsveteranen und einige andere Geistesgest=F6rte
gipfelte. Tats=E4chlich wurden eine Menge Menschen ermordet, eines der 
Opfer  war mein Vater.
Wegen dieses Hintergrundes floh ich mit meiner Familie aus Simbabwe, um
unsre Leben zu retten und lebe vor=FCbergehend in Holland wo
wir um politisches Asyl ersuchen und beschlossen haben, das Geld meines
(Continue reading)

Permalink | Reply | 0 comments |
headers
Prof Brian Ripley | 1 Dec 2005 08:14
Picon
Picon
Favicon

Re: [Rd] \dQuote{} in \code{} not processed

On Wed, 30 Nov 2005, Gavin Simpson wrote:

> Just wondering if this is the expected behaviour.

Yes.  The only command processed inside \code is \link (plus support for 
\example and \usage which go through the same processing).

> I was wanting to produce quoted text within \code{}, without manually
> entering the '"'. \dQuote{} seems advisable after reading the Writing R
> Extensions manual, so I tried \code{\dQuote{mytext}} expecting it to
> produce "mytext" in monospace font (with ' ' round it in the R help
> files) but it appears that \dQuote{mytext} is not processed within \code
> {} as \dQuote{mytext} is printed literally in the produced
> documentation.
>
> Is this intended? I didn't see any statements suggesting \code{} could
> not include other markup, and \code{\link{}} works...

Hmm, \dQuote is described in a section called

 	Marking text

   The following logical markup commands are available for emphasizing or
   quoting text.

and \code is described as

   Indicate text that is a literal example of a piece of a program, e.g., a
   fragment of  <at> R{} code or the name of an  <at> R{} object, using
    <at> code{typewriter} font if possible.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gavin Simpson | 1 Dec 2005 08:56
Picon
Picon
Favicon

Re: [Rd] \dQuote{} in \code{} not processed

On Thu, 2005-12-01 at 07:14 +0000, Prof Brian Ripley wrote:
> On Wed, 30 Nov 2005, Gavin Simpson wrote:
> 
> > Just wondering if this is the expected behaviour.
> 
> Yes.  The only command processed inside \code is \link (plus support for 
> \example and \usage which go through the same processing).
> 
> 
> > I was wanting to produce quoted text within \code{}, without manually
> > entering the '"'. \dQuote{} seems advisable after reading the Writing R
> > Extensions manual, so I tried \code{\dQuote{mytext}} expecting it to
> > produce "mytext" in monospace font (with ' ' round it in the R help
> > files) but it appears that \dQuote{mytext} is not processed within \code
> > {} as \dQuote{mytext} is printed literally in the produced
> > documentation.
> >
> > Is this intended? I didn't see any statements suggesting \code{} could
> > not include other markup, and \code{\link{}} works...
> 
> Hmm, \dQuote is described in a section called
> 
>  	Marking text
> 
>    The following logical markup commands are available for emphasizing or
>    quoting text.
> 
> and \code is described as
> 
>    Indicate text that is a literal example of a piece of a program, e.g., a
(Continue reading)

Permalink | Reply | 0 comments |
headers
briscoee | 1 Dec 2005 10:54

Re: [Rd] Edwin Private web case review and big savin's on our health enhancers. (PR#8360)

Edwin

Just what I was searching for. Thanks for sending it to me.

Kataniya

 -------Original Message-------

From: Maire [mailto:ob <at> qx.com] 
Sent: Wed, 30 Nov 2005 19:56:08 +0100
To: Tommy
Subject: Eulah Purchase your health aids for less money here.

Good Day Treva,

Express transport service makes sure that you get your supplements shipped
to you in the smallest amount of time necessary. Our webpage provides
thousands of products for many embarrassing afflictions. It's time you were
in the know and got your treatments from the most trusted site.
http://geocities.yahoo.com.br/waldo_noll/

Purchasing meds is no joy, but at least you don't have to get up if you get
them from us. 

Stop by our site where the service administration gives more than what's
expected.

Best

Shawn
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Kane | 1 Dec 2005 15:46

[Rd] guidelines on "depends" versus "suggests" and R versions

On the topic of when to use "suggests" and "depends" and on R version requirements.

I have cc'd this message to R-devel because I am curious about what
senior developpers think about these issues. The problem arises
because we are using some functions from the package "matchit" in a
new version of our package "portfolio". We are listing the matchit in
"suggests" rather than "depends" becuase much of the package works
without it. If a user wants the functionality which requires matchit
functions, we prompt them to install it.

Our problem is that when a user loads up matchit, it requires MASS and
Zelig via depends. Moreover, Zelig itself requires MASS and boot. So,
just to use our package portfolio, a user is now required to load up
three packages even though, I think, only a single function from one
of these packages it actually required.

Kosuke Imai writes:
 > We have MASS and Zelig in there because some functions are borrowed from 
 > those packages. 

The right way to handle this is only to make these packages as
"suggests" rather than "depends" and then install them if needed, as
you do correctly with optmatch. Note that Writing R Extensions says:

"Packages that need to be attached to successfully load the package
using library(pkgname) must be listed in the Depends field."

Although this is not directlty on point, my interpretation is that you
need a "good reason" to list a package in Depends rather than
Suggests.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Morgan | 1 Dec 2005 18:34

Re: [Rd] (not just!) Windows R CMD build <pkg> leftovers

Perhaps this earlier post slipped through the cracks? My apologies if
it's still 'in process', or I missed a response, or if the
contribution isn't helpful.

At any rate, I realized that the problem is not windows-specific.

Also, generating $libdir by calling (a sligthly modified) R_tempfile
might give installation more of a fighting chance in a cluttered TMPDIR.

Index: src/scripts/build.in
===================================================================
--- src/scripts/build.in        (revision 36565)
+++ src/scripts/build.in        (working copy)
 <at>  <at>  -76,7 +76,7  <at>  <at> 
 my $R_platform = R_getenv("R_PLATFORM", "unknown-binary");
 my $gzip = R_getenv("R_GZIPCMD", "gzip");
 my $tar = R_getenv("TAR", "tar");
-my $libdir = &file_path(${R::Vars::TMPDIR}, "Rinst.$$");
+my $libdir = R_tempfile("Rinst.");

 my $INSTALL_opts = "";
 $INSTALL_opts .= " --use-zip" if $opt_use_zip;
 <at>  <at>  -434,6 +434,8  <at>  <at> 
            if($doit && R_system($cmd)) {
                $log->error();
                $log->print("Installation failed.\n");
+               $log->print("Removing '$libdir'\n");
+               rmtree($libdir);
                exit(1);
            }
(Continue reading)

Permalink | Reply | 1 comment |
headers
Roger Peng | 1 Dec 2005 20:46
Favicon

Re: [Rd] import of Namespaces

My understanding is of your questions is below:

Matthias Kohl wrote:
> Dear R devels,
> 
> let's say I have three packages "pkg1", "pkg2" and "pkg3" which all 
> contain new S4 classes and methods. Where "pkg3" depends on "pkg2" and 
> "pkg2" depends on "pkg1". Moreover, all three packages have namespaces.
> 
> 1) I use ".onLoad <- function(lib, pkg) require(methods)". Do I also 
> have to import the namespace of "methods" package?

No.

> 
> 2) If I use import("pkg1") in the namespace of "pkg2", does this also 
> (correctly) import the S4 classes and methods of "pkg1"? Or do I 
> explicitly have to use importClassesFrom resp. importMethodsFrom?

Importing an entire package namespace will import all of the exported 
classes/methods from "pkg1".

> 
> 3) If I import the Namespace of "pkg2" in "pkg3", where the namespace of 
> "pkg2" has import("pkg1") (or maybe importClassesFrom, 
> importMethodsFrom) and I also want to use S4 classes and methods of 
> "pkg1" in "pkg3". Is it sufficient to have import("pkg2") in the 
> Namespace of "pkg3" or do I need import("pkg1") and import("pkg2")?

I believe you need to import each separately since the S4
(Continue reading)

Permalink | Reply | 0 comments |
headers
Prof Brian Ripley | 1 Dec 2005 22:09
Picon
Picon
Favicon

[Rd] tuned BLAS

I've been updating the information on tuned BLAS for R-admin in R-patched 
and R-devel.  We have

ATLAS 	(widely available, including for Windows)
MKL	(licensed on ix86 and x86_64 Linux and Windows)
ACML	(by AMD, but for all ix86 and x86_64 chips, Linux and Windows.
          Now available for gfortran.)
Goto	(academic use only, only some chips, only Linux)

MKL and ACML provide full LAPACK, the other two some optimized LAPACK 
routines.  (We have an MKL licence with our icc/ifort licences but it has 
not been delivered yet so I used a non-commercial Linux-only download. 
Hence I have not tried Windows.)

On 32-bit Linux I used my dual Athlon 2600 MP desktop (about to be 
replaced).  Goto no longer supports that chip, and ACML is not threaded 
(for gcc).  ACML was a little faster than ATLAS, which was faster than 
MKL.  However, MKL exploited the two processors to halve the elapsed time. 
MKL on that chip is poor on complex linear algehra.

On 64-bit Linux I used a dual Athlon 248.  Here the Goto BLAS was the 
fastest, but only just faster than ACML when using one CPU.  ATLAS was 
slightly slower, and MKL perhaps 20% slower but good at exploiting 2 
CPUs.  This time it was not relatively slower at complex algebra.

On Windows ACML is effective.  I tested my laptop, a 2GHz Pentium M
(such chips are far faster than their GHz would suggest).
ACML outperformed ATLAS by 10-25%.

These comparisons are biased as I have not compared MKL on Intel
(Continue reading)

Permalink | Reply | 0 comments |
headers
Prof Brian Ripley | 2 Dec 2005 11:28
Picon
Picon
Favicon

Re: [Rd] (not just!) Windows R CMD build <pkg> leftovers

On Thu, 1 Dec 2005, Martin Morgan wrote:

> Perhaps this earlier post slipped through the cracks? My apologies if
> it's still 'in process', or I missed a response, or if the
> contribution isn't helpful.

Have patience, it is `in process'.  But if you consider such things 
important (and clearly you do enough to pester) you should file a bug 
report, not post to R-devel.  This one appears to be a minor infelicity in 
a procedure only for packages with broken vignettes.  (It _would_ have 
helped to have a clearer description of the problem being addressed: 
INSTALL --build is nothing to do with vignettes, and not many CRAN 
packages have vignettes and AFAIK none are broken.  Think abut supplying 
a NEWS entry to describe the fix.)

R.exe CMD is just a roundabout way of doing what Rcmd.exe does. Don't 
confuse `necessary' with `recommended' or `efficient'.

> At any rate, I realized that the problem is not windows-specific.
>
> Also, generating $libdir by calling (a sligthly modified) R_tempfile
> might give installation more of a fighting chance in a cluttered TMPDIR.

Not sure we should be encouraging such bad housekeeping!

> Index: src/scripts/build.in
> ===================================================================
> --- src/scripts/build.in        (revision 36565)
> +++ src/scripts/build.in        (working copy)
>  <at>  <at>  -76,7 +76,7  <at>  <at>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Berwin A Turlach | 2 Dec 2005 11:31
Picon
Picon
Favicon

[Rd] Enlightenment sought and a possible buglet in vector.Rd

Dear all,

First, I recently had reasons to read the help page of as.vector() and
noticed in the example section the following example:

     x <- c(a = 1, b = 2)
     is.vector(x)
     as.vector(x)
     all.equal(x, as.vector(x)) ## FALSE

However, in all versions of R in which I executed this example, the
all.equal command returned TRUE which suggest that either the comment
in the help file is wrong or the all.equal/as.vector combination does
not work as intended in this case.  For the former case, I attach
below a patch which would fix vector.Rd.

Secondly, I stumbled across two behaviours of R that I cannot explain
but would like to know why R behaves as it does.  But since I expect
the explanations to be quite technical, I though that r-devel is the
more appropriate list to ask on than r-help.

The first example is the following:

       > f1
       function(){
           par.def <- par(no.readonly=TRUE)
           on.exit(par(par.def))
           tt <- sys.on.exit()
           print(tt)
           str(tt)
(Continue reading)

Permalink | Reply | 7 comments |

Gmane