[Rd] graphics:persp - suggestion
Dear Devels, I'm not sure if I'm going the right way by mailing to this list. I have two suggestions regarding the persp function from the graphics package: 1. In the documentation of the persp function, it is said, that the "col" argument will ignore transparent colors. However, this is not true, if you use strings as color code - at least it works with HEX-code (eg. : col="#bf22" would produce a red-colored surface with transparency = 22). 2. It would be helpful if one could add a surface to an existing plot. I simply copied persp and deleted the "plot.new()" line, but I guess there are better ways... Cheers, Christoph [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] graphics:persp - suggestion
On 13-10-08 1:48 AM, Christoph Häni wrote: Dear Devels, I'm not sure if I'm going the right way by mailing to this list. I have two suggestions regarding the persp function from the graphics package: 1. In the documentation of the persp function, it is said, that the "col" argument will ignore transparent colors. However, this is not true, if you use strings as color code - at least it works with HEX-code (eg. : col="#bf22" would produce a red-colored surface with transparency = 22). That may be an obsolete limitation. I'll take a look... 2. It would be helpful if one could add a surface to an existing plot. I simply copied persp and deleted the "plot.new()" line, but I guess there are better ways... That won't work in general. persp() relies in the "painter's algorithm", in which objects at the back are drawn before objects in front of them. If you put two surfaces into the same plot there will be no way to guarantee that. If you want two surfaces in the same plot (or other things in a surface plot), you should probably use persp3d from the rgl package. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] graphics:persp - suggestion
On 13-10-08 1:48 AM, Christoph Häni wrote: Dear Devels, I'm not sure if I'm going the right way by mailing to this list. I have two suggestions regarding the persp function from the graphics package: 1. In the documentation of the persp function, it is said, that the "col" argument will ignore transparent colors. However, this is not true, if you use strings as color code - at least it works with HEX-code (eg. : col="#bf22" would produce a red-colored surface with transparency = 22). The actual behaviour is that if lighting (controlled by the "shade" argument) is active, transparency is ignored. However, if the first colour is transparent, lighting is turned off, so transparency *will* be used. I'm not sure what the intention was behind the latter behaviour. Duncan Murdoch 2. It would be helpful if one could add a surface to an existing plot. I simply copied persp and deleted the "plot.new()" line, but I guess there are better ways... Cheers, Christoph [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Allow semantic versioning for packages
On Oct 7, 2013, at 7:35 PM, Gábor Csárdi wrote:
> On Mon, Oct 7, 2013 at 6:32 PM, Simon Urbanek
> wrote:
> On Oct 5, 2013, at 9:19 PM, Gábor Csárdi wrote:
> [...]
> e.g. quoting the spec: "Build metadata SHOULD be ignored when determining
> version precedence."
>
> Indeed, although 'SHOULD' means that it is only a recommendation. And the
> build metadata is the stuff after the plus sign, so the -alpha, -beta, etc.
> is still used to determine precedence.
>
> > I fear that the scheme as described in semver.org is incompatible with the
> > scheme used by R,
> >
> > I believe that they are fully compatible. In the sense that the current R
> > package versioning is a subset of the one at semver.org. In other words,
> > the current compareVersion only gives results that are valid according to
> > semver.org.
> >
>
> Nope, e.g. the most commonly used format 1.0-0 is not even allowed by semver.
>
> Indeed again, I overlooked that the three numbers are required. This is
> something that should be relaxed for R packages, the patch level can be
> omitted.
>
That's not what it means in R - the number after the dash *is* the patch level.
The point is that the semantics of the dash are different in the two standards
and so is the interpretation of the components. That's why I said earlier (in
the part that you cut out) that probably the only viable option is to enhance
the R handling to add some handling of non-integer components.
> You are right, maybe semver.org is something that is appropriate for R
> packages, as it is. But I guess, my feature request still makes sense. I just
> want to be able to use more flexible version strings, and I think semver.org
> is a good starting point, nevertheless.
>
> Again, I understand if you say, that it would cause too much trouble for CRAN
> for not too much benefit. I cannot estimate the amount of extra work
> required. As for updating the compareVersion function, that is probably not
> too bad, there is an existing Python package for it called semver, so that
> could be the starting point.
>
Updating compareVersion() is the least problem - tools that handle package
files often use regexps which will fail once non-intergers are allowed.
Cheers,
Simon
> [...]
> > compareVersion("1.0.0", "1.0.0-alpha")
> > # [1] -1
> > # Warning message:
> > # In compareVersion("1.0.0", "1.0.0-alpha") : NAs introduced by coercion
> >
>
>
> It doesn't fail - just the order inverse to that defined by semver, because R
> treats all parts as integers, regardless of how many exist, and the existence
> of any additional components has higher precedence than the lack thereof
> (assuming full match on existing ones).
>
> Well, there are surely some for which it fails, e.g.:
>
> compareVersion("1.0-alpha", "1.0-beta")
> # Error in if (a[k] > b[k]) return(1) else if (a[k] < b[k]) return(-1L) :
> # missing value where TRUE/FALSE needed
> # In addition: Warning messages:
> # 1: In compareVersion("1.0-alpha", "1.0-beta") : NAs introduced by coercion
> # 2: In compareVersion("1.0-alpha", "1.0-beta") : NAs introduced by coercion
>
> Thanks for taking the time to discuss this issue!
>
> Best,
> Gabor
>
>
> Cheers,
> Simon
>
> [...]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Allow semantic versioning for packages
On Tue, Oct 8, 2013 at 11:14 AM, Simon Urbanek wrote: [...] > > That's not what it means in R - the number after the dash *is* the patch > level. The point is that the semantics of the dash are different in the two > standards and so is the interpretation of the components. That's why I said > earlier (in the part that you cut out) that probably the only viable option > is to enhance the R handling to add some handling of non-integer components. > Well, it is the patch level, or it is not, I am sure that for some people it is, for some it is not, and for many of them it is missing completely. I don't think it is possible to enforce the same semantics of the version numbers on thousands of package maintainers. Of course it is sensible to have some recommendation, Writing R extensions does not say anything about semantics right now. But this is kind of a side issue for me. Adding non-integer components, and defining an ordering for them is exactly what I was after. Maybe referring to semver.org was a mistake by me, I looked around for some standard versioining that is already used by some projects, and it seemed sensible. [...] > Updating compareVersion() is the least problem - tools that handle package > files often use regexps which will fail once non-intergers are allowed. > OK, this is probably a blocker. Thanks for the discussion, anyway. Best, Gabor [...] [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "Failed to locate the 'texi2pdf' output file"
Just thought I would mention that the issue below (and in
https://stat.ethz.ch/pipermail/r-devel/2013-April/066318.html) is still not
resolved.
It hasn't been a big problem, but it potentially could be, if a critical
package were to have this error on release day, then all its dependencies would
fail to build, which would probably require us to postpone our release.
See the complete thread (link above) for followup posts which establish that
this has nothing to do with databases, sockets, or virus scanners, and occurs
even in packages that have no dependencies or R code in them. The post below
from Henrik points to a possible cause.
Thanks,
Dan
On Fri, Apr 12, 2013 at 4:23 PM, Henrik Bengtsson wrote:
> On Fri, Apr 12, 2013 at 3:53 PM, Kasper Daniel Hansen
> wrote:
>> Dan,
>>
>> This error looks _very_ similar to what I reported regarding the use of
>> 'foreach' inside a windows vignette, on the bioc-devel email list. As you
>> say, it looks funny that it lists the tex file, yet fails to find it.
>
> It's not looking for the TeX file, but the PDF file - that is what the
> error message is referring to by "Failed to locate the 'texi2pdf'
> output file". [ Note that in this error message I use the term
> "vignette" in a conceptual sense, not necessarily the vignette
> *source* file (here *.Rnw) - maybe that is what is confusing. ]
> Immediately after calling tools::texi2pdf("OrganismDbi.tex"), the code
> tries to locate the texi2pdf output file, that is, 'OrganismDbi.pdf',
> which it cannot find. This indicates that tools::texi2pdf() gave an
> error (an error message which is currently not reported/available),
> which in turn indicates that the 'OrganismDbi.tex' file is
> corrupt/incomplete.
>
>>
>> The issue had to do with closing relevant connections (for foreach, this
>> was a Windows issue because the default foreach backend on Windows uses
>> connections). For my particular case, solving it was a bit difficult
>> because I could not just close all connections since a vignette is being
>> run inside sink().
>>
>> The package name makes me suspect a database connection. As a starting
>> point I suggest closing all existing connections in the vignette.
>
> I think it's worth looking into what Kasper says - that's hopefully the
> reason.
>
> /Henrik
>
> PS. I do find it odd that these issues starting to occur now, because
> most of the vignette framework is performing the same steps as in R (<
> 3.0.0). The main difference is see is that it now validates/asserts
> that the expected output file is there *immediately* after trying to
> generate them (using weave, tangle, and texi2pdf). If for some reason
> texi2pdf generates the PDF in a background process which is not
> completed in full when returning the control to R, then the PDF is not
> there and you would get this error. I don't know if this can happen.
> The reason why I came to think of this is because I recall that I've
> seen this behavior when using bitmap() and Ghostscript to create PNGs.
> Just a shot from the hip, though.
>
>>
>> Kasper
>>
>>
>>
>> On Fri, Apr 12, 2013 at 5:34 PM, Dan Tenenbaum wrote:
>>
>>> Hi,
>>> Every day a few Bioconductor packages (different ones each day) fail
>>> to build, on Windows only, with an error like this:
>>>
>>> D:\biocbld\bbs-2.13-bioc\meat>D:\biocbld\bbs-2.13-bioc\R\bin\R.exe CMD
>>> build --keep-empty-dirs --no-resave-data OrganismDbi
>>> [...]
>>> Error in find_vignette_product(name, by = "texi2pdf", engine = engine) :
>>> Failed to locate the 'texi2pdf' output file (by engine
>>> 'utils::Sweave') for vignette with name 'OrganismDbi'. The following
>>> files exists in directory '.': 'OrganismDbi.Rnw', 'OrganismDbi.tex',
>>> 'databaseTypes.pdf'
>>> Calls: -> find_vignette_product
>>> Execution halted
>>>
>>> This is puzzling to me because I would have thought that
>>> 'OrganismDbi.tex' was the file it was looking for, yet it says that
>>> file exists.
>>>
>>> These build errors are transient...if I re-run the build, the error
>>> does not recur. So I was hesitant to report the problem because can't
>>> be reproduced consistently. Nevertheless it is a problem.
>>>
>>> > sessionInfo()
>>> R version 3.0.0 (2013-04-03)
>>> Platform: i386-w64-mingw32/i386 (32-bit)
>>>
>>> locale:
>>> [1] LC_COLLATE=English_United States.1252
>>> [2] LC_CTYPE=English_United States.1252
>>> [3] LC_MONETARY=English_United States.1252
>>> [4] LC_NUMERIC=C
>>> [5] LC_TIME=English_United States.1252
>>>
>>> attached base packages:
>>> [1] stats graphics grDevices utils datasets methods base
>>>
>>> Thanks,
>>> Dan
>>>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] http://r.research.att.com/ (daily R binaries for OSX) seems to be down
It appears that http://r.research.att.com/, which provides "daily builds of the R GUI, R-patched and R-devel" for OSX, is down (at least since yesterday). I didn't find any contact information in online web caches, so I'm posting here in case the maintainer is listening. /Henrik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] http://r.research.att.com/ (daily R binaries for OSX) seems to be down
On Oct 8, 2013, at 2:45 PM, Henrik Bengtsson wrote: > It appears that http://r.research.att.com/, which provides "daily > builds of the R GUI, R-patched and R-devel" for OSX, is down (at least > since yesterday). I didn't find any contact information in online web > caches, so I'm posting here in case the maintainer is listening. > > /Henrik There was a post on this to R-SIG-MAC earlier today, with a reply by Peter: https://stat.ethz.ch/pipermail/r-sig-mac/2013-October/010364.html Regards, Marc Schwartz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
