Re: [Rd] problem with \eqn (PR#8322)
> Hin-Tak Leung writes:
> Ross Boylan wrote:
>> On Mon, 2005-11-21 at 10:27 +, Hin-Tak Leung wrote:
>>
>>> Kurt Hornik wrote:
>>>
>>>
Definitely a problem in Rdconv.
E.g.,
$ cat foo.Rd
\description{
\eqn{{A}}{B}
}
[EMAIL PROTECTED]:~/tmp$ R-d CMD Rdconv -t latex foo.Rd | grep eqn
\eqn{{A}}{A}{{B}
shows what is going on.
>>>
>>> There is a "work-around" - putting extra spaces between the two braces:
>>>
>>> $ cat foo.Rd
>>> \description{
>>> \eqn{ {A} }{B}
>>> }
>>>
>>> $R CMD Rdconv -t latex foo.Rd
>>> \HeaderA{}{}{}
>>> \begin{Description}\relax
>>> \eqn{ {A} }{B}
>>> \end{Description}
>>>
>>>
>>> HT
>>
>> Terrific! I can confirm that works for me and, in a way, a work-around
>> is better than a fix. With the work-around, I can distribute the
>> package without needing to require that people get some not-yet-release
>> version of R that fixes the problem. I do hope the problem gets fixed
>> though :)
>>
>> By the way, I couldn't see how the perl code excerpted earlier paid any
>> attention to {}. But perl is not my native tongue.
>>
>> Ross
>>
> Glad to hear - the extra space in the latex-eqn-processed part of
> \eqn (versus the ascii part) possibly get skipped so there shouldn't
> be visual difference if it works.
> Regarding the perl code - "share/perl/R/Rdconv.pm" around line 400 -
> reproduced again here - the way I understand it, "\eqn{{a}}{b}" is first
> transformed into something like
> "\eqnbraces1brace2abrace2brace1brace1bbrace1", then called as
> "get_arguments {'eqn', ..., 2}", which then tries to extract "a" and
> "b". $ID is defined elsewhere to be "brace1", etc. That's the idea.
> The 4 regular expressions - the 1st, 2nd and the 4th probably should be
> non-greedy (i.e. "??" instead of "?", and ".*?" instead of ".*"). But
> then, this is just my idea and I haven't tried very hard to figure out
> what it is supposed and not supposed to do...
> For those who wants to get to the bottom of it, I think inserting
> something like this (this just append $text into a tmp file) would be
> useful, against the small snipplet that Kurt provided:
> open(JUNK, ">> /tmp/junk");
> print JUNK "outer/inner loop:", $text, "\n";
> close(JUNK);
> HT
> ===
> ## Get the arguments of a command.
> sub get_arguments {
> my ($command, $text, $nargs) = @_;
> ## Arguments of get_arguments:
> ## 1, command: next occurence of 'command' is searched
> ## 2, text:'text' is the text containing the command
> ## 3, nargs: the optional number of arguments to be extracted;
> ## default 1
> my @retval;
> ## Returns a list with the id of the last closing bracket and the
> ## arguments.
> if($text =~ /\\($command)(\[[^\]]+\])?($ID)/){
> $id = $3;
> $text =~ /$id(.*)$id/s;
> $retval[1] = $1;
> my $k=2;
> while(($k<=$nargs) && ($text =~ /$id($ID)/)){
> $id = $1;
> $text =~ /$id\s*(.*)$id/s;
> $retval[$k++] = $1;
> }
> }
> $retval[0] = $id;
> @retval;
> }
> ==
> HT
I think I have a fix for this. Will shortly commit to r-devel.
-k
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Makefiles and other customization
> Ross Boylan writes: > Writing R Extensions mentions that a package developer can provide a > Makefile, but gives very little information about what should be in it. > It says there must be a clean target, and later on there's mention of > $(SHLIB): $(OBJECTS) > $(SHLIB_LINK) -o $@ $(OBJECTS) $(ALL_LIBS) > (in the F95 discussion). > What should a Makefile provide, and what can it assume? In other > words, what variables and environment setup should have been done? My > guess is that all the R boilerplate for Makefiles will have been read > before the Makefile I provide. It appears from the F95 example that > the Makefile has to get the names of the files it needs itself. > I suspect this is not documented more fully because of the extreme > difficulty of writing a portable Makefile. However, I already have a > "Makefile.full", so called to avoid having R use it. Makefile.full > does lots of stuff, so portability is already compromised. I'm > thinking it might be more direct to provide "Makefile," since I'm now > trying to alter what R CMD build does. > I posted a related question on r-help, before I realized this kind of > issue is more appropriate for this list. The question I asked there > was whether it would be reasonable to do my own tar of the files I > wanted to distribute in place of using R CMD build. I'm also > interested in knowing about that. > https://stat.ethz.ch/pipermail/r-help/2005-November/081758.html > (though the thread has so far been on a tangential issue). > Here is that first post, if you want more background: > --- > I've made a package for which R CMD build isn't producing very > satisfactory results. I'll get to the details in a moment. > I wonder if it would make sense to have my own makefiles (which > already exist and are doing quite a lot) produce the .tar.gz file > ordinarily produced by R CMD build. As far as I can tell, R CMD build > basically tars up of the project directory after running some checks. > I could run R CMD check separately. > There are two main problems with the results of R CMD build. First, > it has lots of files that I don't want included (the input files used > to generate configure, miscellaneous garbage, other stuff not suitable > for distribution). Second, I have data files as both "data.gz" and > "data". R puts "data" into the .tar.gz file and sensibly ignores the > .gz file. Unfortunately, my makefiles assume the existence of the > "data.gz" files, and so may have trouble after the .tar.gz is unpacked > and there are no "data.gz" files. > My bias would ordinarily be to piggy back on the R build system as > much as possible. In principle, this could get me extra features > (binary builds, MS Windows builds) and it would track the things R > build does beyond tarring files. But in this case using the R build > system seems quite ugly. I could in principle use .Rbuildignore, > probably generated dynamically, to exclude files. That doesn't solve > the 2nd problem (data.gz becomes data). > So does the alternative of doing the tar'ing myself make sense? > Is there another option that could hook into the R CMD build process > more deeply than the use of .Rbuildignore? > I suppose another option would be to do a clean checkout of the sources > for my package, run a special makefile target that would create the > necessary files and delete all unwanted files, and then do a regular R > CMD build. This might still have trouble with "data.gz". > -- I would typically advocate against bypassing the standard tool-chain. R CMD build will continue being enhanced, e.g. by adding more metadata which certify the authenticity of the toolchain and/or the builder. Of course, all this is open source, and one can piggyback on the sources, but one of the great successes of R and related projects is the fact that there is a highly standardized way of managing extensions to the base system. Re hooks, in addition to .Rbuildignore there is a "cleanup" (before packaging) mechanism, see sub cleanup_pkg in the build sources. This is what runs make clean in the src subdir, and under Unix also a cleanup shell script in the top level package source directory (and we could in principle add a cleanup.win mechanism). I am not sure about the data.gz issue: perhaps you can send me a sample package to that I can investigate. -k __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Infinite recursion in S3 methods crashes R on windows (related to PR#8203?)
Rich FitzJohn <[EMAIL PROTECTED]> writes:
> Hi,
>
> Infinite recursion in S3 methods seem to crash R on Windows 2000 (R
> terminating with the ("Rgui.exe has generated errors...") message,
> rather than throwing an error. This happens with both Rgui and Rterm.
>
> The following toy example triggers this:
> myf <- function(x, ...)
> UseMethod("myf")
>
> myf.default <- function(x, ...)
> myf(x)
>
> myf(1)
> ...R crashes...
>
> Which I would expect to terminate with the usual "evaluation nested
> too deeply: infinite recursion" or protect stack overflow message.
>
> This may be related to the reported bug 8203 - apologies if this has
> been fixed. I couldn't find specific mention of this in the NEWS
> file.
>
> This does not happen on R 2.1.0 on Windows 2000 (same machine), or on
> R 2.2.0 on Linux. R/Machine version below.
This is presumably an issue of C stack size. We increased
options("expressions") in 2.2.0 from 500 to 5000, thinking that
"machines are bigger than that these days", but apparently not.
So for 2.2.0 patched we have
o options("expressions") has been reduced to 1000: the limit
of 5000 introduced in 2.1.0 was liable to give crashes from C
stack overflow.
and in R-devel
o options(expressions) reverts to the default of 5000 now
stack checking is in place.
> Cheers,
> Rich
>
> Version:
> platform = i386-pc-mingw32
> arch = i386
> os = mingw32
> system = i386, mingw32
> status =
> major = 2
> minor = 2.0
> year = 2005
> month = 10
> day = 06
> svn rev = 35749
> language = R
>
> Windows 2000 Professional (build 2195) Service Pack 4.0
>
> Locale:
> LC_COLLATE=English_New Zealand.1252;LC_CTYPE=English_New
> Zealand.1252;LC_MONETARY=English_New
> Zealand.1252;LC_NUMERIC=C;LC_TIME=English_New Zealand.1252
>
> Search Path:
> .GlobalEnv, package:methods, package:stats, package:graphics,
> package:grDevices, package:utils, package:datasets, Autoloads,
> package:base
>
>
> --
> Rich FitzJohn
> rich.fitzjohn gmail.com |http://homepages.paradise.net.nz/richa183
> You are in a maze of twisty little functions, all alike
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] winMenuAdd
On Wed, 23 Nov 2005, Seth Falcon wrote: > On 23 Nov 2005, [EMAIL PROTECTED] wrote: > >> I can see no change in the relevant code since 2.2.0 and the release >> version of 2.2.0 does this for me. >> >> It seems to be a long-standard error in rui.c that only 10 menus are >> allocated but 16 are tested for. > > Would it be possible for the allocation to be dynamic? It actually already is in R-devel, but it was not announced because it needed some manual updating of the translations which I did this morning. (We try to leave the RGui translations alone as much as possible because testing them is so tedious.) [Not copied to the poster as he does not do so.] -- 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Changes to Windows registry in R-2.2.0
R-Devel,
I note from the CHANGES log accompanying the Windows version of R-2.2.0 that
the behaviour with respect to the Windows registry has changed. It says:
"If the user chooses to register R during installation, a registry entry
HKEY_LOCAL_MACHINE\Software\R-core\R\{version}\InstallPath will be added.
Users require administrative privileges to create this key. For others,
the same key will be put under the HKEY_CURRENT_USER root."
The old behaviour was to add or modify the registry entry at
HKEY_LOCAL_MACHINE\Software\R-core\R\InstallPath
(ie the same entry, but without the extra {version} key). Having installed
R-2.2.0, I notice that the entry at this location, which used to say
C:\Program Files\R\R-2.1.1
now says
C:\Program Files\R\R-2.2.0
I also tried deleting the \R-core\R key, and re-installing R, and it added
both the
HKEY_LOCAL_MACHINE\Software\R-core\R\R-2.2.0\InstallPath
and
HKEY_LOCAL_MACHINE\Software\R-core\R\InstallPath
entries
In other words, the new behaviour seems to be to *both* modify/add an entry
under
HKEY_LOCAL_MACHINE\Software\R-core\R\InstallPath
*and*
HKEY_LOCAL_MACHINE\Software\R-core\R\{version}\InstallPath
I note also that it adds another entry
HKEY_LOCAL_MACHINE\Software\R-core\R\Current Version
My questions are:
(1) Am I correct that this is the new behaviour?
(2) Can the appropriate developer confirm that this behaviour will be
continued in future versions (at least for a while)? I ask, because I
distribute software that uses R, and it uses the
HKEY_LOCAL_MACHINE\Software\R-core\R\InstallPath
to find R. (It will also now look under HKEY_CURRENT_USER, as documented in
CHANGES.) If future versions will not update this entry, then I'll switch
the behaviour of my software.
(3) Might it be worth documenting this behaviour somewhere? I've searched
all the files in the R-2.2.0 distribution and didn't find it, as well as
looking in the recent r-devel and r-help archives.
There is one out-of-date entry: in R-2.2.0\doc\manual\R-exts.html it says:
[...]
Find and set the R home directory and the user's home directory. The
former may be available from the Windows Registry: it will normally be
in HKEY_LOCAL_MACHINE\Software\R-core\R\InstallPath and can be
set there by running the program R_HOME\bin\RSetReg.exe
Perhaps I missed it elsewhere?
Thanks for any help,
- Len Thomas
--
Len Thomas [EMAIL PROTECTED]http://www.creem.st-and.ac.uk/len/
Centre for Research into Ecological and Environmental Modelling
The Observatory, University of St Andrews, Scotland KY16 9LZ
Tel. (0)1334-461801 Fax. (0)1334-461800 Secretary (0)1334-461842
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Changes to Windows registry in R-2.2.0
On 11/24/2005 5:37 AM, Len Thomas wrote:
> R-Devel,
>
> I note from the CHANGES log accompanying the Windows version of R-2.2.0 that
> the behaviour with respect to the Windows registry has changed. It says:
>
> "If the user chooses to register R during installation, a registry entry
> HKEY_LOCAL_MACHINE\Software\R-core\R\{version}\InstallPath will be added.
> Users require administrative privileges to create this key. For others,
> the same key will be put under the HKEY_CURRENT_USER root."
>
> The old behaviour was to add or modify the registry entry at
> HKEY_LOCAL_MACHINE\Software\R-core\R\InstallPath
> (ie the same entry, but without the extra {version} key). Having installed
> R-2.2.0, I notice that the entry at this location, which used to say
> C:\Program Files\R\R-2.1.1
> now says
> C:\Program Files\R\R-2.2.0
> I also tried deleting the \R-core\R key, and re-installing R, and it added
> both the
> HKEY_LOCAL_MACHINE\Software\R-core\R\R-2.2.0\InstallPath
> and
> HKEY_LOCAL_MACHINE\Software\R-core\R\InstallPath
> entries
>
> In other words, the new behaviour seems to be to *both* modify/add an entry
> under
> HKEY_LOCAL_MACHINE\Software\R-core\R\InstallPath
> *and*
> HKEY_LOCAL_MACHINE\Software\R-core\R\{version}\InstallPath
>
> I note also that it adds another entry
> HKEY_LOCAL_MACHINE\Software\R-core\R\Current Version
>
> My questions are:
>
> (1) Am I correct that this is the new behaviour?
Yes. The value in Current Version can be used to select the subkey from
\R to find the InstallPath.
>
> (2) Can the appropriate developer confirm that this behaviour will be
> continued in future versions (at least for a while)? I ask, because I
> distribute software that uses R, and it uses the
> HKEY_LOCAL_MACHINE\Software\R-core\R\InstallPath
> to find R. (It will also now look under HKEY_CURRENT_USER, as documented in
> CHANGES.) If future versions will not update this entry, then I'll switch
> the behaviour of my software.
The undocumented behaviour (putting InstallPath directly below \R) will
eventually go away. It's there for now for backwards compatibility.
The problem as you've seen is that it gets overwritten every time you
install a new version. Some people will have multiple versions
installed, and there was a request for a mechanism to allow tools to
find them.
You can probably find that if you look back through the archives in this
list (check the revision log on developer.r-project.org for the dates of
the changes if you are having trouble). The code to do this is in
src/gnuwin32/installer/JRins.pl, a Perl script that writes out an Inno
Setup installer script.
> (3) Might it be worth documenting this behaviour somewhere? I've searched
> all the files in the R-2.2.0 distribution and didn't find it, as well as
> looking in the recent r-devel and r-help archives.
The folks who need this are pretty rare, but if you want to work out an
appropriate place for the documentation (I'd guess the R-Admin or
R-Extensions manual) and write it up I'll consider it for addition
there. The source for those manuals is in Texinfo format (.texi); don't
edit the HTML versions.
> There is one out-of-date entry: in R-2.2.0\doc\manual\R-exts.html it says:
> [...]
> Find and set the R home directory and the user's home directory. The
> former may be available from the Windows Registry: it will normally be
> in HKEY_LOCAL_MACHINE\Software\R-core\R\InstallPath and can be
> set there by running the program R_HOME\bin\RSetReg.exe
>
Thanks, I'll fix that.
Duncan Murdoch
>
> Perhaps I missed it elsewhere?
>
> Thanks for any help,
>
> - Len Thomas
>
>
> --
> Len Thomas [EMAIL PROTECTED]http://www.creem.st-and.ac.uk/len/
> Centre for Research into Ecological and Environmental Modelling
> The Observatory, University of St Andrews, Scotland KY16 9LZ
> Tel. (0)1334-461801 Fax. (0)1334-461800 Secretary (0)1334-461842
>
> __
> 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] write.csv
hallo, i have a problem by writing a csv file the first colum is filled with index numbers from 1 to n. i have to unique two csv files once a week while one file is always the same. can anybody tell me, how to write the dataset into a csv file without the first row of the indexnumbers. x[,-1] does not wok as it eliminates the first "interesting" colum. col.names is not accepted by r (do i habe to start a package first? which one?) thx sven [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] write.csv
On Thu, 2005-11-24 at 17:00 +0100, Sven Schaltenbrand wrote: > hallo, > > i have a problem by writing a csv file > the first colum is filled with index numbers from 1 to n. > i have to unique two csv files once a week while one file is always the > same. > can anybody tell me, how to write the dataset into a csv file without the > first row of the indexnumbers. > x[,-1] does not wok as it eliminates the first "interesting" colum. > col.names is not accepted by r (do i habe to start a package first? which > one?) > > thx > > sven > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel This isn't a R-Devel related question, it would have been better sent to R-Help: https://stat.ethz.ch/mailman/listinfo/r-help Also, you are asked to read the docs for the functions you are having problems with. The answer is in ?write.csv and the argument row.names. Setting this to FALSE gives you your desired behaviour, e.g.: > ?write.csv > data(iris) #example data > write.csv(iris, row.names = FALSE) > write.csv(iris, row.names = TRUE) As I didn't specify a filename as the file argument, the results are displayed at the console. HTH G -- %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% Gavin Simpson [T] +44 (0)20 7679 5522 ENSIS Research Fellow [F] +44 (0)20 7679 7565 ENSIS Ltd. & ECRC [E] gavin.simpsonATNOSPAMucl.ac.uk UCL Department of Geography [W] http://www.ucl.ac.uk/~ucfagls/cv/ 26 Bedford Way[W] http://www.ucl.ac.uk/~ucfagls/ London. WC1H 0AP. %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] write.csv
If you don't want the row names, as 'write.csv()' writes out by default, try write.table(, file = "myfile.csv", sep = ",", row.names = FALSE) -roger Sven Schaltenbrand wrote: > hallo, > > i have a problem by writing a csv file > the first colum is filled with index numbers from 1 to n. > i have to unique two csv files once a week while one file is always the > same. > can anybody tell me, how to write the dataset into a csv file without the > first row of the indexnumbers. > x[,-1] does not wok as it eliminates the first "interesting" colum. > col.names is not accepted by r (do i habe to start a package first? which > one?) > > thx > > sven > > [[alternative HTML version deleted]] > > __ > 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] write.csv
I don't understand very well if your problem is rownames or column names, but what you want must be : row.names=FALSE and/or col.names=FALSE, which are arguments of the function 'write.table()' don't think you need to load any particular package for that. see also : 'write.csv' and 'write.csv2' provide convenience wrappers for writing CSV files. They set 'sep', 'dec' and 'qmethod', and 'col.names' to 'NA' if 'row.names = TRUE' and 'TRUE' otherwise. from ?write.table hope this helps. Florence. On 11/24/05, Sven Schaltenbrand <[EMAIL PROTECTED]> wrote: > > hallo, > > i have a problem by writing a csv file > the first colum is filled with index numbers from 1 to n. > i have to unique two csv files once a week while one file is always the > same. > can anybody tell me, how to write the dataset into a csv file without the > first row of the indexnumbers. > x[,-1] does not wok as it eliminates the first "interesting" colum. > col.names is not accepted by r (do i habe to start a package first? which > one?) > > thx > > sven > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] write.csv
On Thu, 24 Nov 2005, Roger Peng wrote: > If you don't want the row names, as 'write.csv()' writes out by default, > try > > write.table(, file = "myfile.csv", sep = ",", row.names = FALSE) Or, better (since it sets other args to the appropriate values), write.csv(, file = "myfile.csv", row.names = FALSE) That write.csv supports row.names = FALSE is explicitly mentioned on the help page. > > -roger > > Sven Schaltenbrand wrote: >> hallo, >> >> i have a problem by writing a csv file >> the first colum is filled with index numbers from 1 to n. >> i have to unique two csv files once a week while one file is always the >> same. >> can anybody tell me, how to write the dataset into a csv file without the >> first row of the indexnumbers. >> x[,-1] does not wok as it eliminates the first "interesting" colum. >> col.names is not accepted by r (do i habe to start a package first? which >> one?) >> >> thx >> >> sven >> >> [[alternative HTML version deleted]] >> >> __ >> 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 > > -- 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] write.csv ignores 'row.names'
Upon replying to this email, I took a look at 'write.csv()' and noticed something interesting. I remember there being a discussion sometime in the past about letting 'write.csv()' accept the 'row.names' argument. However, I get the following error: > write.csv(airquality, file = "myfile.csv", row.names = F) Error in write.table(airquality, file = "myfile.csv", row.names = F, col.names = NA, : col.names = NA makes no sense when row.names = FALSE > In 'write.csv()' there is rn <- Call$row.names Call$col.names <- if (is.logical(rn) && !rn) TRUE but is.logical(rn) is always FALSE because even if 'row.names' is specified (non-NULL), it is of class "name". Perhaps something like rn <- eval(Call$row.names) would suffice? I can't tell if that would break anything. -roger Sven Schaltenbrand wrote: > hallo, > > i have a problem by writing a csv file > the first colum is filled with index numbers from 1 to n. > i have to unique two csv files once a week while one file is always the > same. > can anybody tell me, how to write the dataset into a csv file without the > first row of the indexnumbers. > x[,-1] does not wok as it eliminates the first "interesting" colum. > col.names is not accepted by r (do i habe to start a package first? which > one?) > > thx > > sven > > [[alternative HTML version deleted]] > > __ > 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] write.csv ignores 'row.names'
Okay, upon further examination, it appears that it works fine if you set 'row.names = FALSE' as opposed to 'row.names = F'. -roger Roger Peng wrote: > Upon replying to this email, I took a look at 'write.csv()' and noticed > something interesting. I remember there being a discussion sometime in > the past about letting 'write.csv()' accept the 'row.names' argument. > However, I get the following error: > > > write.csv(airquality, file = "myfile.csv", row.names = F) > Error in write.table(airquality, file = "myfile.csv", row.names = F, > col.names = NA, : > col.names = NA makes no sense when row.names = FALSE > > > > In 'write.csv()' there is > > rn <- Call$row.names > Call$col.names <- if (is.logical(rn) && !rn) > TRUE > > but is.logical(rn) is always FALSE because even if 'row.names' is > specified (non-NULL), it is of class "name". Perhaps something like > > rn <- eval(Call$row.names) > > would suffice? I can't tell if that would break anything. > > -roger > > Sven Schaltenbrand wrote: > >> hallo, >> >> i have a problem by writing a csv file >> the first colum is filled with index numbers from 1 to n. >> i have to unique two csv files once a week while one file is always the >> same. >> can anybody tell me, how to write the dataset into a csv file without the >> first row of the indexnumbers. >> x[,-1] does not wok as it eliminates the first "interesting" colum. >> col.names is not accepted by r (do i habe to start a package first? which >> one?) >> >> thx >> >> sven >> >> [[alternative HTML version deleted]] >> >> __ >> 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] write.csv ignores 'row.names'
Roger Peng <[EMAIL PROTECTED]> writes: > Okay, upon further examination, it appears that it works fine if you set > 'row.names = FALSE' as opposed to 'row.names = F'. Nope. It's still a bug and you're quite right that eval() is needed. We can't have that an argument only works when supplied as an explicit constant. > -roger > > Roger Peng wrote: > > Upon replying to this email, I took a look at 'write.csv()' and noticed > > something interesting. I remember there being a discussion sometime in > > the past about letting 'write.csv()' accept the 'row.names' argument. > > However, I get the following error: > > > > > write.csv(airquality, file = "myfile.csv", row.names = F) > > Error in write.table(airquality, file = "myfile.csv", row.names = F, > > col.names = NA, : > > col.names = NA makes no sense when row.names = FALSE > > > > > > > In 'write.csv()' there is > > > > rn <- Call$row.names > > Call$col.names <- if (is.logical(rn) && !rn) > > TRUE > > > > but is.logical(rn) is always FALSE because even if 'row.names' is > > specified (non-NULL), it is of class "name". Perhaps something like > > > > rn <- eval(Call$row.names) > > > > would suffice? I can't tell if that would break anything. > > > > -roger > > > > Sven Schaltenbrand wrote: > > > >> hallo, > >> > >> i have a problem by writing a csv file > >> the first colum is filled with index numbers from 1 to n. > >> i have to unique two csv files once a week while one file is always the > >> same. > >> can anybody tell me, how to write the dataset into a csv file without the > >> first row of the indexnumbers. > >> x[,-1] does not wok as it eliminates the first "interesting" colum. > >> col.names is not accepted by r (do i habe to start a package first? which > >> one?) > >> > >> thx > >> > >> sven > >> > >> [[alternative HTML version deleted]] > >> > >> __ > >> 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 > -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] write.csv ignores 'row.names'
On Thu, 24 Nov 2005, Roger Peng wrote: > Okay, upon further examination, it appears that it works fine if you set > 'row.names = FALSE' as opposed to 'row.names = F'. Yes. Adding eval.parent() (not eval()) would be better, though, as it would allow a variable (like F) to be used. I rather like the poetic justice of 'F' not working since no developer would have tested that, though. > > -roger > > Roger Peng wrote: >> Upon replying to this email, I took a look at 'write.csv()' and noticed >> something interesting. I remember there being a discussion sometime in >> the past about letting 'write.csv()' accept the 'row.names' argument. >> However, I get the following error: >> >> > write.csv(airquality, file = "myfile.csv", row.names = F) >> Error in write.table(airquality, file = "myfile.csv", row.names = F, >> col.names = NA, : >> col.names = NA makes no sense when row.names = FALSE >> > >> >> In 'write.csv()' there is >> >> rn <- Call$row.names >> Call$col.names <- if (is.logical(rn) && !rn) >> TRUE >> >> but is.logical(rn) is always FALSE because even if 'row.names' is >> specified (non-NULL), it is of class "name". Perhaps something like >> >> rn <- eval(Call$row.names) >> >> would suffice? I can't tell if that would break anything. >> >> -roger >> >> Sven Schaltenbrand wrote: >> >>> hallo, >>> >>> i have a problem by writing a csv file >>> the first colum is filled with index numbers from 1 to n. >>> i have to unique two csv files once a week while one file is always the >>> same. >>> can anybody tell me, how to write the dataset into a csv file without the >>> first row of the indexnumbers. >>> x[,-1] does not wok as it eliminates the first "interesting" colum. >>> col.names is not accepted by r (do i habe to start a package first? which >>> one?) >>> >>> thx >>> >>> sven >>> >>> [[alternative HTML version deleted]] >>> >>> __ >>> 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 > > -- 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Windows R CMD build leftovers
A command
R CMD build
that fails, e.g., because of C code compilation errors, leaves a
directory %TMPDIR%/Rinst.xxx containing the file R.css. Although R
CMD INSTALL --build cleans up after itself, build does not. A fix is
below. Also, build.in references Rcmd.exe, which I thought was no
longer necessary?
Index: build.in
===
--- build.in(revision 36450)
+++ build.in(working copy)
@@ -434,6 +434,8 @@
if($doit && R_system($cmd)) {
$log->error();
$log->print("Installation failed.\n");
+ $log->print("Removing '$libdir'\n");
+ rmtree($libdir);
exit(1);
}
my $R_LIBS = $ENV{'R_LIBS'};
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
