Re: [Rd] 'CanMakeUseOf' field

2006-08-31 Thread Martin Maechler
 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

2006-08-31 Thread Duncan Murdoch
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


[Rd] R-Project logo in SVG format

2006-08-31 Thread Lars D . Noodén
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)

2006-08-31 Thread Thomas Kelder
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)

2006-08-31 Thread Prof Brian Ripley
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

2006-08-31 Thread friedrich . leisch
 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

2006-08-31 Thread Josef Leydold
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)

2006-08-31 Thread msf17
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: 

Re: [Rd] 'CanMakeUseOf' field

2006-08-31 Thread Seth Falcon
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] R-Project logo in SVG format

2006-08-31 Thread Barry Rowlingson
[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

2006-08-31 Thread hadley wickham
   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

2006-08-31 Thread Gregor Gorjanc
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] Overriding InitTempDir

2006-08-31 Thread Jeffrey Horner
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

2006-08-31 Thread Prof Brian Ripley
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