Re: [Rd] [R] Use of .Fortran

[Sharpie]

Prof Brian Ripley wrote:
> 
> Well, it is not Fortran 77 but Fortran 95, and so needs to be given a 
> .f95 extension to be sure to work.
> 

I think most compilers only distinguish two fortran file extensions: .f or
.f90.  .f denotes fixed-form source code while .f90 denotes free-form.  Some
compilers also take the capitalized versions, .F and .F90, to indicate
source code that must be run through a preprocessor.

It is a little weird, but Fortran file extensions have nothing to do with
the year of the language standard the code is to be compiled against.



David Scott wrote:
> 
> file SSFcoef.f
>  subroutine SSFcoef(nmax,nu,A,nrowA,ncolA)
>  implicit double precision(a-h,o-z)
>  implicit integer (i-n)
>  integer l,i,nmax
>  double precision nu,A(0:nmax,0:nmax)
>  A(0,0) = 1D0
>  do l=1,nmax
>   do i=1,l-1
> A(l,i) = (-nu+i+l-1D0)*A(l-1,i)+A(l-1,i-1)
>   end do
>   A(l,0) = (-nu+l-1D0)*A(l-1,0)
>   A(l,l) = 1D0
>  end do
>  return
>  end
> I created a dll (this is windows) using R CMD SHLIB SSFcoef.f
> Then my R code is:
> 
>  ### Load the compiled shared library in.
>  dyn.load("SSFcoef.dll")
> 
>  ### Write a function that calls the Fortran subroutine
>  SSFcoef <- function(nmax, nu){
>   .Fortran("SSFcoef",
>as.integer(nmax),
>as.integer(nu)
>)$A
>  }
> 
>  SSFcoef(10,2)
> 
> which when run gives
> 
>> SSFcoef(10,2)
>  NULL
> 
> I am pretty sure the problem is that I am not dealing with the matrix A
> properly. I also tried this on linux and got a segfault.
> 
> Can anyone supply the appropriate modification to my call (and possibly to
> the subroutine) to make this work?
> 

When calling a Fortran function for R, for each argument that appears in the
subroutine declaration:

  subroutine subName(...arg list...)

You *must* provide a matching input to the .Fortran() call:

  .Fortran("subName", ...arg list...)

In the case of arrays that are filled by the Fortran subroutine, just pass
an empty vector of the appropriate length- perhaps created using the
double() function.

-Charlie

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
-- 
View this message in context: 
http://r.789695.n4.nabble.com/Re-R-Use-of-Fortran-tp2260362p2261266.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] C or Java code generation

[Sharpie]

Romain Francois wrote:
> 
> Hi,
> 
> It installs just like any other R package, there is no need for a
> Makefile.
> 
> $ R CMD RInside_0.2.3.tar.gz
> 

Should probably be:

  R CMD INSTALL RInside_0.2.3.tar.gz


But are we misleading the OP a little bit about what RInside can help him
do?  His original question was:


Vyacheslav Karamov wrote:
> 
> Hi All!
> 
> I'm new to R and I need to know is it possible for R to generate C/C++ 
> source code, Java byte code or native Win32 DLL like MatLab?
> 

He stated that he was looking for this because:


Vyacheslav Karamov wrote:
> 
> Is there any posibility to use R without installing?
> I mean that I have my own application written in MS Visual C++ and I 
> need to use R script in this app. I can install R and use it via DCOM, 
> but it's not convenient for  the end users of my  program.
> 


I think the proper answer to this question is: R is an interpreted language. 
There is not any developed way to compile R code to machine code, an
executable or a library that can be distributed to a computer that does not
have a copy of R installed.


R does include a library with various names such as R.a, libR.so and R.dll
that contains the R interpreter and support functions which could be used to
distribute a stand alone executable that can run R code without the R
distribution being installed.

However the sticking point is packages; the OP is likely trying to embed R
in order to gain access to one, or several, R packages.  As far as I know,
there is no developed way to compile an R package down such that it could be
distributed, perhaps along with R.dll, and stand by its self.

It is theoretically possible, but there is no turnkey solution.


So, unless I am gravely mistaken, RInside is just a nice cross-platform
replacement for the RDCOM interface.  It won't solve the problem of needing
R installed on the client's computer in order to fully use the R environment
which is dependent on packages.

-Charlie

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
-- 
View this message in context: 
http://r.789695.n4.nabble.com/C-or-Java-code-generation-tp2330875p2332606.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] C or Java code generation

[Sharpie]

Dirk Eddelbuettel wrote:
> 
> 
> On 20 August 2010 at 08:02, Sharpie wrote:
> | So, unless I am gravely mistaken, RInside is just a nice cross-platform
> | replacement for the RDCOM interface.  It won't solve the problem of
> needing
> 
> I wrote RInside, and I am unaware of any attempts of mine to either copy,
> clone or otherwise imitate any of the non-portable technologies from the
> Pacific Northwest I happen to be rather unfamiliar with to boot.  So I
> fear
> that were indeed gravely mistaken. Thanks for trying though.
> 
> RInside delivers what it promises: an embedded R instance for your C++
> program.  And thanks to the magic that is Rcpp and all of the work Romain
> and
> I put into it, you get a rather rich interface between R and C++ that has
> no
> parallel I know of.
> 
> | R installed on the client's computer in order to fully use the R
> environment
> | which is dependent on packages.
> 
> That on the other hand is a true statement and as far as I am concerned a
> good thing as well.  
> 
> Dirk
> 

My apologies Dirk, I phrased that badly.  

What I ment is that RInside provides an interface by which the C++ program
can interact with R.  Essentially, what the OP would gain from RInside is
that he would not have to use DCOM.

-Charlie

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
-- 
View this message in context: 
http://r.789695.n4.nabble.com/C-or-Java-code-generation-tp2330875p2332632.html
Sent from the R devel mailing list archive at Nabble.com.

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

[Rd] Rserve graphics output [was Re: C or Java code generation]

[Sharpie]

Donald Paul Winston wrote:
> 
> Aren't you the guy who created Rserve?
> 
> I'd like to develop a web app so clients can perform exploratory data
> analysis with their browser with no installed software, not even java (I
> don't like applets). I thought R would be excellent for this but I need
> some issues cleared up before I invest a lot of time working with it. 
> 

Well, Simon is the one who create Rserve.  However, if you have questions
about Rserve it may be best to start a new thread or at least change the
subject header of your message.  This discussion was about creating
stand-alone executables that use R code for deployment on a desktop.  


Donald Paul Winston wrote:
> 
> It appears R insists on directing plot output to a file. Is their a
> graphics device that keeps the output in memory so it can be returned to
> my java app as a stream of bytes? If I have to wait for it to write to a
> "unique file" and then read it back again then I don't think that's going
> to work. My web app needs to support hundreds of concurrent clients. 
> 

As far as I know all R graphics output that does not go to a screen device,
such as an X window, must be directed to some sort of file.  I am not aware
of a graphics device that provides output to something other than a screen
or a file, but there very well may be such a device in existence.

The functionality you could describe could be implemented by writing a R
graphics device that forwards the R plotting commands to... well anywhere
you want, really.  As the author of an R graphics device, I can say the
trickiest part of such an undertaking will be calculating font metrics so
that R can properly position text in the graphics.  Everything else is very
straight-forward.

I have plans to write a device that forwards the plotting commands to a
socket connection that allows another program to execute them.  In my case,
an Erlang backbone is used to route the results back to web clients using
websockets.  The idea is to have the plot rendered directly in the client's
browser using a JavaScript library like RaphealJS.  However, the school year
is upon me and the project will probably remain on the drawing board until
next summer.


Donald Paul Winston wrote:
> 
> Is REngine.jar and REngineRserve.jar  all I need in my web app?
> 

I can't comment on REngine as I have not used it.


Donald Paul Winston wrote:
> 
> Also, how come their is no shutdown command from the command line for
> Rserve. I see one in the java client api. Do I have to write my own?
> 

I find that on UNIX a SIGTERM, SIGSTOP or SIGKILL signal broadcast using a
command line utility such as kill does the job.

-Charlie

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
-- 
View this message in context: 
http://r.789695.n4.nabble.com/C-or-Java-code-generation-tp2330875p2332761.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] How do you make a formal "feature" request?

[Sharpie]

Donald Paul Winston wrote:
> 
> Who decides what features are in R and how they are implemented? If there
> is someone here who has that authority I have this request: 
> 
> A report() function analogous to the plot() function that makes it easy to
> generate a report from a table of data. This should not be in some
> auxiliary package, but part of the core R just like plot(). As a long time
> SAS user I cannot believe R does not have this. Please don't give me any
> crap about Sweave, LaTex, and the "power" of R to roll your own. You don't
> have to "roll your own" plot do you? Reports are no different. If you
> don't agree do not bother me. If you agree then please bring this request
> to the appropriate authorities for consideration or tell me how to do it.
> 

Well, I can think of three ways it can go down:


1.  You want a shiny new pony.

You ask about it on the mailing list and it seems that everyone else in the
world responds "Hell yeah! I want to ride that too!".  In this case the
natives are restless enough that someone on R-Core may personally implement
the feature- especially if they want to ride the pony as well.

In this case, you need to provide a detailed specification of what kind of
pony you want, how it should be groomed and the exact pitch at which you
want it to whinny.  A good template for such as spec would be a Python
Enhancement Proposal (PEP) which is the way community-suggested core changes
are implemented in python.  An example is: 
http://www.python.org/dev/peps/pep-0389/

However, going this route is extremely rare.  You have to have a significant
amount of the user community rallying behind your idea and buy-in from core
developers who are interested in implementing and, most importantly,
maintaining and supporting the code.


2. You want a shiny new pony but not many other people in the word seem
interested.

In this situation you can do the work yourself, or with a group of other
like-minded pony enthusiasts, to bring your idea into the world.  Perhaps
the genetic material you are looking for is already present in the vast
herds of other ponies running wild on CRAN and elsewhere and you just have
to do a little breeding to get what you want.  Other times, the only way to
do right is to write everything from scratch.  Either way, in the end you
will have a pony that shines exactly the way you want it to that you can
enjoy for the rest of your life.

In this case, getting your new pony into R Core is unlikely.  The best
response you can hope for is something along the lines of "That is a mighty
fine pony you have there, but we really don't want it crapping all over our
stable".  They are not trying to be rude- the facts of life are that the
members of R Core have a limited amount of time and a lot of other ponies to
clean up after.  Add to that the fact that shoveling pony shit is a
thankless job that does not pay well and it is understandable why R Core may
be conservative about the number of ponies they let into the official
stable.

However, they will be more than happy to provide your pony with a stall at
CRAN so that everyone else in the world can take it out for a spin.  I have
never had a problem with installing and using packages from CRAN, even on
windows machines that have been locked down and then shot in both kneecaps
by the friendly neighborhood IT gestapo.  All and all, this option is
actually a pretty sweet deal; you will just have to drop by the CRAN stall
every once and a while and deal with the pony droppings yourself or people
will start to avoid it because of the smell.


3. You want a shiny new pony, but dont have the time or energy to pick out
or put together the exact one you want.

In this case, you can still get the pony you want but it will cost you
money.  There are R programmers out there who can write you a package if you
pay them the right price.  Supporting your local grad student population can
also work; hunger is a great motivator.

In the end you can also pay a corporate pony breeder like SAS for a trusty
thoroughbred that is well respected by people in high places.  However, you
may notice that these ponies bear some telltale signs of inbreeding-- one of
their eyes may not point in the same direction as the other or the pony
becomes confused easily when put in an unfamiliar situation.  Given there is
not a lot you can do about these defects, you may suffer a crippling case of
buyers remorse especially when you see the bill.


Ok, I think i've thoroughly beat this horse analogy to death and I'm going
to stop now.

-Charlie


-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
-- 
View this message in context: 
http://r.789695.n4.nabble.com/How-do-you-make-a-formal-feature-request-tp2333593p2333737.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] including DLL in a package

[Sharpie]

loosmart wrote:
> 
> Good afternoon! 
> 
> It may seem trivial to some/most of You, but I found it difficult to
> properly include a C++-based .dll into a package that I want to build for
> usage in R. I read through the "Writing R extensions..." & "R
> administration ..." instructions, but it seems I did not grasp the bigger
> picture.
> 
> The way I figured out to use the .dll in my package finally worked for
> using that package from the R console, but it gives multiple error and
> warning messages when running the RCMD check pkg command in the shell.
> 
> What I did: I created the package skeleton via package.skeleton()
> including a function that makes (1) a
> library.dynam() call to a .dll and (2) a .C() call including the name of
> the function in that DLL. Next, I run RCMD INSTALL pkg to install the
> package and then created a /lib folder in the installed package containing
> the .dll file.
> I tried alternatives, e.g., (a) containing a /src folder in may package
> skeleton with the .dll in it and/or (b) including zzz.R with a .First.lib
> function including the library call  but nothing worked out when
> running the package check.
> 
> help! thank You very much, MArtin
> 

Hi Martin,

I wrote a detailed example to a similar question on R-help.  It can be
viewed at:

http://r.789695.n4.nabble.com/Writing-own-simulation-function-in-C-td1580190.html#a1580423

The source code mentioned in the post can be obtained from:

http://gist.github.com/323498


The example was for C and not C++, but maybe it can help you get the package
building correctly.  Basically:

1) Write your C functions and put them in the /src directory of the package.

2) Write R wrappers for the C functions and put them in the /R directory
along with a zzz.R that includes a .First.Lib() which calls library.dynam().


With these requirements satisfied both R CMD INSTALL and R CMD build
--binary should be able to produce working packages.  Example files that
satisfy the points above are included in the source code I linked to.

Hope this helps!

-Charlie

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
-- 
View this message in context: 
http://r.789695.n4.nabble.com/including-DLL-in-a-package-tp2336420p2336992.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] embed Sweave driver in .Rnw file

[Sharpie]

Friedrich Leisch wrote:
> 
>> On Tue, 14 Dec 2010 12:40:04 +0100,
>> Romain Francois (RF) wrote:
> 
>   > Hello,
>   > Sweave lets you use alternative drivers through the driver argument,
> and 
>   > several packages take advantage of that and define custom Sweave
> driver 
>   > for various purposes. Most of them are listed on the Reproducible 
>   > Research CTV: 
>   > (http://cran.r-project.org/web/views/ReproducibleResearch.html)
> 
>   > The next natural step is for package developpers to take advantage of 
>   > this in their vignettes. In Rcpp we work around the way package
> building 
>   > works and we do:
>   > - let R build a dummy vignette
>   > - then use the inst/doc/Makefile to replace it with a vignette that is 
>   > processed by the driver from the highlight package (giving syntax 
>   > highlighting).
> 
>   > I played with Sweave so that it would be able to create the driver
> from 
>   > some text included in the text of the .Rnw file:
> 
>   > $ svn diff
>   > Index: src/library/utils/R/Sweave.R
>   > ===
>   > --- src/library/utils/R/Sweave.R  (revision 53846)
>   > +++ src/library/utils/R/Sweave.R  (working copy)
>   > @@ -20,6 +20,16 @@
>   >   # We don't need srclines for code, but we do need it for text, and 
>   > it's easiest
>   >   # to just keep it for everything.
> 
>   > +SweaveGetDriver <- function(file){
>   > +txt <- readLines(file)
>   > +line <- grep( "\\SweaveDriver", txt, value = TRUE )
>   > +if( length(line) ){
>   > +txt <- sub( "^.*\\SweaveDriver[{](.*)[}]", "\\1", line[1L] )
>   > +driver <- try( eval( parse( text = txt ) ), silent = TRUE )
>   > +if( !inherits( driver, "try-error") ) driver
>   > +}
>   > +}
>   > +
>   >   Sweave <- function(file, driver=RweaveLatex(),
>   >  syntax=getOption("SweaveSyntax"), ...)
>   >   {
>   > @@ -28,7 +38,9 @@
>   >   else if(is.function(driver))
>   >   driver <- driver()
> 
>   > -
>   > +drv <- SweaveGetDriver(file)
>   > +if( !is.null(drv) ) driver <- drv
>   > +
>   >   if(is.null(syntax))
>   >   syntax <- SweaveGetSyntax(file)
>   >   if(is.character(syntax))
> 
> 
> 
>   > This allows one to write something like this in their file:
> 
>   > %\SweaveDriver{ { require(highlight); HighlightWeaveLatex() } }
> 
>   > So that when calling :
> 
>   >> Sweave( "somefile.Rnw" )
> 
>   > the highlight driver is used instead of the default driver.
> 
>   > Could something like that be added to Sweave ?
> 
> Yes, sure!
> 
> Will have a look at the patch later this week and apply it if it
> passes the tests. The patch is against a current r-devel?
> 
> Best,
> Fritz
> 


Is there an update on the status of this patch?  I use a particularly ugly
hack to splice a custom driver into one of my package Vignettes and it would
be great to retire it in favor of an officially supported method.

-Charlie  

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
-- 
View this message in context: 
http://r.789695.n4.nabble.com/embed-Sweave-driver-in-Rnw-file-tp3086897p3300339.html
Sent from the R devel mailing list archive at Nabble.com.

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

[Rd] R 2.13.0-beta for Windows, file.copy() throws suspicious errors due to default value of copy.mode

[Sharpie]

While checking packages against R 2.13.0-beta on Windows, I have run into a
few strange error messages related to copying files. The errors all relate
to file.copy() and have the form of:

Error in Sys.chmod(to[okay], file.info(from[okay])$mode, TRUE) : 
  'mode' must be of length at least one

After half a day of tinkering, the best reproducible example I can come up
with involves using Roxygen to generate man files for the tikzDevice:

# Install roxygen from CRAN and grab tikzDevice source code
R --vanilla --slave -e "install.packages('roxygen')"
git clone git://github.com/Sharpie/RTikZDevice.git

# Generate documentation, first run succeeds:
R --vanilla --slave -e "require(roxygen); roxygenize('RTikZDevice',
'RTikZDevice.build', overwrite = TRUE)"

Loading required package: roxygen
Loading required package: digest
Writing anyMultibyteUTF8Characters to
RTikZDevice.copy/man/anyMultibyteUTF8Characters.Rd
Warning in parse.name(partitum) :
  No name found for the following expression in RTikZDevice/R/cacheMetrics.R
line 3:
  `NULL . . .'
Writing queryMetricsDictionary to
RTikZDevice.copy/man/queryMetricsDictionary.Rd
...
Writing namespace directives to RTikZDevice.copy/NAMESPACE 
Merging collate directive with RTikZDevice/DESCRIPTION to
RTikZDevice.copy/DESCRIPTION 

# Try running it again, and it bombs:
R --vanilla --slave -e "require(roxygen); roxygenize('RTikZDevice',
'RTikZDevice.build', overwrite = TRUE)"

Loading required package: roxygen
Loading required package: digest
Error in Sys.chmod(to[okay], file.info(from[okay])$mode, TRUE) : 
  'mode' must be of length at least one
Calls: roxygenize -> copy.dir -> file.copy -> Sys.chmod
In addition: Warning message:
In file.create(to[okay]) :
  cannot create file
'RTikZDevice.copy/.git/objects/pack/pack-cc0dd1e2622e87f86f8c5a8e617fbf77e253cea1.idx',
reason 'Permission denied'
Execution halted


If I replace all calls to file.copy(...) in the roxygen package with
file.copy(..., copy.mode = FALSE) and reinstall it, then I can regenerate
package documentation all day long without errors. I also get no errors when
I perform the same task with R 2.12.2 on Windows or R 2.13.0-beta on OS X
and Linux.

Maybe roxygenize() is abusing file.copy() somehow, but I find the "'mode'
must be of length at least one" error suspicious.

Any ideas?

Using:
Windows 7 x86_64
R 2.13.0-beta
Rtools 2.13

-Charlie


-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
--
View this message in context: 
http://r.789695.n4.nabble.com/R-2-13-0-beta-for-Windows-file-copy-throws-suspicious-errors-due-to-default-value-of-copy-mode-tp3434559p3434559.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] How to get R to compile with PNG support

[Sharpie]

Dear R devel list,

Good morning; I'm with the Sage (http://www.sagemath.org) project.
(Some of you might have seen my talk on this at last summer's useR
conference).

Thanks for stoping by Karl! I have to say that I am a big fan of the Sage
project---it is a very good idea and I really appreciate all the time you
guys put into it. I may not be able to answer all of your questions
concerning PNG support, but hopefully some of the following pointers will be
useful.



Karl-Dieter Crisman wrote:
> 
> We have some rudimentary support for using R graphics in various
> cases, which has proved useful to many of our users who want to go
> back and forth between R and other capabilities within Sage.
> Unfortunately, the way we originally implemented this was using the
> png and plot functions in R itself, which perhaps isn't the best
> (i.e., everyone uses ggplot now? but I digress).
> 

One important distinction to make is between R graphics functions such as
plot and ggplot, and R graphics *devices*, such as png. The devices provide
back ends that take the R-level function calls and actually execute the
low-level "draw line from a to b, clip to rectangle A, insert left-justified
text at x,y" primitives that get written to an output format.

Bottom line for Sage is that as long as you implement at least one device
function, such as png, your users should be able to call plot, ggplot, and
the rest of R's graphics functions to their heart's content, they just won't
have a wide selection of output formats.



Karl-Dieter Crisman wrote:
> 
> That means that when people download a binary of ours, or compile
> their own, whether R's plot and png functions work depends heavily on
> the rather obscure (to users) issue of exactly what headers are
> present on the compiling machine.
> 
> Unfortunately, it is *very* unclear what actually needs to be present!
>  There are innumerable places where this has come up for us, but
> http://trac.sagemath.org/sage_trac/ticket/8868 and
> http://ask.sagemath.org/question/192/compiling-r-with-png-support are
> two of the current places where people have compiled information.
> 
> The FAQ says, "Unless you do not want to view graphs on-screen you
> need ‘X11’ installed, including its headers and client libraries. For
> recent Fedora distributions it means (at least) ‘libX11’,
> ‘libX11-devel’, ‘libXt’ and ‘libXt-devel’. On Debian we recommend the
> meta-package ‘xorg-dev’. If you really do not want these you will need
> to explicitly configure R without X11, using --with-x=no."
> 
> Well, we don't actually need to view graphs on-screen, but we do need
> to be able to generate them and save them (as pngs, for instance) to
> the correct directory in Sage for viewing.  But we have people who've
> tried to do this in Ubuntu, with libpng and xorg-dev installed, and
> the file /usr/include/X11/Xwindows.h exists, but all to no avail.
> There are almost as many solutions people have found as there are
> computers out there, it seems - slight hyperbole, but that's what it
> feels like.
> 
> We've posted more than once (I think) to the r-help list, but have
> gotten no useful feedback.  Is there *anywhere* that the *exact*
> requirements R has for having
> 
> capabilities("png")
>   png
> FALSE
> 
> come out TRUE are documented?
> 
> Then, not only could we be smarter in how we compile R (currently
> somewhat naively searching for /usr/include/X11/Xwindows.h to
> determine whether we'll try for png support), but we would be able to
> tell users something very precise to do (e.g., apt-get foo) if they
> currently have R without PNG support in Sage.  Again, I emphasize that
> apparently getting xorg-dev doesn't always do the trick.
> 
> We do realize that for most people wanting to use just R, it's best to
> download a binary, which will behave nicely; Sage's "batteries
> included" philosophy means that we are asking for more specialized
> info from upstream, and for that I apologize in advance.  I also
> apologize if I said something silly above, because I don't actually
> know what all these files are - I've just looked into enough support
> requests to have a decent idea of what's required.We are trying
> not to have to parse the makefile to figure all this out, and possibly
> making some mistake there as well.
> 
> Thank you SO much for any help with this,
> Karl-Dieter Crisman
> for the Sage team
> 


In the trac ticket you linked, the configure output shows PNG is enabled
(I.E. the library was found) but you may be ending up with no support for an
actual png() graphics device due to one of the following

  - configure didn't find Xlib as X11 is not listed under Interfaces
  - configure didn't find cairo as it is not listed under Additional
capabilities

So, although R has the PNG library that is only useful for writing PNG
files. R also needs the Xlib or Cairo libraries to provide drawing
primitives that will create the figures those files will contain.

In the ask.sagemath question the 

Re: [Rd] Sweave support added to rgl package

[Sharpie]

Duncan Murdoch-2 wrote:
> 
> I have just committed some code to the rgl package on 
> https://r-forge.r-project.org/projects/rgl/ to allow rgl images to be 
> inserted into Sweave documents.  (This is not in the CRAN version yet.)  
> It makes use of the custom graphics driver support added by Brian Ripley.
> 
> In R-devel (which will become R 2.14.0 next spring in New Zealand, next 
> fall in most other places), usage is quite straightforward.  For
> example, code like this in a Sweave document:
> 
> <>=
> x <- rnorm(100); y <- rnorm(100); z <- rnorm(100)
> plot3d(x, y, z)
> @
> 
> will insert a .png snapshot of the figure.  Because that chunk has 
> "stayopen=TRUE", it can be followed by another chunk to add
> to the figure, e.g.
> 
> <>=
> lines3d(x[1:10], y[1:10], z[1:10], col="red")
> @
> 
> All of this is possible in R 2.13.0, but it takes more work:  see the 
> ?rgl.Sweave help page.
> 
> I will eventually add postscript and PDF output options as well, and 
> perhaps some support for the LaTeX movie15 package, but those are not 
> there yet.  Comments or bug reports are welcome.
> 
> Duncan Murdoch
> 

This is great news Duncan!

If you do consider adding support for movie15, the Asymptote graphics
language may be handy:

http://asymptote.sourceforge.net/

Asymptote can embed 3D graphs into LaTeX documents that are fully
zoomable/manipulatable. It also uses LaTeX to typeset the figure text.

-Charlie


-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
--
View this message in context: 
http://r.789695.n4.nabble.com/Sweave-support-added-to-rgl-package-tp3461163p3463653.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] Patching "update.packages" to enable updating of only a user defined subset of packages

[Sharpie]

Tal Galili wrote:
> 
> Hello dear R developers,
> 
> I recently found out that it is not possible to limit update.packages() to
> update only a few packages at a time.
> 
> The patch offered simply adds a 'subset' parameter and the statement
> bounded
> within "if(!missing(subset))" to implement it.
> The code is pasted bellow (and also attached as an .r file).
> 
> Might this patch be considered valuable to be added to R?
> 
> 
> (in the code bellow I called the function "update.packages.2" so to not
> mask
> the original update.packages)
> 
> 
> With much respect,
> Tal
> 

Hi Tal,

I think if you pass a character vector in the `oldPkgs` argument of
update.packages, it will only consider packages in that list for updating.

-Charlie


-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
--
View this message in context: 
http://r.789695.n4.nabble.com/Patching-update-packages-to-enable-updating-of-only-a-user-defined-subset-of-packages-tp3456738p3463670.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] FW: [Rcpp-devel] Question on 5.6 Interfacing C++ code

[Sharpie]

smcguffee wrote:
> 
> You are right, I looked and I did find the R source code. However, it's
> largely written in R! I mean, I don't know how to trace the R code where
> INSTALL is recognized and follow it to a c or c++ level command. For
> example
> these are hits in .R files, not c files, and I don't know how to connect
> 
> ...
> 
> If you could point me to the functions that are called a c or c++ level,
> I'd
> love to see what R is doing for myself.
> Thanks!
> Sean
> 

Hi Sean!

Along with many other people in this thread, I would strongly recommend a
top-down approach to this. Build a package, stick some stuff in the src
folder, run R CMD INSTALL on it and see what happens. The reason I recommend
this approach is that it lets you focus on writing a package that does
something useful rather than the nuts and bolts of cross platform
compilation and installation. R CMD INSTALL takes care of this for you
automagically and it is very good at what it does.

I wrote a post some time back about building an example package from scratch
that contains C code:

http://r.789695.n4.nabble.com/Writing-own-simulation-function-in-C-td1580190.html#a1580423

It begins with the using the package.skeleton() function to kickstart
things, discusses how to make sure the compiled code is dynamically loaded
when a user runs library(your_package) and even discusses how to call R
functions from inside of C functions and vice-versa. The example code is
still available and I'm sure it could be generalized to C++ quite easily. 
There are also some other responses in that thread that offer useful advice.


At the beginning it is just best to treat R CMD INSTALL as a magical unicorn
that gets you where you need to go:

http://abstrusegoose.com/120
(keep clicking the images to get the full story)


If you are absolutely, positively dying to know what really happens... well,
the relative files in the R source are `src/library/tools/R/install.R` and
`src/library/tools/R/build.R`.


But seriously. Magical unicorn. Takes care of the hard stuff so you can
build awesome packages.

Hope this helps!

-Charlie

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
--
View this message in context: 
http://r.789695.n4.nabble.com/FW-Rcpp-devel-Question-on-5-6-Interfacing-C-code-tp3465257p3467221.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] FW: [Rcpp-devel] Question on 5.6 Interfacing C++ code

[Sharpie]

tion and execution
> options,
> but I imagine it would be way over my head, a long time coming, and of
> course potentially unstable. The long and short of it for me is that it
> was
> way cool to see how R is calling C functions from packages or non-R
> libraries.
> 

Quite a brain dump there!  Some things that you may want to look into in the
future:

  - The original mailing list you posted to, Rcpp, is for an R package that
wraps the C API of R into C++ classes.  I would bet it also provides methods
for calling R code and C++ without having to write as many R functions.  I
have not had the pleasure of using Rcpp yet---Fortran was my first compiled
language and I am still moving my way up the food chain :)

  - The inline package may be of interest to you---It allows C, C++ and
Fortran programs to be stored as text strings at the R level and then
dynamically compiled, loaded and interfaced.  Could be along the lines of
what you were thinking about with "building dynamic compilation and
execution options".

  - Also, it is always fun to drop by the Omegahat project
(www.omegahat.org) and see what Duncan Temple Lang has been cooking up. He
has a couple of packages for interfacing R with compiled code via LibFFI
(rather than the built in pointer method you observed) and one package that
has the beginnings of some LLVM bindings.


-Charlie


On 4/21/11 10:02 PM, "Sharpie" <ch...@sharpsteen.net> wrote:

> 
> smcguffee wrote:
>> 
>> You are right, I looked and I did find the R source code. However, it's
>> largely written in R! I mean, I don't know how to trace the R code where
>> INSTALL is recognized and follow it to a c or c++ level command. For
>> example
>> these are hits in .R files, not c files, and I don't know how to connect
>> 
>> ...
>> 
>> If you could point me to the functions that are called a c or c++ level,
>> I'd
>> love to see what R is doing for myself.
>> Thanks!
>> Sean
>> 
> 
> Hi Sean!
> 
> Along with many other people in this thread, I would strongly recommend a
> top-down approach to this. Build a package, stick some stuff in the src
> folder, run R CMD INSTALL on it and see what happens. The reason I
> recommend
> this approach is that it lets you focus on writing a package that does
> something useful rather than the nuts and bolts of cross platform
> compilation and installation. R CMD INSTALL takes care of this for you
> automagically and it is very good at what it does.
> 
> I wrote a post some time back about building an example package from
> scratch
> that contains C code:
> 
> http://r.789695.n4.nabble.com/Writing-own-simulation-function-in-C-td1580190.h
> tml#a1580423
> 
> It begins with the using the package.skeleton() function to kickstart
> things, discusses how to make sure the compiled code is dynamically loaded
> when a user runs library(your_package) and even discusses how to call R
> functions from inside of C functions and vice-versa. The example code is
> still available and I'm sure it could be generalized to C++ quite easily.
> There are also some other responses in that thread that offer useful
> advice.
> 
> 
> At the beginning it is just best to treat R CMD INSTALL as a magical
> unicorn
> that gets you where you need to go:
> 
> http://abstrusegoose.com/120
> (keep clicking the images to get the full story)
> 
> 
> If you are absolutely, positively dying to know what really happens...
> well,
> the relative files in the R source are `src/library/tools/R/install.R` and
> `src/library/tools/R/build.R`.
> 
> 
> But seriously. Magical unicorn. Takes care of the hard stuff so you can
> build awesome packages.
> 
> Hope this helps!
> 
> -Charlie


-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
--
View this message in context: 
http://r.789695.n4.nabble.com/FW-Rcpp-devel-Question-on-5-6-Interfacing-C-code-tp3465257p3468640.html
Sent from the R devel mailing list archive at Nabble.com.

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

[Rd] Source for bash_completion.d/R?

[Sharpie]

Hello, I was just tweaking the R build for the Homebrew package manager and I
thought it would be nice to enable bash completion. I noticed that
Debian-based systems install `/etc/bash_completion.d/R` but could not find a
source for this file in the `etc` folder of the R source.

Is the R bash completion script publicly available somewhere so that it
could be pulled in by curl?

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
--
View this message in context: 
http://r.789695.n4.nabble.com/Source-for-bash-completion-d-R-tp3490662p3490662.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] Curry: proposed new functional programming, er, function.

[Sharpie]

Byron Ellis-2 wrote:
> 
> Hi all (especially R-core) I suppose,
> 
> With the introduction of the new functional programming functions into
> base I thought I'd ask for a Curry() function. I use a simple one that
> looks this:
> 
> Curry = function(FUN,...) { .orig = list(...);function(...)
> do.call(FUN,c(.orig,list(...))) }
> 
> ...
> 
> 

I would like to see this as well---it is one of the functional programming
constructs I really miss in R after playing with languages like Haskell.

Currently, the only Curry implementation I know of is in the roxygen package
which is kind of a weird dependency to install just for this one function.

-Charlie

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
--
View this message in context: 
http://r.789695.n4.nabble.com/Curry-proposed-new-functional-programming-er-function-tp917654p3496226.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows

[Sharpie]

Yihui Xie-2 wrote:
> 
> Hi,
> 
> I guess this issue must have been brought forward long time ago, but I
> still hope you can consider under Windows (during installation):
> 
> 1. put R's bin path in the PATH variable of the system so that we can
> use the commands "R" and "Rscript" more easily;
> 

On one hand it certainly would be nice to have this as an option similar to
what the RTools installer does. For the 32/64 bit decision, perhaps
RHOME/bin could be placed on the PATH and bin/R.exe turned into a bin/R.bat
that calls bin/i386/R.exe, bin/x64/R.exe depending on the Windows
architecture.

On the other hand, the grizzled developer in me is saying "this is a
teaching moment. If someone is using a programming language they should know
what an environment variable is and how to set it".  Admittingly, setting
environment variables is a PITA on Windows compared to UNIX. Here's a great
freeware tool I have found that makes it so much easier:

  http://www.rapidee.com

Another issue is that many Windows machines are locked down in such a way
that environment variables cannot be set permanently. To deal with this, I
carry a USB stick that has R installed on it and a batch script that
`setx`es environment variables for me. Combined with an `autorun.inf`
script, this basically lets me plug my USB stick into a Windows machine and
get to work without worrying about how careful the sysadmin was when they
set up the tools I like to use (or if they even bothered to include the
tools I like to use).

A good video tutorial for setting up autorun.inf from Tinkernut.com:

  http://www.youtube.com/watch?v=lFlgddjOPpw

Some of the things in that video are outdated and the overall goal is to
show how they could be used for nefarious purposes, but the part about
converting a `.bat` script to a `.exe` binary and setting up an autorun.inf
to execute the result is solid. Combine with MikTeX Portable and you should
be able to Sweave from anywhere.



Yihui Xie-2 wrote:
> 
> 2. remove the version string like R-2.13.0 in the default installation
> directory, e.g. only use a directory like C:/Program Files/R/ instead
> of C:/Program Files/R/R-2.13.0/; I know many people just follow the
> default setting when installing R, and this version string will often
> lead to many (unnecessary) copies of R in the system and brings
> difficulty to the first issue (several possible bin directories);
> 
> I'm aware of some existing efforts in overcoming the difficulty of
> calling R under Windows like the R batch files project
> (http://code.google.com/p/batchfiles/), but I believe this is better
> to be solved in R directly.
> 

As a package developer I rather like this---I can have multiple versions of
R installed and easily set up my testsuite such that it loops through each
one and executes the tests.

-Charlie


-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
--
View this message in context: 
http://r.789695.n4.nabble.com/Wishlist-write-R-s-bin-path-to-the-PATH-variable-and-remove-the-version-string-in-the-installation-ds-tp3493922p3496533.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] fortan common block

[Sharpie]

Paul Gilbert wrote:
> 
> Is it possible in R to call a fortran routine that sets variables in a
> common block and expect the values to persist when a call is made from R
> to a second routine that uses the common block?
> 
> If not (as I suspect),  is it possible to use a common block in a group of
> routines that are used together, for as long the routines do not return to
> R?
> 
> Paul
> 

Don't see why not--should be pretty easy to test. Personally, I would use
variables in a Fortran 90 module over a common block.

-Charlie

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
--
View this message in context: 
http://r.789695.n4.nabble.com/fortan-common-block-tp3503204p3506373.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] matrix multiplication speed R

[Sharpie]

aftar wrote:
> 
> Hi
> 
> Can we use BLAS in R X64 for windows?
> 
> Regards
> Aftar
> 

You are already using BLAS in R as R includes its own BLAS library. On
Windows the 64-bit DLL is located at R_HOME\bin\x64\Rblas.dll.

If you are asking about swapping that out for an optimized BLAS, you will
probably have to:

  1. Obtain and build an optimized BLAS such as ATLAS, Goto BLAS or Intel
MKL

  2. Build your own copy of R from source that links against this new blas.

If there is a simpler way, I'm sure someone will correct me.


-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
--
View this message in context: 
http://r.789695.n4.nabble.com/matrix-multiplication-speed-R-tp3217257p3510979.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] Fortran Symbol Name not in Load Table

[Sharpie]

vioravis wrote:
> 
> I used the DLL export viewer to what is the table name being exported. It
> is showing as VALUEAHROPTIMIZE_. This is the name of the function we have
> used plus the underscore.
> 
> Is there any other reason for the function not getting recognized???
> Thanks.
> 

Which compiler are you using? Which version of R?

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
--
View this message in context: 
http://r.789695.n4.nabble.com/Fortran-Symbol-Name-not-in-Load-Table-tp3508719p3513005.html
Sent from the R devel mailing list archive at Nabble.com.

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

[Rd] Inconsistencies in device_Raster when axes are reflected

[Sharpie]

I noticed some undocumented and inconsistent behavior in device_Raster when a
plot is produced with reflected axes such as:

image(volcano, xlim = c(1,0), useRaster = TRUE)
image(volcano, ylim = c(1,0), useRaster = TRUE)

The `pdf` device will perform horizontal and vertical reflections, while
`quartz` will ignore the transformations when plotting to the screen, but
when plotting to a file, `quartz(file = 'test.pdf', type = 'pdf')`, it will
produce horizontal reflections and ignore vertical ones.

When the `xlim` or `ylim` is reversed, negative widths and heights are
passed to the C function `device_Raster`, which is not a behavior documented
in `R_ext/GraphicsDevice.h`. Also, the values of `x` and `y` passed to
`device_Raster` will be shifted by the width or height of the image such
that the coordinates no longer reference the bottom-left corner of the image
as `R_ext/GraphicsDevice.h` says they should.

Given the inconsistencies in documentation and behavior, I am wondering what
the intended behavior of `device_Raster` is in this situation.

Thanks!

-Charlie

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
--
View this message in context: 
http://r.789695.n4.nabble.com/Inconsistencies-in-device-Raster-when-axes-are-reflected-tp4286320p4286320.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] Command completion of the R binary / Ubuntu

[Sharpie]

Deepayan Sarkar-3 wrote
> 
> I believe only Debian/Ubuntu package it (and this would have been more
> appropriate for r-sig-debian). I'll coordinate with Dirk et al to
> update the relevant files.
> 
> -Deepayan
> 

The bash completion script is also used by the Homebrew package manager on
OS X.

-Charlie

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
--
View this message in context: 
http://r.789695.n4.nabble.com/Command-completion-of-the-R-binary-Ubuntu-tp4285040p4286476.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] Inconsistencies in device_Raster when axes are reflected

[Sharpie]

Paul Murrell wrote
> 
> I think the problem is that I just failed to anticipate this situation 
> (i.e., the current documentation and behaviour both assume xlim[1] < 
> xlim[2] and ylim[1] < ylim[2]).
> 
> Will take a look at where to apply a fix (EITHER allow the API to be 
> more flexible [allow negative 'width' and 'height' and 'x' and 'y' to be 
> other than left-bottom], which will require complicating the code in 
> some devices OR keep the API fixed and complicate the graphics engine 
> code instead).  The rotation argument adds an interesting twist ...
> 
> Thanks for the report!
> 
> Paul
> 

Thanks for the reply Paul!

This isn't too hard to handle at the device level. For example, all I had to
do to the tikzDevice was add a loop and some logic that re-ordered the
raster vector and re-positioned the coordinate anchor:


int i, j, index, target, row_offset = 0, col_offset = 0, row_trans = 1,
col_trans = 1;
  if ( height < 0 ) {
/* Using these parameters, one can cause a loop to "count backwards" */
row_trans = -1;
row_offset = h - 1;
/*
 * If a dimension is negative, the (x,y) coordinate no longer references
 * the lower left corner of the image. We correct for this and then make
 * sure the dimension is positive.
 */
y += height;
height = fabs(height);
  }

  if ( width < 0 ) {
col_trans = -1;
col_offset = w - 1;
x += width;
width = fabs(width);
  }

  for ( i = 0; i < h; ++i ) {
for ( j = 0; j < w; ++j ) {
  target = i*w + j;
  index = (row_trans*i + row_offset)*w + (col_trans*j + col_offset);

  INTEGER(red_vec)[target] = R_RED(raster[index]);
  INTEGER(green_vec)[target] = R_BLUE(raster[index]);
  INTEGER(blue_vec)[target] = R_GREEN(raster[index]);
  INTEGER(alpha_vec)[target] = R_ALPHA(raster[index]);
}
  }


This gives the device the same behavior as the PDF device. So, the behavior
isn't too difficult to correct on the device end---I was just concerned by
the difference between documentation and behavior and wanted to make sure
the graphics engine was not expecting something different.


-Charlie

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
--
View this message in context: 
http://r.789695.n4.nabble.com/Inconsistencies-in-device-Raster-when-axes-are-reflected-tp4286320p4289713.html
Sent from the R devel mailing list archive at Nabble.com.

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

[Rd] Ignore user interrupts

[Sharpie]

Is there a way to suspend user interrupts for the duration of a function
call? There is a point in one of my packages where values are being written
to a Filehash database. If the user is unlucky enough to send an interrupt
while this code is active, then they have to:

  - Hunt down a lock file and dispose of it before the package will work
again.

  - Possibly trash the Filehash database and start over if the interrupt
caused R to leave the database file in a corrupted state.

Is there something analogous to the C macros
BEGIN_SUSPEND_INTERRUPTS/END_SUSPEND_INTERRUPTS that I can use at the R
level to delay interrupts until after critical code has executed?

If not, would it work to move the function call into a C function that uses
`eval` inside a block protected by BEGIN_SUSPEND_INTERRUPTS?

-Charlie

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
--
View this message in context: 
http://r.789695.n4.nabble.com/Ignore-user-interrupts-tp4321252p4321252.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] Ignore user interrupts

[Sharpie]

Sharpie wrote
> 
> If not, would it work to move the function call into a C function that
> uses `eval` inside a block protected by BEGIN_SUSPEND_INTERRUPTS?
> 

Just to clarify, if there is no functionality at the R level for evaluating
an expression without interrupts, would it be possible to create it by
defining a function:

evalWithoutInterrupts <- function(expr, envir = parent.frame())
{
  .Call(do_evalWithoutInterrupts, expr, envir)
}


With a C-level implemention:

SEXPR do_evalWithoutInterrupts(SEXP expr, SEXP envir)
{
  SEXP result;

  BEGIN_SUSPEND_INTERRUPTS{
result = eval(expr, envir);
  }END_SUSPEND_INTERRUPTS;

  return result;
}


Would that be a correct way to tackle the problem?

-Charlie

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
--
View this message in context: 
http://r.789695.n4.nabble.com/Ignore-user-interrupts-tp4321252p4321817.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] Non-default build options

[Sharpie]

Dirk Eddelbuettel wrote
> 
>b) having BLAS as a defined interface is wonderful for swapping default
>   (unaccelerated) BLAS for accelerated BLAS like Atlas, Goto,
> OpenBLAS,
>   MKL, ... Several of these BLAS have in fact been available for
> either
>   Debian or Ubuntu in some form (sometimes involving a helper script
> as
>   eg Goto could never be part of an FLOSS distro).
> 

Just an aside: Goto BLAS is now available under the BSD license, so it
should be perfectly acceptable to include in a FLOSS distribution. However,
development has ceased so Goto will probably loose it's edge as new CPU
families are shipped.

-Charlie

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
--
View this message in context: 
http://r.789695.n4.nabble.com/Non-default-build-options-tp4328512p4329615.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] Ignore user interrupts

[Sharpie]

Sharpie wrote
> 
> evalWithoutInterrupts <- function(expr, envir = parent.frame())
> {
>   .Call(do_evalWithoutInterrupts, expr, envir)
> }
> 
> 
> With a C-level implemention:
> 
> SEXPR do_evalWithoutInterrupts(SEXP expr, SEXP envir)
> {
>   SEXP result;
> 
>   BEGIN_SUSPEND_INTERRUPTS{
> result = eval(expr, envir);
>   }END_SUSPEND_INTERRUPTS;
> 
>   return result;
> }
> 

Some more info, and a possible bug:

This approach appears to work if I change `evalWithoutInterrupts` so that it
invokes `substitute` on `expr` before passing to the C code:


evalWithoutInterrupts <- function(expr, envir = parent.frame())
{
  .Call(do_evalWithoutInterrupts, substitute(expr), envir)
}


For example, I can do the following (using OS X, R 2.14.1 in Terminal.app):

eval({for(i in 1:1000){log(i)};message("Hello, world!")})
evalWithoutInterrupts({for(i in 1:1000){log(i)};message("Hello,
world!")})

The `eval` call can be interrupted by CTRL-C as normal. However, with the
`evalWithoutInterrupts` call, I can tap on CTRL-C and the loop will still
execute, "Hello, world!" will be printed and then the interrupt will be
registered:

> evalWithoutInterrupts({for(i in 1:1000){log(i)};message("Hello,
world!")})
^C^C^C^C^CHello, world!

> 


The only odd thing I came across was when I tried to test this function
using `Sys.sleep` instead of a long loop:

evalWithoutInterrupts(Sys.sleep(3);message("Hello, world!")})

The call can be interrupted immediately by CTRL-C. Some poking in GDB
reveals that the call chain passes from my C function
`evalWithoutInterrupts` to `do_syssleep` an finally to `Rf_onintr` through
`R_checkActivity`:

Breakpoint 1, Rf_onintr () at errors.c:123
123 if (R_interrupts_suspended) {
(gdb) bt   
#0  Rf_onintr () at errors.c:123
#1  0x0001001ced41 in R_SelectEx (n=1, readfds=0x10038cdc0,
writefds=0x0, exceptfds=0x0, timeout=0x7fff5fbf8b60, intr=0) at
sys-std.c:127
#2  0x0001001cf109 in R_checkActivityEx (usec=300, ignore_stdin=1,
intr=0) at sys-std.c:329
#3  0x0001001cf14b in R_checkActivity (usec=300, ignore_stdin=1) at
sys-std.c:338
#4  0x0001001d0fbb in do_syssleep (call=0x1025bb200, op=0x10086d0d8,
args=0x1033679b8, rho=0x1033679f0) at sys-std.c:1299
#5  0x0001000c7608 in bcEval (body=0x1025ba878, rho=0x1033679f0,
useCache=TRUE) at eval.c:4445
#6  0x0001000bcb69 in Rf_eval (e=0x1025ba878, rho=0x1033679f0) at
eval.c:401
#7  0x0001000bddd7 in Rf_applyClosure (call=0x103366e38, op=0x1025ba8e8,
arglist=0x103367a60, rho=0x100877ea8, suppliedenv=0x100877ee0) at eval.c:840
#8  0x0001000bd22e in Rf_eval (e=0x103366e38, rho=0x100877ea8) at
eval.c:515
#9  0x0001000bf879 in do_begin (call=0x103366ee0, op=0x10084e6e0,
args=0x103366dc8, rho=0x100877ea8) at eval.c:1422
#10 0x0001000bcf40 in Rf_eval (e=0x103366ee0, rho=0x100877ea8) at
eval.c:471
#11 0x000102fc736d in evalWithoutInterrupts ()


However, at this point the variable `R_interrupts_suspended` is not set to
`TRUE` as I would expect due to the `BEGIN_SUSPEND_INTERRUPTS` block in
`evalWithoutInterrupts`:

(gdb) p R_interrupts_suspended 
$1 = FALSE


Bug?

-Charlie


-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
--
View this message in context: 
http://r.789695.n4.nabble.com/Ignore-user-interrupts-tp4321252p4331653.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] Tabs in R source code

[Sharpie]

pengyu.ut wrote:
> 
> http://google-styleguide.googlecode.com/svn/trunk/google-r-style.html
> 
> Here is the R style, which does not recommend using tabs. Although it
> might take some time to forbidden the use of tabs, it will eventually
> be a good practice that benefits everyone in the future.
> 

Whoa, put the kibosh on that thought. 

That is Google's style guide for R code written at Google by Google
employees.  It is by no means the style guide adopted by the R core team. 
Representing it as the "official" R style guide is just inviting a torrent
of flaming email.

-- 
View this message in context: 
http://n4.nabble.com/Tabs-in-R-source-code-tp930751p948240.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] Getting started with .C

[Sharpie]

Jeff Brown wrote:
> 
> Hi,
> 
> I'm trying to learn to use .C, which lets one invoke compiled C code from
> within R.  To do that, one has to first get the C code into R as a shared
> object, which (I think) means first compiling it (with COMPILE or SHLIB)
> and then loading it (with dyn.load()).  
> 

I would suggest taking it a step further and building an R package to hold
your compiled code.  The pros are:

  *  It keeps the R wrapper scripts and other things you will end up
creating packaged together with your code.

  *  It handles compilation automagically during installation.

  *  It handles loading the dylib for you.

The only con I can think of is:

  *  It takes ~2 extra minutes of your time to set up.  But compared to
other languages I have used this is a ridiculously small price to pay for
the portability and organization offered by packages.

I wrote a post that goes through step-by-step how to do this for the .Call()
interface, including example code.  You can find it at:

 
http://n4.nabble.com/Writing-own-simulation-function-in-C-td1580190.html#a1580423



In "Writing R Extensions", p. 79, they give the following example of a C
program for convolution of two vectors.  (The details aren't important; it's
just a function that does something to some stuff.)

void convolve (double *a, int *na, double *b, int *nb, double *ab) {
int i, j, nab = *na + *nb - 1;
for(i = 0; i < nab; i++)
ab[i] = 0.0;
for(i = 0; i < *na; i++)
for(j = 0; j < *nb; j++)
ab[i + j] += a[i] * b[j]
}



Jeff Brown wrote:
> 
> The document suggests calling it from R like this (again the details
> aren't important):
> 
> conv <- function(a, b) 
>   .C("convolve",
>   as.double(a), 
>   as.integer(length(a)), 
>   as.double(b), 
>   as.integer(length(b)), 
>   ab = double(length(a) + length(b) - 1))$ab
> 
> I wrote a file, "convolve.c", with nothing but the above C code in it.  I
> can't figure out how to compile it.  I don't understand the syntax (no
> parentheses?) and I always get the same information-free error message:
> 
>> list.files()
> [1] "AER""convolve.c" "sendmailR" 
>> R CMD SHLIB "compile.c"
> Error: syntax error
>> COMPILE "compile.c"
> Error: syntax error
>> R CMD SHLIB "compile"
> Error: syntax error
>> COMPILE "compile"
> Error: syntax error
>> R CMD SHLIB compile.c
> Error: syntax error
>> COMPILE compile.c
> Error: syntax error
>> R CMD SHLIB compile
> Error: syntax error
>> COMPILE compile
> Error: syntax error
> 
> I'm using an Intel MacBook Pro running Leopard.  At a console, typing "gcc
> --version" yields 4.2.1.  I know I'm supposed to be using version 4.2; I
> thought 4.2.1 would qualify, but please let me know if I'm wrong about
> that.
> 
> For guidance I've been relying on "Writing R Extensions", "R Installatino
> and Administration", the "R for Mac OS X Developer's Page", and the
> built-in help.  Please let me know if there are other important resources
> I've missed.
> 
> Many thanks,
> Jeff
> 

All R CMD commands must be executed at the command line- i.e. in a Windows
CMD shell or Unix/Linux bash shell.  They are not meant for use inside the R
interpreter.

Hope this helps!

-Charlie

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
-- 
View this message in context: 
http://n4.nabble.com/Getting-started-with-C-tp1837912p1837936.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] .Fortran interface error

[Sharpie]

jgarcia-2 wrote:
> 
> Hi,
> I've stripped all the code, and it seems that any simple attempt to
> open/close a file from fortran is the cause of the error, and the error
> appears in f77 as well as in f95 code. Please, find attached a foo package
> that reproduce the errors, it should build/check/install without any
> problem (it does in my computer). If the code
> 
>  OPEN( UNIT=5, FILE=runfile, STATUS='OLD', ACTION='READ', &
>IOSTAT=status)
>  WRITE (*,*) 'status:   ', status
>  IF ( status == 0 ) THEN
>READ(5,'(A)') modelsel
>READ(5,'(A)') modelfile
>READ(5,'(A)') datdirpid
>CLOSE(5)
> 
>WRITE (*,*) 'selected model:   ', modelsel
>WRITE (*,*) 'model input file: ', modelfile
>WRITE (*,*) 'datdirpid: ', datdirpid
>  ELSE
>WRITE (*,1002) status
> 1002 FORMAT (1X,'open runfile failed--status = ', I6)
>STOP
>  END IF
> 
> is commented out in any of the two sources files (the f77 or the f95 one),
> none of the two corresponding wrappers (as they appear in the examples)
> give an error. Thus it seems clear that the operation causing it is the
> OPEN/CLOSE. Without commenting out these pieces of code, everything seems
> to work right but R halts after a call to the wrapper functions. I cannot
> find any comment about this in the documentation. Please, could you tell
> me if this is a known error?
> 
> Thanks,
> 
> Javier
> 

It looks like you may have some I/O collisions occurring.  Some Fortran
compilers treat unit 5 as being STDIN, so attempting to read from that
stream when the Fortran program is embedded may be giving R a headache.  I
would recommend either passing "modelsel", "modelfile" and "datadirpid" as
parameters from R, or reading from a file using a different unit number.

For output, instead of using write(*,*) you may need to use some of the R
output callbacks described in section 6.5.1 of "Writing R Extensions".

Hope this helps!

-Charlie



-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
-- 
View this message in context: 
http://n4.nabble.com/Fortran-interface-error-tp1838225p183.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] .Fortran interface error

[Sharpie]

jgarcia-2 wrote:
> 
> Yes That's it! Thanks a lot!!
> Changing UNIT=5 in the F95 code by UNIT=7 solves the collision.
> 
> Thank you very much Charlie, I've spent a lot of hours with this.
> 

I'm glad it worked!

Google seems to indicate that units 0, 5, 6, 100, 101 and 102 are special in
Fortran.  However, the professor who taught me Fortran recommended using
unit numbers that were 11 or greater as his experience with several Fortran
compilers was that they tended to appropriate units <= 10 for their own uses
and this behavior was not well standardized.

I haven't been able to verify this myself, but there may be something to his
warning.


jgarcia-2 wrote:
> 
> Still
> 
> R -d valgrind --vanilla < foofortran.Rcheck/foofortran-Ex.R
> 
> gives 3 errors (two "Invalid read of size 8" and one "Syscall param
> write(buf) points to uninitialised byte(s)"), which are the same it gave
> with UNIT=5. However, everything seems to work fine now in the normal
> execution :-)
> 
> Thank you very much again
> 
> Javier
> 

I'm not well acquainted with valgrind so I can't offer any advice on this
part :(

Good luck!

-Charlie

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
-- 
View this message in context: 
http://n4.nabble.com/Fortran-interface-error-tp1838225p1839012.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] SHLIB works but inline compilation does not

[Sharpie]

Jeff Brown wrote:
> 
> Hi,
> 
> I appear to be able to compile, load and call shared objects using SHLIB
> and .Call:
> 
>> code <- '#include \n #include \n SEXP f(){\n return
>> R_NilValue ; }' 
>> writeLines( code, "test.c" ) 
>> system( "R CMD SHLIB test.c" )
> gcc -arch i386 -std=gnu99
> -I/Library/Frameworks/R.framework/Resources/include
> -I/Library/Frameworks/R.framework/Resources/include/i386 
> -I/usr/local/include-fPIC  -g -O2 -c test.c -o test.o
> gcc -arch i386 -std=gnu99 -dynamiclib -Wl,-headerpad_max_install_names
> -mmacosx-version-min=10.4 -undefined dynamic_lookup -single_module
> -multiply_defined suppress -L/usr/local/lib -o test.so test.o
> -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework
> -Wl,CoreFoundation
>> dyn.load( "test.so" ) 
>> .Call( "f" ) 
> NULL
> 
> The above follows Romaine-Francois 3's suggestion here:
> http://n4.nabble.com/I-can-t-run-the-example-shown-in-the-inline-package-td1774328.html#a1778838
> 
> However, when I try to use the "inline" package, I can't get it to work:
> 
>> code <- "
> + int i, j, nab = *na + *nb - 1; 
> + for(i = 0; i < nab; i++) 
> +   ab[i] = 0.0; 
> + for(i = 0; i < *na; i++) {
> +   for(j = 0; j < *nb; j++) 
> +   ab[i + j] += a[i] * b[j]; 
> + }"
>> fun <- cfunction(
> + signature(a="numeric", na="numeric", b="numeric", nb="numeric",
> ab="numeric"), 
> + code, 
> + language="C", 
> + convention=".C" )
> 
> ERROR(s) during compilation: source code errors or compiler configuration
> errors!
> 
> Program source:
>   1: #include 
>   2: 
>   3: 
>   4: void file4431b782 ( double * a, double * na, double * b, double * nb,
> double * ab ) {
>   5: 
>   6:  int i, j, nab = *na + *nb - 1; 
>   7:  for(i = 0; i < nab; i++) 
>   8:ab[i] = 0.0; 
>   9:  for(i = 0; i < *na; i++) {
>  10:for(j = 0; j < *nb; j++) 
>  11:ab[i + j] += a[i] * b[j]; 
>  12:  }
>  13: }
> Error in compileCode(f, code, language, verbose) : 
>   Compilation ERROR, function(s)/method(s) not created!
> 
> The C function above is the one from "Writing R Extensions", p. 79; the
> suggestion for how to compile it inline is from Dirk Eddelbuettel, at this
> thread:
> http://n4.nabble.com/Getting-started-with-C-td1837912.html#a1837912
> 
> R says it's either a source code or configuration error.  I got the code
> from "Writing R Extensions", and Dirk tried it out too.  But if it's a
> compilation error, then shouldn't the first method (with SHLIB) not work
> either?
> 
> I realize I could stick to the SHLIB method, which Charlie ("The Sharpie")
> Sharpsteen wrote up in fantastic detail here:
> http://n4.nabble.com/Writing-own-simulation-function-in-C-td1580190.html#a1580423
> But there's so much more stuff I'll need to understand if I do it that way
> ...
> 
> I use an Intel MacBook Pro with OS X 10.6.2, XCode 3.2.1, gcc 4.2.1.
> 
> Thanks,
> Jeff
> 
> 

I could not reproduce this problem on my computer, OS X 10.6.3, gcc 4.2.1, R
2.10.1, inline 0.3.4:

code <- " 
int i, j, nab = *na + *nb - 1; 
for(i = 0; i < nab; i++) 
 ab[i] = 0.0; 
for(i = 0; i < *na; i++) { 
 for(j = 0; j < *nb; j++) 
 ab[i + j] += a[i] * b[j]; 
}" 

fun <- cfunction( 
signature(a="numeric", na="numeric", b="numeric", nb="numeric",
ab="numeric"), 
code, 
language="C", 
convention=".C" ) 

fun( 1:3, 3, 4:6, 3, double(5) )

$a
[1] 1 2 3

$na
[1] 3

$b
[1] 4 5 6

$nb
[1] 3

$ab
[1]  4 13 28 27 18


The only thing I can think of is that you may have a newline issue going on. 
Here's the dump of the code object:

dput(code)

" \nint i, j, nab = *na + *nb - 1; \nfor(i = 0; i < nab; i++) \n ab[i] =
0.0; \nfor(i = 0; i < *na; i++) { \n for(j = 0; j < *nb; j++) \n ab[i + j]
+= a[i] * b[j]; \n}"

Do you have newlines, \n, that are in different places?  An easy way to
check may be to copy the results of running dput() on your code object into
one file, mine into another and running diff.

Hope this helps!

-Charlie

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
-- 
View this message in context: 
http://n4.nabble.com/SHLIB-works-but-inline-compilation-does-not-tp1839090p1839237.html
Sent from the R devel mailing list archive at Nabble.com.

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

[Rd] Rtools for building 64 bit windows packages

[Sharpie]

Hello R developers,

I sincerely apologize if the answer to this question is clearly documented
somewhere, but I was unable to figure it out over my morning coffee.

I just downloaded today's release of R 2.11.0 and installed it on my Windows
7 64 bit VM.  I also downloaded the latest version of Rtools211 from
Professor Murdoch's site.   The first thing I attempted to do was build some
of my packages from source to check that they work with the new version.  I
got the following error message:

  making DLL ...
x86_64-w64-mingw32-gcc -I"C:/PROGRA~1/R/R-211~1.0-X/include" -O2
-Wall  -std=gnu99 -c tikzDevice.c -o tikzDevice.o
x86_64-w64-mingw32-gcc: not found

This does not surprise me, R 2.11.0 is hot out of the forge and Rtools
probably hasn't been repacked to support the 64 bit version.  I gathered
from the Windows FAQ and the list archives that the MinGW-w64 project
supplies the compilers and linkers used by the 64 bit version- I visited
their site and found the selection of packages available for download...
confusing.

I guess what I'm asking: 

  * Do I use the Cygwin binaries?

  * If not, is there an officially "blessed" binary distribution of Windows
x86_64 compilers and binutils?

  * If not, do I build the x86_64 toolchain from the current HEAD, or is
there a specific revision that has been determined to be stable?


Thanks for your time and effort on maintaining and enhancing such a
wonderful language!

-Charlie

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
-- 
View this message in context: 
http://r.789695.n4.nabble.com/Rtools-for-building-64-bit-windows-packages-tp2021034p2021034.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] Rtools for building 64 bit windows packages

[Sharpie]

Duncan Murdoch-2 wrote:
> 
> You can use the Rtools for the stuff other than the compilers.  You need 
> the MinGW 64 bit versions of the compilers; they are not nicely packaged 
> yet, but the instructions for finding them are in the new version of the 
> R-admin manual, in the section 3.3, "Building R for 64 bit Windows". 
> 

Ahh, thank you Duncan- this was exactly the information I was looking for. 
When I looked in R-admin this morning, I skipped straight to Appendix D as I
wasn't interested in building R, just packages.

Thanks again!

-Charlie

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
-- 
View this message in context: 
http://r.789695.n4.nabble.com/Rtools-for-building-64-bit-windows-packages-tp2021034p2022510.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] Incorrect positioning of raster images on Windows

[Sharpie [via R]]

Michael Sumner-2 wrote:
> 
> I think there's something about the "discrete cell" versus "centre value"
> interpretation here, and you are pushing the "pixels" through R's graphics
> engine as well as whatever the png device has to do.
> 
> I can't enlighten you about the details of that, but by creating an image
> file more directly with "pixels as data" you can get the result exactly:
> 
> test <- matrix(c(0, 255), 3, 5)
> library(rgdal)
> ## transpose to get orientation right
> x <- image2Grid(list(x = 1:ncol(test), y = 1:nrow(test), z = t(test)))
> writeGDAL(x, "raster.png", driver = "PNG", type = "Byte")
> 
> 
> 
> On Mon, Oct 18, 2010 at 3:17 PM, Sharpie  wrote:
> 
>>
>> I am working on dumping raster data from R into PNG files using
>> rasterImage().  I am working with a test matrix from the rasterImage()
>> example and using it to produce a PNG image with the following code:
>>
>>
>> # From the example for rasterImage(). A 3 pixel by 5 pixel b/w
>> checkerboard.
>> testImage <- as.raster(0:1, nrow=3, ncol=5)
>>
>> testImage
>> [,1]  [,2]  [,3]  [,4]  [,5]
>> [1,] "#00" "#FF" "#00" "#FF" "#00"
>> [2,] "#FF" "#00" "#FF" "#00" "#FF"
>> [3,] "#00" "#FF" "#00" "#FF" "#00"
>>
>> png('test.png', width=5, height=3, units='px')
>>
>> # Just want the image, no margins, boarders or other fancy stuff.
>> par(mar = c(0,0,0,0) )
>> plot.new()
>> plotArea = par('fig')
>>
>> rasterImage(testImage, plotArea[1], plotArea[3],
>>  plotArea[2], plotArea[4], interpolate = FALSE )
>>
>> dev.off()
>>
>>
>> However, using R 2.12.0, 64 bit on Windows 7 I have a strange issue where
>> the image is shifted up by one row and to the left by one row.  In other
>> words, the bottom row of pixels is missing along with the right column.
>>  The
>> code works as I expect it to on OS X and Debian.
>>
>>
>> Am I misusing the plotting commands in some way or should I submit an
>> off-by-one bugreport to Bugzilla?
>>
>> Any suggestions or comments are most welcome.
>>
>> -Charlie
>>
>> -
>> Charlie Sharpsteen
>> Undergraduate-- Environmental Resources Engineering
>> Humboldt State University
>> --
>> View this message in context:
>> http://r.789695.n4.nabble.com/Incorrect-positioning-of-raster-images-on-Windows-tp2999649p2999649.html
>> Sent from the R help mailing list archive at Nabble.com.
>>
>> __
>> r-h...@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide
>> http://www.R-project.org/posting-guide.html<http://www.r-project.org/posting-guide.html>
>> and provide commented, minimal, self-contained, reproducible code.
>>
> 
> 
> 
> -- 
> Michael Sumner
> Institute for Marine and Antarctic Studies, University of Tasmania
> Hobart, Australia
> e-mail: mdsum...@gmail.com
> 



Hi Micheal,

I appreciate the suggestion.  However, rgdal is very heavyweight and
installing the GDAL library is not a trivial operation automagically handled
`install.packages()` on every platform R supports.  As I am not doing
spatial analysis, I am very reluctant to add rgdal to the dependency list of
my package.

I would very much prefer to find the root cause of the difference in `png()`
behavior on Windows when compared to OS X and Linux.  If anyone on this list
has some insight to share, I would be very grateful to hear it.

I waffled a bit on whether to send this to R-help or R-devel, in the light
of day (as opposed to the foggy darkness that surrounds 2am) think it may be
more of an R-devel question.  Forwarding it there now.

-Charlie

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University

__
This email was sent by Sharpie (via Nabble)
Your replies will appear at 
http://r.789695.n4.nabble.com/Incorrect-positioning-of-raster-images-on-Windows-tp2999649p3001166.html
To receive all replies by email, subscribe to this discussion: 
http://r.789695.n4.nabble.com/template/TplServlet.jtp?tpl=subscribe_by_code&node=3001166&code=ci1kZXZlbEByLXByb2plY3Qub3JnfDMwMDExNjZ8MTA4OTQ3MDc5MQ==

[[alternative HTML version deleted]]

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