Hi All
I run across the following situation quite frequently and was wondering if
there exists a simple solution that I missed.
Situation:
I develop some graphical display using the nice basic R graphical
functions (plots, lines, images, histogramm ...).
Now I would like to add a few simple user
On CRAN, the package RSVGTipsDevice is only installed for 32bit Windows, and is
not available as a 64bit package for Windows.
The file linked to in the package check summary on CRAN says "NB: this package
is only installed for sub-architecture 'i386' ".
What do I need to do to make it available
On Dec 19, 2011, at 2:22 PM, Dan Tenenbaum wrote:
> On Thu, Dec 15, 2011 at 4:46 PM, Simon Urbanek
> wrote:
>> Dan,
>>
>> I don't know why, but something is off in the recent R-devel build for ppc.
>> The result is that the installed binary ppc is older than the other ones, so
>> it doesn't h
On Thu, Dec 15, 2011 at 4:46 PM, Simon Urbanek
wrote:
> Dan,
>
> I don't know why, but something is off in the recent R-devel build for ppc.
> The result is that the installed binary ppc is older than the other ones, so
> it doesn't have paste0 while the others do.
>
> The really strange thing i
If all else fails, read the manual: it is explicitly documented that you
need a file src/Makefile.win .
And very likely you should rather study the manual to resolve what issue
you think 'requires' a Makefile: those who want to use R on other
platforms (e.g. Solaris and AIX) are unlikely to th
On Dec 19, 2011, at 10:30 AM, Jonathan Shore wrote:
> I've written a rather complex package that requires overriding the default
> compilation behavior for the C code component. In the src dir I have a
> Makefile that is used correctly on OSX and Linux builds of the package, but
> completely
On 19.12.2011 16:30, Jonathan Shore wrote:
I've written a rather complex package that requires overriding the default
compilation behavior for the C code component. In the src dir I have a
Makefile that is used correctly on OSX and Linux builds of the package, but
completely ignored on win
Martin,
On Dec 19, 2011, at 6:39 AM, Martin Maechler wrote:
>> Barry Rowlingson
>>on Sun, 18 Dec 2011 01:32:52 + writes:
>
>> Scenario: Here I am working away in R. I've got results
>> that prove global warming is anthropogenic and also the
>> solution for producing limitless ca
I've written a rather complex package that requires overriding the default
compilation behavior for the C code component. In the src dir I have a
Makefile that is used correctly on OSX and Linux builds of the package, but
completely ignored on windows.
R CMD INSTALL
on windows runs Makecon
Indeed I broke the function when adding support for bibentry objects...
By the way, let's give credits back to Ceasars: I am not the author of
the bibtex package, Romain Francois is. I just contributed the write.bib
function, mainly inspired by Achim's function.
Romain, I will send a fix for t
On 12/19/2011 2:02 AM, Renaud Gaujoux wrote:
Hi,
I actually adapted and integrated this feature into Achim's -- nice --
function (posted on r-help).
Romain included it a couple of weeks ago into the bibtex package as
function write.bib, and submitted the update to CRAN, but some NOTEs
in the
It seems that there are speed issues when printing to the R console from a
tcl/tk GUI.
Here are functions to write a lot of output, and to display how long it
takes.
printsalot <- function(n)
{
for(i in 1:n) cat(i, fill = TRUE)
}
timings <- function(n = 1e3)
{
print(system.time(printsalot(n)
On 19 Dec 2011, at 12:22, Prof Brian Ripley wrote:
>> it seems there's a possible bug in edit(x) if x is a matrix filled with NA
>> only.
>
> It's as documented. Hint: look at mode(a) or str(a), and check what values
> are accepted for a logical matrix.
Thank you very much! I wasn't aware of
> Barry Rowlingson
> on Sun, 18 Dec 2011 01:32:52 + writes:
> Scenario: Here I am working away in R. I've got results
> that prove global warming is anthropogenic and also the
> solution for producing limitless carbon-neutral energy
> from nuclear fusion. Its been
On 19/12/2011 09:48, Hans-Jörg Bibiko wrote:
Hi,
it seems there's a possible bug in edit(x) if x is a matrix filled with NA only.
It's as documented. Hint: look at mode(a) or str(a), and check what
values are accepted for a logical matrix.
To reproduce please do the following:
a<- matrix
Hi,
it seems there's a possible bug in edit(x) if x is a matrix filled with NA only.
To reproduce please do the following:
a <- matrix()
edit(a)
change e.g. the cell value to 1 and close the GUI-based editor. edit(a) returns
NA. This also happens for any dimension of the matrix as long as all
16 matches
Mail list logo
