Re: [Rd] X11 window title setting in X11() Device (PR#11325)
Can you please give precise reproduction instructions -- you don't even
tell us what the window manager is.
I'd be willing to consider a workaround, but only if I can reproduce the
problem (which appears to be a false assumption elsewhere in your setup).
On Mon, 28 Apr 2008, [EMAIL PROTECTED] wrote:
> --=-=-=
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: quoted-printable
>
> Hi,
>
> I think I have found a very little bug in the new version of the X11()
> device in R 2.7.0, more precisely in the devX11.c file.
>
> The problem is that when you open a new window with X11(), the title
> of the window (the WM_NAME property) is not immediately set. It seems
> that the window is created, then it is displayed (mapped) with no
> title, and then the title is set.
Which is perfectly valid in X11, so I don't see where the 'bug' is.
R changes the title to reflect the window state, do the supplied 'title'
is never actually used without decoration. R 2.6.x put up one title and
then immediately changed it, but that was undocumented and not safe to
rely on (as you found).
> It is something absolutely invisible for the user, but it leads to
> problem for me because I use a window manager that relies on window
> titles to give them different attributes (I use it to make all my R
> Graphics windows floating). And due to the fact that the title is set
> after opening, my window manager rules don't apply anymore.
>
> I found a quick and dirty workaround which set the title immediately
> after the window opening if the =C2=ABtitle=C2=BB option in X11.options() is
> set. You will find the patch for devX11.c attached to this mail, it is
> just two lines moved before the call to X11_Open.
>
> Surely there could be something much better, but I am quite new to C
> and X11 programming...
>
> Here is my sessionInfo() :
>
> ,
> | R version 2.7.0 (2008-04-22)=20
> | i486-pc-linux-gnu=20
> |=20
> | locale:
> | LC_CTYPE=3Dfr_FR.UTF-8;LC_NUMERIC=3DC;LC_TIME=3Dfr_FR.UTF-8;LC_COLLATE=3D=
> fr_FR.UTF-8;LC_MONETARY=3DC;LC_MESSAGES=3Dfr_FR.UTF-8;LC_PAPER=3Dfr_FR.UTF-=
> 8;LC_NAME=3DC;LC_ADDRESS=3DC;LC_TELEPHONE=3DC;LC_MEASUREMENT=3Dfr_FR.UTF-8;=
> LC_IDENTIFICATION=3DC
> |=20
> | attached base packages:
> | [1] grDevices utils datasets graphics stats methods base=20=
> =20=20=20=20
> |=20
> | other attached packages:
> | [1] car_1.2-7
> `
>
> Thanks for all your work !
>
> Regards,
>
> Julien=20
>
>
> --=-=-=
> Content-Type: text/x-diff
> Content-Disposition: attachment; filename=devX11_patch.diff
>
> --- devX11.c.orig 2008-04-28 16:22:46.0 +0200
> +++ devX11.c 2008-04-28 16:22:57.0 +0200
> @@ -2225,6 +2225,9 @@
> else strcpy(xd->symbolfamily,fn);
> }
>
> +strncpy(xd->title, title, 100);
> +xd->title[100] = '\0';
> +
> /*Start the Device Driver and Hardcopy. */
>
> if (!X11_Open(dd, xd, disp_name, width, height,
> @@ -2238,8 +2241,6 @@
> xd->fill = 0x; /* this is needed to ensure that the
> first newpage does set whitecolor
> if par("bg") is not transparent */
> -strncpy(xd->title, title, 100);
> -xd->title[100] = '\0';
>
> #if BUG
> R_ProcessX11Events((void*) NULL);
>
> --=-=-=--
>
> __
> 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
Re: [Rd] R-Forge SVN repositories: R CMD build/check error on Windows machines
Duncan Murdoch wrote: On 28/04/2008 12:22 PM, Stefan Theussl wrote: Dear R-devel, One of our R-Forge developers pointed out that it is not possible to build packages under Windows using the R-Forge repository structure: a package resides in ./pkg - not in a directory with the same name as the package name. Under Linux 'R CMD build pkg' or 'R CMD check pkg' work pretty well (I think Kurt Hornik fixed that in R 2.5.1 or so) whereas under Windows one gets the following error (this is the example sent by the user): c:\work\packages\spdep>R CMD check pkg * checking for working pdflatex ... OK * using log directory 'C:/work/packages/spdep/pkg.Rcheck' * using R version 2.7.0 (2008-04-22) * using session charset: ISO8859-1 * checking for file 'pkg/DESCRIPTION' ... OK * this is package 'spdep' version '0.4-21' * package encoding: latin1 * checking package name space information ... OK * checking package dependencies ... OK * checking if this is a source package ... WARNING Subdirectory 'pkg/src' contains object files. * checking whether package 'spdep' can be installed ... ERROR Installation failed. See 'C:/work/packages/spdep/pkg.Rcheck/00install.out' for details. which is: installing R.css in C:/work/packages/spdep/pkg.Rcheck -- Making package pkg adding build stamp to DESCRIPTION installing NAMESPACE file and metadata making DLL ... ... DLL made installing DLL installing R files installing inst files installing data files preparing package pkg for lazy loading Loading required package: tripack Loading required package: sp ... Error in findpack(package, lib.loc) : *there is no package called 'pkg'* Calls: -> findpack Execution halted make[2]: *** [lazyload] Error 1 make[1]: *** [all] Error 2 make: *** [pkg-pkg] Error 2 *** Installation of pkg failed *** I could verify this on our 'Windows package building machine' not only for this package but also for others. Therefore, it seems to me that the (Windows) R CMD build/check scripts are not considering the package name in the DESCRIPTION file but rather take the directory name as package name. Or are we just doing something completely wrong? You're right, on Windows there's an assumption that package foo is in directory foo. But I don't see why this is a big problem. Can't you just check out pkg into foo, e.g. svn co svn://svn.r-forge.r-project.org/svnroot/foo/pkg foo (Not that I'd be against accepting a patch to remove this restriction; occasionally it might be nice to have two versions of the same package side-by-side.) Yes, you're right. Actually we do it this way when exporting the R-Forge packages. We just look for the package name in the DESCRIPTION file and do an 'svn export' using this information. The other possibility on R-Forge would be to have the package in a directory ./pkg/foo in the repository. This is supported by our build process. Therefore this is no problem at all for us. Nevertheless, I think that this is a useful convenience feature (indeed I use that very often under Linux). E.g., one wants to have his or her packages in different directories like foo-devel, foo-release and just say R CMD build/check on them. Best, Stefan Duncan Murdoch I used R-patched 2.7.0 on R-Forge to reproduce this error. Best regards, Stefan __ 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] R-Forge SVN repositories: R CMD build/check error on Windows machines
Deepayan Sarkar wrote: On 4/28/08, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: The difference is in INSTALL, not build/check. You are right that the Unix INSTALL was changed in r25808 (Aug 2003), but AFAICS this was not documented at the time in [O]NEWS, nor anywhere else. Can you point me to the documentation you used to implement this? FWIW, the NEWS for 2.5.0 [1] has o R CMD build now takes the package name from the DESCRIPTION file and not from the directory. (PR#9266) and that does seem to work on Windows. Indeed, this works but with the side effect of getting the error message Error in findpack(package, lib.loc) : there is no package called 'pkg' Calls: -> findpack Execution halted make[2]: *** [lazyload] Error 1 make[1]: *** [all] Error 2 make: *** [pkg-pkg] Error 2 *** Installation of pkg failed *** which comes from R CMD INSTALL as Brian Ripley pointed out already. Nevertheless, the package gets built and you can handle the tarball with no further problems as always. Stefan [1] https://stat.ethz.ch/pipermail/r-announce/2007/000828.html -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-Forge SVN repositories: R CMD build/check error on Windows machines
On Tue, 29 Apr 2008, Stefan Theussl wrote: Duncan Murdoch wrote: On 28/04/2008 12:22 PM, Stefan Theussl wrote: Dear R-devel, One of our R-Forge developers pointed out that it is not possible to build packages under Windows using the R-Forge repository structure: a package resides in ./pkg - not in a directory with the same name as the package name. Under Linux 'R CMD build pkg' or 'R CMD check pkg' work pretty well (I think Kurt Hornik fixed that in R 2.5.1 or so) whereas under Windows one gets the following error (this is the example sent by the user): [...] Nevertheless, I think that this is a useful convenience feature (indeed I use that very often under Linux). E.g., one wants to have his or her packages in different directories like foo-devel, foo-release and just say R CMD build/check on them. (I think the problem with 'build' on Windows comes from packages with vignettes.) Features such as this have a little cost (not least in maintenance when developers don't know about them). However, the plan is to move INSTALL to an R script used by both Unix and Windows for 2.8.0 which would allow more flexibility and keep the platforms in line. Knowing this is required at the design stage is much easier than bolting it on afterwards. (One consequence is that I am not at all keen to change the Windows INSTALL for 2.7.x.) -- 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] Some compiling problems
Dear R experts, I had some difficulties to build R on Linux (cross-build) and Windows (via Rtools) and hope it is appropriate to post for help, Our system has gcc 3.4.6 on RedHat Linux x86_64. With the help of Makefile-rcb by Yan and Rossini (setting BUILD=CROSS, R_EXE, F77 and FLIBS to g77 and g2c) I was able to build R 2.7.0 but most of the executables failed to initialise under Windows XP or Vista. After manually zip on Linux and unzip under Windows, all executables work. There appears to be problems with the compression? Earlier I kept Excel files in inst/doc but would corrupt in Windows packages from cross-build. Maybe it is a bad practice to have those anyway? I was able to build R 2.5.1 myself under Windows and with R 2.7.0 this is much simpler and led to the point of success but is still stuck with 'make distribution' since bitmap directory does not have a proper Makefile as before. I do notice they are available from Cross-build or it is possible to build outside R framework via Cygwin. Many thanks for your help, Jing Hua _ Bag extra points with the Walkers Brit Trip Game [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] X11 window title setting in X11() Device (PR#11325)
Hi,
> Can you please give precise reproduction instructions -- you don't
> even tell us what the window manager is.
> I'd be willing to consider a workaround, but only if I can reproduce
> the problem (which appears to be a false assumption elsewhere in your
> setup).
Yes, sorry, it is one of my first bug report so please forgive me for
being incomplete.
The window manager I use is dwm, which can be found at :
http://www.suckless.org/wiki/dwm
It is a lightweight tiled window manager with configuration by
compilation. You can change settings by modifying the config.h file
and recompiling dwm.c. The setting which cause problem in my config.h
is the following :
Rule rules[] =3D {
/* classinstancetitle tags refisf=
loating */
{ NULL, NULL, "R Graphics", NULL,True},
which makes every window whose title match the =C2=ABR Graphics=C2=BB subst=
ring
to be considered as a floating window.
If you use dwm with this configuration rule, launch R and open a
graphics window, it will not be set as floating but will remain tiled
(which is the default).
The problem is that dwm applies the rule given above as soon as the
window is mapped. But in R 2.7.0, when the window is mapped she
doesn't have any title (it is assigned later), so the rule doesn't
apply because the window is considered having no instance name, no
class name (the WM_CLASS attribute) and no title.
> Which is perfectly valid in X11, so I don't see where the 'bug' is.
>
> R changes the title to reflect the window state, do the supplied
> title' is never actually used without decoration. R 2.6.x put up one
> title and then immediately changed it, but that was undocumented and
> not safe to rely on (as you found).
You're perfectly right by saying that it is not a bug per se, it is
just a small change which shouldn't affect the vast majority of users
but those who rely on windows attributes to manage them. But maybe I
am the only one in that case...
Another workaround could be to give a class or instance name specific
to the graphics windows.
Thanks for your answer and sorry for the incomplete bug report.
Regards,
--=20
Julien Barnier
Groupe de Recherche sur la Socialisation
ENS Lettres et Sciences humaines, Lyon
T=C3=A9l : 04 37 37 62 92
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Some compiling problems
jing hua zhao wrote: Dear R experts, I had some difficulties to build R on Linux (cross-build) and Windows (via Rtools) and hope it is appropriate to post for help, Our system has gcc 3.4.6 on RedHat Linux x86_64. With the help of Makefile-rcb by Yan and Rossini (setting BUILD=CROSS, R_EXE, F77 and FLIBS to g77 and g2c) I was able to build R 2.7.0 but most of the executables failed to initialise under Windows XP or Vista. After manually zip on Linux and unzip under Windows, all executables work. There appears to be problems with the compression? Earlier I kept Excel files in inst/doc but would corrupt in Windows packages from cross-build. Maybe it is a bad practice to have those anyway? I was able to build R 2.5.1 myself under Windows and with R 2.7.0 this is much simpler and led to the point of success but is still stuck with 'make distribution' since bitmap directory does not have a proper Makefile as before. I do notice they are available from Cross-build or it is possible to build outside R framework via Cygwin. R-2.5.1 is not R-2.7.0, hence re-read the manuals and update your compilers, bitmap requirements etc. Uwe Ligges Many thanks for your help, Jing Hua _ Bag extra points with the Walkers Brit Trip Game [[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
[Rd] reproducible segmentation fault caused by textConnection()
Dear all,
It seems that textConnection() can trigger a segmentation fault. The
following script (using two large loops) makes this bug reproducible:
for (i in 1:1) {
z=textConnection(NULL,open='w')
for (j in 1:100) {
write(runif(1)*1e6,file=z)
write('\n',file=z)
}
close(z)
}
The bug could be reproduced on R-2.6.1, R-2.7.0 and on the latest
R-devel 2008-04-29 r45543.
Here are some sessionInfo() details:
**
R version 2.6.1 (2007-11-26)
x86_64-unknown-linux-gnu
locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
**
R version 2.7.0 (2008-04-22)
x86_64-unknown-linux-gnu
locale:
LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices datasets utils methods base
**
R version 2.8.0 Under development (unstable) (2008-04-29 r45543)
x86_64-unknown-linux-gnu
locale:
LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices datasets utils methods base
Greg
---
Gregoire Pau
EMBL/EBI Cambridge, UK
http://www.ebi.ac.uk/~gpau
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] reproducible segmentation fault caused by textConnection()
Hi Greg,
I get a different error on my mac:
> for (i in 1:1) {
+ try({z=textConnection(NULL,open='w')
+ for (j in 1:100) {
+write(runif(1)*1e6,file=z)
+write('\n',file=z)
+ }
+ close(z)})
+ }
Error : cannot set length of non-vector
In addition: Warning message:
closing unused connection 3 (NULL)
Error: no function to return from, jumping to top level
In addition: Warning message:
closing unused connection 3 (NULL)
Error : Value of SET_STRING_ELT() must be a 'CHARSXP' not a 'character'
Error : cannot set length of non-vector
Error : cannot set length of non-vector
Error : cannot set length of non-vector
Error: no function to return from, jumping to top level
In addition: Warning messages:
1: closing unused connection 7 (NULL)
2: closing unused connection 6 (NULL)
3: closing unused connection 5 (NULL)
4: closing unused connection 4 (NULL)
Error : cannot set length of non-vector
Error : cannot set length of non-vector
In addition: Warning message:
closing unused connection 5 (NULL)
Error: no function to return from, jumping to top level
In addition: Warning message:
closing unused connection 5 (NULL)
Error : SET_STRING_ELT() can only be applied to a 'character vector', not a
'integer'
Error: no function to return from, jumping to top level
In addition: Warning message:
closing unused connection 6 (NULL)
Error : cannot set length of non-vector
Error : Value of SET_STRING_ELT() must be a 'CHARSXP' not a 'character'
In addition: Warning message:
closing unused connection 7 (NULL)
Error : cannot set length of non-vector
whence I ^C out of the loop.
> sessionInfo()
R version 2.7.0 Patched (2008-04-28 r45540)
i386-apple-darwin8.10.1
locale:
C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
On Tue, Apr 29, 2008 at 2:52 PM, Gregoire Pau <[EMAIL PROTECTED]> wrote:
> Dear all,
>
> It seems that textConnection() can trigger a segmentation fault. The
> following script (using two large loops) makes this bug reproducible:
>
> for (i in 1:1) {
> z=textConnection(NULL,open='w')
> for (j in 1:100) {
>write(runif(1)*1e6,file=z)
>write('\n',file=z)
> }
> close(z)
> }
>
> The bug could be reproduced on R-2.6.1, R-2.7.0 and on the latest R-devel
> 2008-04-29 r45543.
> Here are some sessionInfo() details:
> **
> R version 2.6.1 (2007-11-26)
> x86_64-unknown-linux-gnu
>
> locale:
>
> LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
> **
> R version 2.7.0 (2008-04-22)
> x86_64-unknown-linux-gnu
>
> locale:
>
> LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics grDevices datasets utils methods base
> **
> R version 2.8.0 Under development (unstable) (2008-04-29 r45543)
> x86_64-unknown-linux-gnu
>
> locale:
>
> LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics grDevices datasets utils methods base
>
> Greg
> ---
> Gregoire Pau
> EMBL/EBI Cambridge, UK
> http://www.ebi.ac.uk/~gpau
>
> __
> 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] reproducible segmentation fault caused by textConnection()
Hi Tony, Greg.
I get the same as Greg's: segfault
*** R version 2.7.0 (2008-04-22) [/research/osklyar/R-2.7.0] ***
> sessionInfo()
R version 2.7.0 (2008-04-22)
x86_64-unknown-linux-gnu
locale:
LC_CTYPE=en_GB;LC_NUMERIC=C;LC_TIME=en_GB;LC_COLLATE=C;LC_MONETARY=C;LC_
MESSAGES=en_GB;LC_PAPER=en_GB;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_M
EASUREMENT=en_GB;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
> for (i in 1:1) {
+
+z=textConnection(NULL,open='w')
+
+for (j in 1:100) {
+
+ write(runif(1)*1e6,file=z)
+
+ write('\n',file=z)
+
+}
+
+close(z)
+
+ }
*** caught segfault ***
address 0xa0b0, cause 'memory not mapped'
Traceback:
1: cat(x, file = file, sep = c(rep.int(sep, ncolumns - 1), "\n"),
append = append)
2: write(runif(1) * 1e+06, file = z)
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection:
Dr Oleg Sklyar
Technology Group
Man Investments Ltd
+44 (0)20 7144 3803
[EMAIL PROTECTED]
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tony Chiang
> Sent: 29 April 2008 15:02
> To: Gregoire Pau
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] reproducible segmentation fault caused by
> textConnection()
>
> Hi Greg,
>
> I get a different error on my mac:
>
> > for (i in 1:1) {
> + try({z=textConnection(NULL,open='w')
> + for (j in 1:100) {
> +write(runif(1)*1e6,file=z)
> +write('\n',file=z)
> + }
> + close(z)})
> + }
> Error : cannot set length of non-vector
> In addition: Warning message:
> closing unused connection 3 (NULL)
> Error: no function to return from, jumping to top level In
> addition: Warning message:
> closing unused connection 3 (NULL)
> Error : Value of SET_STRING_ELT() must be a 'CHARSXP' not a
> 'character'
> Error : cannot set length of non-vector
> Error : cannot set length of non-vector
> Error : cannot set length of non-vector
> Error: no function to return from, jumping to top level In
> addition: Warning messages:
> 1: closing unused connection 7 (NULL)
> 2: closing unused connection 6 (NULL)
> 3: closing unused connection 5 (NULL)
> 4: closing unused connection 4 (NULL)
> Error : cannot set length of non-vector
> Error : cannot set length of non-vector
> In addition: Warning message:
> closing unused connection 5 (NULL)
> Error: no function to return from, jumping to top level In
> addition: Warning message:
> closing unused connection 5 (NULL)
> Error : SET_STRING_ELT() can only be applied to a 'character
> vector', not a 'integer'
> Error: no function to return from, jumping to top level In
> addition: Warning message:
> closing unused connection 6 (NULL)
> Error : cannot set length of non-vector
> Error : Value of SET_STRING_ELT() must be a 'CHARSXP' not a
> 'character'
> In addition: Warning message:
> closing unused connection 7 (NULL)
> Error : cannot set length of non-vector
>
> whence I ^C out of the loop.
>
> > sessionInfo()
> R version 2.7.0 Patched (2008-04-28 r45540)
> i386-apple-darwin8.10.1
>
> locale:
> C
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> On Tue, Apr 29, 2008 at 2:52 PM, Gregoire Pau <[EMAIL PROTECTED]> wrote:
>
> > Dear all,
> >
> > It seems that textConnection() can trigger a segmentation
> fault. The
> > following script (using two large loops) makes this bug
> reproducible:
> >
> > for (i in 1:1) {
> > z=textConnection(NULL,open='w')
> > for (j in 1:100) {
> >write(runif(1)*1e6,file=z)
> >write('\n',file=z)
> > }
> > close(z)
> > }
> >
> > The bug could be reproduced on R-2.6.1, R-2.7.0 and on the latest
> > R-devel
> > 2008-04-29 r45543.
> > Here are some sessionInfo() details:
> > **
> > R version 2.6.1 (2007-11-26)
> > x86_64-unknown-linux-gnu
> >
> > locale:
> >
> >
> LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US
> >
> .UTF-8;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.
> >
> UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8
> > ;LC_IDENTIFICATION=C
> >
> > attached base packages:
> > [1] stats graphics grDevices utils datasets methods base
> > **
> > R version 2.7.0 (2008-04-22)
> > x86_64-unknown-linux-gnu
> >
> > locale:
> >
> >
> LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB
> >
> .UTF-8;LC_MONETARY=C;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_N
> >
> AME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTI
> > FICATION=C
> >
> > attached base packages:
> > [1] stats graphics grDevices datasets utils methods base
> > **
> > R version 2.8.0 Under development (unstable) (2008-04-29 r45543)
> > x86_64-unknown-linux-gnu
> >
> > locale:
> >
> >
> LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB
> >
> .UTF-8;LC_MONETARY=C;LC_MESSAG
[Rd] help text for xlim
Dear R-developers,
A student asked me today of how to specify the limits of the x-axis. I
knew that he should use xlim, but I tried to encourage him to have a try
himself with the various help functions. I do not judge if he used the
correct search strategy or right key words, but anyway here is what he
tried: he looked at ?plot. There xlim is not mentioned. He checked ?par.
There you find xlim mentioned under the xaxs argument, but not how to
specify xlim itself. He also failed with help.search("x-axis limits")
and help.search("x-axis range") and dito apropos(). Neither did
Rsitesearch() for these terms leed him reasonably straight to the xlim.
Finally, he checked under See Also: plot.default, and there xlim is
mentioned as argument, but it does not appear in the examples.
I think it is fair enough that xlim does not appear under ?plot or ?par,
but would it be possible to add an explicit xlim example under
plot.default and perhaps to make xlim more likely to be hit by
'xlim-related' searches?
Best regards,
Henrik
> sessionInfo()
R version 2.7.0 (2008-04-22)
i386-pc-mingw32
locale:
LC_COLLATE=English_United Kingdom.1252;LC_CTYPE=English_United
Kingdom.1252;LC_MONETARY=English_United
Kingdom.1252;LC_NUMERIC=C;LC_TIME=English_United Kingdom.1252
WinXP
--
Henrik Pärn
Centre for Conservation Biology
Department of Biology
Norwegian University of Science and Technology
NO-7491 Trondheim
Norway
Office: +47 73596285
Fax: +47 73596100
Mobile: +47 90989255
E-mail: [EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] help text for xlim
Note that first hit of
RSiteSearch("xlim")
gives an example.
On Tue, Apr 29, 2008 at 10:38 AM, Henrik Parn <[EMAIL PROTECTED]> wrote:
> Dear R-developers,
>
> A student asked me today of how to specify the limits of the x-axis. I knew
> that he should use xlim, but I tried to encourage him to have a try himself
> with the various help functions. I do not judge if he used the correct
> search strategy or right key words, but anyway here is what he tried: he
> looked at ?plot. There xlim is not mentioned. He checked ?par. There you
> find xlim mentioned under the xaxs argument, but not how to specify xlim
> itself. He also failed with help.search("x-axis limits") and
> help.search("x-axis range") and dito apropos(). Neither did Rsitesearch()
> for these terms leed him reasonably straight to the xlim. Finally, he
> checked under See Also: plot.default, and there xlim is mentioned as
> argument, but it does not appear in the examples.
>
> I think it is fair enough that xlim does not appear under ?plot or ?par, but
> would it be possible to add an explicit xlim example under plot.default and
> perhaps to make xlim more likely to be hit by 'xlim-related' searches?
>
>
> Best regards,
>
> Henrik
>
>
> > sessionInfo()
> R version 2.7.0 (2008-04-22)
> i386-pc-mingw32
>
> locale:
> LC_COLLATE=English_United Kingdom.1252;LC_CTYPE=English_United
> Kingdom.1252;LC_MONETARY=English_United
> Kingdom.1252;LC_NUMERIC=C;LC_TIME=English_United Kingdom.1252
>
> WinXP
>
> --
> Henrik Pärn
> Centre for Conservation Biology
> Department of Biology
> Norwegian University of Science and Technology
> NO-7491 Trondheim
> Norway
>
> Office: +47 73596285
> Fax: +47 73596100
> Mobile: +47 90989255
>
> E-mail: [EMAIL PROTECTED]
>
> __
> 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] help text for xlim
I think you're right, xlim is harder to discover than it should be. If
we added the right "concept" marker to the page, then help.search()
would find it. But a lot of things are mentioned on the plot.default
page; how many others there are just as hard as xlim to find? I'd
rather not fix xlim today, and then something else tomorrow, etc: I'd
prefer it if someone looked carefully at what the concepts are on that
page and whether it is the best place to find descriptions of them. Any
volunteers?
Duncan Murdoch
Henrik Parn wrote:
Dear R-developers,
A student asked me today of how to specify the limits of the x-axis. I
knew that he should use xlim, but I tried to encourage him to have a try
himself with the various help functions. I do not judge if he used the
correct search strategy or right key words, but anyway here is what he
tried: he looked at ?plot. There xlim is not mentioned. He checked ?par.
There you find xlim mentioned under the xaxs argument, but not how to
specify xlim itself. He also failed with help.search("x-axis limits")
and help.search("x-axis range") and dito apropos(). Neither did
Rsitesearch() for these terms leed him reasonably straight to the xlim.
Finally, he checked under See Also: plot.default, and there xlim is
mentioned as argument, but it does not appear in the examples.
I think it is fair enough that xlim does not appear under ?plot or ?par,
but would it be possible to add an explicit xlim example under
plot.default and perhaps to make xlim more likely to be hit by
'xlim-related' searches?
Best regards,
Henrik
> sessionInfo()
R version 2.7.0 (2008-04-22)
i386-pc-mingw32
locale:
LC_COLLATE=English_United Kingdom.1252;LC_CTYPE=English_United
Kingdom.1252;LC_MONETARY=English_United
Kingdom.1252;LC_NUMERIC=C;LC_TIME=English_United Kingdom.1252
WinXP
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] crash in Mac.app (PR#11334)
Full_Name: Alex Cozzi Version: 2.7 OS: OS X 10.4 Submission from: (NULL) (209.131.62.113) Observed a crash while pressing ctrl-A and ESC in R.app Date/Time: 2008-04-29 09:18:28.501 -0700 OS Version: 10.4.11 (Build 8S2167) Report Version: 4 Command: R Path:/Applications/R.app/Contents/MacOS/R Parent: WindowServer [2784] Version: R 2.7.0 GUI 1.24 (5102) PID:9213 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0004 Thread 0 Crashed: 0 com.apple.CoreFoundation0x90872f9c __CFStorageFindByte + 23 1 com.apple.CoreFoundation0x90873069 __CFStorageFindByte + 228 2 com.apple.CoreFoundation0x90870d59 CFStorageGetValueAtIndex + 319 3 com.apple.AppKit0x9339c901 -[NSLayoutManager intAttribute:forGlyphAtIndex:] + 182 4 com.apple.AppKit0x937232b7 -[NSTextView(NSKeyBindingCommands) moveRight:] + 1128 5 com.apple.AppKit0x93380e29 -[NSResponder doCommandBySelector:] + 76 6 com.apple.AppKit0x93380cbc -[NSTextView doCommandBySelector:] + 229 7 com.apple.AppKit0x93376448 -[NSKeyBindingManager(NSKeyBindingManager_MultiClients) interpretEventAsCommand:forClient:] + 1932 8 com.apple.AppKit0x933749a9 -[NSTSMInputContext interpretKeyEvents:] + 1157 9 com.apple.AppKit0x93373d50 -[NSView interpretKeyEvents:] + 65 10 com.apple.AppKit0x93373c3e -[NSTextView keyDown:] + 1061 11 org.R-project.R 0x00030a88 -[RTextView keyDown:] + 319 (RTextView.m:259) 12 com.apple.AppKit0x933737c1 -[NSWindow sendEvent:] + 7377 13 com.apple.AppKit0x93364f28 -[NSApplication sendEvent:] + 5023 14 org.R-project.R 0x8f46 -[RController doProcessEvents:] + 530 (RController.m:2201) 15 org.R-project.R 0x6350 -[RController handleReadConsole:] + 126 (RController.m:1118) 16 org.R-project.R 0x00010fa9 Re_ReadConsole + 494 (Rcallbacks.m:143) 17 org.R-project.R 0x00018aed run_REngineRmainloop + 867 (Rinit.m:393) 18 org.R-project.R 0x0001142a -[REngine runREPL] + 260 (REngine.m:181) 19 org.R-project.R 0x2e91 main + 795 (main.m:126) 20 org.R-project.R 0x2b5a _start + 216 21 org.R-project.R 0x2a81 start + 41 Thread 1: 0 libSystem.B.dylib 0x90009cd7 mach_msg_trap + 7 1 com.apple.CoreFoundation0x9082d21b CFRunLoopRunSpecific + 2014 2 com.apple.CoreFoundation0x9082ca36 CFRunLoopRunInMode + 61 3 com.apple.Foundation0x92854c76 +[NSURLCache _diskCacheSyncLoop:] + 206 4 com.apple.Foundation0x927f839c forkThreadForFunction + 123 5 libSystem.B.dylib 0x90024227 _pthread_body + 84 Thread 2: 0 libSystem.B.dylib 0x9001a1cc select + 12 1 com.apple.Foundation0x927f839c forkThreadForFunction + 123 2 libSystem.B.dylib 0x90024227 _pthread_body + 84 Thread 3: 0 libSystem.B.dylib 0x900248c7 semaphore_wait_signal_trap + 7 1 com.apple.Foundation0x9284e2fc -[NSConditionLock lockWhenCondition:] + 39 2 com.apple.AppKit0x9336ce50 -[NSUIHeartBeat _heartBeatThread:] + 377 3 com.apple.Foundation0x927f839c forkThreadForFunction + 123 4 libSystem.B.dylib 0x90024227 _pthread_body + 84 Thread 4: 0 libSystem.B.dylib 0x90009cd7 mach_msg_trap + 7 1 com.apple.CoreFoundation0x9082d21b CFRunLoopRunSpecific + 2014 2 com.apple.CoreFoundation0x9082ca36 CFRunLoopRunInMode + 61 3 com.apple.Foundation0x9282da40 +[NSURLConnection(NSURLConnectionInternal) _resourceLoadLoop:] + 259 4 com.apple.Foundation0x927f839c forkThreadForFunction + 123 5 libSystem.B.dylib 0x90024227 _pthread_body + 84 Thread 5: 0 libSystem.B.dylib 0x9001a1cc select + 12 1 libSystem.B.dylib 0x90024227 _pthread_body + 84 Thread 6: 0 libSystem.B.dylib 0x90026d5c kevent + 12 1 ...ple.CoreServices.CarbonCore 0x90cb8c68 PrivateMPEntryPoint + 51 2 libSystem.B.dylib 0x90024227 _pthread_body + 84 Thread 7: 0 libSystem.B.dylib 0x900248c7 semaphore_wait_signal_trap + 7 1 ...ple.CoreServices.CarbonCore 0x90cb8e0d MPWaitOnQueue + 198 2 com.apple.DesktopServices 0x9271e943 TNodeSyncTask::SyncTaskProc(void*) + 143 3 ...ple.CoreServices.CarbonCore 0x90cb8c68 PrivateMPEntryPoint + 51 4 libSystem.B.dylib 0x90024227 _pthread_body + 84 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x18361b90 ebx: 0x9
[Rd] R code for weighted Deming regression?
Hi, Any one has the code that I can borrow? Or any suggestions? Highly appreciate. Hongyan Du -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, April 29, 2008 11:25 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [Rd] crash in Mac.app (PR#11334) Full_Name: Alex Cozzi Version: 2.7 OS: OS X 10.4 Submission from: (NULL) (209.131.62.113) Observed a crash while pressing ctrl-A and ESC in R.app Date/Time: 2008-04-29 09:18:28.501 -0700 OS Version: 10.4.11 (Build 8S2167) Report Version: 4 Command: R Path:/Applications/R.app/Contents/MacOS/R Parent: WindowServer [2784] Version: R 2.7.0 GUI 1.24 (5102) PID:9213 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0004 Thread 0 Crashed: 0 com.apple.CoreFoundation0x90872f9c __CFStorageFindByte + 23 1 com.apple.CoreFoundation0x90873069 __CFStorageFindByte + 228 2 com.apple.CoreFoundation0x90870d59 CFStorageGetValueAtIndex + 319 3 com.apple.AppKit0x9339c901 -[NSLayoutManager intAttribute:forGlyphAtIndex:] + 182 4 com.apple.AppKit0x937232b7 -[NSTextView(NSKeyBindingCommands) moveRight:] + 1128 5 com.apple.AppKit0x93380e29 -[NSResponder doCommandBySelector:] + 76 6 com.apple.AppKit0x93380cbc -[NSTextView doCommandBySelector:] + 229 7 com.apple.AppKit0x93376448 -[NSKeyBindingManager(NSKeyBindingManager_MultiClients) interpretEventAsCommand:forClient:] + 1932 8 com.apple.AppKit0x933749a9 -[NSTSMInputContext interpretKeyEvents:] + 1157 9 com.apple.AppKit0x93373d50 -[NSView interpretKeyEvents:] + 65 10 com.apple.AppKit0x93373c3e -[NSTextView keyDown:] + 1061 11 org.R-project.R 0x00030a88 -[RTextView keyDown:] + 319 (RTextView.m:259) 12 com.apple.AppKit0x933737c1 -[NSWindow sendEvent:] + 7377 13 com.apple.AppKit0x93364f28 -[NSApplication sendEvent:] + 5023 14 org.R-project.R 0x8f46 -[RController doProcessEvents:] + 530 (RController.m:2201) 15 org.R-project.R 0x6350 -[RController handleReadConsole:] + 126 (RController.m:1118) 16 org.R-project.R 0x00010fa9 Re_ReadConsole + 494 (Rcallbacks.m:143) 17 org.R-project.R 0x00018aed run_REngineRmainloop + 867 (Rinit.m:393) 18 org.R-project.R 0x0001142a -[REngine runREPL] + 260 (REngine.m:181) 19 org.R-project.R 0x2e91 main + 795 (main.m:126) 20 org.R-project.R 0x2b5a _start + 216 21 org.R-project.R 0x2a81 start + 41 Thread 1: 0 libSystem.B.dylib 0x90009cd7 mach_msg_trap + 7 1 com.apple.CoreFoundation0x9082d21b CFRunLoopRunSpecific + 2014 2 com.apple.CoreFoundation0x9082ca36 CFRunLoopRunInMode + 61 3 com.apple.Foundation0x92854c76 +[NSURLCache _diskCacheSyncLoop:] + 206 4 com.apple.Foundation0x927f839c forkThreadForFunction + 123 5 libSystem.B.dylib 0x90024227 _pthread_body + 84 Thread 2: 0 libSystem.B.dylib 0x9001a1cc select + 12 1 com.apple.Foundation0x927f839c forkThreadForFunction + 123 2 libSystem.B.dylib 0x90024227 _pthread_body + 84 Thread 3: 0 libSystem.B.dylib 0x900248c7 semaphore_wait_signal_trap + 7 1 com.apple.Foundation0x9284e2fc -[NSConditionLock lockWhenCondition:] + 39 2 com.apple.AppKit0x9336ce50 -[NSUIHeartBeat _heartBeatThread:] + 377 3 com.apple.Foundation0x927f839c forkThreadForFunction + 123 4 libSystem.B.dylib 0x90024227 _pthread_body + 84 Thread 4: 0 libSystem.B.dylib 0x90009cd7 mach_msg_trap + 7 1 com.apple.CoreFoundation0x9082d21b CFRunLoopRunSpecific + 2014 2 com.apple.CoreFoundation0x9082ca36 CFRunLoopRunInMode + 61 3 com.apple.Foundation0x9282da40 +[NSURLConnection(NSURLConnectionInternal) _resourceLoadLoop:] + 259 4 com.apple.Foundation0x927f839c forkThreadForFunction + 123 5 libSystem.B.dylib 0x90024227 _pthread_body + 84 Thread 5: 0 libSystem.B.dylib 0x9001a1cc select + 12 1 libSystem.B.dylib 0x90024227 _pthread_body + 84 Thread 6: 0 libSystem.B.dylib 0x90026d5c kevent + 12 1 ...ple.CoreServices.CarbonCore 0x90cb8c68 PrivateMPEntryPoint + 51 2 libSystem.B.dylib 0x90024227 _pthread_body + 84 Thread 7: 0 libSystem.B.dylib 0x900248c7 semaphore_wait_signal_trap + 7 1 ...ple.CoreServices.CarbonCore 0x90cb8e0d MPWaitO
[Rd] R code for weighted Deming regression? (PR#11334)
Hi, Any one has the code that I can borrow? Or any suggestions? Highly appreciate. Hongyan Du =20 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, April 29, 2008 11:25 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [Rd] crash in Mac.app (PR#11334) Full_Name: Alex Cozzi Version: 2.7 OS: OS X 10.4 Submission from: (NULL) (209.131.62.113) Observed a crash while pressing ctrl-A and ESC in R.app Date/Time: 2008-04-29 09:18:28.501 -0700 OS Version: 10.4.11 (Build 8S2167) Report Version: 4 Command: R Path:/Applications/R.app/Contents/MacOS/R Parent: WindowServer [2784] Version: R 2.7.0 GUI 1.24 (5102) PID:9213 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0004 Thread 0 Crashed: 0 com.apple.CoreFoundation0x90872f9c __CFStorageFindByte + 23 1 com.apple.CoreFoundation0x90873069 __CFStorageFindByte + 228 2 com.apple.CoreFoundation0x90870d59 CFStorageGetValueAtIndex + 319 3 com.apple.AppKit0x9339c901 -[NSLayoutManager intAttribute:forGlyphAtIndex:] + 182 4 com.apple.AppKit0x937232b7 -[NSTextView(NSKeyBindingCommands) moveRight:] + 1128 5 com.apple.AppKit0x93380e29 -[NSResponder doCommandBySelector:] + 76 6 com.apple.AppKit0x93380cbc -[NSTextView doCommandBySelector:] + 229 7 com.apple.AppKit0x93376448 -[NSKeyBindingManager(NSKeyBindingManager_MultiClients) interpretEventAsCommand:forClient:] + 1932 8 com.apple.AppKit0x933749a9 -[NSTSMInputContext interpretKeyEvents:] + 1157 9 com.apple.AppKit0x93373d50 -[NSView interpretKeyEvents:] + 65 10 com.apple.AppKit0x93373c3e -[NSTextView keyDown:] + 1061 11 org.R-project.R 0x00030a88 -[RTextView keyDown:] + 319 (RTextView.m:259) 12 com.apple.AppKit0x933737c1 -[NSWindow sendEvent:] + 7377 13 com.apple.AppKit0x93364f28 -[NSApplication sendEvent:] + 5023 14 org.R-project.R 0x8f46 -[RController doProcessEvents:] + 530 (RController.m:2201) 15 org.R-project.R 0x6350 -[RController handleReadConsole:] + 126 (RController.m:1118) 16 org.R-project.R 0x00010fa9 Re_ReadConsole + 494 (Rcallbacks.m:143) 17 org.R-project.R 0x00018aed run_REngineRmainloop + 867 (Rinit.m:393) 18 org.R-project.R 0x0001142a -[REngine runREPL] + 260 (REngine.m:181) 19 org.R-project.R 0x2e91 main + 795 (main.m:126) 20 org.R-project.R 0x2b5a _start + 216 21 org.R-project.R 0x2a81 start + 41 Thread 1: 0 libSystem.B.dylib 0x90009cd7 mach_msg_trap + 7 1 com.apple.CoreFoundation0x9082d21b CFRunLoopRunSpecific + 2014 2 com.apple.CoreFoundation0x9082ca36 CFRunLoopRunInMode + 61 3 com.apple.Foundation0x92854c76 +[NSURLCache _diskCacheSyncLoop:] + 206 4 com.apple.Foundation0x927f839c forkThreadForFunction + 123 5 libSystem.B.dylib 0x90024227 _pthread_body + 84 Thread 2: 0 libSystem.B.dylib 0x9001a1cc select + 12 1 com.apple.Foundation0x927f839c forkThreadForFunction + 123 2 libSystem.B.dylib 0x90024227 _pthread_body + 84 Thread 3: 0 libSystem.B.dylib 0x900248c7 semaphore_wait_signal_trap + 7 1 com.apple.Foundation0x9284e2fc -[NSConditionLock lockWhenCondition:] + 39 2 com.apple.AppKit0x9336ce50 -[NSUIHeartBeat _heartBeatThread:] + 377 3 com.apple.Foundation0x927f839c forkThreadForFunction + 123 4 libSystem.B.dylib 0x90024227 _pthread_body + 84 Thread 4: 0 libSystem.B.dylib 0x90009cd7 mach_msg_trap + 7 1 com.apple.CoreFoundation0x9082d21b CFRunLoopRunSpecific + 2014 2 com.apple.CoreFoundation0x9082ca36 CFRunLoopRunInMode + 61 3 com.apple.Foundation0x9282da40 +[NSURLConnection(NSURLConnectionInternal) _resourceLoadLoop:] + 259 4 com.apple.Foundation0x927f839c forkThreadForFunction + 123 5 libSystem.B.dylib 0x90024227 _pthread_body + 84 Thread 5: 0 libSystem.B.dylib 0x9001a1cc select + 12 1 libSystem.B.dylib 0x90024227 _pthread_body + 84 Thread 6: 0 libSystem.B.dylib 0x90026d5c kevent + 12 1 ...ple.CoreServices.CarbonCore 0x90cb8c68 PrivateMPEntryPoint + 51 2 libSystem.B.dylib 0x90024227 _pthread_body + 84 Thread 7: 0 libSystem.B.dylib 0x900248c7 semaphore_wait_signal_trap + 7 1 ...ple.CoreServices.CarbonCore 0x90cb8e0d MPWai
Re: [Rd] reproducible segmentation fault caused by textConnection()
On Tue, 29 Apr 2008, Gregoire Pau wrote:
> Dear all,
>
> It seems that textConnection() can trigger a segmentation fault. The
> following script (using two large loops) makes this bug reproducible:
>
> for (i in 1:1) {
>z=textConnection(NULL,open='w')
>for (j in 1:100) {
> write(runif(1)*1e6,file=z)
> write('\n',file=z)
>}
>close(z)
> }
>
> The bug could be reproduced on R-2.6.1, R-2.7.0 and on the latest
> R-devel 2008-04-29 r45543.
valgrind shows that it uses freed memory after
a garbage collecting episode (after many iterations),
because a Routtextconn's 'data' component was freed:
==24210== Invalid read of size 1
==24210==at 0x810B328: Rf_lengthgets (Rinlinedfuns.h:358)
==24210==by 0x8121C48: text_vfprintf (connections.c:2064)
==24210==by 0x809D0C1: Rvprintf (printutils.c:770)
==24210==by 0x809D105: Rprintf (printutils.c:668)
==24210==by 0x810A984: do_cat (builtin.c:617)
==24210== Address 0x5823CD8 is 0 bytes inside a block of size 1,176 free'd
==24210==at 0x40052A3: free (vg_replace_malloc.c:233)
==24210==by 0x805AC3D: R_gc_internal (memory.c:769)
==24210==by 0x805B873: Rf_cons (memory.c:1757)
==24210==by 0x81571F6: Rf_promiseArgs (eval.c:1633)
(gdb) where 5
#0 Rf_lengthgets (x=0x5823cd8, len=289)
at ../../src/include/Rinlinedfuns.h:358
#1 0x08121c49 in text_vfprintf (con=0x500f280, format=0x81e64d8 "\n",
ap=0xbef18b84 "?\213??") at connections.c:2064
#2 0x0809d0c2 in Rvprintf (format=0x81e64d8 "\n", arg=0xbef18b84 "?\213??")
at printutils.c:770
#3 0x0809d106 in Rprintf (format=0x81e64d8 "\n") at printutils.c:668
#4 0x0810a985 in do_cat (call=0x4ae31f0, op=0x4104eec, args=0x55bb2bc,
rho=0x55baf20) at builtin.c:617
(More stack frames follow...)
(gdb) up
#1 0x08121c49 in text_vfprintf (con=0x500f280, format=0x81e64d8 "\n",
ap=0xbef18b84 "?\213??") at connections.c:2064
2064PROTECT(tmp = lengthgets(this->data, ++this->len));
(gdb) print this->data
$1 = 0x5823cd8
(gdb) whatis this
type = Routtextconn
(gdb) whatis this->data
type = SEXP
(gdb) print *this->data
$2 = {sxpinfo = {type = 16, obj = 0, named = 2, gp = 0, mark = 0, debug = 0,
trace = 0, spare = 0, gcgen = 0, gccls = 7}, attrib = 0x40ae088,
gengc_next_node = 0x8235270, gengc_prev_node = 0x8235270, u = {primsxp = {
offset = 288}, symsxp = {pname = 0x120, value = 0x0,
internal = 0x57685c0}, listsxp = {carval = 0x120, cdrval = 0x0,
tagval = 0x57685c0}, envsxp = {frame = 0x120, enclos = 0x0,
hashtab = 0x57685c0}, closxp = {formals = 0x120, body = 0x0,
env = 0x57685c0}, promsxp = {value = 0x120, expr = 0x0,
env = 0x57685c0}}}
Bill Dunlap
Insightful Corporation
bill at insightful dot com
"All statements in this message represent the opinions of the author and do
not necessarily reflect Insightful Corporation policy or position."
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] build packages with vignettes in Windows
I've been trying to build a Windows binary of a package of mine without success. It seems that the files under inst/doc throw the script off. I am using the command 'Rcmd INSTALL --build'. -- Making package genepi adding build stamp to DESCRIPTION installing NAMESPACE file and metadata installing R files installing inst files FIND: Parameter format not correct make[2]: *** [C:/Library/R/genepi/inst] Error 2 make[1]: *** [all] Error 2 make: *** [pkg-genepi] Error 2 *** Installation of genepi failed *** I also tried a couple of packages downloaded from CRAN. Those without inst/doc directory worked fine and those who do have it didn't. I'm using a fresh install of R-2.7.0 and Rtools-2.7. Any clue of what was wrong with my setup? Thanks, Michael __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] build packages with vignettes in Windows
On 29/04/2008 12:54 PM, Michael wrote: I've been trying to build a Windows binary of a package of mine without success. It seems that the files under inst/doc throw the script off. I am using the command 'Rcmd INSTALL --build'. -- Making package genepi adding build stamp to DESCRIPTION installing NAMESPACE file and metadata installing R files installing inst files FIND: Parameter format not correct That looks as though you don't have the tools installed correctly, you have some other "find" earlier on your path. Duncan Murdoch make[2]: *** [C:/Library/R/genepi/inst] Error 2 make[1]: *** [all] Error 2 make: *** [pkg-genepi] Error 2 *** Installation of genepi failed *** I also tried a couple of packages downloaded from CRAN. Those without inst/doc directory worked fine and those who do have it didn't. I'm using a fresh install of R-2.7.0 and Rtools-2.7. Any clue of what was wrong with my setup? Thanks, Michael __ 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] build packages with vignettes in Windows
On Tue, 29 Apr 2008, Michael wrote: I've been trying to build a Windows binary of a package of mine without success. It seems that the files under inst/doc throw the script off. I am using the command 'Rcmd INSTALL --build'. -- Making package genepi adding build stamp to DESCRIPTION installing NAMESPACE file and metadata installing R files installing inst files FIND: Parameter format not correct make[2]: *** [C:/Library/R/genepi/inst] Error 2 make[1]: *** [all] Error 2 make: *** [pkg-genepi] Error 2 *** Installation of genepi failed *** I also tried a couple of packages downloaded from CRAN. Those without inst/doc directory worked fine and those who do have it didn't. I'm using a fresh install of R-2.7.0 and Rtools-2.7. Any clue of what was wrong with my setup? Your path is incorrect -- as 'R Installation and Administration' does warn you. Thanks, Michael __ 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] non-digits in svnversion output mess up windows build if USE_SVNVERSION=yes (PR#11339)
Full_Name: Bill Dunlap
Version: 2.8.0dev
OS: Windows XP
Submission from: (NULL) (70.98.76.47)
I tried for the first time to build R from source on Windows, where I
got the source code via svn. Per the Installation and Administration
manual, I altered src\gnuwin32\MkRules so it had the the locally
correct paths to HTML Help Workshop and Inno Setup 5. I also set
USE_SVNVERSION=yes, as suggested in MkRules itself. Then, while in
the directory src/gnuwin32 I ran 'make all recommended' and got an
error from windres very early in the build:
E:\R\R-svn\r-devel\src\gnuwin32>make all recommended
make --no-print-directory -C front-ends Rpwd
make -C ../../include -f Makefile.win version
make Rpwd.exe
gcc -std=gnu99 -I../../include -O3 -Wall -pedantic -c rpwd.c -o rpwd.o
windres --preprocessor="gcc -E -xc -DRC_INVOKED" -i rcico.rc -o rcico.o
c:\Rtools\MinGW\bin\windres.exe: rcico.rc:9: syntax error
make[3]: *** [rcico.o] Error 1
make[2]: *** [Rpwd] Error 2
make[1]: *** [front-ends/Rpwd.exe] Error 2
make: *** [all] Error 2
Line 9 of src\gnuwin32\front-ends\rcico.rc is
FILEVERSION R_FILEVERSION
The problem was that my change to MkRules caused 'svnversion' to put an
'M' (modified) on the end of the svn version it reports. This svn
version number is used in the R_FILEVERSION macro, which is used in in
the *.rc files. The resource file compiler, windres, appears to choke on
non-digits in R_FILEVERSION. (A comment in tools\GETVERSION indicates
it might choke on leading 0's as well.)
svnversion can also output a string of the form "123:125"
to mean the current source is from a variety of svn revisions,
between 123 through 125. An "M" or "S" may also be appended.
If you don't have Subversion installed then you might get
a svn version of "unknown". None of these non-digits is
acceptble to windres.
I patched tools/GETVERSION to fix up this problem. It removes
the trailing M or S and removes anything up to an including a
colon, so it reports the highest version in the range. If there
are still non-digits in there it makes the version string "0"
(not useful, but doesn't kill the build with a noninformative
error message).
I ran into another problem with the trailing 'M' from svnversion
when doing 'make rinstaller' in R_HOME/src/gnuwin32:
E:\R\R-svn\r-devel\src\gnuwin32\installer>type R-2.8.0dev.log
Inno Setup 5 Command-Line Compiler
...
Compiler engine version: Inno Setup 5.2.3 (ISPP 5.2.3.0)
...
[ISPP] Preprocessing.
...
[ISPP] Preprocessed.
Parsing [Setup] section, line 10
...
Parsing [Setup] section, line 20
Error on line 12 in e:\R\R-svn\r-devel\src\gnuwin32\installer\R.iss: Value of
[Setup] section directive "VersionInfoVersion" is invalid.
Compile aborted.
The offending line 12 in R.iss is
12 VersionInfoVersion=2.8.0.45381M
and it is put there by src/gnuwin32/installer/JRins.pl.
I patched JRins.pl to ensure the svn revision consisted
of only digits.
Then I could build R on Windows (make distribution)
with USE_SVNVERSION=yes set in src/gnuwin32/MkRules
and with a variety of svn revision settings.
Index: src/gnuwin32/installer/JRins.pl
===
--- src/gnuwin32/installer/JRins.pl (revision 45553)
+++ src/gnuwin32/installer/JRins.pl (working copy)
@@ -44,6 +44,11 @@
$SVN = ;
close ver;
$SVN =~s/Revision: //;
+## inno setup requires that SVN be all numeric, not 123M, 120:123, "unknown",
or empty
+$SVN =~s/[MS]* *$//;
+$SVN =~s/^.*://;
+$SVN =~s/[^0-9]//g;
+$SVN =~s/^$/0/;
$RVER0 .= "." . $SVN;
open insfile, "> R.iss" || die "Cannot open R.iss\n";
Index: tools/GETVERSION
===
--- tools/GETVERSION(revision 45479)
+++ tools/GETVERSION(working copy)
@@ -24,6 +24,7 @@
y1=6
svn_rev=unknown
fi
+ all_numeric_svn_rev=`echo ${svn_rev}|sed -e 's/[MS]*$//' -e 's/^.*://' -e
's/[^0-9]//g' -e 's/^$/0/'`
echo "/* Rversion.h. Generated automatically. */"
echo "#ifndef R_VERSION_H"
echo "#define R_VERSION_H"
@@ -43,7 +44,7 @@
echo "#define R_SVN_REVISION \"${svn_rev}\""
## Using 1-digit year stops problems with leading zeros
# echo "#define R_FILEVERSION${maj},${pl}${sl},${y1}${m}${d},0"
- echo "#define R_FILEVERSION${maj},${pl}${sl},${svn_rev},0"
+ echo "#define R_FILEVERSION${maj},${pl}${sl},${all_numeric_svn_rev},0"
echo
echo '#ifdef __cplusplus'
echo '}'
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] build packages with vignettes in Windows
The use of the UNIX find command on Windows makes installation very troublesome and fragile. I wonder if you could include a find2 or somesuch with the tools and change the scripts to use that getting rid of find or use just use the Windows find command in the scripts. Or some other solution so that one does not have to have a non-Windows find on the PATH. If you don't have the find in Rtools first in your path then you have problems like the one below and if you do have it first then it throws off the scripts from other software. On Tue, Apr 29, 2008 at 2:29 PM, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > On 29/04/2008 12:54 PM, Michael wrote: > > I've been trying to build a Windows binary of a package of mine without > > success. It seems that the files under inst/doc throw the script off. > > > > I am using the command 'Rcmd INSTALL --build'. > > > > -- Making package genepi > > adding build stamp to DESCRIPTION > > installing NAMESPACE file and metadata > > installing R files > > installing inst files > > FIND: Parameter format not correct > > > > That looks as though you don't have the tools installed correctly, you have > some other "find" earlier on your path. > > Duncan Murdoch > > > > > make[2]: *** [C:/Library/R/genepi/inst] Error 2 > > make[1]: *** [all] Error 2 > > make: *** [pkg-genepi] Error 2 > > *** Installation of genepi failed *** > > > > I also tried a couple of packages downloaded from CRAN. Those without > > inst/doc directory worked fine and those who do have it didn't. > > > > I'm using a fresh install of R-2.7.0 and Rtools-2.7. > > Any clue of what was wrong with my setup? > > > > Thanks, > > > > Michael > > > > __ > > 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 > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] build packages with vignettes in Windows
On 29/04/2008 2:51 PM, Gabor Grothendieck wrote: The use of the UNIX find command on Windows makes installation very troublesome and fragile. I wonder if you could include a find2 or somesuch with the tools and change the scripts to use that getting rid of find or use just use the Windows find command in the scripts. Or some other solution so that one does not have to have a non-Windows find on the PATH. Find isn't unique: there are lots of versions of make, and grep, and tar that don't work, either. We've adopted a simple solution, and it works: when you're using the R tools, put them first on the path. We've thought about including the R tools with R, which would increase the size of the distribution quite a bit. Then Rcmd.exe could do the path modifications, and you wouldn't need to worry about doing it yourself. That might still happen for 2.8.0. Duncan Murdoch If you don't have the find in Rtools first in your path then you have problems like the one below and if you do have it first then it throws off the scripts from other software. On Tue, Apr 29, 2008 at 2:29 PM, Duncan Murdoch <[EMAIL PROTECTED]> wrote: On 29/04/2008 12:54 PM, Michael wrote: I've been trying to build a Windows binary of a package of mine without success. It seems that the files under inst/doc throw the script off. I am using the command 'Rcmd INSTALL --build'. -- Making package genepi adding build stamp to DESCRIPTION installing NAMESPACE file and metadata installing R files installing inst files FIND: Parameter format not correct That looks as though you don't have the tools installed correctly, you have some other "find" earlier on your path. Duncan Murdoch make[2]: *** [C:/Library/R/genepi/inst] Error 2 make[1]: *** [all] Error 2 make: *** [pkg-genepi] Error 2 *** Installation of genepi failed *** I also tried a couple of packages downloaded from CRAN. Those without inst/doc directory worked fine and those who do have it didn't. I'm using a fresh install of R-2.7.0 and Rtools-2.7. Any clue of what was wrong with my setup? Thanks, Michael __ 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 __ 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] non-digits in svnversion output mess up windows build if USE_SVNVERSION=yes (PR#11339)
This is not a bug, it's a feature.
It stops me from distributing versions with unintentional uncommitted
changes.
Duncan Murdoch
On 29/04/2008 2:30 PM, [EMAIL PROTECTED] wrote:
Full_Name: Bill Dunlap
Version: 2.8.0dev
OS: Windows XP
Submission from: (NULL) (70.98.76.47)
I tried for the first time to build R from source on Windows, where I
got the source code via svn. Per the Installation and Administration
manual, I altered src\gnuwin32\MkRules so it had the the locally
correct paths to HTML Help Workshop and Inno Setup 5. I also set
USE_SVNVERSION=yes, as suggested in MkRules itself. Then, while in
the directory src/gnuwin32 I ran 'make all recommended' and got an
error from windres very early in the build:
E:\R\R-svn\r-devel\src\gnuwin32>make all recommended
make --no-print-directory -C front-ends Rpwd
make -C ../../include -f Makefile.win version
make Rpwd.exe
gcc -std=gnu99 -I../../include -O3 -Wall -pedantic -c rpwd.c -o rpwd.o
windres --preprocessor="gcc -E -xc -DRC_INVOKED" -i rcico.rc -o rcico.o
c:\Rtools\MinGW\bin\windres.exe: rcico.rc:9: syntax error
make[3]: *** [rcico.o] Error 1
make[2]: *** [Rpwd] Error 2
make[1]: *** [front-ends/Rpwd.exe] Error 2
make: *** [all] Error 2
Line 9 of src\gnuwin32\front-ends\rcico.rc is
FILEVERSION R_FILEVERSION
The problem was that my change to MkRules caused 'svnversion' to put an
'M' (modified) on the end of the svn version it reports. This svn
version number is used in the R_FILEVERSION macro, which is used in in
the *.rc files. The resource file compiler, windres, appears to choke on
non-digits in R_FILEVERSION. (A comment in tools\GETVERSION indicates
it might choke on leading 0's as well.)
svnversion can also output a string of the form "123:125"
to mean the current source is from a variety of svn revisions,
between 123 through 125. An "M" or "S" may also be appended.
If you don't have Subversion installed then you might get
a svn version of "unknown". None of these non-digits is
acceptble to windres.
I patched tools/GETVERSION to fix up this problem. It removes
the trailing M or S and removes anything up to an including a
colon, so it reports the highest version in the range. If there
are still non-digits in there it makes the version string "0"
(not useful, but doesn't kill the build with a noninformative
error message).
I ran into another problem with the trailing 'M' from svnversion
when doing 'make rinstaller' in R_HOME/src/gnuwin32:
E:\R\R-svn\r-devel\src\gnuwin32\installer>type R-2.8.0dev.log
Inno Setup 5 Command-Line Compiler
...
Compiler engine version: Inno Setup 5.2.3 (ISPP 5.2.3.0)
...
[ISPP] Preprocessing.
...
[ISPP] Preprocessed.
Parsing [Setup] section, line 10
...
Parsing [Setup] section, line 20
Error on line 12 in e:\R\R-svn\r-devel\src\gnuwin32\installer\R.iss: Value of
[Setup] section directive "VersionInfoVersion" is invalid.
Compile aborted.
The offending line 12 in R.iss is
12 VersionInfoVersion=2.8.0.45381M
and it is put there by src/gnuwin32/installer/JRins.pl.
I patched JRins.pl to ensure the svn revision consisted
of only digits.
Then I could build R on Windows (make distribution)
with USE_SVNVERSION=yes set in src/gnuwin32/MkRules
and with a variety of svn revision settings.
Index: src/gnuwin32/installer/JRins.pl
===
--- src/gnuwin32/installer/JRins.pl (revision 45553)
+++ src/gnuwin32/installer/JRins.pl (working copy)
@@ -44,6 +44,11 @@
$SVN = ;
close ver;
$SVN =~s/Revision: //;
+## inno setup requires that SVN be all numeric, not 123M, 120:123, "unknown",
or empty
+$SVN =~s/[MS]* *$//;
+$SVN =~s/^.*://;
+$SVN =~s/[^0-9]//g;
+$SVN =~s/^$/0/;
$RVER0 .= "." . $SVN;
open insfile, "> R.iss" || die "Cannot open R.iss\n";
Index: tools/GETVERSION
===
--- tools/GETVERSION(revision 45479)
+++ tools/GETVERSION(working copy)
@@ -24,6 +24,7 @@
y1=6
svn_rev=unknown
fi
+ all_numeric_svn_rev=`echo ${svn_rev}|sed -e 's/[MS]*$//' -e 's/^.*://' -e
's/[^0-9]//g' -e 's/^$/0/'`
echo "/* Rversion.h. Generated automatically. */"
echo "#ifndef R_VERSION_H"
echo "#define R_VERSION_H"
@@ -43,7 +44,7 @@
echo "#define R_SVN_REVISION \"${svn_rev}\""
## Using 1-digit year stops problems with leading zeros
# echo "#define R_FILEVERSION${maj},${pl}${sl},${y1}${m}${d},0"
- echo "#define R_FILEVERSION${maj},${pl}${sl},${svn_rev},0"
+ echo "#define R_FILEVERSION${maj},${pl}${sl},${all_numeric_svn_rev},0"
echo
echo '#ifdef __cplusplus'
echo '}'
__
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] non-digits in svnversion output mess up windows build if (PR#11340)
This is not a bug, it's a feature.
It stops me from distributing versions with unintentional uncommitted
changes.
Duncan Murdoch
On 29/04/2008 2:30 PM, [EMAIL PROTECTED] wrote:
> Full_Name: Bill Dunlap
> Version: 2.8.0dev
> OS: Windows XP
> Submission from: (NULL) (70.98.76.47)
>
>
> I tried for the first time to build R from source on Windows, where I
> got the source code via svn. Per the Installation and Administration
> manual, I altered src\gnuwin32\MkRules so it had the the locally
> correct paths to HTML Help Workshop and Inno Setup 5. I also set
> USE_SVNVERSION=yes, as suggested in MkRules itself. Then, while in
> the directory src/gnuwin32 I ran 'make all recommended' and got an
> error from windres very early in the build:
>
> E:\R\R-svn\r-devel\src\gnuwin32>make all recommended
> make --no-print-directory -C front-ends Rpwd
> make -C ../../include -f Makefile.win version
> make Rpwd.exe
> gcc -std=gnu99 -I../../include -O3 -Wall -pedantic -c rpwd.c -o rpwd.o
> windres --preprocessor="gcc -E -xc -DRC_INVOKED" -i rcico.rc -o rcico.o
> c:\Rtools\MinGW\bin\windres.exe: rcico.rc:9: syntax error
> make[3]: *** [rcico.o] Error 1
> make[2]: *** [Rpwd] Error 2
> make[1]: *** [front-ends/Rpwd.exe] Error 2
> make: *** [all] Error 2
>
> Line 9 of src\gnuwin32\front-ends\rcico.rc is
> FILEVERSION R_FILEVERSION
> The problem was that my change to MkRules caused 'svnversion' to put an
> 'M' (modified) on the end of the svn version it reports. This svn
> version number is used in the R_FILEVERSION macro, which is used in in
> the *.rc files. The resource file compiler, windres, appears to choke on
> non-digits in R_FILEVERSION. (A comment in tools\GETVERSION indicates
> it might choke on leading 0's as well.)
>
> svnversion can also output a string of the form "123:125"
> to mean the current source is from a variety of svn revisions,
> between 123 through 125. An "M" or "S" may also be appended.
> If you don't have Subversion installed then you might get
> a svn version of "unknown". None of these non-digits is
> acceptble to windres.
>
> I patched tools/GETVERSION to fix up this problem. It removes
> the trailing M or S and removes anything up to an including a
> colon, so it reports the highest version in the range. If there
> are still non-digits in there it makes the version string "0"
> (not useful, but doesn't kill the build with a noninformative
> error message).
>
> I ran into another problem with the trailing 'M' from svnversion
> when doing 'make rinstaller' in R_HOME/src/gnuwin32:
>E:\R\R-svn\r-devel\src\gnuwin32\installer>type R-2.8.0dev.log
>Inno Setup 5 Command-Line Compiler
>...
>Compiler engine version: Inno Setup 5.2.3 (ISPP 5.2.3.0)
>...
>[ISPP] Preprocessing.
>...
>[ISPP] Preprocessed.
>Parsing [Setup] section, line 10
>...
>Parsing [Setup] section, line 20
>Error on line 12 in e:\R\R-svn\r-devel\src\gnuwin32\installer\R.iss: Value
> of
> [Setup] section directive "VersionInfoVersion" is invalid.
>Compile aborted.
> The offending line 12 in R.iss is
> 12 VersionInfoVersion=2.8.0.45381M
> and it is put there by src/gnuwin32/installer/JRins.pl.
>
> I patched JRins.pl to ensure the svn revision consisted
> of only digits.
>
> Then I could build R on Windows (make distribution)
> with USE_SVNVERSION=yes set in src/gnuwin32/MkRules
> and with a variety of svn revision settings.
>
> Index: src/gnuwin32/installer/JRins.pl
> ===
> --- src/gnuwin32/installer/JRins.pl (revision 45553)
> +++ src/gnuwin32/installer/JRins.pl (working copy)
> @@ -44,6 +44,11 @@
> $SVN = ;
> close ver;
> $SVN =~s/Revision: //;
> +## inno setup requires that SVN be all numeric, not 123M, 120:123, "unknown",
> or empty
> +$SVN =~s/[MS]* *$//;
> +$SVN =~s/^.*://;
> +$SVN =~s/[^0-9]//g;
> +$SVN =~s/^$/0/;
> $RVER0 .= "." . $SVN;
>
> open insfile, "> R.iss" || die "Cannot open R.iss\n";
> Index: tools/GETVERSION
> ===
> --- tools/GETVERSION(revision 45479)
> +++ tools/GETVERSION(working copy)
> @@ -24,6 +24,7 @@
> y1=6
> svn_rev=unknown
>fi
> + all_numeric_svn_rev=`echo ${svn_rev}|sed -e 's/[MS]*$//' -e 's/^.*://' -e
> 's/[^0-9]//g' -e 's/^$/0/'`
>echo "/* Rversion.h. Generated automatically. */"
>echo "#ifndef R_VERSION_H"
>echo "#define R_VERSION_H"
> @@ -43,7 +44,7 @@
>echo "#define R_SVN_REVISION \"${svn_rev}\""
> ## Using 1-digit year stops problems with leading zeros
> # echo "#define R_FILEVERSION${maj},${pl}${sl},${y1}${m}${d},0"
> - echo "#define R_FILEVERSION${maj},${pl}${sl},${svn_rev},0"
> + echo "#define R_FILEVERSION${maj},${pl}${sl},${all_numeric_svn_rev},0"
>echo
>echo '#ifdef __cplusplus'
>echo '}'
>
> __
> R-devel@r-project.org mailing list
> https:/
Re: [Rd] build packages with vignettes in Windows
On 29 Apr 2008, Duncan Murdoch wrote: > On 29/04/2008 12:54 PM, Michael wrote: > > I've been trying to build a Windows binary of a package of mine without > > success. It seems that the files under inst/doc throw the script off. > > > > I am using the command 'Rcmd INSTALL --build'. > > > > -- Making package genepi > > adding build stamp to DESCRIPTION > > installing NAMESPACE file and metadata > > installing R files > > installing inst files > > FIND: Parameter format not correct > That looks as though you don't have the tools installed correctly, you have > some other "find" earlier on your path. Thanks, I didn't let the Rtools Installer to update the PATH variable for me because it says 'restart is required' which I didn't want to do, since I can update the environment variable without rebooting Windows. Michael __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] build packages with vignettes in Windows
On 29/04/2008 4:26 PM, Michael wrote: On 29 Apr 2008, Duncan Murdoch wrote: On 29/04/2008 12:54 PM, Michael wrote: I've been trying to build a Windows binary of a package of mine without success. It seems that the files under inst/doc throw the script off. I am using the command 'Rcmd INSTALL --build'. -- Making package genepi adding build stamp to DESCRIPTION installing NAMESPACE file and metadata installing R files installing inst files FIND: Parameter format not correct That looks as though you don't have the tools installed correctly, you have some other "find" earlier on your path. Thanks, I didn't let the Rtools Installer to update the PATH variable for me because it says 'restart is required' which I didn't want to do, since I can update the environment variable without rebooting Windows. Right, you don't need to set the system path for everything, but you do need to set it in CMD (or other shell) before running Rcmd. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] non-digits in svnversion output mess up windows build if USE_SVNVERSION=yes (PR#11339)
On Tue, 29 Apr 2008, Duncan Murdoch wrote: > This is not a bug, it's a feature. > > It stops me from distributing versions with unintentional uncommitted > changes. It does have that effect, but the error messages are pretty obscure: c:\Rtools\MinGW\bin\windres.exe: rcico.rc:9: syntax error and Error on line 12 in e:\R\R-svn\r-devel\src\gnuwin32\installer\R.iss: Value of [Setup] section directive "VersionInfoVersion" is invalid. Both problems are Windows-specific and the desire to not distribute versions with unintentional uncommitted uncommitted changes is not Windows-specific. Note that the rcico.rc problem arises as the first step of compiling R on Windows from clean source tree, so you cannot even test a proposed change. I ran into it because I had to change src/gnuwin32/MkRules to say that I put Inno Setup in its standard place, "C:/Program Files/Inno Setup 5", and not in "C:/packages/inno". I guess I don't need to have USE_SVNVERSION=yes, but doing that means that version$"svn rev" shows me I have a non-standard version: that will show the svn version as something like "123M" or "123:145S". It is too bad it only is available on the Windows build. I think it would be a good thing to have on the non-Windows builds also. They use 'svn info' instead, which does not tell you that the local version is not the standard one. If we did that on all platforms then we could check the disribution by checking that !is.na(as.integer(svn$"svn rev")). It might also be nice to include the output of 'svn diff' in the distribution so a user or tester could see how this version was different than the official one. > On 29/04/2008 2:30 PM, [EMAIL PROTECTED] wrote: > > Full_Name: Bill Dunlap > > Version: 2.8.0dev > > OS: Windows XP > > Submission from: (NULL) (70.98.76.47) > > > > > > I tried for the first time to build R from source on Windows, where I > > got the source code via svn. Per the Installation and Administration > > manual, I altered src\gnuwin32\MkRules so it had the the locally > > correct paths to HTML Help Workshop and Inno Setup 5. I also set > > USE_SVNVERSION=yes, as suggested in MkRules itself. Then, while in > > the directory src/gnuwin32 I ran 'make all recommended' and got an > > error from windres very early in the build: > > > > E:\R\R-svn\r-devel\src\gnuwin32>make all recommended > > make --no-print-directory -C front-ends Rpwd > > make -C ../../include -f Makefile.win version > > make Rpwd.exe > > gcc -std=gnu99 -I../../include -O3 -Wall -pedantic -c rpwd.c -o rpwd.o > > windres --preprocessor="gcc -E -xc -DRC_INVOKED" -i rcico.rc -o rcico.o > > c:\Rtools\MinGW\bin\windres.exe: rcico.rc:9: syntax error > > make[3]: *** [rcico.o] Error 1 > > make[2]: *** [Rpwd] Error 2 > > make[1]: *** [front-ends/Rpwd.exe] Error 2 > > make: *** [all] Error 2 > > > > Line 9 of src\gnuwin32\front-ends\rcico.rc is > > FILEVERSION R_FILEVERSION > > The problem was that my change to MkRules caused 'svnversion' to put an > > 'M' (modified) on the end of the svn version it reports. This svn > > version number is used in the R_FILEVERSION macro, which is used in in > > the *.rc files. The resource file compiler, windres, appears to choke on > > non-digits in R_FILEVERSION. (A comment in tools\GETVERSION indicates > > it might choke on leading 0's as well.) > > > > svnversion can also output a string of the form "123:125" > > to mean the current source is from a variety of svn revisions, > > between 123 through 125. An "M" or "S" may also be appended. > > If you don't have Subversion installed then you might get > > a svn version of "unknown". None of these non-digits is > > acceptble to windres. > > > > I patched tools/GETVERSION to fix up this problem. It removes > > the trailing M or S and removes anything up to an including a > > colon, so it reports the highest version in the range. If there > > are still non-digits in there it makes the version string "0" > > (not useful, but doesn't kill the build with a noninformative > > error message). > > > > I ran into another problem with the trailing 'M' from svnversion > > when doing 'make rinstaller' in R_HOME/src/gnuwin32: > >E:\R\R-svn\r-devel\src\gnuwin32\installer>type R-2.8.0dev.log > >Inno Setup 5 Command-Line Compiler > >... > >Compiler engine version: Inno Setup 5.2.3 (ISPP 5.2.3.0) > >... > >[ISPP] Preprocessing. > >... > >[ISPP] Preprocessed. > >Parsing [Setup] section, line 10 > >... > >Parsing [Setup] section, line 20 > >Error on line 12 in e:\R\R-svn\r-devel\src\gnuwin32\installer\R.iss: > > Value of > > [Setup] section directive "VersionInfoVersion" is invalid. > >Compile aborted. > > The offending line 12 in R.iss is > > 12 VersionInfoVersion=2.8.0.45381M > > and it is put there by src/gnuwin32/installer/JRins.pl. > > > > I patched JRins.pl to ensure the svn revision consisted > > of only digits. > > > > Then I could build R on Windo
Re: [Rd] non-digits in svnversion output mess up windows build if (PR#11341)
On Tue, 29 Apr 2008, Duncan Murdoch wrote: > This is not a bug, it's a feature. > > It stops me from distributing versions with unintentional uncommitted > changes. It does have that effect, but the error messages are pretty obscure: c:\Rtools\MinGW\bin\windres.exe: rcico.rc:9: syntax error and Error on line 12 in e:\R\R-svn\r-devel\src\gnuwin32\installer\R.iss: Value of [Setup] section directive "VersionInfoVersion" is invalid. Both problems are Windows-specific and the desire to not distribute versions with unintentional uncommitted uncommitted changes is not Windows-specific. Note that the rcico.rc problem arises as the first step of compiling R on Windows from clean source tree, so you cannot even test a proposed change. I ran into it because I had to change src/gnuwin32/MkRules to say that I put Inno Setup in its standard place, "C:/Program Files/Inno Setup 5", and not in "C:/packages/inno". I guess I don't need to have USE_SVNVERSION=yes, but doing that means that version$"svn rev" shows me I have a non-standard version: that will show the svn version as something like "123M" or "123:145S". It is too bad it only is available on the Windows build. I think it would be a good thing to have on the non-Windows builds also. They use 'svn info' instead, which does not tell you that the local version is not the standard one. If we did that on all platforms then we could check the disribution by checking that !is.na(as.integer(svn$"svn rev")). It might also be nice to include the output of 'svn diff' in the distribution so a user or tester could see how this version was different than the official one. > On 29/04/2008 2:30 PM, [EMAIL PROTECTED] wrote: > > Full_Name: Bill Dunlap > > Version: 2.8.0dev > > OS: Windows XP > > Submission from: (NULL) (70.98.76.47) > > > > > > I tried for the first time to build R from source on Windows, where I > > got the source code via svn. Per the Installation and Administration > > manual, I altered src\gnuwin32\MkRules so it had the the locally > > correct paths to HTML Help Workshop and Inno Setup 5. I also set > > USE_SVNVERSION=yes, as suggested in MkRules itself. Then, while in > > the directory src/gnuwin32 I ran 'make all recommended' and got an > > error from windres very early in the build: > > > > E:\R\R-svn\r-devel\src\gnuwin32>make all recommended > > make --no-print-directory -C front-ends Rpwd > > make -C ../../include -f Makefile.win version > > make Rpwd.exe > > gcc -std=gnu99 -I../../include -O3 -Wall -pedantic -c rpwd.c -o rpwd.o > > windres --preprocessor="gcc -E -xc -DRC_INVOKED" -i rcico.rc -o rcico.o > > c:\Rtools\MinGW\bin\windres.exe: rcico.rc:9: syntax error > > make[3]: *** [rcico.o] Error 1 > > make[2]: *** [Rpwd] Error 2 > > make[1]: *** [front-ends/Rpwd.exe] Error 2 > > make: *** [all] Error 2 > > > > Line 9 of src\gnuwin32\front-ends\rcico.rc is > > FILEVERSION R_FILEVERSION > > The problem was that my change to MkRules caused 'svnversion' to put an > > 'M' (modified) on the end of the svn version it reports. This svn > > version number is used in the R_FILEVERSION macro, which is used in in > > the *.rc files. The resource file compiler, windres, appears to choke on > > non-digits in R_FILEVERSION. (A comment in tools\GETVERSION indicates > > it might choke on leading 0's as well.) > > > > svnversion can also output a string of the form "123:125" > > to mean the current source is from a variety of svn revisions, > > between 123 through 125. An "M" or "S" may also be appended. > > If you don't have Subversion installed then you might get > > a svn version of "unknown". None of these non-digits is > > acceptble to windres. > > > > I patched tools/GETVERSION to fix up this problem. It removes > > the trailing M or S and removes anything up to an including a > > colon, so it reports the highest version in the range. If there > > are still non-digits in there it makes the version string "0" > > (not useful, but doesn't kill the build with a noninformative > > error message). > > > > I ran into another problem with the trailing 'M' from svnversion > > when doing 'make rinstaller' in R_HOME/src/gnuwin32: > >E:\R\R-svn\r-devel\src\gnuwin32\installer>type R-2.8.0dev.log > >Inno Setup 5 Command-Line Compiler > >... > >Compiler engine version: Inno Setup 5.2.3 (ISPP 5.2.3.0) > >... > >[ISPP] Preprocessing. > >... > >[ISPP] Preprocessed. > >Parsing [Setup] section, line 10 > >... > >Parsing [Setup] section, line 20 > >Error on line 12 in e:\R\R-svn\r-devel\src\gnuwin32\installer\R.iss: > > Value of > > [Setup] section directive "VersionInfoVersion" is invalid. > >Compile aborted. > > The offending line 12 in R.iss is > > 12 VersionInfoVersion=2.8.0.45381M > > and it is put there by src/gnuwin32/installer/JRins.pl. > > > > I patched JRins.pl to ensure the svn revision consisted > > of only digits. > > > > Then I could build R on Windo
Re: [Rd] build packages with vignettes in Windows
On Tue, Apr 29, 2008 at 4:00 PM, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > On 29/04/2008 2:51 PM, Gabor Grothendieck wrote: > > The use of the UNIX find command on Windows makes installation > > very troublesome and fragile. I wonder if you could include a > > find2 or somesuch with the tools and change the scripts to use that > > getting rid of find or use just use the Windows find command in the > > scripts. Or some other solution so that one does not have to have > > a non-Windows find on the PATH. > > > > Find isn't unique: there are lots of versions of make, and grep, and tar > that don't work, either. We've adopted a simple solution, and it works: It only works if you are very careful and actually it doesn't work because it does not preserve Windows functionality for other programs. > when you're using the R tools, put them first on the path. That's not comparable because find comes with Windows whereas those other programs you mention are addons. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] reproducible segmentation fault caused by textConnection()
If you call gctorture(TRUE) the error happens immediately,
at the same place.
2064PROTECT(tmp = lengthgets(this->data, ++this->len));
Is this a case where PROTECT_WITH_INDEX() and REPROTECT()
need to be used (in connections.c)? Could lengthgets (used
by the SET_LENGTH() macro) be changed to propogate the protection
status? It looks like it always requires protection tricks
to use.
Bill
On Tue, 29 Apr 2008, Bill Dunlap wrote:
> On Tue, 29 Apr 2008, Gregoire Pau wrote:
>
> > Dear all,
> >
> > It seems that textConnection() can trigger a segmentation fault. The
> > following script (using two large loops) makes this bug reproducible:
> >
> > for (i in 1:1) {
> >z=textConnection(NULL,open='w')
> >for (j in 1:100) {
> > write(runif(1)*1e6,file=z)
> > write('\n',file=z)
> >}
> >close(z)
> > }
> >
> > The bug could be reproduced on R-2.6.1, R-2.7.0 and on the latest
> > R-devel 2008-04-29 r45543.
>
> valgrind shows that it uses freed memory after
> a garbage collecting episode (after many iterations),
> because a Routtextconn's 'data' component was freed:
>
>==24210== Invalid read of size 1
>==24210==at 0x810B328: Rf_lengthgets (Rinlinedfuns.h:358)
>==24210==by 0x8121C48: text_vfprintf (connections.c:2064)
>==24210==by 0x809D0C1: Rvprintf (printutils.c:770)
>==24210==by 0x809D105: Rprintf (printutils.c:668)
>==24210==by 0x810A984: do_cat (builtin.c:617)
>==24210== Address 0x5823CD8 is 0 bytes inside a block of size 1,176 free'd
>==24210==at 0x40052A3: free (vg_replace_malloc.c:233)
>==24210==by 0x805AC3D: R_gc_internal (memory.c:769)
>==24210==by 0x805B873: Rf_cons (memory.c:1757)
>==24210==by 0x81571F6: Rf_promiseArgs (eval.c:1633)
>
>(gdb) where 5
>#0 Rf_lengthgets (x=0x5823cd8, len=289)
>at ../../src/include/Rinlinedfuns.h:358
>#1 0x08121c49 in text_vfprintf (con=0x500f280, format=0x81e64d8 "\n",
> ap=0xbef18b84 "?\213??") at connections.c:2064
>#2 0x0809d0c2 in Rvprintf (format=0x81e64d8 "\n", arg=0xbef18b84
> "?\213??")
>at printutils.c:770
>#3 0x0809d106 in Rprintf (format=0x81e64d8 "\n") at printutils.c:668
>#4 0x0810a985 in do_cat (call=0x4ae31f0, op=0x4104eec, args=0x55bb2bc,
>rho=0x55baf20) at builtin.c:617
>(More stack frames follow...)
>(gdb) up
>#1 0x08121c49 in text_vfprintf (con=0x500f280, format=0x81e64d8 "\n",
>ap=0xbef18b84 "?\213??") at connections.c:2064
>2064PROTECT(tmp = lengthgets(this->data, ++this->len));
>(gdb) print this->data
>$1 = 0x5823cd8
>(gdb) whatis this
>type = Routtextconn
>(gdb) whatis this->data
>type = SEXP
>(gdb) print *this->data
>$2 = {sxpinfo = {type = 16, obj = 0, named = 2, gp = 0, mark = 0, debug =
> 0,
> trace = 0, spare = 0, gcgen = 0, gccls = 7}, attrib = 0x40ae088,
> gengc_next_node = 0x8235270, gengc_prev_node = 0x8235270, u = {primsxp =
> {
> offset = 288}, symsxp = {pname = 0x120, value = 0x0,
> internal = 0x57685c0}, listsxp = {carval = 0x120, cdrval = 0x0,
> tagval = 0x57685c0}, envsxp = {frame = 0x120, enclos = 0x0,
> hashtab = 0x57685c0}, closxp = {formals = 0x120, body = 0x0,
> env = 0x57685c0}, promsxp = {value = 0x120, expr = 0x0,
> env = 0x57685c0}}}
Bill Dunlap
Insightful Corporation
bill at insightful dot com
360-428-8146
"All statements in this message represent the opinions of the author and do
not necessarily reflect Insightful Corporation policy or position."
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: What should ?foo do?
> "DM" == Duncan Murdoch <[EMAIL PROTECTED]>
> on Sat, 26 Apr 2008 17:21:06 -0400 writes:
DM> On 25/04/2008 2:47 PM, Prof Brian Ripley wrote:
>> On Fri, 25 Apr 2008, Deepayan Sarkar wrote:
>>
>>> For what it's worth, I use ?foo mostly to look up usage of functions
>>> that I know I want to use, and find it perfect for that (one benefit
>>> over help() is that completion works for ?). The only thing I miss is
>>> the ability to do the equivalent of help("foo", package = "bar");
>>> ?bar::foo gives the help page for "::". Perhaps that would be
>>> something to consider for addition.
>>
>> That fits most naturally with the (somewhat technical) idea that
bar::foo
>> becomes a symbol and not a function call. I believe that several of
think
>> that is in principle a better idea, but no one has as yet (AFAIK)
explored
>> the ramifications.
>>
>> However, 5 mins looking at the sources suggests that it is easy to do.
DM> And you already did. Thanks!
indeed.
DM> I'm going to make the following change soon (in R-devel).
DM> ??foo
DM> will now be like help.search("foo"). This will work with your change,
DM> so ??utils::foo will limit the search to the utils package. This is
DM> also quite easy. A more difficult thing I'd like to do is to broaden
DM> the search to look outside the man pages, but that's a lot harder, and
I
DM> haven't started on it.
DM> I will also follow Hadley's suggestion and change the format of the
DM> help.search results, so you can just cut and paste after a question
mark
DM> to look up the particular topic, e.g. ??foo gives
DM> utils::citEntry Writing Package CITATION Files
DM> Type '?PKG::FOO' to inspect entry 'PKG::FOO TITLE'.
DM> I haven't touched the case of ?foo failing; I'll want to try it for a
DM> while to decide whether I like it best as is:
>> ?foo
DM> No documentation for 'foo' in specified packages and libraries:
DM> you could try '??foo'
DM> or whether it should just automatically call help.search, or something
DM> in between.
Please the former, at least by default!
[The case of 1500 installed packages was mentioned before...]
Note one thing that hasn't been mentioned before:
help() has had the optional argument
' try.all.packages = getOption("help.try.all.packages") '
for many years now, and I have been involved in its history as
well but don't recall all details. IIRC,
help() {and hence "?"} used to *default* to
'try.all.packages = TRUE' for a while and later it was the
default for me (and our whole statistics departmental unit).
But we found that it *was* inconvenient that a big search was
started, often just because of a typo.
So I think ? should ``answer quickly'' by
default.
Martin Maechler
DM> Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
