Re: [Rd] 'CanMakeUseOf' field
> "Seth" == Seth Falcon <[EMAIL PROTECTED]>
> on Wed, 30 Aug 2006 07:06:24 -0700 writes:
Seth> Kurt Hornik <[EMAIL PROTECTED]> writes:
>> An internal environment variable called
>>
>> _R_CHECK_FORCE_SUGGESTS_
>>
>> which controls this has been in place for quite some time now. One can
>> trivially add a Perl R CMD check configure variable for it. I am a bit
>> hesitant to add a --force-suggests cola to R CMD check, as this
>> hardwires a legacy dependency model which may not be up to future needs.
>>
>> As an aside, I have never understood whe developers have need for such
>> an option (as I would have assumed that they'd typically try to check
>> all of their code).
Seth> This is not an aside, but the heart of the issue IMHO :-)
Seth> One case in which checking Suggests does not make sense is when a
Seth> package provides optional functionality that is platform specific. A
Seth> given Suggests entry may only be available on platform A, but it still
Seth> is desirable to check the package on platform B. Similar issues can
Seth> arise during development when a given Suggests entry stops working
Seth> with R-devel.
Seth> Further, if an item in Suggests means it is optional, then one
Seth> _should_ test that by testing the package without the optional packge
Seth> being available. There are a few ways for a true dependency to sneak
Seth> into the code. So I agree that typically developers want to test all
Seth> of their code, but that implies being able to check a package without
Seth> its Suggests being available (I realize this may be hard to implement,
Seth> but easily having R CMD check ignore Suggests is a good start).
Seth> And lastly, Suggests is currently used to list packages used for
Seth> extended examples in package vignettes and being able to easily
Seth> perform all other checks makes sense to me.
Very good points, thanks.
I think it's clear that some R developers see a clear need for
this and their (our) output would be enhanced by such a very
small addition --- it would probably only be a small addition
addition to the "Writing R Extension" manual for the moment.
I don't understand why some developers have such a resistance
to allow one other such keyword.
Dirk mentioned 'Enhances' --- something which I could also live
with instead of 'CanUse' -- I just to be generous
with myself (as package author) in my interpretation of
"enhancing" :-)
Those developers who cannot remember disambiguating more than
one field for 'optional' are well allowed to keep using just
one, i.e., 'Suggests'.
But others who want to be more precise and or want to better expose
(via DESCRIPTION) what they do anyway
(via 'if(require(*)) { .. }') inside their code, examples, and
or vignettes would just converge on *how* the new field should
be baptized.
Since 'R CMD check' is not affected, there's no other
consequence for any package writer.
Having a much more expressive scheme, namely also specifying where
and how the 'canUse' packages are made use of,
could be even more useful.
However, given the overall reactions and the average package
writer's inertia or even "I don't want to have to know this as
well, I just want my package out" mind set -- which can
perfectly make sense, BTW --
I think we should strive for Einstein's
"Make everything as simple as possible, but not simpler"
here.
I'd really like to conclude this thread or at least concentrate
on the "how" rather than the "do we need this at all?" part.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field
On 8/31/2006 3:40 AM, Martin Maechler wrote:
>> "Seth" == Seth Falcon <[EMAIL PROTECTED]>
>> on Wed, 30 Aug 2006 07:06:24 -0700 writes:
>
> Seth> Kurt Hornik <[EMAIL PROTECTED]> writes:
> >> An internal environment variable called
> >>
> >> _R_CHECK_FORCE_SUGGESTS_
> >>
> >> which controls this has been in place for quite some time now. One can
> >> trivially add a Perl R CMD check configure variable for it. I am a bit
> >> hesitant to add a --force-suggests cola to R CMD check, as this
> >> hardwires a legacy dependency model which may not be up to future
> needs.
> >>
> >> As an aside, I have never understood whe developers have need for such
> >> an option (as I would have assumed that they'd typically try to check
> >> all of their code).
>
> Seth> This is not an aside, but the heart of the issue IMHO :-)
>
> Seth> One case in which checking Suggests does not make sense is when a
> Seth> package provides optional functionality that is platform specific.
> A
> Seth> given Suggests entry may only be available on platform A, but it
> still
> Seth> is desirable to check the package on platform B. Similar issues can
> Seth> arise during development when a given Suggests entry stops working
> Seth> with R-devel.
>
> Seth> Further, if an item in Suggests means it is optional, then one
> Seth> _should_ test that by testing the package without the optional
> packge
> Seth> being available. There are a few ways for a true dependency to
> sneak
> Seth> into the code. So I agree that typically developers want to test
> all
> Seth> of their code, but that implies being able to check a package
> without
> Seth> its Suggests being available (I realize this may be hard to
> implement,
> Seth> but easily having R CMD check ignore Suggests is a good start).
>
> Seth> And lastly, Suggests is currently used to list packages used for
> Seth> extended examples in package vignettes and being able to easily
> Seth> perform all other checks makes sense to me.
>
> Very good points, thanks.
> I think it's clear that some R developers see a clear need for
> this and their (our) output would be enhanced by such a very
> small addition --- it would probably only be a small addition
> addition to the "Writing R Extension" manual for the moment.
>
> I don't understand why some developers have such a resistance
> to allow one other such keyword.
My objection is that adding a keyword that people don't understand will
lead to inconsistent use and confusion. It will make "Writing R
Extensions" harder to read, and packages harder to write.
I could be wrong that your proposal is one that won't be understood.
Could you post a proposed revision to the docs that describes it?
Duncan Murdoch
> Dirk mentioned 'Enhances' --- something which I could also live
> with instead of 'CanUse' -- I just to be generous
> with myself (as package author) in my interpretation of
> "enhancing" :-)
>
> Those developers who cannot remember disambiguating more than
> one field for 'optional' are well allowed to keep using just
> one, i.e., 'Suggests'.
> But others who want to be more precise and or want to better expose
> (via DESCRIPTION) what they do anyway
> (via 'if(require(*)) { .. }') inside their code, examples, and
> or vignettes would just converge on *how* the new field should
> be baptized.
> Since 'R CMD check' is not affected, there's no other
> consequence for any package writer.
>
> Having a much more expressive scheme, namely also specifying where
> and how the 'canUse' packages are made use of,
> could be even more useful.
> However, given the overall reactions and the average package
> writer's inertia or even "I don't want to have to know this as
> well, I just want my package out" mind set -- which can
> perfectly make sense, BTW --
> I think we should strive for Einstein's
> "Make everything as simple as possible, but not simpler"
> here.
>
> I'd really like to conclude this thread or at least concentrate
> on the "how" rather than the "do we need this at all?" part.
>
> Martin
>
> __
> 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] Suggestion for read.table()
On Thu, 31 Aug 2006, Simon Urbanek wrote:
>
> On Aug 30, 2006, at 10:15 PM, Prof Brian Ripley wrote:
>
> >On Wed, 30 Aug 2006, [EMAIL PROTECTED] wrote:
> >
> > >However, direct reading might be a good option?
> >
> >See ?textConnection for how to do this.
> >
> >inp <- " x y z
> >1 2 3
> >4 5 6
> >"
> >read.table(textConnection(inp), header=TRUE)
> >
> >The most common case is wanting to paste in, and we have "clipboard" for
> >that (at least on Windows on X11: it would be a nice addition on Aqua).
> >
>
> On Mac OS X (Aqua or cmd line) you can use clipboard input like this:
> read.table(pipe("pbpaste"))
> It seems to be quite popular especially in conjunction with Excel...
Yes, I know (I even documented in ?connections). What would be nice is if
read.table("clipboard")
worked as it does on the other platforms.
--
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] R-Project logo in SVG format
Hi, I'm looking for a version of the R-Project logo in SVG format. I've found the bitmapped versions, http://developer.r-project.org/Logo/ but would prefer a scalable version as it usually looks better when printed. Where may I find one? -Lars Lars Nooden ([EMAIL PROTECTED]) On the Internet, nobody knows you're a dog ... ... until you start barking. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] stop R mainloop without calling exit(1)
Hello,
I'm trying to make my Java application work with R, which involves
sending and retrieving data and to run R functions from within the
Java application. I also need to have "live interaction" with R, to
show the R console output (e.g. warnings and print) and to enable the
user to enter input when a function asks for it.
Therefore I created a simple R console in Java using JRI
(http://rosuda.org/JRI/), and it works ok. The only problem is that I
have to start the R main loop which doesn't return. The only way to
stop it is to give R the quit command ('q()'), but then 'exit(1)' is
called from the R code and the Java Virtual Machine (including my
application) also shuts down.
My quick solution to this problem was to modify the R source code so
that the main loop ends without the need to call exit. The 'do_quit'
method in main.c now returns NULL instead of calling exit(1) and
'Rf_ReplIteration' checks for a returned NULL after each eval() and
breaks the main loop by returning -1.
Here are the simple changes to the R source code ('+' are the lines I
added, '//' are the lines I removed):
src/main/main.c : Rf_ReplIteration(...):
--
value = eval(R_CurrentExpr, rho);
+if(value == NULL)
+return(-1);
src/main/main.c : do_quit():
-
//exit(0);
+return(NULL)
I also removed the call to exit in src/linux/sys-std.c:Rstd_CleanUp
and src/gnuwin32/system.c:R_CleanUp for linux and windows
respectively.
This is obviously a quick hack to make it work (but it works fine,
also the standalone R exits ok this way), but I can imagine more
people want to use the mainloop with the possibility to return from it
without making their application to exit too. I wonder if it's
possible to include this possibility in future versions of R. Or do I
see this wrong and are there other (easier) solutions to achieve what
I want? Thanks in advance for your comments/reactions.
Thomas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] stop R mainloop without calling exit(1)
This is already covered in the R-devel version of R: please consult
`Writing R Extensions' in that version.
On Thu, 31 Aug 2006, Thomas Kelder wrote:
> Hello,
>
> I'm trying to make my Java application work with R, which involves
> sending and retrieving data and to run R functions from within the
> Java application. I also need to have "live interaction" with R, to
> show the R console output (e.g. warnings and print) and to enable the
> user to enter input when a function asks for it.
>
> Therefore I created a simple R console in Java using JRI
> (http://rosuda.org/JRI/), and it works ok. The only problem is that I
> have to start the R main loop which doesn't return.
But that's not true. The documented way is
setup_Rmainloop
run a loop (which can return)
end_Rmainloop
The problem was that the only documented way to shut R down cleanly was
end_Rmainloop (which did call exit), whereas there now is Rf_endEmbeddedR.
> The only way to stop it is to give R the quit command ('q()'), but then
> 'exit(1)' is called from the R code and the Java Virtual Machine
> (including my application) also shuts down.
That's because you called end_Rmainloop, possibly by calling
run_Rmainloop rather than taking control of the loop.
It seems that almost all users of embedded R did not call end_Rmainloop,
and I met this when creating a common embedding interface for Unix and
Windows versions of R: the Windows widgets (such as the graphics device)
do need to be told to shut down.
[...]
--
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-Project logo in SVG format
> Hi, > > I'm looking for a version of the R-Project logo in SVG format. I've found > the bitmapped versions, > http://developer.r-project.org/Logo/ > > but would prefer a scalable version as it usually looks better when > printed. > > Where may I find one? After you created one and submitted it to us probably at the same place as the bitmaps. In the meantime it will have to suffice that you use all we have, and that are the bitmaps (the logo was done by a volunteer who chose to use a bitmapped graphics program). It is not like we keep the good stuff back on purpose ... Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Interface for package supplied random number generator
Hi, As you probably know, there is a problem with the interface for adding uniform random number generators in R (see by article in R News 5/2, November 2005). There exists a mechanism called "user-supplied" that allows users of R to run their own generator in R. However, there is no such mechanism for package writers. Those who want to add their own generators abuse RNGkind(kind="user-supplied") for their purpose. The problem with this approach is that it relies on the unique existence of the function "user_unif_rand". When two packages are loaded that use this interface, then at least one package is broken. If the user herself loads a shared library that contains such a function, some of the functionalities of all the corresponding packages are broken. When writing my paper I found the following packages on CRAN that abuse this interface (meanwhile there might be more packages): randaes_0.1.tar.gz rlecuyer_0.1.tar.gz rsprng_0.3-1.tar.gz rstream_1.1.tar.gz SuppDists_1.0-13.tar.gz what makes the situation even more complicated is the fact that some of these packages are loaded automaticall by other packages. For example, package 'rlecuyer' is loaded by snow_0.2-1.tar.gz snowFT_0.0-1.tar.gz varSelRF_0.6-2.tar.gz To solve this problem, Stefan Theussl and I have tried to extend the mechanism for random number generators in the following way: - we have added a new kind of generators: "package-supplied" - this generator kind needs functions named 'package_unif_rand', 'package_unif_init', 'package_unif_nseed', and 'package_unif_seedloc' (analogously to the functions for kind "user-supplied") - RNGkind has an additional optional argument: RNGkind <- function(kind = NULL, normal.kind = NULL, PACKAGE = "") argument 'PACKAGE' is only used for the new generator kind "package-supplied" - similarly the function set.seed needs the optinal argument 'PACKAGE' Since I need such an extended interface (and I assume that other package write do also) I ask whether this extension can be included into R. We have implemented a first experimental version of this modified interface. A patch against the development snapshot R-devel_2006-08-30.tar.gz is available. However, it is a little bit too long (239 lines) to be posted here. Of course suggestions for an alternative approach are welcome. Josef -- - Josef Leydold | Vienna University of Economics and Business Administration | Department of Statistics and Mathematics - Augasse 2-6 | Tel. +43 1 31336 4695 A-1090 Vienna | FAX+43 1 31336 774 European Union | email [EMAIL PROTECTED] - Alles Unglueck kam daher, dass die Denkenden nicht mehr handeln konnten, und die Handelnden keine Zeit mehr fanden zu denken. (Marlen Haushofer) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R crashes in Mac OS 10.4 when Find is used (PR#9192)
Full_Name: Matt Fantle Version: 1.16 OS: Mac OS 10.4.7 Submission from: (NULL) (128.118.174.213) Problem: R crashes when 'Command-f' is pressed to begin "Find" Frequency: This problem is intermittant. Once R crashes, the only solution is to restart R and try to Find again. There is no regularity to the problem. If R is opened by double-clicking on a ".R" file, the problem might be there. If R is opened by double-clicking the application or alias, the problem may also still be there. Log report: OS Version: 10.4.7 (Build 8J135) Report Version: 4 Command: R Path:/Applications/R.app/Contents/MacOS/R Parent: WindowServer [60] Version: 1.16 (3198) PID:474 Thread: 0 Exception: EXC_BREAKPOINT (0x0006) Code[0]:0x0001 Code[1]:0x9295f120 Thread 0 Crashed: 0 com.apple.Foundation0x9295f120 _NSRaiseError + 264 1 com.apple.AppKit0x937c9274 -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 160 2 com.apple.AppKit0x937c8ce4 -[NSMenu performKeyEquivalent:] + 272 3 com.apple.AppKit0x937c88c4 -[NSApplication _handleKeyEquivalent:] + 220 4 com.apple.AppKit0x936d2408 -[NSApplication sendEvent:] + 2944 5 org.R-project.R 0xb730 -[RController handleReadConsole:] + 88 (RController.m:869) 6 org.R-project.R 0x0002c0b8 Re_ReadConsole + 108 (Rcallbacks.m:137) 7 org.R-project.R 0x0003223c run_REngineRmainloop + 300 (Rinit.c:341) 8 org.R-project.R 0x0002aa1c -[REngine runREPL] + 68 (REngine.m:167) 9 org.R-project.R 0x0001d340 main + 680 (main.m:101) 10 org.R-project.R 0x2e8c _start + 340 (crt.c:272) 11 org.R-project.R 0x2d34 start + 60 Thread 1: 0 libSystem.B.dylib 0x9000b268 mach_msg_trap + 8 1 libSystem.B.dylib 0x9000b1bc mach_msg + 60 2 com.apple.CoreFoundation0x907dbb78 __CFRunLoopRun + 832 3 com.apple.CoreFoundation0x907db47c CFRunLoopRunSpecific + 268 4 com.apple.Foundation0x92939598 -[NSConnection sendInvocation:] + 1468 5 com.apple.Foundation0x92938034 -[NSObject(NSForwardInvocation) forward::] + 408 6 libobjc.A.dylib 0x90a430b0 _objc_msgForward + 176 7 com.apple.Foundation0x9293839c -[NSDistantObject methodSignatureForSelector:] + 268 8 com.apple.Foundation0x92937f04 -[NSObject(NSForwardInvocation) forward::] + 104 9 libobjc.A.dylib 0x90a430b0 _objc_msgForward + 176 10 org.R-project.R 0xacc0 -[RController readThread:] + 2436 (RController.m:613) 11 com.apple.Foundation0x92944194 forkThreadForFunction + 108 12 libSystem.B.dylib 0x9002bc28 _pthread_body + 96 Thread 2: 0 libSystem.B.dylib 0x9002c2e8 semaphore_wait_signal_trap + 8 1 libSystem.B.dylib 0x90030dcc pthread_cond_wait + 480 2 com.apple.Foundation0x9294b300 -[NSConditionLock lockWhenCondition:] + 68 3 com.apple.AppKit0x9376a708 -[NSUIHeartBeat _heartBeatThread:] + 324 4 com.apple.Foundation0x92944194 forkThreadForFunction + 108 5 libSystem.B.dylib 0x9002bc28 _pthread_body + 96 Thread 3: 0 libSystem.B.dylib 0x9000b268 mach_msg_trap + 8 1 libSystem.B.dylib 0x9000b1bc mach_msg + 60 2 com.apple.CoreFoundation0x907dbb78 __CFRunLoopRun + 832 3 com.apple.CoreFoundation0x907db47c CFRunLoopRunSpecific + 268 4 com.apple.Foundation0x9296b69c +[NSURLConnection(NSURLConnectionInternal) _resourceLoadLoop:] + 264 5 com.apple.Foundation0x92944194 forkThreadForFunction + 108 6 libSystem.B.dylib 0x9002bc28 _pthread_body + 96 Thread 4: 0 libSystem.B.dylib 0x9000b268 mach_msg_trap + 8 1 libSystem.B.dylib 0x9000b1bc mach_msg + 60 2 com.apple.CoreFoundation0x907dbb78 __CFRunLoopRun + 832 3 com.apple.CoreFoundation0x907db47c CFRunLoopRunSpecific + 268 4 com.apple.Foundation0x9296c7dc +[NSURLCache _diskCacheSyncLoop:] + 152 5 com.apple.Foundation0x92944194 forkThreadForFunction + 108 6 libSystem.B.dylib 0x9002bc28 _pthread_body + 96 Thread 5: 0 libSystem.B.dylib 0x9000b268 mach_msg_trap + 8 1 libSystem.B.dylib 0x9000b1bc mach_msg + 60 2 com.apple.CoreFoundation0x907dbb78 __CFRunLoopRun + 832 3 com.apple.CoreFoundation0x907db47c CFRunLoopRunSpecific + 268 4 com.apple.Foundation0x92953164 -[NSRunLoop runMode:beforeDate:] + 172 5 com.apple.Foundation0x9295309c -[NSRunLoop run] + 76 6 com.apple.WebKit0x9562ff70 +[WebFileDatabase _syncLoop:] + 176 7 com.apple.Foundation0x92944194 forkThreadForFunction + 108 8 libSystem.B.dylib 0x9002bc28 _pthread_body + 96 Thread 0 crashed with PPC Thread State 64: srr0: 0x9295f120 srr1: 0x0202f030 vrsave: 0x cr: 0x24000442 xer: 0x
Re: [Rd] 'CanMakeUseOf' field
Martin Maechler <[EMAIL PROTECTED]> writes:
>> "Seth" == Seth Falcon <[EMAIL PROTECTED]>
>> on Wed, 30 Aug 2006 07:06:24 -0700 writes:
>
> Seth> Kurt Hornik <[EMAIL PROTECTED]> writes:
> >> An internal environment variable called
> >>
> >> _R_CHECK_FORCE_SUGGESTS_
> >>
> >> which controls this has been in place for quite some time now. One can
> >> trivially add a Perl R CMD check configure variable for it. I am a bit
> >> hesitant to add a --force-suggests cola to R CMD check, as this
> >> hardwires a legacy dependency model which may not be up to future
> needs.
> >>
> >> As an aside, I have never understood whe developers have need for such
> >> an option (as I would have assumed that they'd typically try to check
> >> all of their code).
>
> Seth> This is not an aside, but the heart of the issue IMHO :-)
>
> Seth> One case in which checking Suggests does not make sense is when a
> Seth> package provides optional functionality that is platform specific.
> A
> Seth> given Suggests entry may only be available on platform A, but it
> still
> Seth> is desirable to check the package on platform B. Similar issues can
> Seth> arise during development when a given Suggests entry stops working
> Seth> with R-devel.
>
> Seth> Further, if an item in Suggests means it is optional, then one
> Seth> _should_ test that by testing the package without the optional
> packge
> Seth> being available. There are a few ways for a true dependency to
> sneak
> Seth> into the code. So I agree that typically developers want to test
> all
> Seth> of their code, but that implies being able to check a package
> without
> Seth> its Suggests being available (I realize this may be hard to
> implement,
> Seth> but easily having R CMD check ignore Suggests is a good start).
>
> Seth> And lastly, Suggests is currently used to list packages used for
> Seth> extended examples in package vignettes and being able to easily
> Seth> perform all other checks makes sense to me.
>
> Very good points, thanks.
> I think it's clear that some R developers see a clear need for
> this and their (our) output would be enhanced by such a very
> small addition --- it would probably only be a small addition
> addition to the "Writing R Extension" manual for the moment.
>
> I don't understand why some developers have such a resistance
> to allow one other such keyword.
> Dirk mentioned 'Enhances' --- something which I could also live
> with instead of 'CanUse' -- I just to be generous
> with myself (as package author) in my interpretation of
> "enhancing" :-)
This is my last post until we discuss this next year ;-)
The easy solution is to add a new term, but I don't think this is a
good solution at all.
A new developer would have a hard time guessing the difference between
Suggests and CanUse. Why? Because 'CanUse' exists because of a
disagreement about how R CMD check should operate. The meaning of
CanUse is just that it doesn't get checked by R CMD check.
I think we should consider keeping the two levels: Depends and
Suggests and improve R CMD check to:
* Be able to check a package when any subset of Suggests
is present.
* Be able to check a package forcing all Suggests to be unavailable.
If new terms are wanted, they should have clear semantics. From the
discussion, here are some possibilities:
DocDepends: Needed for vignette or extended example
RelatedTo: Loose affinity for listed package
Adding DocDepends, it would make sense to modify R CMD check to know
about it. Probably not for RelatedTo.
> Those developers who cannot remember disambiguating more than
> one field for 'optional' are well allowed to keep using just
> one, i.e., 'Suggests'.
> But others who want to be more precise and or want to better expose
> (via DESCRIPTION) what they do anyway
> (via 'if(require(*)) { .. }') inside their code, examples, and
> or vignettes would just converge on *how* the new field should
> be baptized.
> Since 'R CMD check' is not affected, there's no other
> consequence for any package writer.
I fail to see how adding an ambiguous term with fuzzy meaning is good
for package developers wishing to be more precise. At the same time,
if changes to R CMD check are decided against, I would rather have an
extra term.
Bw,
+ seth
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] stop R mainloop without calling exit(1)
Dear Professor Ripley,
Thank you for your reply. I have a few questions left:
> > But that's not true. The documented way is
> >
> > setup_Rmainloop
> > run a loop (which can return)
> > end_Rmainloop
> >
> > The problem was that the only documented way to shut R down cleanly was
> > end_Rmainloop (which did call exit), whereas there now is Rf_endEmbeddedR.
In the documentation "run_Rmainloop" is called to start the loop:
Rf_initEmbeddedR(argc, argv);
/* submit some code to R, which is done interactively via
run_Rmainloop();
*/
Rf_endEmbeddedR(0);
But that method doesn't return normally, right? It only ends if
ReplIteration returns -1.
Or do you mean I need to re-implement the read-and-evaluate loop in a
way that I can interrupt it (at "run a loop (which can return)" in
your example)? So instead of calling run_Rmainloop, I can copy the
loop in R_ReplConsole, add an interrupted flag and check that every
iteration.
> > It seems that almost all users of embedded R did not call end_Rmainloop,
> > and I met this when creating a common embedding interface for Unix and
> > Windows versions of R: the Windows widgets (such as the graphics device)
> > do need to be told to shut down.
> Another idea on Unix-alikes is to replace R_CleanUp by your own callback:
> it is part of the documented interface for writing a front-end.
So for the Unix alikes I could use a customized R_CleanUp for the
non-devel versions of R. For windows I should still call
end_Rmainloop, but if I understand you well, this is only needed if I
use the windows widgets in R. I don't want to, so it shouldn't be a
problem then?
Thank you for your help, I'm going to try to modify the JRI interface
by writing a custom loop instead of calling run_Rmainloop.
By the way, I use R version 2.2.1 in linux, because I got the "Error:
C stack usage is too close to the limit R" error in higher versions (I
saw there was a topic about this already:
https://stat.ethz.ch/pipermail/r-devel/2006-April/037219.html). I
tried to use the R-devel version to make use of the Rf_endEmbeddedR
method, but the error also occurs in this version. Could this be a
bug?
Thomas
2006/8/31, Prof Brian Ripley <[EMAIL PROTECTED]>:
> Another idea on Unix-alikes is to replace R_CleanUp by your own callback:
> it is part of the documented interface for writing a front-end.
>
> On Thu, 31 Aug 2006, Prof Brian Ripley wrote:
>
> > This is already covered in the R-devel version of R: please consult
> > `Writing R Extensions' in that version.
> >
> > On Thu, 31 Aug 2006, Thomas Kelder wrote:
> >
> > > Hello,
> > >
> > > I'm trying to make my Java application work with R, which involves
> > > sending and retrieving data and to run R functions from within the
> > > Java application. I also need to have "live interaction" with R, to
> > > show the R console output (e.g. warnings and print) and to enable the
> > > user to enter input when a function asks for it.
> > >
> > > Therefore I created a simple R console in Java using JRI
> > > (http://rosuda.org/JRI/), and it works ok. The only problem is that I
> > > have to start the R main loop which doesn't return.
> >
> > But that's not true. The documented way is
> >
> > setup_Rmainloop
> > run a loop (which can return)
> > end_Rmainloop
> >
> > The problem was that the only documented way to shut R down cleanly was
> > end_Rmainloop (which did call exit), whereas there now is Rf_endEmbeddedR.
> >
> > > The only way to stop it is to give R the quit command ('q()'), but then
> > > 'exit(1)' is called from the R code and the Java Virtual Machine
> > > (including my application) also shuts down.
> >
> > That's because you called end_Rmainloop, possibly by calling
> > run_Rmainloop rather than taking control of the loop.
> >
> > It seems that almost all users of embedded R did not call end_Rmainloop,
> > and I met this when creating a common embedding interface for Unix and
> > Windows versions of R: the Windows widgets (such as the graphics device)
> > do need to be told to shut down.
> >
> > [...]
> >
> >
>
> --
> 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] stop R mainloop without calling exit(1)
Thomas Kelder wrote: [...] > By the way, I use R version 2.2.1 in linux, because I got the "Error: > C stack usage is too close to the limit R" error in higher versions (I > saw there was a topic about this already: > https://stat.ethz.ch/pipermail/r-devel/2006-April/037219.html). I > tried to use the R-devel version to make use of the Rf_endEmbeddedR > method, but the error also occurs in this version. Could this be a > bug? Try this in your code. It turns off stack checking altogether: #ifdef CSTACK_DEFNS /* Don't do any stack checking */ R_CStackLimit = -1; #endif Rf_initEmbeddedR(R_argc, R_argv); Jeff -- http://biostat.mc.vanderbilt.edu/JeffreyHorner __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-Project logo in SVG format
[EMAIL PROTECTED] wrote: > After you created one and submitted it to us probably at the same place as > the bitmaps. In the meantime it will have to suffice that you use all we > have, and that are the bitmaps (the logo was done by a volunteer who chose > to use a bitmapped graphics program). It is not like we keep the good > stuff back on purpose ... It does look like it would be near-impossible to parameterise the logo efficiently into a vector format - all that shading and 3-d effect stuff. The largest PNG file there is 1450x1100 pixels which at 300 dpi gives you a 4-inch logo. Although looking at it full-size on my monitor reveals some artifacts in the 3-d shading... Do any other materials exist for making the logo? A description of the fonts used, a 3-d model R and O-shape, a layered PSD or XCF file, or a Gimp/Photoshop macro set for getting that effect? I dont believe this was painted pixel-by-pixel... When was the last time the mailing list had a 'need a new logo' thread? Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-Project logo in SVG format
> It does look like it would be near-impossible to parameterise the logo > efficiently into a vector format - all that shading and 3-d effect > stuff. These days, most vector graphics programs provide gradient shading primitives - that's all you need to recreate most 3D effects. Hadley __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wish: keep names in mapply() result
Hello,
Charles Berry sent me (off-list) his proposal, which I find better
(after slight modification) than mine. I would say that proposed changes
make mapply even more consistent with (some) *apply* funcs in terms of
names. Patches to mapply.R and mapply.Rd are attached. I have runned
make check-all and it seems that there are no problems with this change.
I hope R core will find this worth to apply.
New behaviour without first ... as character:
l <- list(a=1, b=2)
k <- list(1)
mapply(FUN="+", l, k)
a b
2 3
mapply(FUN="+", l, k, USE.NAMES=FALSE)
[1] 2 3
mapply(FUN="+", l, k, SIMPLIFY=FALSE)
$a
[1] 2
$b
[1] 3
mapply(FUN="+", l, k, SIMPLIFY=FALSE, USE.NAMES=FALSE)
[[1]]
[1] 2
[[2]]
[1] 3
New behaviour with first ... as character _with_ names:
l <- c("1", "2")
names(l) <- c("a", "b")
mapply(FUN="paste", l, k)
a b
"1 1" "2 1"
mapply(FUN="paste", l, k, USE.NAMES=FALSE)
[1] "1 1" "2 1"
mapply(FUN="paste", l, k, SIMPLIFY=FALSE)
$a
[1] "1 1"
$b
[1] "2 1"
mapply(FUN="paste", l, k, SIMPLIFY=FALSE, USE.NAMES=FALSE)
[[1]]
[1] "1 1"
[[2]]
[1] "2 1"
New behaviour with first ... as character _without_ names:
l <- c("1", "2")
mapply(FUN="paste", l, k)
1 2
"1 1" "2 1"
mapply(FUN="paste", l, k, USE.NAMES=FALSE)
[1] "1 1" "2 1"
mapply(FUN="paste", l, k, SIMPLIFY=FALSE)
$`1`
[1] "1 1"
$`2`
[1] "2 1"
mapply(FUN="paste", l, k, SIMPLIFY=FALSE, USE.NAMES=FALSE)
[[1]]
[1] "1 1"
[[2]]
[1] "2 1"
Regards, Gregor
Gregor Gorjanc wrote:
> Hello!
>
> I have noticed that mapply() drops names in R 2.3.1 as well as in
> r-devel. Here is a simple example:
>
> l <- list(a=1, b=2)
> k <- list(1)
> mapply(FUN="+", l, k)
> [1] 2 3
> mapply(FUN="+", l, k, SIMPLIFY=FALSE)
> [[1]]
> [1] 2
>
> [[2]]
> [1] 3
>
> Help page does not indicate that this should happen. Argument USE.NAMES
> does not have any effect here as it used only in a bit special
> situation: "If the first ... argument is character and the result does
> not already have names, use it as the names." But result is always
> without names as shown above. Did I miss any peculiarities?
>
> This is not consistent with lapply, which keeps names i.e.
>
> lapply(l, "+", 1)
> $a
> [1] 2
>
> $b
> [1] 3
>
> I have attached and copied (at the end) patch proposal against SVN that
> adds names back to the result if x had it (only R as my C is ...). This
> way it would also be consistent with lapply. make check-all seems to be
> happy with changes. Now we get:
>
> mapply(FUN="+", l, k)
> a b
> 2 3
>
> mapply(FUN="+", l, k, SIMPLIFY=FALSE)
> $a
> [1] 2
>
> $b
> [1] 3
>
> And if we had "character" (with some variations) for first ... then:
>
> l <- list(a="1", b="2")
> mapply(FUN="paste", l, k)
> a b
> "1 1" "2 1"
>
> l <- list("1", "2")
> mapply(FUN="paste", l, k)
> [1] "1 1" "2 1"
>
> l <- c("1", "2")
> mapply(FUN="paste", l, k)
> 1 2
> "1 1" "2 1"
>
> Index: src/library/base/R/mapply.R
> ===
> --- src/library/base/R/mapply.R (revision 39024)
> +++ src/library/base/R/mapply.R (working copy)
> @@ -3,8 +3,16 @@
> FUN <- match.fun(FUN)
> dots <- list(...)
>
> +if(!is.null(names(dots[[1]]))) {
> +isNamed <- TRUE
> +namesX <- names(dots[[1]])
> +} else {
> +isNamed <- FALSE
> +}
> +
> answer<-.Call("do_mapply", FUN, dots, MoreArgs, environment(),
>PACKAGE="base")
> +if(isNamed) names(answer) <- namesX
>
> if (USE.NAMES && length(dots) && is.character(dots[[1]]) &&
> is.null(names(answer))) names(answer) <- dots[[1]]
> @@ -47,4 +55,4 @@
> }
> formals(FUNV) <- formals(FUN)
> FUNV
> -}
> \ No newline at end of file
> +}
>
>
>
>
>
> Index: src/library/base/R/mapply.R
> ===
> --- src/library/base/R/mapply.R (revision 39024)
> +++ src/library/base/R/mapply.R (working copy)
> @@ -3,8 +3,16 @@
> FUN <- match.fun(FUN)
> dots <- list(...)
>
> +if(!is.null(names(dots[[1]]))) {
> +isNamed <- TRUE
> +namesX <- names(dots[[1]])
> +} else {
> +isNamed <- FALSE
> +}
> +
> answer<-.Call("do_mapply", FUN, dots, MoreArgs, environment(),
>PACKAGE="base")
> +if(isNamed) names(answer) <- namesX
>
> if (USE.NAMES && length(dots) && is.character(dots[[1]]) &&
> is.null(names(answer))) names(answer) <- dots[[1]]
> @@ -47,4 +55,4 @@
> }
> formals(FUNV) <- formals(FUN)
> FUNV
> -}
> \ No newline at end of file
> +}
mapply.R.patch.gz
Description: GNU Zip compressed data
mapply.Rd.patch.gz
Description: GNU Zip compressed data
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] S4 changes - sp fails
Under R version 2.4.0 (2006-08-30 r39024), sp fails CMD check following
the latest changes in methods.
The failures are in running examples and occur in CMD check:
> data(state)
> dd2dms(state.center$x)
Error in function (classes, fdef, mtable) :
unable to find an inherited method for function "initialize", for
signature "integer"
Offending code:
deg <- as(floor(dd), "integer")
After replacing by as.integer(floor(dd)), it fails on the local class
definition:
> dd2dms(state.center$x)
Error in function (classes, fdef, mtable) :
unable to find an inherited method for function "initialize", for
signature "DMS"
Installing sp, example("DMS-class") runs successfully interactively
(other examples do too).
The methods package is declared as Depends: in DESCRIPTION, and
import(methods) in NAMESPACE;
.onLoad <- function(lib, pkg) require(methods) is in the first R source
file in Collate: order.
Should the methods package be being invoked in some other way, is there a
reason why the installed package appears to run examples successfully that
fail under CMD check?
Roger
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: [EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Overriding InitTempDir
For embedded projects, one may want to eliminate the per-session temp
directory created by InitTempDir() and just use a system-specific temp
directory. Here's my solution:
extern char *R_TempDir;
void my_InitTempDir()
{
char *tmp;
if (R_TempDir){
if (rmdir(R_TempDir) != 0){
perror("Fatal Error: could not remove R's TempDir!");
exit(1);
}
}
tmp = getenv("TMPDIR");
if (tmp == NULL) {
tmp = getenv("TMP");
if (tmp == NULL) {
tmp = getenv("TEMP");
if (tmp == NULL)
tmp = "/tmp";
}
}
R_TempDir=tmp;
if (setenv("R_SESSION_TMPDIR",tmp,1) != 0){
perror("Fatal Error: couldn't set/replace R_SESSION_TMPDIR!");
exit(1);
}
}
This function is called after Rf_initEmbeddedR; it's seems like a hack
but it works. Does anyone have other solutions?
Maybe InitTempDir could check if R_TempDir was not NULL and then just
return.
--
http://biostat.mc.vanderbilt.edu/JeffreyHorner
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 changes - sp fails
Roger,
I had managed to run R CMD check on sp successfully on r39021 and r39043
(current) in my nightly checks. (There are a couple of tests where the
show/print method is not being invoked, but that is not new.)
All I can suggest is to install R from scratch (make distclean), and then
reinstall all relevant packages. At a guess, your interactive use and R
CMD check are picking up different libraries.
There are around a dozen S4-using packages on CRAN that are currently
failing their checks: some look like newly-discovered bugs but some look
like problems in S4 dispatch (even of S3 dispatch for S3 generics turned
into S4 generics). More are producing apparently incorrect warnings.
Brian
On Thu, 31 Aug 2006, Roger Bivand wrote:
> Under R version 2.4.0 (2006-08-30 r39024), sp fails CMD check following
> the latest changes in methods.
>
> The failures are in running examples and occur in CMD check:
>
> > data(state)
> > dd2dms(state.center$x)
> Error in function (classes, fdef, mtable) :
> unable to find an inherited method for function "initialize", for
> signature "integer"
>
> Offending code:
>
> deg <- as(floor(dd), "integer")
>
> After replacing by as.integer(floor(dd)), it fails on the local class
> definition:
>
> > dd2dms(state.center$x)
> Error in function (classes, fdef, mtable) :
> unable to find an inherited method for function "initialize", for
> signature "DMS"
>
> Installing sp, example("DMS-class") runs successfully interactively
> (other examples do too).
>
> The methods package is declared as Depends: in DESCRIPTION, and
> import(methods) in NAMESPACE;
>
> .onLoad <- function(lib, pkg) require(methods) is in the first R source
> file in Collate: order.
>
> Should the methods package be being invoked in some other way, is there a
> reason why the installed package appears to run examples successfully that
> fail under CMD check?
>
> Roger
>
>
--
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
