[Rd] Hyball in R? (Factor analysis & exploratory SEM)

[Chris]

Dear all,

Hyball is a free, DOS program for factor analysis and exploratory
structural equation modeling (SEM), with some distinct capabilities. For
a brief introduction and overview see
 http://www.psych.ualberta.ca/~rozeboom/READHYBL.TXT
(A list of more formal references is at the end of this e-mail.)
The program itself is available from
 http://www.psych.ualberta.ca/~rozeboom/

The program was developed by Bill Rozeboom, and I recently inquired if
he had ever considered translating it into an application package for R.
He informed me that he is retired, and can no longer manage new
adaptations of Hyball. So I am writing the list to see if anyone else is
interested in such a project? (Perhaps some of the individuals who
developed the existing factor analysis and/ or SEM packages in R?) All
of the source code, written in Lahey LF90 Fortran, can be obtained by
downloading and unpacking the HYPAK.EXE file --a self-extracting
ZIP-file-- from the above url. (The source code will be in the files
with extension FOR.)

For those of you wondering why I am not undertaking this project, the
answer is quite simple: Because it is far beyond my capabilities. To
paraphrase an old Dilbert cartoon, I wasted my college years drinking
beer and studying psychology, instead of something useful like computer
science ;-)
Bill however, says that he could be of some limited assistance.

If any one is interest, please let either me  or
Bill know. Again, the program files can be obtained from Bill's website.
If you encounter problems downloading the HYPAK.EXE file, let me know
and I can try to e-mail you a copy. I can also provide copies of the
articles listed below, in the form of .pdf files.

Thank you.

Chris


References
Rozeboom, W. W. (1991a). Hyball: A method for subspace-constrained 
factor rotation. Multivariate Behavioral Research, 26 (1), 163-177.
Rozeboom, W. W. (1991b). Theory and practice of analytic hyperplane 
optimization. Multivariate Behavioral Research, 26 (1), 177-197.
Rozeboom, W. W. (1992). The glory of suboptimal factor rotation: Why 
local minima in analytic optimization of simple structure are more blessing 
than curse. Multivariate Behavioral Research, 27 (4), 585-599.
Rozeboom, W. W. (2000, October). Rotation to recover factors lacking 
pure indicators. Paper presented at the annual meeting of the Society of 
Multivariate Experimental Psychology (SMEP).
Rozeboom, W. W. HYBLOCK: A routine for exploratory factoring of 
block-structured data. Unpublished Manuscript. [Included in the Hyball package 
in as .PDF file.]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] vignette("introduction") causes "Error in sprintf(" (PR#9069)

[chris]

Full_Name: Chris Evans
Version: 2.3.1
OS: Windoze XP
Submission from: (NULL) (217.34.100.197)


If I give "vignette("introduction")" I get: 
  Error in sprintf(gettext(fmt, domain = domain), ...) : 
use format %s for character objects

vignette() works for some other vignettes and "vignette()" gets me a list of
vignettes and shows three with the name "introduction" (on my package
collection).  I don't know if that's related to this.  

Happy to try anything you want done (except perhaps trying to install the
bleeding edge version of R!)

Chris

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] floating point control on windows

[Chris Paulse]

Hi,

I'm sure that this question has come up many times before.  When I load an R
extension dll I've built with the Microsoft compiler, I get the warning:

 

Warning message:

DLL attempted to change FPU control word from 8001f to 9001f

 

So, what I did to try to fix the problem (to my knowledge, Microsoft will
not support compile time switching of floating point control until version
8.0 of their compiler - see: http://blogs.msdn.com/ericflee) was to place
the following statement inside R_init_mylib:

 

 

_controlfp(_MCW_PC, _PC_64); // use extended precision for operations in x87
FPU

 

This didn't fix my problem.  I ended up sprinkling these liberally
throughout my code, but that didn't help.  One thing I do like about the
Microsoft compiler is the debugging facility.  But, I'll definitely switch
to gcc if this is necessary to get rid of the problem.

 

Thanks,

Chris Paulse

 

 


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] floating point control on windows

[Chris Paulse]

Thanks for the guidance.

Using the following code fixed my problem:

#ifdef _WIN32
BOOL APIENTRY DllMain( HANDLE hModule, 
   DWORD  ul_reason_for_call, 
   LPVOID lpReserved
 )
{
if (ul_reason_for_call == DLL_PROCESS_ATTACH)
{
Rwin_fpset();
}

return TRUE;
}
#endif

-Original Message-
From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] 
Sent: Monday, August 29, 2005 10:53 AM
To: Chris Paulse
Cc: r-devel@r-project.org
Subject: Re: [Rd] floating point control on windows

We recommend calling Rwin_fpset() which is exported by R.dll and is known
to do the trick.  As it contains

 _controlfp(_PC_64, _MCW_PC);

it may be that the args you used are incorrect (and I am not on Windows 
to check the docs, but note that is the form used in the URL you cite).

On Mon, 29 Aug 2005, Chris Paulse wrote:

> Hi,
>
> I'm sure that this question has come up many times before.  When I load an
R
> extension dll I've built with the Microsoft compiler, I get the warning:

> Warning message:
>
> DLL attempted to change FPU control word from 8001f to 9001f
>
> So, what I did to try to fix the problem (to my knowledge, Microsoft will
> not support compile time switching of floating point control until version
> 8.0 of their compiler - see: http://blogs.msdn.com/ericflee) was to place
> the following statement inside R_init_mylib:

> _controlfp(_MCW_PC, _PC_64); // use extended precision for operations in
x87
> FPU
>
> This didn't fix my problem.  I ended up sprinkling these liberally
> throughout my code, but that didn't help.  One thing I do like about the
> Microsoft compiler is the debugging facility.  But, I'll definitely switch
> to gcc if this is necessary to get rid of the problem.

-- 
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] indicating progress in RGui from a c function

[Chris Paulse]

Hi,

I'm sure this issue has come up before, but searching the archives didn't
lead me to a solution or resolution of the issue.

 

I'd like to indicate progress of a calculation from within a C shared
library to the R GUI.  The apparent function call is flush.console() after
RPrintf, but it isn't clear to me what the easiest way to do this is.  Would
it be possible to add a flag to RPrintf to have this done implicitly?

 

Thanks,

chris


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Rserve setSEXP command

[Chris Burke]

Can any valid SEXP expression be given in the setSEXP command?

I tried to send a numeric matrix by including the dim attribute with the
data, but get an error code 68 (some parameters are invalid). Is the dim
attribute not supported by setSEXP? If so, does this mean a matrix
should be sent as a list, then a dim command sent in a second step?

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Rserve setSEXP command

[Chris Burke]

Simon Urbanek wrote:
>> Can any valid SEXP expression be given in the setSEXP command?
>>
>> I tried to send a numeric matrix by including the dim attribute  with
>> the data, but get an error code 68 (some parameters are  invalid). Is
>> the dim attribute not supported by setSEXP? If so,  does this mean a
>> matrix should be sent as a list, then a dim  command sent in a second
>> step?
> 
> 
> It's a combination of a bug and missing feature. The bug is that the 
> attribute of an expression is not decoded at all. The missing feature 
> is that (dotted-pair) lists are not supported in decode, so you can't 
> pass an attribute anyway, because they are stored in dotted-pair  lists.
> So, for now, yes, you have to assign the names in a separate  step -
> I'll need to fix that ... I'll keep you posted.

Hi Simon

Thanks for the quick response.

A couple of other things I noticed:

1. It would be useful to support the complex datatype. I suspect this
would be straightforward for Rserve and it would be up to the client to
make proper use of it.

2. The documentation and behaviour when sending character strings could
be improved. For example, suppose the character string is 'abcde'. You
need to send the length, but is the length 5 (=number of characters), 6
(5 + the zero character), or 8 (actual length of transmitted data
rounded to 4 byte boundary?

I had expected it to be 8, which is the length of data the programmer
needs to pick up, before moving on to the next block. The character
string would then be read up to the first 0. Actually, if you give a len
of 8, then:

  CMD_setSEXP 'var';'abcde'

assigns the value as in:

  var=c("abcde","","")

This means that the two additional zeros that are padding, are
interpreted as empty strings. So in practice, a len of 6 is needed (i.e.
length of string plus the zero character).

It is probably worth documenting which is correct, and also, for
zero-terminated strings, always reading them up to the first zero only,
and discarding the rest.

Incidentally, this is for the XT_STR expression. For DT_STR, lengths of
either 6 or 8 work correctly.

Great program, by the way.

Chris

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Bug 17432 in readLines with R >= 3.5.0 still a problem

[Chris Culnane]

Bug 17432 (https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17432) is still 
a problem when using pipes for IPC. 

The bug is evident when calling R from another process and trying to 
communicate via StdIn. R will buffer the input and not read lines until the 
buffer is exceeded or StdIn is closed by the sending process. This prevents 
interactive communication between a calling process and a child R process. 

>From a quick look at the source code, it looks like the bug is caused by only 
>disabling buffering when isatty() returns true for a file descriptor 
>(connections.c). This fixes the original bug when the script is run in a 
>terminal, but doesn't help for pipes, which will return false for isatty().

An example R script and python script are provided to demonstrate the problem:

R script (example.r):

f <- file("stdin")
open(f)
while(length(line <- readLines(f,n=1)) > 0) {
  write(line, stderr())
}

Python3 script:

import sys, os, subprocess
process = subprocess.Popen(['Rscript', 'example.r'], stdin=subprocess.PIPE, 
stdout=subprocess.PIPE)
for line in sys.stdin:
process.stdin.write((line + '\n').encode('utf-8'))
process.stdin.flush()


Expected Behaviour:
Run python script, each line entered is echoed back immediately by the R script 
- which is what happens on 3.4.4

Observed Behaviiour on >=3.5.0 (include devel):
The R script does not process lines as they are sent, it only receives them 
when StdIn is closed.


Best Regards

Chris 

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] R with ATLAS avoids Linux cpu affinity

[Chris Jewell]

Hi all,

I have a problem with cpu affinity in my R-2.11.1 installation compiled against 
ATLAS running on a Linux (Ubuntu 10.04) cluster under GridEngine.  I wish to 
use Grid Engine's core binding feature to bind user processes into the number 
of cores they request on the cluster, thus preventing badly behaved 
multi-threaded libraries from consuming more cores than requested.  An example 
of this is R compiled against multithreaded ATLAS, which needs to be bound into 
a single core if a user submits a 1 core job.  Grid Engine achieves this 
through the sched_setaffinity system call under Linux 2.6.  For most 
applications (including if I write a test C program that uses ATLAS BLAS), this 
works well, and prevents threads from 'leaking' outside the cpu set they are 
assigned.  However, R appears to be able to avoid the core binding.  This is 
*very* strange as I was under the impression that any child processes or 
threads inherit the cpu affinity of the parent.

Does anyone have experience of this and could offer a comment or solution?

Thanks,

Chris

--
Dr Chris Jewell
Department of Statistics
University of Warwick
Coventry
CV4 7AL
UK
Tel: +44 (0)24 7615 0778

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R with ATLAS avoids Linux cpu affinity

[Chris Jewell]

On 6 Dec 2010, at 16:03, Dirk Eddelbuettel wrote:
> AFAICT R should not alter CPU affinity.  So if I were you I'd swap the BLAS
> implementation and try again.  As you are on Ubuntu, you can try the MKL that
> comes with the (now a littler older) Revolution R in Ubuntu 9.10; otherwise I
> can highly recommend the GotoBLAS2 helper package listed in my paper for a
> local GotoBLAS2 built.   The script may be out of sync with the fairly recent
> license change of GotoBLAS2 (to the more liberal BSD license permitting
> redistribution).  With some luck we will GotoBLAS2 deb packages in future
> Debian and Ubuntu releases.


Thanks for the comments, Dirk.  I take your point about ATLAS having the cores 
compiled in.  I have replaced ATLAS with ACML, and all works fine.

Cheers,

Chris


--
Dr Chris Jewell
Department of Statistics
University of Warwick
Coventry
CV4 7AL
UK
Tel: +44 (0)24 7615 0778

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] please apply my patches

[Chris Smowton]

Agreed regarding read line-- absent mindedly using C-c to exit a search and
then accidentally running garbage because the prompt looks blank but isn't
continues to be a problem.
On 17 May 2016 2:41 a.m.,  wrote:

Dear R Devel,

Sorry for sending so many emails, but I haven't heard that anyone is
working on the patches I created.

A few weeks ago I wanted to do something to contribute to R because I
use it a lot. I picked the most annoying bugs I could find, and
created two of the simplest patches I could create, but all I've had
in response from the R core team (aside from briefly banning my
Bugzilla account) is a lengthy explanation for why power users don't
use the basic command line interface. I'm grateful to Peter for the
list of tools like ESS that people use to interface with R; but if I
wanted to submit a bug to ESS then I would have sent it to a different
mailing list.

Thank you Göran for confirming that you experience these bugs. I've
Cc'ed two other users, Chris Smowton and "Terran", who commented on
the Bugzilla bugs. Do you guys want to weigh in on the relative
importance of getting these fixed?

Nobody asked me to describe the patches in more detail, but I'll give
a brief summary in case it helps: One of my patches adds a signal
handler for SIGWINCH (which GNU Readline stopped handling a few years
ago without telling anyone). There is no other use of SIGWINCH in the
R code so I don't think this will cause problems. This makes
terminal-resizing possible. The other one adds some additional cleanup
to popReadline. Now, popReadline is called every time a command is
entered at the prompt, or when R catches SIGINT, to reset the terminal
settings and take control back from Readline. My second patch fixes
incremental-search by amending popReadline to clear the line state as
well. I invite creative suggestions as to how these might lead to
unforeseen trouble for Unix or non-Unix users - what I might have
missed in my testing, etc.

Otherwise, I would appreciate some kind of real input as to what I
should do or who I should contact to get this rolling. We're all short
on time; if we can get this taken care of quickly and efficiently then
we'll have more time left for other stuff.

Thank you,

Frederick


On Fri, May 13, 2016 at 10:02:54AM +0200, Göran Broström wrote:
> Dear Frederik,
>
> I can confirm that especially the first issue on your list (resizing the
> terminal) has "bothered me" badly for some time now: I'm on Ubuntu
> (usually).
>
> Göran Broström
>
>
> On 2016-05-13 00:23, frede...@ofb.net wrote:
> > Hi Peter, Martin, and others,
> >
> > Thanks for your replies.
> >
> > - The bugs apply to all systems that use GNU Readline, not just Linux
> >or Arch Linux.
> >
> > - Readline version 6.3 changed the signal handling so that SIGWINCH is
> >no longer handled automatically by the library. This means it's not
> >currently possible for people using R on e.g. Linux to resize the
> >terminal, or at least when they do so they have to make sure that
> >all their commands fit in one line and don't wrap.
> >
> > - There is also a long-standing bug in Readline where the callback
> >interface didn't properly clear the line on SIGINT (^C). This means
> >that "exiting" reverse-incremental-search with ^C would give an
> >apparently empty prompt which still had some pending input, so if
> >you hit ^C-Return then an unintended command would get executed.
> >
> > If they're not "bothering all that many people", then perhaps it's
> > because everyone uses Windows or Mac OS X or RStudio. For me these are
> > pretty significant bugs. The second one causes unintended code to be
> > executed. Random code could delete files, for example, or worse. The
> > first one bites me every time I want to change the size of a window,
> > which is pretty often.
> >
> > I tried to get Readline maintainer Chet Ramey to fix these on the
> > Readline side, but he disagreed with my proposal:
> >
> > https://lists.gnu.org/archive/html/bug-readline/2016-04/threads.html
> >
> > I'm glad that my message here at least was seen and I hope that
> > someone who uses the R command line on Linux will have time to verify
> > that the patches work correctly. They are basically Chet-approved
> > workarounds for bugs/changes in Readline, not very complicated.
> >
> > Do either of you know a Linux R person you could ping to get these
> > patches checked out? I'm not overly frustrated, and I'm not in a major
> > hurry, but from what we've observed it seems like waiting for someone
> > concerned to come a

[Rd] v3.4.0-2 incompatible with gcc 7.1

[Chris Cole]

I'm on Arch Linux kernel version 4.11.6-1 using gcc version 7.1.1:

gcc --version
gcc (GCC) 7.1.1 20170516

I have installed R through the arch package manager pacman and when I
attempt to initiate it, R crashes stating a missing dependency:

/usr/lib64/R/bin/exec/R: error while loading shared libraries:
libgfortran.so.3: cannot open shared object file: No such file or directory

I thought that maybe a symlink was improperly placed in the package so I
looked in /usr/lib to try to find the offending library.

ls -halt /usr/lib/libgfortran.so.*
lrwxrwxrwx 1 root root 20 May 16 03:01 /usr/lib/libgfortran.so.4 ->
libgfortran.so.4.0.0
-rwxr-xr-x 1 root root 7.1M May 16 03:01 /usr/lib/libgfortran.so.4.0.0

Simply symlinking libgfortran.so.4.0.0 to libgfortran.so.3 did not work,
and after some questioning on SO (
https://stackoverflow.com/questions/44658867/r-v3-4-0-2-unable-to-find-libgfortran-so-3-on-arch)
it seems that gfortran 7 has bumped the .so object to version 4.

It seems that a relatively straightforward workaround for the present would
be to install a legacy version of gcc alongside the current version.

I'm wondering if Rcore or Rdevel are moving towards being able to handle
the new compiler version any time soon, and if there are any other
workarounds than having two versions of the compiler.

Thanks.

Chris

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] v3.4.0-2 incompatible with gcc 7.1

[Chris Cole]

Thank you for correcting my misunderstandings, Professor. Compiling from
source did the trick, and I'll be following up with the arch maintainers
about addressing the issue on their end.

Best,

Chris

On Fri, 23 Jun 2017 at 11:02 Prof Brian Ripley 
wrote:

> R is compatible with GCC 7.1 !  New compiler versions are tested, as
> well as those under development for the major compilers.  (A few
> packages still fail with GCC 7.1, but that was reported to their
> maintainers months ago.)
>
> Just follow the instructions in the R-admin manual to install from sources.
>
> OTOH, ' v3.4.0-2 ' is not an R version number, so I think you are
> referring to binary distributions on your Linux distro, which are not
> the responsibility of 'Rcore or Rdevel' (whatever they are).
>
> On 23/06/2017 14:40, Chris Cole wrote:
> > I'm on Arch Linux kernel version 4.11.6-1 using gcc version 7.1.1:
> >
> > gcc --version
> > gcc (GCC) 7.1.1 20170516
> >
> > I have installed R through the arch package manager pacman and when I
> > attempt to initiate it, R crashes stating a missing dependency:
> >
> > /usr/lib64/R/bin/exec/R: error while loading shared libraries:
> > libgfortran.so.3: cannot open shared object file: No such file or
> directory
> >
> > I thought that maybe a symlink was improperly placed in the package so I
> > looked in /usr/lib to try to find the offending library.
> >
> > ls -halt /usr/lib/libgfortran.so.*
> > lrwxrwxrwx 1 root root 20 May 16 03:01 /usr/lib/libgfortran.so.4 ->
> > libgfortran.so.4.0.0
> > -rwxr-xr-x 1 root root 7.1M May 16 03:01 /usr/lib/libgfortran.so.4.0.0
> >
> > Simply symlinking libgfortran.so.4.0.0 to libgfortran.so.3 did not work,
> > and after some questioning on SO (
> >
> https://stackoverflow.com/questions/44658867/r-v3-4-0-2-unable-to-find-libgfortran-so-3-on-arch
> )
> > it seems that gfortran 7 has bumped the .so object to version 4.
> >
> > It seems that a relatively straightforward workaround for the present
> would
> > be to install a legacy version of gcc alongside the current version.
> >
> > I'm wondering if Rcore or Rdevel are moving towards being able to handle
> > the new compiler version any time soon, and if there are any other
> > workarounds than having two versions of the compiler.
> >
> > Thanks.
> >
> > Chris
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>
> --
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> Emeritus Professor of Applied Statistics, University of Oxford
>
> __
> 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] v3.4.0-2 incompatible with gcc 7.1

[Chris Cole]

Thanks Ista, that's good to know. Did you install from pacman?

Chris

On Fri, 23 Jun 2017 at 20:35 Ista Zahn  wrote:

> FWIW, I don't have any problems with R on Arch Linux.
>
> On Jun 23, 2017 1:32 PM, "Chris Cole"  wrote:
>
>> Thank you for correcting my misunderstandings, Professor. Compiling from
>> source did the trick, and I'll be following up with the arch maintainers
>> about addressing the issue on their end.
>>
>> Best,
>>
>> Chris
>>
>> On Fri, 23 Jun 2017 at 11:02 Prof Brian Ripley 
>> wrote:
>>
>> > R is compatible with GCC 7.1 !  New compiler versions are tested, as
>> > well as those under development for the major compilers.  (A few
>> > packages still fail with GCC 7.1, but that was reported to their
>> > maintainers months ago.)
>> >
>> > Just follow the instructions in the R-admin manual to install from
>> sources.
>> >
>> > OTOH, ' v3.4.0-2 ' is not an R version number, so I think you are
>> > referring to binary distributions on your Linux distro, which are not
>> > the responsibility of 'Rcore or Rdevel' (whatever they are).
>> >
>> > On 23/06/2017 14:40, Chris Cole wrote:
>> > > I'm on Arch Linux kernel version 4.11.6-1 using gcc version 7.1.1:
>> > >
>> > > gcc --version
>> > > gcc (GCC) 7.1.1 20170516
>> > >
>> > > I have installed R through the arch package manager pacman and when I
>> > > attempt to initiate it, R crashes stating a missing dependency:
>> > >
>> > > /usr/lib64/R/bin/exec/R: error while loading shared libraries:
>> > > libgfortran.so.3: cannot open shared object file: No such file or
>> > directory
>> > >
>> > > I thought that maybe a symlink was improperly placed in the package
>> so I
>> > > looked in /usr/lib to try to find the offending library.
>> > >
>> > > ls -halt /usr/lib/libgfortran.so.*
>> > > lrwxrwxrwx 1 root root 20 May 16 03:01 /usr/lib/libgfortran.so.4 ->
>> > > libgfortran.so.4.0.0
>> > > -rwxr-xr-x 1 root root 7.1M May 16 03:01 /usr/lib/libgfortran.so.4.0.0
>> > >
>> > > Simply symlinking libgfortran.so.4.0.0 to libgfortran.so.3 did not
>> work,
>> > > and after some questioning on SO (
>> > >
>> >
>> https://stackoverflow.com/questions/44658867/r-v3-4-0-2-unable-to-find-libgfortran-so-3-on-arch
>> > )
>> > > it seems that gfortran 7 has bumped the .so object to version 4.
>> > >
>> > > It seems that a relatively straightforward workaround for the present
>> > would
>> > > be to install a legacy version of gcc alongside the current version.
>> > >
>> > > I'm wondering if Rcore or Rdevel are moving towards being able to
>> handle
>> > > the new compiler version any time soon, and if there are any other
>> > > workarounds than having two versions of the compiler.
>> > >
>> > > Thanks.
>> > >
>> > > Chris
>> > >
>> > >   [[alternative HTML version deleted]]
>> > >
>> > > __
>> > > R-devel@r-project.org mailing list
>> > > https://stat.ethz.ch/mailman/listinfo/r-devel
>> > >
>> >
>> >
>> > --
>> > Brian D. Ripley,  rip...@stats.ox.ac.uk
>> > Emeritus Professor of Applied Statistics, University of Oxford
>> >
>> > __
>> > 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
>>
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Problem with a regular expression.

[Chris Triggs]

Hi...

I have come upon a problem with a regular expression which causes base-R to 
freeze.  I have reproduced the phenomenon on several machines running R under 
Windows 10, and also under OSX  on different Apple MACs.

The minimal example is:-
Oldterm is a vector of characters, e.g. "A", "B", "A", "*", "B"
The regular expression is ")"

The call which freezes R is
strsplit(Oldterm, ")" )

Thomas - after he had reproduced the problem - suggested that I submit it to 
r-devel.

Best wishes
   Chris Triggs


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Possible bug(s) causing ggplot2 and XLConnect to crash recent builds of r-devel

[Chris Brien]

The following R code causes R to crashes under recent r-devel builds of R: 

library(ggplot2)
RCBD.lay <- data.frame(Blocks = factor(rep(1:5, each = 6)), 
   Units = factor(rep(1:6, times = 5)),
   Treatments = factor(rep(1:6, times = 5)))
ggplot(data = RCBD.lay, aes(x = Units, y = Blocks, label = Treatments)) +
  geom_text(aes(colour = Treatments))

I have installed and am running R on a Windows 10 machine with Rtools34.exe 
installed. I am using RStudio version 1.1.383

This bug happens with combined Windows 32/64 bit binary builds of the 
2017-11-11 r73707 and 2017-11-14 r73724 development snapshot of R. It does not 
occur under the build of the 2017-06-27 r72859 development snapshot of R.

I installed the latest build with an empty R library tree " D:/Analyses/R 
LibDevel". 

> .libPaths()
[1] "D:/Analyses/R LibDevel" 
[2] "C:/Program Files/StatSoft/R/R-devel.724/library"

I installed package ggplot2 and its dependencies from CRAN using RStudio. As a 
result the following 20 packages were the only packages installed in the 
previously empty library tree:

"colorspace","dichromat","digest","ggplot2","gtable","labeling","lazyeval",
  
"magrittr","munsell","plyr","R6","RColorBrewer","Rcpp","reshape2","rlang","scales",
  "stringi","stringr","tibble","viridisLite"

I then executed the above code in the Console window of Rstudio (running 64 bit 
R) and received the message "R Session aborted" with the information that "R 
encountered a fatal error".

I also started the RGui for the 64-bit version and entered the same code into 
the console. The error message displayed in a dialog box was "R Windows GUI 
front-end has stopped working". Closing the dialog box cause RGui to close.

I had a similar experience with the package XLConnect.

Having used remove.packages to remove the ggplot2 and associated packages from 
the library, I installed XLConnect and it dependencies from CRAN from RStudio. 
Now the packages installed in "D:/Analyses/R LibDevel" were: "rJava", 
"XLConnect", "XLConnectJars".

In this case executing library(XLConnect) cause the same response - "R Session 
aborted" with the information that "R encountered a fatal error".

These are not packages that I maintain. However, I have packages (imageData and 
dae) that depend on ggplot2 and it seems that this bug is preventing me from 
compiling the packages under the most recent builds, although I can build the 
packages under the build of the 2017-06-27 r72859 development snapshot of R.

Regards, 

  Chris Brien

Adjunct Senior Lecturer in Statistics
-
Phenomics and Bioinformatics Research Centre
University of South Australia
GPO Box 2471
ADELAIDE  5001  South Australia
Phone:  +61 8 8302 5535   Fax:  +61 8 8302 5785
Email:   chris.br...@unisa.edu.au 
WEB page:  <http://people.unisa.edu.au/Chris.Brien> 
CRICOS No 00121B 

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [EXTERNAL] Re: NOTE: multiple local function definitions for ?fun? with different formal arguments

[Chris Black]

Hopefully to too much of a tangent: A related problem this check doesn’t catch 
is accidental top-level redefinitions in package code, such as

## a.R:
helper <- function() 1

f <- function() {
helper()
}
# “cool, f() must return 1"

## b.R:
helper <- function(x) 2

g <- function() {
helper()
}
# “cool, g() must return 2"

## Runtime: 
# > c(pkg::f(), pkg::g())
# [1] 2 2
# “oh right, only the last definition of helper() is used”
 
I’ve seen several variants of this issue in code from folks who are new to 
package development, especially if they're naively refactoring something that 
started out as an interactively-run analysis. Collaborators who are puzzled by 
it get my “packages are collections of objects not sequences of expressions, 
yes that needs to be in your mental model, here’s the link to RWE again” talk, 
but I would be happy to be able to point them to a check result to go along 
with it.

I don’t think this is grounds on its own to change a 20-year precedent, but in 
case anyone is collecting wishlist reasons to make the check look harder...

Thanks,
Chris

> On Feb 6, 2024, at 3:17 PM, Martin Morgan  wrote:
> 
> I went looking and found this in codetools, where it's been for 20 years
> 
> https://gitlab.com/luke-tierney/codetools/-/blame/master/R/codetools.R?ref_type=heads#L951
> 
> I think the call stack in codetools is checkUsagePackage -> checkUsageEnv -> 
> checkUsage, and these are similarly established. The call from the tools 
> package 
> https://github.com/wch/r-source/blame/95146f0f366a36899e4277a6a722964a51b93603/src/library/tools/R/QC.R#L4585
>  is also quite old.
> 
> I'm not sure this had been said explicitly, but perhaps the original intent 
> was to protect against accidentally redefining a local function. Obviously 
> one could do this with a local variable too, though that might less often be 
> an error…
> 
> toto <- function(mode) {
>tata <- function(a, b) a * b  # intended
>tata <- function(a, b) a / b  # oops
>…
> }
> 
> Another workaround is to actually name the local functions
> 
> toto <- function(mode) {
>tata <- function(a, b) a * b
>titi <- function(u, v, w) (u + v) / w
>if (mode == 1)
>tata
>else
>titi
> }
> 
> … or to use a switch statement
> 
> toto <- function(mode) {
>## fun <- switch(…) for use of `fun()` in toto
>switch(
>mode,
>tata = function(a, b) a * b,
>titi = function(u, v, w) (u + v) / w,
>stop("unknown `mode = '", mode, "'`")
>)
> }
> 
> … or similarly to write `fun <- if … else …`, assigning the result of the 
> `if` to `fun`. I guess this last formulation points to the fact that a more 
> careful analysis of Hervé's original code means that `fun` can only take one 
> value (only one branch of the `if` can be taken) so there can only be one 
> version of `fun` in any invocation of `toto()`.
> 
> Perhaps the local names (and string-valued 'mode') are suggestive of special 
> case, so serve as implicit documentation?
> 
> Adding `…` to `tata` doesn't seem like a good idea; toto(1)(3, 5, 7) no 
> longer signals an error.
> 
> There seems to be a lot in common with S3 and S4 methods, where `toto` 
> corresponds to the generic, `tata` and `titi` to methods. This 'dispatch' is 
> brought out by using `switch()`. There is plenty of opportunity for thinking 
> that you're invoking one method but actually you're invoking the other. For 
> instance with dplyr, I like that I can tbl |> print(n = 2) so much that I 
> find myself doing this with data.frame df |> print(n = 2), which is an error 
> (`n` partially matches `na.print`, and 2 is not a valid value); both methods 
> silently ignore the typo print(m = 2).
> 
> Martin Morgan
> 
> From: R-devel  on behalf of Henrik Bengtsson 
> 
> Date: Tuesday, February 6, 2024 at 4:34 PM
> To: Izmirlian, Grant (NIH/NCI) [E] 
> Cc: r-devel@r-project.org 
> Subject: Re: [Rd] [EXTERNAL] Re: NOTE: multiple local function definitions 
> for ?fun? with different formal arguments
> Here's a dummy example that I think illustrates the problem:
> 
> toto <- function() {
>  if (runif(1) < 0.5)
>function(a) a
>  else
>function(a,b) a+b
> }
> 
>> fcn <- toto()
>> fcn(1,2)
> [1] 3
>> fcn <- toto()
>> fcn(1,2)
> [1] 3
>> fcn <- toto()
>> fcn(1,2)
> Error in fcn(1, 2) : unused argument (2)
> 
> How can you use the returned function, if you get different arguments?
> 
> In your example, you cannot use the returned function without knowing
> 'mode', or

Re: [Rd] specials and ::

[Chris Black]

It’s completely reasonable to decline to do extra work to support it, but at 
the same time: Qualified calls are widely used and recommended, and users are 
also being completely reasonable when they try to use them (probably without 
checking the manual!) and expect them to work.

Would there be a tolerably easy way to make the fit fail loudly on 
`survival::strata(…)` rather than return the wrong result?



> On Aug 26, 2024, at 7:42 AM, Therneau, Terry M., Ph.D. via R-devel 
>  wrote:
> 
> The survival package makes significant use of the "specials" argument of 
> terms(), before 
> calling model.frame; it is part of nearly every modeling function. The reason 
> is that 
> strata argments simply have to be handled differently than other things on 
> the right hand 
> side. Likewise for tt() and cluster(), though those are much less frequent.
> 
> I now get "bug reports" from the growing segment that believes one should put 
> packagename:: in front of every single instance.   For instance
>   fit <- survival::survdiff( survival::Surv(time, status) ~ ph.karno + 
> survival::strata(inst),  data= survival::lung)
> 
> This fails to give the correct answer because it fools terms(formula, 
> specials= 
> "strata").I've stood firm in my response of "that's your bug, not mine", 
> but I begin 
> to believe I am swimming uphill.   One person responded that it was company 
> policy to 
> qualify everything.
> 
> I don't see an easy way to fix survival, and even if I did it would be a 
> tremendous amout 
> of work.   What are other's thoughts?
> 
> Terry
> 
> 
> 
> -- 
> 
> Terry M Therneau, PhD
> Department of Quantitative Health Sciences
> Mayo Clinic
> thern...@mayo.edu
> 
> "TERR-ree THUR-noh"
> 
> [[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] Multiple versions of data in a package

[Chris Wallace]

Dear R-devel,

I am writing for help on how I should include parallel sets of data in 
my package.


Brief summary: I am new to using data within packages.  I want a user to 
be able to specify one of two alternative versions of within-package 
datasets to use, and I want to load just that one.  I have a solution 
that works, but it doesn't seem as simple as it should be from a user's 
point of view, nor does it seem robust to errors.  What should I do better?


More details:

My package is a relatively simple set of plotting functions, that plot 
user supplied data across a number of SNPs from their experiment, and 
annotates the plot using some external data.  For example, the user supplies


SNP value
A 2
B 1.2
C 7.8

etc

The external datasets will allow me to look up the location of SNPs A, 
B, C, ... on the human genome so the user's data can be plotted in 
relation to that map, to annotate the position of local genes etc.  My 
problem is that there is no single map of the genome, so I can prepare 
external data with the positions of SNPs and genes in version 36 or 37.  
To allow this, my data/ directory contains


snps_37.Rdata, snps_36.RData, genes_37.RData, genes_36.RData

the objects in these files are called, respectively,

snps, snps, genes, genes

Therefore, a user types

> data(snps_37)
> data(genes_37)

or

> data(snps_36)
> data(genes_36)

to set up build 36 or build 37 and then my functions need only use the 
object names snps or genes, and all is fine.  But, this doesn't seem 
like a good solution.  What if a user has snps_36 and genes_37 loaded?  
What if they have an object named snps in their working environment 
called snps?  Alternatively, I could load all datasets and they could 
pass an argument "build" to my functions, but these are large datasets, 
and I don't want to use time and memory loading both versions when I 
expect any individual user to pick a single version and stick with it.


Can anyone suggest how else I might proceed?

Thank you,

Chris




--
JDRF/WT Diabetes & Inflammation Laboratory (DIL),
NIHR Cambridge Biomedical Research Centre,
Cambridge Institute for Medical Research,
University of Cambridge

Website:http://www-gene.cimr.cam.ac.uk/staff/wallace
DIL Website:http://www-gene.cimr.cam.ac.uk

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] How to (appropropriately) use require in a package?

[Chris Green]

I am not an expert here, but if it's a package, couldn't (shouldn't?) you
include Package B in one of the Depends: or Imports: lines in the
DESCRIPTION file? That would ensure Package B is automatically made
accessible whenever Package A is loaded. For example, see the Writing R
Extensions manual:

http://cran.fhcrc.org/doc/manuals/r-release/R-exts.html#Package-Dependencies


Chris Green
Ph.D. Student, Statistics
University of Washington, Seattle




On Thu, Aug 7, 2014 at 4:35 PM, Joshua Wiley  wrote:

> Dear All,
>
> What is the preferred way for Package A, to initialize a cluster, and load
> Package B on all nodes?
>
> I am writing a package that parallelizes some functions through the use of
> a cluster if useRs are on a Windows machine (using parLapply and family).
>  I also make use of another package in some of my code, so it is necessary
> to load the required packages on each slave once the cluster is started.
>
> Right now, I have done this, by evaluating require(packages) on each slave;
> however, Rcmd check has a note that I should remove the "require" in my
> code.
>
> Thanks!
>
> Josh
>
> --
> Joshua F. Wiley
> Ph.D. Student, UCLA Department of Psychology
> http://joshuawiley.com/
> Senior Analyst, Elkhart Group Ltd.
> http://elkhartgroup.com
> Office: 260.673.5518
>
> [[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

[Rd] does parLapplyLB do load-balancing?

[Chris Paciorek]

Looking at parLapplyLB, one sees that it takes in X and then passes
splitList(X, length(cl)) to clusterApplyLB, which then calls
dynamicClusterApply.  Thus while dynamicClusterApply does handle tasks
in a load-balancing fashion, sending out individual tasks as previous
tasks complete, parLapplyLB preempts that by splitting up the tasks in
advance into as many groups of tasks as there are cluster processes.
This seems to defeat the purpose of load-balancing and of the manner
in which dynamicClusterApply is coded.

This question basically repeats a question posed in 2013 -- see
http://r.789695.n4.nabble.com/parLapplyLB-Load-balancing-tt4671848.html

I'm reposting because there doesn't seem to have been any response to
the previous posting, and it looks like the issue is still present in
R 3.1 so it seems asking again if this is the intended behavior of
parLapplyLB.

I'm using R 3.1.1 and the 3.1.1 version of the parallel package under
Ubuntu 14.04, but the code appears to be the same in R-devel.


Chris


--
Chris Paciorek

Statistical Computing Consultant
Statistical Computing Facility, Econometrics Laboratory, Berkeley
Research Computing

Office: 495 Evans Hall  Email: pacio...@stat.berkeley.edu
Mailing Address:Voice: 510-842-6670
Department of StatisticsFax:   510-642-7892
367 Evans Hall  Skype: cjpaciorek
University of California, Berkeley  WWW:
www.stat.berkeley.edu/~paciorek
Berkeley, CA 94720 USA  Permanent forward:
pacio...@alumni.cmu.edu

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Inserting and testing revised functions in a package

[Chris Warren]

Thanks, that was helpful in finding a bug in a library I was using, but now I'd
like to run the original code (the revised code is unable to access some of the
functions in the package, apparently, but I think I can work around it by
running and checking the original function). 

How can I recover the original function?  I tried using  
insertSource("SourceFileWithOriginalFunctionCode.R", package = "Package",
functions = "functionOfInterest")

but I run into the same inability to access some the package functions used by
the function.

I also tried reloading but got 

"The following object(s) are masked _by_ ‘.GlobalEnv’:

probtrans"



Thanks for your help,
Chris

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Licensing concerns in porting S-Plus code to R libraries

[Chris Green]

I used S-Plus for many years, and developed lots of code for my research.
When I switched to R a few years ago, I ported most of my S-Plus code over
to R for my own use. Now that some of this code is quite polished, I would
like to make it available as an R package on CRAN.

Some of my S-Plus code, however, was based on Insightful S-Plus functions;
for instance, I took a Trellis function, and modified to suit my needs. In
some cases the modifications are minor (e.g., adding extra functionality,
changing colors), while in other cases I've made substantial changes (e.g.,
a new function that just uses the techniques of the internal function).
Furthermore, in porting the code to R, I of course had to make further
changes (e.g., Trellis functions for lattice/grid functions, new C code to
replace internal S-Plus routines to which I did not have the source code).

I wondering if anyone can provide some guidance here as to what I can
release without running afoul of any user agreement that may have come with
S-Plus long ago. I'm assuming other package developers, especially those
that were S-Plus users long ago, have encountered this issue and can advise
me on what to do.

Many thanks,

Chris Green

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] "Default" accessor in S4 classes

[Chris Jewell]

Hi All,

I'm currently trying to write an S4 class that mimics a data.frame, but stores 
data on disc in HDF5 format.  The idea is that the dataset is likely to be too 
large to fit into a standard desktop machine, and by using subscripts, the user 
may load bits of the dataset at a time.  eg:

> myLargeData <- LargeData("/path/to/file")
> mySubSet <- myLargeData[1:10, seq(1,15,by=3)]

I've therefore defined by LargeData class thus

> LargeData <- setClass("LargeData", representation(filename="character"))
> setMethod("initialize","LargeData", function(.Object,filename) 
> .Object@filename <- filename)

I've then defined the "[" method to call a C++ function (Rcpp), opening the 
HDF5 file, and returning the required rows/cols as a data.frame.

However, what if the user wants to load the entire dataset into memory?  Which 
method do I overload to achieve the following?

> fullData <- myLargeData
> class(fullData)
[1] "data.frame"

or apply transformations:

> myEigen <- eigen(myLargeData)

In C++ I would normally overload the "double" or "float" operator to achieve 
this -- can I do the same thing in R?

Thanks,

Chris

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] "Default" accessor in S4 classes

[Chris Jewell]

Okay, thanks for the input, All.  I'd settled on the explicit coercion 
as.data.frame as well as the myObject[] syntax which makes a lot of sense.  I'd 
also like to implement an as.double() method.  However, I'm having trouble 
embedding this into my package.  In the R file I have:

setMethod("as.double", "HD5Proxy", function(x) as.double(x[]))

and exportMethods(as.double) in my NAMESPACES file.  However, on checking the 
package, I get an error saying that method "as.double" cannot be found.  I 
noticed that the setMethod command actually returns a character vector with 
"as.numeric", so I'm assuming this is the problem.  How do I explicitly export 
my as.double method?

Thanks,

Chris

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Catch SIGINT from user in backend C++ code

[Jewell, Chris]

Hi,

I was wondering if anybody knew how to trap SIGINTs (ie Ctrl-C) in backend C++ 
code for R extensions?  I'm writing a package that uses the GPU for some hefty 
matrix operations in a tightly coupled parallel algorithm implemented in CUDA.

The problem is that once running, the C++ module cannot apparently be 
interrupted by a SIGINT, leaving the user sat waiting even if they realise 
they've launched the algorithm with incorrect settings.  Occasionally, the 
SIGINT gets through and the C++ module stops.  However, this leaves the CUDA 
context hanging, meaning that if the algorithm is launched again R dies.  If I 
could trap the SIGINT, then I could make sure a) that the algorithm stops 
immediately, and b) that the CUDA context is destructed nicely.

Is there a "R-standard" method of doing this?

Thanks,

Chris


--
Dr Chris Jewell
Lecturer in Biostatistics
Institute of Fundamental Sciences
Massey University
Private Bag 11222
Palmerston North 4442
New Zealand
Tel: +64 (0) 6 350 5701 Extn: 3586

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Small patch to packages.R

[Chris Masters]

Very small patch to packages.R

install.packages on an internal package repository that worked with 2.9
failed in 2.10

Problem:
> available.packages(contriburl="http://url.to.my/repo";)
Error in f(res) : invalid subscript type 'list'

This occurred because the PACKAGES file had no dependency on R in the
Depends field on any of the packages. Got around it by adding "Depends: R
(>=2.7.0)" to the packages but it was still a regression from 2.9 behaviour.

Cheers

Chris
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Typo in help(Special) (PR#14111)

[chris . jackson]

There's a typo in the definition of the Gamma function in help(Special)
i.e. the file

src/library/base/man/Special.Rd

Looks like "a" should be replaced by "x" in the equation on line 63:

\deqn{\Gamma(x) = \int_0^\infty t^{a-1} e^{-t} dt}{integral_0^Inf 
t^(a-1) exp(-t) dt}

I checked this is still in current r-patched and r-devel.

Chris



--please do not edit the information below--

Version:
  platform = sparc-sun-solaris2.10
  arch = sparc
  os = solaris2.10
  system = sparc, solaris2.10
  status =
  major = 2
  minor = 10.0
  year = 2009
  month = 10
  day = 26
  svn rev = 50208
  language = R
  version.string = R version 2.10.0 (2009-10-26)

Locale:
/en_GB.ISO8859-1/C/en_GB.ISO8859-1/en_GB.ISO8859-1/C/C

Search Path:
  .GlobalEnv, package:stats, package:graphics, package:grDevices, 
package:datasets, package:utils, package:methods, Autoloads, package:base

-- 
Christopher Jackson 
Research Statistician, MRC Biostatistics Unit, Institute of Public
Health, Robinson Way, Cambridge, UK, CB2 0SR. +44 (1223) 330381

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Package options

[Chris Brien]

Dear all,

I am developing a package foo that has a namespace. I would like to be able to 
provide an option, say opt, that 

1) is set to a default value when the package is loaded
2) can be set to a different value by the package user
3) is used by functions within the package

How can I achieve this?

Cheers,
 
Chris Brien
Adjunct Senior Lecturer in Statistics
-
School of Mathematics & Statistics - Mawson Lakes
Phenomics and Bioinformatics Research Centre
University of South Australia
GPO Box 2471
ADELAIDE  5001  South Australia
Phone:  +61 8 8302 5873   Fax:  +61 8 8302 5785
Email:   chris.br...@unisa.edu.au 
WEB page:  <http://people.unisa.edu.au/Chris.Brien> 
CRICOS No 00121B 

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] rendering dashed steps produces solid horizontal lines (PR#9953)

[chris . bainbridge]

Full_Name: Chris Bainbridge
Version: 2.2.1
OS: Linux
Submission from: (NULL) (86.157.4.96)


The following python script will render two pdf files, one with lines and one
with steps. The pdf with steps (s.pdf) renders the horizontal line as a solid
when it should be dotted as in lpdf. It seems as though R tries to render every
data point individually when using steps, but manages to join them all together
as a straight line when using lines.

#!/usr/bin/python   
  
import os   
  

  
f=open('x.txt','w') 
  
i=0 
  
f.write('x y\n')
  
while i<100:
  
f.write('%f %f\n'%(i,0.5))  
  
i+=1
  
f.close()   
  
rscr="""pdf('%s.pdf')   
  
d <- read.table('x.txt', header=T)  
  
attach(d)   
  
plot(x,y, bty='n', las=1, lty=2,type='%s')  
  
""" 
  
f=open('l.r','w')   
  
f.write(rscr%('l','l')) 
  
f.close()   
  
os.system('R -q --no-save < l.r')   
  
f=open('s.r','w')   
  
f.write(rscr%('s','s')) 
  
f.close()   
  
os.system('R -q --no-save < s.r')

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] failure to find lapply (PR#9999)

[chris . knight]

I have been unable to reproduce this problem but the warning I got told 
me to send a bug report, so here it is.

After a fairly lengthy session, using the ape and ade4 packages, 
conducted via a terminal in kate under kubuntu 6.06 linux , I found 
errors claiming not to find lapply- see first  section below.

...
 > if(nas>0){
+ tree<-drop.tip(tree,tip=which(is.na(scorei)))
+ scorei<-scorei[which(!is.na(scorei))]
+ }
Error in paste("as.", value, sep = "") : could not find function "lapply"
 > tree2<-newick2phylog(write.tree(tree, multi.line=FALSE))
Error in paste("%.", digits, "g", sep = "") :
  could not find function "lapply"
 > n<-length(tree$tip.label)-1
 > e<-rep(NA,n)
 > k<-1/(1:n)
 > for(j in 1:n){
+ Error in sapply(c("(", ")"), function(s) gregexpr(s, substr(line, 1, 
cursor),  :
  could not find function "lapply"
 > e[j]<-sum(k[j:n])
Error: object "j" not found
 > Error in sapply(c("(", ")"), function(s) gregexpr(s, substr(line, 1, 
cursor),  :
  could not find function "lapply"
 > }

...

This continued in a similar vein as I had pasted in quite a few lines 
until the warning suggesting a bug report (below).
As can be seen below, this error prevented directly calling either 
bug.report() or sessionInfo(), however the R.version output was possible 
and the output from bug.report() and sessionInfo() from another session 
started just after on the same machine are given below:

...
 > tree<-drop.tip(tree,tip=which(is.na(scorei)))
Error in paste("as.", value, sep = "") : could not find function "lapply"
 > Error in sapply(c("(", ")"), function(s) gregexpr(s, substr(line, 1, 
cursor),  :
  could not find function "lapply"
 > scorei<-scorei[which(!is.na(scorei))]
Warning message:
An unusual circumstance has arisen in the nesting of readline input. 
Please report using bug.report()
 > bug.report()
Error in paste(names(R.version), R.version, sep = " = ", collapse = "\\n 
") :
  could not find function "lapply"
 > lapply
[[1]]
Error in paste("Error in", dcall, ": ") :
  could not find function "lapply"
 >  
 > sessionInfo()
Error in sapply(package, function(x) x == "package:base" || 
!is.null(attr(as.environment(x),  :
  could not find function "lapply"
 > R.version
   _
platform   i486-pc-linux-gnu
arch   i486
os linux-gnu
system i486, linux-gnu
status
major  2
minor  6.0
year   2007
month  10
day03
svn rev43063
language   R
version.string R version 2.6.0 (2007-10-03)

...

sessionInfo() from another, similar session:

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] ade4_1.4-4 lattice_0.16-5 nlme_3.1-85gee_4.13-13ape_2.0-1

loaded via a namespace (and not attached):
[1] grid_2.6.0  rcompgen_0.1-15

 From bug.report() in another session

--please do not edit the information below--

Version:
platform = i486-pc-linux-gnu
arch = i486
os = linux-gnu
system = i486, linux-gnu
status =
major = 2
minor = 6.0
year = 2007
month = 10
day = 03
svn rev = 43063
language = R
version.string = R version 2.6.0 (2007-10-03)

Locale:
LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.UTF-8;LC_MONETARY=en_GB.UTF-8;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

Search Path:
.GlobalEnv, package:ade4, package:lattice, package:nlme, package:gee, 
package:ape, package:stats, package:graphics, package:grDevices, 
package:utils, package:datasets, package:methods, Autoloads, package:base
~
~
~
~
~
~
~
~
~
~
"R.bug.report" 27L, 783C 4,0-1 All

-- 

Dr Christopher Knight Manchester Interdisciplinary Biocentre
room 2.001  The University of Manchester
Tel:  +44 (0)161 3065138 131 Princess Street
Fax:  +44 (0)161 3064556   Manchester M1 7DN
[EMAIL PROTECTED] UK 
www.dbkgroup.org/MCISB/people/knight/   ` · . ,,><(((°>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] vignette("introduction") causes "Error in sprintf(" (PR#9069)

[Chris Evans]

Gabor Grothendieck sent the following  at 09/07/2006 19:02:
> Same for me.  Looking through the output of vignette
> I noticed that both the ggplot and reshape packages have
> a vignette called "introduction" in my case and either of
> the following brings up the associated vignette (as opposed
> to the error message):
> 
> vignette("introduction", "ggplot")
> vignette("introduction", "reshape")

Aha, works for me too.  Sorry, I probably should have been able to work
that out myself.

So: not so much a bug, more a wish as it might be good if the vignette
code checked for multiple vignettes with the same name and returned a
choice or a message warning you that there are multiples.  Should I do a
follow-up to that bug?

Many thanks to you and all for R: incredible resource.

Chris

-- 
Chris Evans <[EMAIL PROTECTED]>
Professor of Psychotherapy, Nottingham University;
Consultant Psychiatrist in Psychotherapy, Rampton Hospital;
Research Programmes Director, Nottinghamshire NHS Trust;
Hon. SL Institute of Psychiatry, Hon. Con., Tavistock & Portman Trust
**If I am writing from one of those roles, it will be clear. Otherwise**

**my views are my own and not representative of those institutions**

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] vignette("introduction") causes "Error in sprintf(" (PR#9069)

[Chris Evans]

Friedrich Leisch sent the following  at 10/07/2006 11:28:

... some snipped ...

> Fixed now in both r-patched and r-devel.
> 
> Fritz
> 

Wow, wonderful, thanks.  My first ever R bug report resolved and closed
in a weekend.  Stunning.

C

-- 
Chris Evans <[EMAIL PROTECTED]>
Professor of Psychotherapy, Nottingham University;
Consultant Psychiatrist in Psychotherapy, Rampton Hospital;
Research Programmes Director, Nottinghamshire NHS Trust;
Hon. SL Institute of Psychiatry, Hon. Con., Tavistock & Portman Trust
**If I am writing from one of those roles, it will be clear. Otherwise**

**my views are my own and not representative of those institutions**

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Choropleths maps of the USA states (PR#9111)

[Chris Lawrence]

On 7/31/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I have a problem with the choropleths maps of the USA states=20
>
>  In fact, when I use the following code
>
> #
>
> palette(gray(seq(0,.9,len=3D10)))
>
>  ordena.estados<-c("ALABAMA","ARIZONA","ARKANSAS","CALIFORNIA","COLORADO",
> "CONNECTICUT","DELAWARE","FLORIDA","GEORGIA","IDAHO","ILLINOIS","INDIANA","=
> IOWA",
> "KANSAS",
> "KENTUCKY","LOUISIANA","MAINE","MARYLAND","MASSACHUSETTS","MICHIGAN","MINNE=
> SOTA","MISSISSIPI",
>  "MISSOURI", "MONTANA","NEBRASKA","NEVADA","NEW HAMPSHIRE","NEW JERSEY",
> "NEW MEXICO","NEW YORK",
> "NORTH CAROLINA","NORTH DAKOTA","OHIO","OKLAHOMA","OREGON","PENNSYLVANIA","=
> RHODE ISLAND",
> "SOUTH CAROLINA",
> "SOUTH DAKOTA","TENNESSEE","TEXAS","UTAH","VERMONT","VIRGINIA","WASHINGTON",
> "WEST VIRGINIA","WISCONSIN","WYOMING")
>
> W<-c(1,10,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1=
> ,1,1,1,1,1,1,1,1,1,1,1,1,1)
>
> mapa.sat<-map('state', region =3D ordena.estados,fill=3DT,col=3DW)=20=20
>
> #
>
> That should paint all the states with the same colour except   "ARIZONA" , =
>  I get the  "UTAH" state also coloured as "ARIZONA".
>
> The same thing happens with some other states, I get two states coloured in=
> stead of one.
>
> Is there any problem with the way I have made the ranking of states in "ord=
> ena.estados"?

I believe that Michigan and Virginia (at least... there may be others)
have more than one polygon.  So... you end up not having enough colors
in the list and it wraps around.

I once put together a little recipe including a call to grep() that
handled the duplicate polygons.  Try something like:

regions <- map('state', namesonly=T)
W <- rep(1, length(regions))
W[grep('^arizona', regions, ignore.case=T)] <- 10
map('state', fill=T, col=W)

It should also work for the weird states like Michigan and Virginia
(with the appropriate change to the grep call).

Hope this helps...


Chris

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Scoping issues

[Chris Eisley]

Hi everyone,

I'm trying to split up a large R file that implements a tcl/tk gui into
several smaller ones.  The problem is that the main GUI creation
function defines many tclVars and tkframes that need to be accessible to
functions that are currently defined in main function, but which I'd
like to move to different source files.  These files make up a package,
so it seems that using source() is a bad idea.  I could try argument
passing, but there are a lot of arguments to pass in some cases.

The lexical scoping is hurting me here, but I assume there's a good way
to deal with this kind of issue.  Any help is greatly appreciated.

-Chris

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Scoping issues

[Chris Eisley]

Hello Prof Ripley,

Prof Brian Ripley wrote:
> I don't undersand what the issues are, but he actually said
> 
>>> These files make up a package,
> 
> and all the source files on an R packages are concatenated and loaded 
> into a single environment.  So my understanding of the answer to
> 
>>> I assume there's a good way to deal with this kind of issue.
> 
> is 'yes, build an R package'.
> 

My code is built as a package, but having a package doesn't seem to 
prevent the kind of problem I'm running into.  My code is currently 
structured as such:

ui.main <- function() {
ui.func1 <- function {
...
do.something(ui.widget1)
do.something(ui.widget2)
do.something(ui.widget3)
...
}
ui.widget1 <- tkframe(...)
ui.widget2 <- tkframe(...)
ui.widget3 <- tkframe(...)
...
ui.func1()
}

I'd like to move the definition of ui.func1 and those of other functions 
like it to seperate source files, since my main "ui" source file is 
getting quite large.  The variables need to be available to several 
other functions that I'd like to move to separate source files.  Since 
the tkframe variables can't be created in the environment of ui.main, 
I'm not sure how to get around this problem without a lot of argument 
passing.


> On Sun, 7 Jan 2007, John Fox wrote:
> 

Hello John,

>> Dear Chris,
>>
>> If I correctly understand what you want to do, the Rcmdr package uses the
>> following functions (slightly modified from original version 
>> contributed by
>> Philippe Grosjean) to solve a similar problem:
>>
>> RcmdrEnv <- function() {
>>pos <-  match("RcmdrEnv", search())
>>if (is.na(pos)) { # Must create it
>>RcmdrEnv <- list()
>>attach(RcmdrEnv, pos = length(search()) - 1)
>>rm(RcmdrEnv)
>>pos <- match("RcmdrEnv", search())
>>}
>>return(pos.to.env(pos))
>>}
>>
>> putRcmdr <- function(x, value)
>>assign(x, value, envir = RcmdrEnv())
>>
>> getRcmdr <- function(x, mode="any")
>>get(x, envir = RcmdrEnv(), mode = mode, inherits = FALSE)
>>

I think I understand what's going on here, but it seems like a rather 
arcane solution to such a basic problem.  It seems as if I'm trying to 
code in a way that's incompatible with R's scoping.

-Chris

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [EXTERNAL] Re: NOTE: multiple local function definitions for ?fun? with different formal arguments

[Chris Black]

I’m replying 8 months later to say a proper thanks to Duncan for the function 
below. It’s been helping me clean up duplicate (and not-quite duplicate!) 
function definitions in amateur code ever since, and I’m reminded to say so now 
because I just passed it along to Ben Zipperer in response to a very similar 
question[1] on Mastodon. 

In the Mastodon thread there were several R experts expecting the existing 
package checks to catch this and being surprised to realize they don't, which I 
think mostly goes to highlight that it really is a corner case… but in any case 
thank you for your help to keep the “bitten by function redefinition” club a 
small one.

Thanks,
Chris

[1] https://mastodon.social/@benzipperer/113328761897124440



> On Feb 7, 2024, at 11:53 AM, Duncan Murdoch  wrote:
> 
> I put the idea below into a function that gives nicer looking results. Here's 
> the new code:
> 
> dupnames <- function(path = ".") {
> 
>  Rfiles <- pkgload:::find_code(path)
>  allnames <- data.frame(names=character(), filename=character(), line = 
> numeric())
>  result <- NULL
>  for (f in Rfiles) {
>exprs <- parse(f, keep.source = TRUE)
>locs <- getSrcLocation(exprs)
>names <- character(length(exprs))
>lines <- numeric(length(exprs))
>for (i in seq_along(exprs)) {
>  expr <- exprs[[i]]
>  if (is.name(expr[[1]]) &&
>  deparse(expr[[1]]) %in% c("<-", "=") &&
>  is.name(expr[[2]])) {
>names[i] <- deparse(expr[[2]])
>lines[i] <- locs[i]
>  }
>}
>keep <- names != ""
>if (any(keep)) {
>  names <- names[keep]
>  lines <- lines[keep]
> 
>  prev <- nrow(allnames)
>  allnames <- rbind(allnames, data.frame(name = names, filename = 
> basename(f), line = lines))
>  dups <- which(duplicated(allnames$name))
>  dups <- dups[dups > prev]
>  if (any(dups)) {
>origfile <- character(length(dups))
>origline <- numeric(length(dups))
>for (i in seq_along(dups)) {
>  prev <- which(allnames$name == allnames$name[dups[i]])[1]
>  origfile[i] <- allnames$filename[prev]
>  origline[i] <- allnames$line[prev]
>}
> 
>result <- rbind(result,
>data.frame(name = allnames$name[dups],
>   first = paste(origfile, origline, sep=":"),
>   dup = paste(allnames$filename[dups], 
> allnames$line[dups], sep = ":")))
>  }
>}
>  }
>  result
> }
> 
> 
> And here's what I get when I run it on rgl:
> 
> dupnames("rgl")
>  name  first  dup
> 1  fns knitr.R:12  knitr.R:165
> 2  fns knitr.R:12 pkgdown.R:14
> 3  fns knitr.R:12shiny.R:8
> 
> Those are okay; the fns object is a temporary that is later removed in each 
> case.
> 
> Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R CMD check and CRAN's Rust policy

[Chris Black]

I took a more extreme version of this approach for a project that keeps many R 
packages in a monorepo and checks them all at once, where we do a lot of saying 
“let’s ignore this warning _in this package_ until someone has a chance to fix 
it properly, but still fail the build if it shows up in _other packages_”.

The key idea in our approach is for each package you check to cache a previous 
check result that contains the warning(s) you want to ignore, then compare the 
current check against it and have your action fail only on _newly added_ 
warnings.

My implementation[1] is brittle and fussy and could be simplified a lot if 
you’re only checking one package at a time, but may be a useful starting point.

[1] 
https://github.com/PecanProject/pecan/blob/develop/scripts/check_with_errors.R

> On Mar 31, 2025, at 11:33 AM, Duncan Murdoch  wrote:
> 
> I don't see an easy way, but I think this is an approach:
> 
> Configure r-lib/actions/check-r-package to not fail on warnings, only on 
> errors, and to upload the result of the rcmdcheck() run.  I think it will 
> contain all errors, warnings, and notes.  There are options "error-on" which 
> should be set to "error", and "upload-result", which should be set to "true". 
>  So this is the easy part.
> 
> Then examine those results, ignore the warnings you don't care about, and 
> trigger on warnings you do care about.  I have never written a github action, 
> but this one sounds possible.
> 
> Duncan Murdoch
> 
> 
> On 2025-03-31 1:48 p.m., Ben Bolker wrote:
>> On 2025-03-31 1:04 p.m., Duncan Murdoch wrote:
>>> On 2025-03-31 12:41 p.m., Josiah Parry wrote:
 Duncan, the changes to symbols checking was introduced March 22nd see
 https://bugs.r-project.org/show_bug.cgi?id=18789  and https://developer.r-
 project.org/blosxom.cgi/R-devel/NEWS/2025/03/22#n2025-03-22 >>> developer.r-project.org/blosxom.cgi/R-devel/
 NEWS/2025/03/22#n2025-03-22>. But that is unrelated.
>>> 
>>> Sorry, I missed that.
>>> 
 
 To Tim's comment—the check is a simple grep of the installation log
 for "Downloading crates." This could be easily circumvented on CRAN
 and locally by suppressing stdout/err. But that would be adversarial
 and I would like to adhere to the intent of the check.
>>> 
>>> I think Tim was suggesting that you modify your Github action to ignore
>>> this particular warning.  The warning would still appear, but it
>>> wouldn't cause a check failure.
>>> 
>>> Duncan Murdoch
>>At a very quick look, I don't see an easy way to do that (but I am
>> admittedly really bad at doing stuff with Github actions). Maybe longer
>> term, but it feels like the best way to do this would be to request a
>> feature in `rcmdcheck` that allowed the user to request ignoring
>> specific warnings (e.g. specified by regexp?), then expose that feature
>> in the r-check-package action (or whatever it's called ...)
>>> 
>>> 
>>> 
 
 
 
 On Mon, Mar 31, 2025 at 9:23 AM Duncan Murdoch
 mailto:murdoch.dun...@gmail.com>> wrote:
 
 On 2025-03-31 11:50 a.m., Josiah Parry wrote:
  > Following up with this as I address the new R-devel "Compiled code
  > should not call entry points which might terminate R" WARNING and
 this
  > issue has reared its head again.
  >
  > Would a path forward be an environment variable similar
  > to _R_CHECK_CRAN_INCOMING_ to skip this check primarily for GitHub
  > Actions and CI?
 
 The "Compiled code should not call entry points which might
 terminate R"
 isn't a new warning.  I think the last change to it was made in 2022.
 
 Maybe your code, or code in one of the libraries you use, has
 changed?
 
 Duncan Murdoch
 
 
 
 
  >
  > Or, alternatively, if this could be a NOTE when the `--as-cran`
 flag
  > isn't set but a WARNING when it is?
  >
  > Re-vendoring dependencies each time they are changed during the
  > development lifecycle is quite a bit. However, vendoring once
 prior to
  > publishing makes good sense.
  >
  > Is there a balance we can strike here to lower development
 friction but
  > also ensure the robust package installation requirements when
 expected?
  >
  > Using
  >
  >
  >
  >
  > On Sun, Mar 2, 2025 at 11:42 AM Duncan Murdoch
 mailto:murdoch.dun...@gmail.com>
  > >> wrote:
  >
  > On 2025-03-02 1:09 p.m., Ben Bolker wrote:
  >  >I, like Duncan, am just following along here. I think
 there
  > might be
  >  > two distinct questions which it would be useful to keep
 d

[Rd] Feature request: Limiting output of installed.packages()

[Chris Woelkers - NOAA Federal via R-devel]

I'm going to ask this here before submitting it to Bugzilla. Is this a good
idea and worthy of being considered? I think it is but others may not feel
the same.
The installed.packages() function is very useful but can be more
information than needed. While the function includes the argument 'fields'
it seems to do nothing as all fields are outputted when running the
function with or without the 'fields' argument.
I suggest changing the functionality to do the following. When the 'fields'
argument is not present all fields are outputted as is the current
behaviour. But when the 'fields' argument is present only those fields that
are listed are outputted. This would help me greatly as I could then run
just the installed.packages(fields = ) function without having to add any
sorting after the fact.

Thanks,

Chris Woelkers

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel