Re: [Rd] AddComment (gram.y)
> IIRC, because there were always cases where they were attached to > the wrong expression, and we were more or less convinced, there was > no to do it "right" in all cases. Doxygen and Javadoc seem to have solved the problem of comment-object association, implying that it's not generally intractable; are there any ambiguities specific to R (but not, say, C++ or Java) that make it a special case? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] AddComment (gram.y)
> They aren't "cannibalized", they are still there, where the source
> ref says they are.
I was thinking along the lines of using parse() to unambiguously
associate a comment block with a code object; sure, srcref() retains
them: but that's no different than parsing a text file.
If I can't associate comment with code in parse(), I don't see how I
can avoid reimplementing the R parser; at least far enough to identify
top-level objects (but why stop there?).
By "cannibalizing", I'm referring to the following; take trivial.R:
# Comment relevant to foo
foo <- "bar"
attributes(parse("trivial.R"))$srcref[[1]] returns:
foo <- "bar"
which is consistent with SkipComment.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] swig 1.3.35 & R - is the R wrapper still maintained and of interest?
On Sun, Apr 20, 2008 at 12:42 PM, Duncan Temple Lang < [EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > Dirk Eddelbuettel wrote: > | Duncan, > | > | On 20 April 2008 at 05:44, Duncan Temple Lang wrote: > | | ~ I've waited to see if there would be posts from others, but am > | | a little surprised to see only your two. It would seem people aren't > | | using SWIG for R and I wonder why this community hasn't used or wanted > | > | AFAICT it is a classic chicken and egg problem. > | > | "Something" exists, but is not exactly mature, been used mostly just for > a > | very large and rapidly changing codebase (ie Quantlib, which should > stabilise > | after the 1.0 release 'real soon now') with moderate success and hence > | doesn't get off the ground for more. > > I concur fully. And while it is reasonable for people to wait until there > are good examples and a > working tool, it would be helpful if people would express a sense of > interest for such potential > projects. We have built too many "good" things that people haven't used, > and it would be > good to evaluate this before committing too much time into them. In the > case of something like > interface generators, the idea is well known, so people could express an > interest in the concept > without too much learning being necessary. > Indeed, I recall in 2001 asking why people hadn't cried out for SWIG > facilities for R > and I got at least one blank look :-) > > > > | > | | such tools? Do we not have a need for them, or are we not aware of > them, ...? > | | or > | > | My conjecture is that it would take off rather forcefully if only there > were > | one or two use cases for moderately-sized well-known libraries, > providing > | both use cases and usage templates. > > I'm working on that for wxWidgets and Qt at the moment. > And I have some for smaller codebases. > > | > | | ~ So what to do? Firstly, I don't get that crash on load on my Linux > | | box. So we would have to investigate further, but at least it does > work > | | somewhere. And such extreme failures are actually less worrying than > the > | | potential lack of functionality in the bindings. > | | > | | ~ Soeren has already been in touch with me and indeed the > | | code in the SWIG distribution comes origially from the RSWIG source on > the > | | omegahat repository. Unfortunately, the person who took that code > | | and put into the SWIG distribution did by himself and didn't seem > | | to want to work together to improve it add get it beyond the > experimental state > | | it was in. Futher, he apparently listed me as the contributor, > | | but haven't communicated at all with the SWIG developers and so I do > not have > | > | I think that is not true. Joe Wang had me CCed on a few email he had > with the > | Swig maintainers. He either has or had write access to the Swig repo, > and > | that seems to make sense as he was, afaik, the only one showing up > there. Or > | did you ever offer your code for inclusion there? > > Well, we are talking about different things. I know Joe had SWIG svn > access. > I didn't get the opportunity to discuss how to include my code as Joe > included > it before I was ready to make it public in that way given its experimental > nature. > Adding it implies some sense of maintenance obligation, potential back > compatability, > etc. and that is why it is not particularly helpful to take a project > somebody is actively working > on and make decisions about it without that person's approval. It is > "water under the bridge", > but helpful to learn from. > > | > | But all that is spilled milk now. Soeren has an _actual_ issue _right > now_ > | so what can we do to get a proven tool (ie Swig) working and integrated > with > | R for him to get his work done and R and Shogun integrated ? > > One "issue" whether Soeren or anyone else needs the R interface > "immediately" or whether this would be just a nice thing to have. > Again, chicken and egg, but given the limited amount of time available > of people who know how to do this "properly", whether a stop-gap solution > or whether we can do it properly over a period of time. > > It is complex to create the general mechanism for SWIG code generation > that covers C and C++ > and handles important aspects. I _might_ be able to get to it > in late summer, but I cannot guarantee it. Once I finish the approach that > leverages > GCC, then I should have at least all the issues resolved with how I think > the mapping > should generate the code. That should simplify implementing the map in > Perl. > > I would be very keen to chat with people who are interested in helping or > have > examples to try out and are willing to withstand the volatility of > development > versions. > > > > > | > | | access to the SWIG repository and cannot change the code. > | | So we have a little bit of a problem that might have been better dealt > with if > | | code had continued to be develo
Re: [Rd] package building problem under Windows Vista
On 20/04/2008 5:00 PM, Prof Brian Ripley wrote:
> On Sun, 20 Apr 2008, Duncan Murdoch wrote:
>
>> On 20/04/2008 1:21 PM, Prof Brian Ripley wrote:
>>> On Sun, 20 Apr 2008, Duncan Murdoch wrote:
>>>
On 20/04/2008 8:43 AM, Gabor Grothendieck wrote:
> There does seem to be some general problem associated with Sweave
> and graphics when I try it on my Vista system with
> [1] "R version 2.7.0 RC (2008-04-17 r45367)"
>>> There is no evidence whatsoever of 'some general problem', and it is quite
>>> specific to that package. We've tested all the CRAN and BioC packages with
>>> vignettes, and accounted for all the errors.
>>>
> Using tradeCosts-article.Rnw from the tradeCosts package:
>
> setwd(path.to.tradeCosts-article.Rnw)
> Sweave("tradeCosts-article.Rnw")
>
> appears to work properly; however, if we try it from the
> command line:
>
> R CMD Sweave tradeCosts-article.Rnw
>
> to simulate what happens when trying to build the package it
> indicates that in chunk 2 that pdf is masked from grDevices.
tradeCosts has its own pdf(), which is an S4 generic. Once you have
attached that package, the regular pdf() device driver is hidden. So it
looks as though running Sweave from the R console does the search in the
intended way, but running it from R CMD Sweave finds the tradeCosts
version of pdf() instead of the standard one.
>>> Sweave does call grDevices::pdf explicitly. But that's not the issue as
>>>
>>> R --slave < tradeCosts-article.R
>>>
>>> also fails at
>>>
>>> Calls: plot ... barplot -> barplot.default -> par -> pdf ->
>>>
>>> So the issue is that pdf() is getting called because no device has been
>>> opened, and "pdf" is the default device. That seems quite reasonable to
>>> me: if you create a function "pdf" high on the path it indicates that you
>>> want that to be the default device. (And the default device is used.)
>> I think there may be another problem. Running R on the Stangle output is
>> different than running Sweave, because Sweave knows that certain chunks have
>> fig=TRUE, and so it should set up the graphics device for them. I don't
>> think there's a chunk in that file that does graphics without declaring
>> fig=TRUE, so the original Sweave run should succeed, even if the run above
>> fails.
>>
>> So I still don't understand why in chunk 17 "pdf" is being used instead of
>> "grDevices::pdf".
>
> That's equally true of the example used in example(Sweave), and that puts
> up a graphics device, just as this one does.
>
> fig=TRUE asks for *additional* runs with devices set -- see the code in
> makeRweaveLatexCodeRunner. If options$eval is true
>
> if(options$eval) err <- evalFunc(ce, options)
>
> is run (and if it isn't options$eps and options$pdf are not reached).
Thanks, that explains it.
Duncan Murdoch
> Or look at ?RweaveLatex which says
>
> eval: logical ('TRUE'). If 'FALSE', the code chunk is not
>evaluated, and hence no text or graphical output produced.
>
> Try
>
> options(device="pdf")
> example(Sweave)
>
> and see what gets generated.
>
> Or (as I had done), put options(device=grDevice::pdf) in the first chunk
> of the tradeCosts example, and see what gets plotted in Rplots.pdf.
>
> [...]
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Extending R formulas
Dear list, I'm currently trying to write a new R package to model spatial extremes. In particular, for a model fitting procedure, I'd like to use flexible response surfaces (like linear models, splines, ...) for the parameters of my model. Following this idea, I'd like to allow "a new interpretation" of an R formula given by the user, like y ~ x1 + rb(x2, knots, degree, penalty) where x1, x2 are covariates and rb stands for using a radial basis smooth splines with given knots, degree and penalty coefficient. Such "new formula" should then provide the appropriate design matrix. I know that existing packages have done this way too - e.g. mgcv; but their codes are quite hard to understand - for me I mean. Does anyone can provide some useful guidelines to do this kind of stuffs or provide more readable codes? In advance, thank you Best, Mathieu -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package building problem under Windows Vista
On Sun, 20 Apr 2008, Duncan Murdoch wrote:
> On 20/04/2008 1:21 PM, Prof Brian Ripley wrote:
>> On Sun, 20 Apr 2008, Duncan Murdoch wrote:
>>
>>> On 20/04/2008 8:43 AM, Gabor Grothendieck wrote:
There does seem to be some general problem associated with Sweave
and graphics when I try it on my Vista system with
[1] "R version 2.7.0 RC (2008-04-17 r45367)"
>>
>> There is no evidence whatsoever of 'some general problem', and it is quite
>> specific to that package. We've tested all the CRAN and BioC packages with
>> vignettes, and accounted for all the errors.
>>
Using tradeCosts-article.Rnw from the tradeCosts package:
setwd(path.to.tradeCosts-article.Rnw)
Sweave("tradeCosts-article.Rnw")
appears to work properly; however, if we try it from the
command line:
R CMD Sweave tradeCosts-article.Rnw
to simulate what happens when trying to build the package it
indicates that in chunk 2 that pdf is masked from grDevices.
>>> tradeCosts has its own pdf(), which is an S4 generic. Once you have
>>> attached that package, the regular pdf() device driver is hidden. So it
>>> looks as though running Sweave from the R console does the search in the
>>> intended way, but running it from R CMD Sweave finds the tradeCosts
>>> version of pdf() instead of the standard one.
>>
>> Sweave does call grDevices::pdf explicitly. But that's not the issue as
>>
>> R --slave < tradeCosts-article.R
>>
>> also fails at
>>
>> Calls: plot ... barplot -> barplot.default -> par -> pdf ->
>>
>> So the issue is that pdf() is getting called because no device has been
>> opened, and "pdf" is the default device. That seems quite reasonable to
>> me: if you create a function "pdf" high on the path it indicates that you
>> want that to be the default device. (And the default device is used.)
>
> I think there may be another problem. Running R on the Stangle output is
> different than running Sweave, because Sweave knows that certain chunks have
> fig=TRUE, and so it should set up the graphics device for them. I don't
> think there's a chunk in that file that does graphics without declaring
> fig=TRUE, so the original Sweave run should succeed, even if the run above
> fails.
>
> So I still don't understand why in chunk 17 "pdf" is being used instead of
> "grDevices::pdf".
That's equally true of the example used in example(Sweave), and that puts
up a graphics device, just as this one does.
fig=TRUE asks for *additional* runs with devices set -- see the code in
makeRweaveLatexCodeRunner. If options$eval is true
if(options$eval) err <- evalFunc(ce, options)
is run (and if it isn't options$eps and options$pdf are not reached).
Or look at ?RweaveLatex which says
eval: logical ('TRUE'). If 'FALSE', the code chunk is not
evaluated, and hence no text or graphical output produced.
Try
options(device="pdf")
example(Sweave)
and see what gets generated.
Or (as I had done), put options(device=grDevice::pdf) in the first chunk
of the tradeCosts example, and see what gets plotted in Rplots.pdf.
[...]
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package building problem under Windows Vista
On 20/04/2008 1:21 PM, Prof Brian Ripley wrote:
> On Sun, 20 Apr 2008, Duncan Murdoch wrote:
>
>> On 20/04/2008 8:43 AM, Gabor Grothendieck wrote:
>>> There does seem to be some general problem associated with Sweave
>>> and graphics when I try it on my Vista system with
>>> [1] "R version 2.7.0 RC (2008-04-17 r45367)"
>
> There is no evidence whatsoever of 'some general problem', and it is quite
> specific to that package. We've tested all the CRAN and BioC packages
> with vignettes, and accounted for all the errors.
>
>>> Using tradeCosts-article.Rnw from the tradeCosts package:
>>>
>>> setwd(path.to.tradeCosts-article.Rnw)
>>> Sweave("tradeCosts-article.Rnw")
>>>
>>> appears to work properly; however, if we try it from the
>>> command line:
>>>
>>> R CMD Sweave tradeCosts-article.Rnw
>>>
>>> to simulate what happens when trying to build the package it
>>> indicates that in chunk 2 that pdf is masked from grDevices.
>> tradeCosts has its own pdf(), which is an S4 generic. Once you have
>> attached that package, the regular pdf() device driver is hidden. So it
>> looks as though running Sweave from the R console does the search in the
>> intended way, but running it from R CMD Sweave finds the tradeCosts
>> version of pdf() instead of the standard one.
>
> Sweave does call grDevices::pdf explicitly. But that's not the issue as
>
> R --slave < tradeCosts-article.R
>
> also fails at
>
> Calls: plot ... barplot -> barplot.default -> par -> pdf ->
>
> So the issue is that pdf() is getting called because no device has been
> opened, and "pdf" is the default device. That seems quite reasonable to
> me: if you create a function "pdf" high on the path it indicates that you
> want that to be the default device. (And the default device is used.)
I think there may be another problem. Running R on the Stangle output
is different than running Sweave, because Sweave knows that certain
chunks have fig=TRUE, and so it should set up the graphics device for
them. I don't think there's a chunk in that file that does graphics
without declaring fig=TRUE, so the original Sweave run should succeed,
even if the run above fails.
So I still don't understand why in chunk 17 "pdf" is being used instead
of "grDevices::pdf".
> If you want grDevices::pdf to be the default device, that is what you need
> to specify (as written).
>
> The solution is to open a device explicitly in the vignette, e.g. call
> dev.new() before library(tradeCosts).
>
>> I don't see why there's any difference here,
>
> batch vs interactive.
>
>> but utils (where Sweave lives) doesn't state that it depends on
>> grDevices (which is where the standard pdf() comes from). However,
>> fixing this is not enough to fix the error.
>
> (That's intentional, as is the use of grDevices::pdf.)
>
>
>> I see that tradeCosts doesn't declare any dependency on grDevices;
>> fixing that also doesn't fix the problem.
>>
>> When tradeCosts creates the S4 generic for pdf(), it uses a signature
>> that is inconsistent with the standard one; that might be the problem.
>> However, I don't see how to fix it. The docs for setGeneric suggest
>> simply using
>>
>> setGeneric("pdf")
>>
>> but that doesn't work:
>>
>> Loading required package: grDevices
>> Loading required package: graphics
>> Loading required package: stats
>> Loading required package: tools
>> Error in setGeneric("pdf") :
>> must supply a function skeleton, explicitly or via an existing function
>>
>> I don't know why setGeneric can't see pdf() in grDevices. I think John
>> Chambers is offline for a while, so this will likely have to wait.
>
> If you did this in the package, that code is run without importing
> grDevices. If you do, it has a different complaint (that the signatures
> differ).
I did this by adding grDevices to the Depends line in the package
DESCRIPTION.
I think we need to simplify this stuff. I was under the impression that
Depends implied Imports, and seeing the "Loading required" messages
makes me think that at the time setGeneric("pdf") was called (I put it
in the AllGenerics.R file), grDevices would at least be on the search
path. I later put an explicit "library(grDevices)" ahead of the call to
setGeneric("pdf"), and that still didn't work.
So the problem is that our search strategy is too complicated. I'd
expect if a function was visible to be executed (as pdf() was at that
point), then it should be visible to be used in setGeneric(). It
shouldn't matter if it is imported, or just on the search path: we
should consistently see it or consistently not see it. (I would
actually prefer the latter. If you don't explicitly import it, then you
shouldn't be able to use it in package code.)
Duncan Murdoch
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] swig 1.3.35 & R - is the R wrapper still maintained and of interest?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dirk Eddelbuettel wrote: | Duncan, | | On 20 April 2008 at 05:44, Duncan Temple Lang wrote: | | ~ I've waited to see if there would be posts from others, but am | | a little surprised to see only your two. It would seem people aren't | | using SWIG for R and I wonder why this community hasn't used or wanted | | AFAICT it is a classic chicken and egg problem. | | "Something" exists, but is not exactly mature, been used mostly just for a | very large and rapidly changing codebase (ie Quantlib, which should stabilise | after the 1.0 release 'real soon now') with moderate success and hence | doesn't get off the ground for more. I concur fully. And while it is reasonable for people to wait until there are good examples and a working tool, it would be helpful if people would express a sense of interest for such potential projects. We have built too many "good" things that people haven't used, and it would be good to evaluate this before committing too much time into them. In the case of something like interface generators, the idea is well known, so people could express an interest in the concept without too much learning being necessary. Indeed, I recall in 2001 asking why people hadn't cried out for SWIG facilities for R and I got at least one blank look :-) | | | such tools? Do we not have a need for them, or are we not aware of them, ...? | | or | | My conjecture is that it would take off rather forcefully if only there were | one or two use cases for moderately-sized well-known libraries, providing | both use cases and usage templates. I'm working on that for wxWidgets and Qt at the moment. And I have some for smaller codebases. | | | ~ So what to do? Firstly, I don't get that crash on load on my Linux | | box. So we would have to investigate further, but at least it does work | | somewhere. And such extreme failures are actually less worrying than the | | potential lack of functionality in the bindings. | | | | ~ Soeren has already been in touch with me and indeed the | | code in the SWIG distribution comes origially from the RSWIG source on the | | omegahat repository. Unfortunately, the person who took that code | | and put into the SWIG distribution did by himself and didn't seem | | to want to work together to improve it add get it beyond the experimental state | | it was in. Futher, he apparently listed me as the contributor, | | but haven't communicated at all with the SWIG developers and so I do not have | | I think that is not true. Joe Wang had me CCed on a few email he had with the | Swig maintainers. He either has or had write access to the Swig repo, and | that seems to make sense as he was, afaik, the only one showing up there. Or | did you ever offer your code for inclusion there? Well, we are talking about different things. I know Joe had SWIG svn access. I didn't get the opportunity to discuss how to include my code as Joe included it before I was ready to make it public in that way given its experimental nature. Adding it implies some sense of maintenance obligation, potential back compatability, etc. and that is why it is not particularly helpful to take a project somebody is actively working on and make decisions about it without that person's approval. It is "water under the bridge", but helpful to learn from. | | But all that is spilled milk now. Soeren has an _actual_ issue _right now_ | so what can we do to get a proven tool (ie Swig) working and integrated with | R for him to get his work done and R and Shogun integrated ? One "issue" whether Soeren or anyone else needs the R interface "immediately" or whether this would be just a nice thing to have. Again, chicken and egg, but given the limited amount of time available of people who know how to do this "properly", whether a stop-gap solution or whether we can do it properly over a period of time. It is complex to create the general mechanism for SWIG code generation that covers C and C++ and handles important aspects. I _might_ be able to get to it in late summer, but I cannot guarantee it. Once I finish the approach that leverages GCC, then I should have at least all the issues resolved with how I think the mapping should generate the code. That should simplify implementing the map in Perl. I would be very keen to chat with people who are interested in helping or have examples to try out and are willing to withstand the volatility of development versions. | | | access to the SWIG repository and cannot change the code. | | So we have a little bit of a problem that might have been better dealt with if | | code had continued to be developed outside of SWIG by the R community. | | | | ~ If there is nobody interested in using SWIG in R, then there is little point | | in fixing it. I have been working on an alternative way to generate bindings using | | output from GCC (gcc & g++) and exploring how the bindings should work | | Sure, that is
Re: [Rd] package building problem under Windows Vista
On Sun, 20 Apr 2008, Duncan Murdoch wrote:
> On 20/04/2008 8:43 AM, Gabor Grothendieck wrote:
>> There does seem to be some general problem associated with Sweave
>> and graphics when I try it on my Vista system with
>> [1] "R version 2.7.0 RC (2008-04-17 r45367)"
There is no evidence whatsoever of 'some general problem', and it is quite
specific to that package. We've tested all the CRAN and BioC packages
with vignettes, and accounted for all the errors.
>> Using tradeCosts-article.Rnw from the tradeCosts package:
>>
>> setwd(path.to.tradeCosts-article.Rnw)
>> Sweave("tradeCosts-article.Rnw")
>>
>> appears to work properly; however, if we try it from the
>> command line:
>>
>> R CMD Sweave tradeCosts-article.Rnw
>>
>> to simulate what happens when trying to build the package it
>> indicates that in chunk 2 that pdf is masked from grDevices.
>
> tradeCosts has its own pdf(), which is an S4 generic. Once you have
> attached that package, the regular pdf() device driver is hidden. So it
> looks as though running Sweave from the R console does the search in the
> intended way, but running it from R CMD Sweave finds the tradeCosts
> version of pdf() instead of the standard one.
Sweave does call grDevices::pdf explicitly. But that's not the issue as
R --slave < tradeCosts-article.R
also fails at
Calls: plot ... barplot -> barplot.default -> par -> pdf ->
So the issue is that pdf() is getting called because no device has been
opened, and "pdf" is the default device. That seems quite reasonable to
me: if you create a function "pdf" high on the path it indicates that you
want that to be the default device. (And the default device is used.)
If you want grDevices::pdf to be the default device, that is what you need
to specify (as written).
The solution is to open a device explicitly in the vignette, e.g. call
dev.new() before library(tradeCosts).
> I don't see why there's any difference here,
batch vs interactive.
> but utils (where Sweave lives) doesn't state that it depends on
> grDevices (which is where the standard pdf() comes from). However,
> fixing this is not enough to fix the error.
(That's intentional, as is the use of grDevices::pdf.)
> I see that tradeCosts doesn't declare any dependency on grDevices;
> fixing that also doesn't fix the problem.
>
> When tradeCosts creates the S4 generic for pdf(), it uses a signature
> that is inconsistent with the standard one; that might be the problem.
> However, I don't see how to fix it. The docs for setGeneric suggest
> simply using
>
> setGeneric("pdf")
>
> but that doesn't work:
>
> Loading required package: grDevices
> Loading required package: graphics
> Loading required package: stats
> Loading required package: tools
> Error in setGeneric("pdf") :
> must supply a function skeleton, explicitly or via an existing function
>
> I don't know why setGeneric can't see pdf() in grDevices. I think John
> Chambers is offline for a while, so this will likely have to wait.
If you did this in the package, that code is run without importing
grDevices. If you do, it has a different complaint (that the signatures
differ).
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fortran underscore problem persists on Linux x86/64 (PR#11206)
On Sun, 20 Apr 2008, Thomas Petzoldt wrote: > Dear Prof. Ripley, > > thank you very much for correcting the treatment of 'extra underscore' that > in fact solved our problem with the Fortran interface on my Ubuntu 7.1 > x86/64, even with g77 3.4.6. I accidentally installed g77 instead of gfortran > (4.x), sorry for my limited knowledge about that. Is it still necessary to > provide detailed information about all involved compilers and symbol tables? Not if the problem is solved, thank you. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fortran underscore problem persists on Linux x86/64 (PR#11206)
Dear Prof. Ripley, thank you very much for correcting the treatment of 'extra underscore' that in fact solved our problem with the Fortran interface on my Ubuntu 7.1 x86/64, even with g77 3.4.6. I accidentally installed g77 instead of gfortran (4.x), sorry for my limited knowledge about that. Is it still necessary to provide detailed information about all involved compilers and symbol tables? Thomas Petzoldt -- Thomas Petzoldt Technische Universitaet Dresden Institut fuer Hydrobiologie[EMAIL PROTECTED] 01062 Dresden http://tu-dresden.de/hydrobiologie/ GERMANY __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Java->R functions (or possibly C++ -> R)
Hi > Genetic algorithms / evolutionary computing _are_ already available via CRAN, > see eg rgenoud and DEoptim. Wrapping existing ones is also fairly easy; I am > sometimes use PGAPack from R at work (using non-released code) thanks for the pointers to the various packages, I'll check them out. I may still be interested in writing my own though. > As for Jave, as I understand it, rjava is _the_ common interface. Doesn't this go R->Java? I want to be able to call R from Java, ie Java->R .. but I'll take another look at the documentation. thank you also for the the search suggestions, those will come in very handy. Esmail _ Going green? See the top 12 foods to eat organic. 1N1653A [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package building problem under Windows Vista
On 20/04/2008 8:43 AM, Gabor Grothendieck wrote:
> There does seem to be some general problem associated with Sweave
> and graphics when I try it on my Vista system with
> [1] "R version 2.7.0 RC (2008-04-17 r45367)"
>
> Using tradeCosts-article.Rnw from the tradeCosts package:
>
> setwd(path.to.tradeCosts-article.Rnw)
> Sweave("tradeCosts-article.Rnw")
>
> appears to work properly; however, if we try it from the
> command line:
>
> R CMD Sweave tradeCosts-article.Rnw
>
> to simulate what happens when trying to build the package it
> indicates that in chunk 2 that pdf is masked from grDevices.
tradeCosts has its own pdf(), which is an S4 generic. Once you have
attached that package, the regular pdf() device driver is hidden. So it
looks as though running Sweave from the R console does the search in the
intended way, but running it from R CMD Sweave finds the tradeCosts
version of pdf() instead of the standard one. I don't see why there's
any difference here, but utils (where Sweave lives) doesn't state that
it depends on grDevices (which is where the standard pdf() comes from).
However, fixing this is not enough to fix the error.
I see that tradeCosts doesn't declare any dependency on grDevices;
fixing that also doesn't fix the problem.
When tradeCosts creates the S4 generic for pdf(), it uses a signature
that is inconsistent with the standard one; that might be the problem.
However, I don't see how to fix it. The docs for setGeneric suggest
simply using
setGeneric("pdf")
but that doesn't work:
Loading required package: grDevices
Loading required package: graphics
Loading required package: stats
Loading required package: tools
Error in setGeneric("pdf") :
must supply a function skeleton, explicitly or via an existing function
I don't know why setGeneric can't see pdf() in grDevices. I think John
Chambers is offline for a while, so this will likely have to wait.
Duncan Murdoch
> Then in chunk 17, when plotting is attempted the first time,
> it chokes.
>
> Maybe someone familiar with the relevant internals can explain.
>
> I have shown chunks 1, 2 and 17 as output from Stangle,
> the Rnw file up to the end of chunk 2 and the error log
> from Sweave in the sections below.
>
>
> -
> ###
> ### chunk number 1:
> ###
> options(digits = 3, width = 60, scipen = 99)
> set.seed(1)
>
> cat.df.without.rownames <- function (d, file = ""){
> stopifnot(is.data.frame(d))
> row.names(d) <- 1:nrow(d)
> x <- NULL
> conn <- textConnection("x", "w", local = TRUE)
> capture.output(print(d), file = conn)
> close(conn)
> cat(substring(x, first = max(nchar(row.names(d))) + 2), sep = "\n",
> file = file)
> }
>
>
> ###
> ### chunk number 2:
> ###
> library(tradeCosts)
> data(trade.mar.2007)
> head(trade.mar.2007)
>
>
> ###
> ### chunk number 17:
> ###
> plot(result.batched, "time.series.bps")
>
> -
>
>
> \documentclass[a4paper]{report}
> \usepackage[round]{natbib}
>
> \usepackage{Rnews}
> \usepackage{fancyvrb}
> \usepackage{Sweave}
> \hyphenation{tradeCosts}
> \hyphenation{tradeCostsResults}
> \hyphenation{decision}
>
> \DefineVerbatimEnvironment{Sinput}{Verbatim}{fontsize=\small,fontshape=sl}
> \DefineVerbatimEnvironment{Soutput}{Verbatim}{fontsize=\small}
> \DefineVerbatimEnvironment{Scode}{Verbatim}{fontsize=\small,fontshape=sl}
>
> %% \SweaveOpts{prefix.string=graphics/portfolio}
>
> \bibliographystyle{abbrvnat}
>
> \begin{document}
> \begin{article}
> \title{Trade Costs}
> \author{Jeff Enos, David Kane, Arjun Ravi Narayan, Aaron Schwartz,
> Daniel Suo and Luyi Zhao}
>
> %%\VignetteIndexEntry{Trade Costs}
> %%\VignetteDepends{tradeCosts}
>
> <>=
> options(digits = 3, width = 60, scipen = 99)
> set.seed(1)
>
> cat.df.without.rownames <- function (d, file = ""){
> stopifnot(is.data.frame(d))
> row.names(d) <- 1:nrow(d)
> x <- NULL
> conn <- textConnection("x", "w", local = TRUE)
> capture.output(print(d), file = conn)
> close(conn)
> cat(substring(x, first = max(nchar(row.names(d))) + 2), sep = "\n",
> file = file)
> }
> @
>
> \maketitle
>
> \setkeys{Gin}{width=0.95\textwidth}
>
>
> \section*{Introduction}
>
> Trade costs are the costs a trader must pay to implement a decision to
> buy or sell a security. Consider a single trade of a single equity
> security. Suppose on the evening of August 1, a trader decides to
> purchase 10,000 shares of IBM at \$10, the \emph{decision price} of
> the trade. The next day, the trader's broker buys 10,000 shares in a
> rising market and pays \$11 per share, th
Re: [Rd] Java->R functions (or possibly C++ -> R)
On 20 April 2008 at 09:22, esmail bonakdarian wrote:
| I am trying to implement a simple Genetic Algorithm using some of the
| functions of R (such as lm). I am a total newbie with regard to R, but
| not programming or GAs.
Genetic algorithms / evolutionary computing _are_ already available via CRAN,
see eg rgenoud and DEoptim. Wrapping existing ones is also fairly easy; I am
sometimes use PGAPack from R at work (using non-released code).
As for Jave, as I understand it, rjava is _the_ common interface.
I prefer C++ and use RCpp (now on r-forge.r-project.org) and there are
parallel discussions going on regarding Swig.
| PS:Does anyone know how to do an effective search for R in google (or
|other search engines). The fact that this is a single letters seems
i) Use the dedicated front-ends to searching as eg RSiteSearch("foo") from
within R, or
ii) combine your search terms with terms like 'r-help' or 'r-devel'
| PPS: I there a USENET group dedicated to R?
There are several lists/usenet gateways like eg gmane. See the R FAQ/
Dirk
--
Three out of two people have difficulties with fractions.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Java->R functions (or possibly C++ -> R)
Hello all, I am trying to implement a simple Genetic Algorithm using some of the functions of R (such as lm). I am a total newbie with regard to R, but not programming or GAs. I thought I would have to do this in R but now it seems there are ways to call R functions from Java after all. (C++ would work for me too, having a compiled language should speed up the program.) Are there recommended approaches/packages for the Java->R interfaces? Is JRI the way to go? I would like this to work under Windows and Linux ideally, and be relatively painless to install/work :-) I am assuming the Java->R approach might be more efficient vs implementation in the R language (which I am willing to learn if necessary) - but I lack experience with R to judge this. (ie byte-compiled vs purely interpreted) There will probably be more elementary questions (I am reading the various manuals too .. but if anyone has some other favorite sites they want to recommend please do so) Thanks! Esmail PS:Does anyone know how to do an effective search for R in google (or other search engines). The fact that this is a single letters seems to have most applications ignore this input. This might help me in finding answers to some other basic questions I have (such as is there an equivalent function to "printf" in R? "cat" and "print" are not quite working right for me -- but I need to dig deeper into the documentation) PPS: I there a USENET group dedicated to R? _ Going green? See the top 12 foods to eat organic. 1N1653A [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fortran underscore problem persists on Linux x86/64 (PR#11206)
>>
>> Thanks, for code-compilation problems we need that level of detail.
>>
>> Your problem appears to be that you are mixing gcc4 and g77 (not
>> recommended), and g77 does use extra underscores, I believe. I have
>>
>> /* Define if your Fortran compiler appends an extra_underscore to
>> external
>>names containing an underscore. */
>> /* #undef HAVE_F77_EXTRA_UNDERSCORE */
>>
>> /* Define if your Fortran compiler appends an underscore to external
>> names. */
>> #define HAVE_F77_UNDERSCORE 1
>>
>> in src/include/config.h. If the first of these is defined, please
>> try commenting it out and rebuilding R.
>>
>> I've found an old Solaris box that still has g77 on, and I can
>> reproduce this there. I will patch the sources after further
>> testing, but altering src/include/config.h worked for me.
>>
>> I was certainly not expecting Ubuntu 7.07 to be using g77, so we need
>> the same details from Thomas Petzoldt.
>
> Is this perhaps an installation issue (missing gfortran)?
>
> more `R RHOME`/etc/Makeconf
>
> should tell you which compilers R itself was built with. In my
> experience, it just doesn't work to mix v.3.x and 4.x compilers (Brian
> might correct me on that though).
>
Thank you, your hint worked!
I commented out the line:
#define HAVE_F77_EXTRA_UNDERSCORE 1
in the R configure script (line 28098 in R 2.7.0 RC (2008-04-15 r45347))
Contrary to what I thought previously, I have gfortran installed:
> gfortran-4.0 --version
GNU Fortran 95 (GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5))
And here is the content of the "working" Makeconf:
## Makeconf
# etc/Makeconf. Generated from Makeconf.in by configure.
#
# ${R_HOME}/etc/Makeconf
include $(R_SHARE_DIR)/make/vars.mk
AR = ar
BLAS_LIBS = -L$(R_HOME)/lib$(R_ARCH) -lRblas
C_VISIBILITY = -fvisibility=hidden
CC = gcc -std=gnu99
CFLAGS = -g -O2
CPICFLAGS = -fpic
CPPFLAGS = -I/usr/local/include
CXX = g++
CXXCPP = g++ -E
CXXFLAGS = -g -O2
CXXPICFLAGS = -fpic
DYLIB_EXT = .so
DYLIB_LD = gcc -std=gnu99
DYLIB_LDFLAGS = -shared
DYLIB_LINK = $(DYLIB_LD) $(DYLIB_LDFLAGS) $(LDFLAGS)
ECHO = echo
ECHO_C =
ECHO_N = -n
ECHO_T =
F77 = g77
F77_VISIBILITY =
FC = g77
FCFLAGS = -g -O2
FFLAGS = -g -O2
FLIBS = -L/usr/lib/gcc/x86_64-linux-gnu/3.4.6 -lg2c -lm
FCPICFLAGS = -fpic
FPICFLAGS = -fpic
FOUNDATION_CPPFLAGS =
FOUNDATION_LIBS =
JAR = /usr/bin/jar
JAVA = /usr/local/jre/bin/java
JAVAC =
JAVAH =
JAVA_HOME = /usr/local/jre1.5.0_07
JAVA_LD_LIBRARY_PATH =
$(JAVA_HOME)/lib/amd64/server:$(JAVA_HOME)/lib/amd64:$(JAVA_HOME)/../lib/amd64:/usr/local/lib64
JAVA_LIBS = -L$(JAVA_HOME)/lib/amd64/server -L$(JAVA_HOME)/lib/amd64
-L$(JAVA_HOME)/../lib/amd64 -L/usr/local/lib64 -ljvm
JAVA_CPPFLAGS = ~autodetect~
LAPACK_LIBS = -L$(R_HOME)/lib$(R_ARCH) -lRlapack
## we only need this is if it is external, as otherwise link to R
LIBINTL=
LIBM = -lm
LIBR =
LIBS = -ldl -lm
## needed by R CMD config
LIBnn = lib64
LIBTOOL = $(SHELL) $(R_HOME)/bin/libtool
LDFLAGS = -L/usr/local/lib64
## needed to build applications linking to static libR
MAIN_LD = gcc -std=gnu99
MAIN_LDFLAGS = -Wl,--export-dynamic
MAIN_LINK = $(MAIN_LD) $(MAIN_LDFLAGS) $(LDFLAGS)
OBJC =
OBJCFLAGS =
OBJC_LIBS =
OBJCXX =
R_ARCH =
RANLIB = ranlib
SAFE_FFLAGS = -g -O2 -ffloat-store
SED = /bin/sed
SHELL = /bin/sh
SHLIB_CFLAGS =
SHLIB_CXXFLAGS =
SHLIB_CXXLD = g++
SHLIB_CXXLDFLAGS = -shared
SHLIB_EXT = .so
SHLIB_FCLD = g77
SHLIB_FCLDFLAGS = -shared
SHLIB_FFLAGS =
SHLIB_LD = gcc -std=gnu99
SHLIB_LDFLAGS = -shared
SHLIB_LIBADD =
SHLIB_LINK = $(SHLIB_LD) $(SHLIB_LDFLAGS) $(LDFLAGS)
STRIP_LIBS = strip --strip-unneeded
STRIP_STATIC_LIBS = strip --strip-debug
TCLTK_CPPFLAGS = -I/usr/include/tcl8.4
TCLTK_LIBS = -L/usr/lib -ltcl8.4 -L/usr/lib -ltk8.4 -lX11
## for linking to libR.a
STATIC_LIBR = # $(R_HOME)/lib$(R_ARCH)/libR.a $(BLAS_LIBS) $(FLIBS)
$(LIBINTL) -lreadline $(LIBS)
R_XTRA_CFLAGS =
R_XTRA_CPPFLAGS = -I$(R_INCLUDE_DIR)
R_XTRA_CXXFLAGS =
R_XTRA_FFLAGS =
ALL_CFLAGS = $(R_XTRA_CFLAGS) $(PKG_CFLAGS) $(CPICFLAGS) $(SHLIB_CFLAGS)
$(CFLAGS)
ALL_CPPFLAGS = $(R_XTRA_CPPFLAGS) $(PKG_CPPFLAGS) $(CPPFLAGS)
$(CLINK_CPPFLAGS)
ALL_CXXFLAGS = $(R_XTRA_CXXFLAGS) $(PKG_CXXFLAGS) $(CXXPICFLAGS)
$(SHLIB_CXXFLAGS) $(CXXFLAGS)
ALL_OBJCFLAGS = $(PKG_OBJCFLAGS) $(CPICFLAGS) $(SHLIB_CFLAGS) $(OBJCFLAGS)
ALL_OBJCXXFLAGS = $(PKG_OBJCXXFLAGS) $(CXXPICFLAGS) $(SHLIB_CXXFLAGS)
$(OBJCXXFLAGS)
ALL_FFLAGS = $(R_XTRA_FFLAGS) $(PKG_FFLAGS) $(FPICFLAGS) $(SHLIB_FFLAGS)
$(FFLAGS)
ALL_LIBS = $(PKG_LIBS) $(SHLIB_LIBADD) $(LIBR)# $(LIBINTL)
.SUFFIXES:
.SUFFIXES: .c .cc .cpp .C .d .f .f90 .f95 .m .mm .M .o
.c.o:
$(CC) $(ALL_CPPFLAGS) $(ALL_CFLAGS) -c $< -o $@
.c.d:
@echo "making $@ from $<"
@gcc -std=gnu99 -MM $(ALL_CPPFLAGS) $< > $@
.m.d:
@echo > $@
.cc.o:
$(CXX) $(ALL_CPPFLAGS) $(ALL_CXXFLAGS) -c $< -o $@
.cpp.o:
$(CXX) $(ALL_CPPFLAGS) $(ALL_CXXFLAGS) -c $< -o $@
.C.o:
$(CXX) $(ALL_CPPFLAGS) $(ALL_CXXFLAGS) -c $< -o $@
.cc.d:
@echo "making $@ from $<"
@$(CXX) -M $(ALL
Re: [Rd] package building problem under Windows Vista
There does seem to be some general problem associated with Sweave
and graphics when I try it on my Vista system with
[1] "R version 2.7.0 RC (2008-04-17 r45367)"
Using tradeCosts-article.Rnw from the tradeCosts package:
setwd(path.to.tradeCosts-article.Rnw)
Sweave("tradeCosts-article.Rnw")
appears to work properly; however, if we try it from the
command line:
R CMD Sweave tradeCosts-article.Rnw
to simulate what happens when trying to build the package it
indicates that in chunk 2 that pdf is masked from grDevices.
Then in chunk 17, when plotting is attempted the first time,
it chokes.
Maybe someone familiar with the relevant internals can explain.
I have shown chunks 1, 2 and 17 as output from Stangle,
the Rnw file up to the end of chunk 2 and the error log
from Sweave in the sections below.
-
###
### chunk number 1:
###
options(digits = 3, width = 60, scipen = 99)
set.seed(1)
cat.df.without.rownames <- function (d, file = ""){
stopifnot(is.data.frame(d))
row.names(d) <- 1:nrow(d)
x <- NULL
conn <- textConnection("x", "w", local = TRUE)
capture.output(print(d), file = conn)
close(conn)
cat(substring(x, first = max(nchar(row.names(d))) + 2), sep = "\n",
file = file)
}
###
### chunk number 2:
###
library(tradeCosts)
data(trade.mar.2007)
head(trade.mar.2007)
###
### chunk number 17:
###
plot(result.batched, "time.series.bps")
-
\documentclass[a4paper]{report}
\usepackage[round]{natbib}
\usepackage{Rnews}
\usepackage{fancyvrb}
\usepackage{Sweave}
\hyphenation{tradeCosts}
\hyphenation{tradeCostsResults}
\hyphenation{decision}
\DefineVerbatimEnvironment{Sinput}{Verbatim}{fontsize=\small,fontshape=sl}
\DefineVerbatimEnvironment{Soutput}{Verbatim}{fontsize=\small}
\DefineVerbatimEnvironment{Scode}{Verbatim}{fontsize=\small,fontshape=sl}
%% \SweaveOpts{prefix.string=graphics/portfolio}
\bibliographystyle{abbrvnat}
\begin{document}
\begin{article}
\title{Trade Costs}
\author{Jeff Enos, David Kane, Arjun Ravi Narayan, Aaron Schwartz,
Daniel Suo and Luyi Zhao}
%%\VignetteIndexEntry{Trade Costs}
%%\VignetteDepends{tradeCosts}
<>=
options(digits = 3, width = 60, scipen = 99)
set.seed(1)
cat.df.without.rownames <- function (d, file = ""){
stopifnot(is.data.frame(d))
row.names(d) <- 1:nrow(d)
x <- NULL
conn <- textConnection("x", "w", local = TRUE)
capture.output(print(d), file = conn)
close(conn)
cat(substring(x, first = max(nchar(row.names(d))) + 2), sep = "\n",
file = file)
}
@
\maketitle
\setkeys{Gin}{width=0.95\textwidth}
\section*{Introduction}
Trade costs are the costs a trader must pay to implement a decision to
buy or sell a security. Consider a single trade of a single equity
security. Suppose on the evening of August 1, a trader decides to
purchase 10,000 shares of IBM at \$10, the \emph{decision price} of
the trade. The next day, the trader's broker buys 10,000 shares in a
rising market and pays \$11 per share, the trade's \emph{execution price}.
How much did it cost to implement this trade? In the most basic
ex-post analysis, trade costs are calculated by comparing the
execution price of a trade to a benchmark price.\footnote{For an
in-depth discussion of both ex-ante modeling and ex-post measurement
of trade costs, see \citet{kissell:glantz}.} Suppose we
wished to compare the execution price to the price of the security at
the time of the decision in the above example. Since the trader's
decision occurred at \$10 and the broker paid \$11, the cost of the
trade relative to the decision price was $\$11 - \$10 = \$1$ per
share, or \$10,000 (9.1\% of the total value of the execution).
Measuring costs relative to a trade's decision price captures costs
associated with the delay in the release of a trade into the market
and movements in price after the decision was made but before the
order is completed. It does not, however, provide a means to
determine whether the broker's execution reflects a fair price. For
example, the price of \$11 would be a poor price if most transactions
in IBM on August 2 occurred at \$10.50. For this purpose a better
benchmark would be the day's volume-weighted average price, or VWAP.
If VWAP on August 2 was \$10.50 and the trader used this as her
benchmark, then the trade cost would be \$0.50 per share, or \$500.
The first version of the \pkg{tradeCosts} package provides a simple
framework for calculating the cost of trades relative to a benchmark
price, such as VWAP or decision price, over multiple periods and basic
reporting and plotting facilities to analyse these c
Re: [Rd] Fortran underscore problem persists on Linux x86/64 (PR#11206)
Prof Brian Ripley wrote: > On Sun, 20 Apr 2008, Thibaut Jombart wrote: > >> Prof Brian Ripley wrote: >> >>> And your machine is? -- you haven't given the 'at a minimum' >>> information asked for in the posting guide. >>> >>> Neither example is reproducible on my Fedora 8 x86_64 systems (nor >>> in the case of tripack, on CRAN's). It will need someone with an >>> affected system to debug this. One possibility is that they are >>> using double underscores, where the code does not look right to me >>> -- but few systems do and this code is the same as in 2.6.2. >>> >>> For the record, 'iniaqua' is a not a valid Fortran entry point, and >>> all these issues will go away if you register your package's symbols. >>> >>> What does nm -g report on the affected DSOs? >>> >>> >> My mistake, I thought sessionInfo() would be enough. My system is an >> Ubuntu Dapper Drake (6.06.2 LTS, 64 bits version). R installed from >> the sources, same for the packages, using install.packages (one >> warning for tripack: an unmatched right brace in a manpage). My >> fortran and C compilers are respectively g77 and gcc: >>> g77 -dumpversion >> GNU Fortran (GCC) 3.4.6 (Ubuntu 3.4.6-1ubuntu2) >> >>> gcc --version >> gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) > > Thanks, for code-compilation problems we need that level of detail. > > Your problem appears to be that you are mixing gcc4 and g77 (not > recommended), and g77 does use extra underscores, I believe. I have > > /* Define if your Fortran compiler appends an extra_underscore to > external >names containing an underscore. */ > /* #undef HAVE_F77_EXTRA_UNDERSCORE */ > > /* Define if your Fortran compiler appends an underscore to external > names. */ > #define HAVE_F77_UNDERSCORE 1 > > in src/include/config.h. If the first of these is defined, please try > commenting it out and rebuilding R. > > I've found an old Solaris box that still has g77 on, and I can > reproduce this there. I will patch the sources after further testing, > but altering src/include/config.h worked for me. > > I was certainly not expecting Ubuntu 7.07 to be using g77, so we need > the same details from Thomas Petzoldt. Is this perhaps an installation issue (missing gfortran)? more `R RHOME`/etc/Makeconf should tell you which compilers R itself was built with. In my experience, it just doesn't work to mix v.3.x and 4.x compilers (Brian might correct me on that though). -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fortran underscore problem persists on Linux x86/64 (PR#11206)
On Sun, 20 Apr 2008, Thibaut Jombart wrote: Prof Brian Ripley wrote: And your machine is? -- you haven't given the 'at a minimum' information asked for in the posting guide. Neither example is reproducible on my Fedora 8 x86_64 systems (nor in the case of tripack, on CRAN's). It will need someone with an affected system to debug this. One possibility is that they are using double underscores, where the code does not look right to me -- but few systems do and this code is the same as in 2.6.2. For the record, 'iniaqua' is a not a valid Fortran entry point, and all these issues will go away if you register your package's symbols. What does nm -g report on the affected DSOs? My mistake, I thought sessionInfo() would be enough. My system is an Ubuntu Dapper Drake (6.06.2 LTS, 64 bits version). R installed from the sources, same for the packages, using install.packages (one warning for tripack: an unmatched right brace in a manpage). My fortran and C compilers are respectively g77 and gcc: g77 -dumpversion GNU Fortran (GCC) 3.4.6 (Ubuntu 3.4.6-1ubuntu2) gcc --version gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) Thanks, for code-compilation problems we need that level of detail. Your problem appears to be that you are mixing gcc4 and g77 (not recommended), and g77 does use extra underscores, I believe. I have /* Define if your Fortran compiler appends an extra_underscore to external names containing an underscore. */ /* #undef HAVE_F77_EXTRA_UNDERSCORE */ /* Define if your Fortran compiler appends an underscore to external names. */ #define HAVE_F77_UNDERSCORE 1 in src/include/config.h. If the first of these is defined, please try commenting it out and rebuilding R. I've found an old Solaris box that still has g77 on, and I can reproduce this there. I will patch the sources after further testing, but altering src/include/config.h worked for me. I was certainly not expecting Ubuntu 7.07 to be using g77, so we need the same details from Thomas Petzoldt. BDR # This may be useful: ld --version GNU ld version 2.16.91 20060118 Debian GNU/Linux # Your request: nm -g /usr/local/lib64/R-rc/library/tripack/libs/tripack.so 1f40 T addcst_ 2270 T addnod_ 2820 T areap_ 2890 T bdyadd_ 29c0 T bnodes_ 1cc0 T border_ 0010c53c A __bss_start 2a40 T circum_ 2c40 T crtri_ w __cxa_finalize@@GLIBC_2.2.5 2cd0 T delarc_ 2eb0 T delnb_ 3050 T delnod_ U do_fio 0010c53c A _edata 3910 T edge_ 0010c568 A _end U e_wsfe a6c8 T _fini 4570 T getnp_ w __gmon_start__ 5010 T indxcc_ 1740 T inhull_ 14c0 T _init 5090 T insert_ 50c0 T intadd_ 51f0 T intsec_ 5370 T jrand_ w _Jv_RegisterClasses 5450 T left_ 5490 T lstptr_ 54c0 T nbcnt_ 54e0 T nearnd_ 1940 T onhull_ 5910 T optim_ 1d10 T qsort_ a620 T rmshnb_ 0010c550 B stcom_ 5b90 T store_ 5ba0 T swap_ 0010c560 B swpcom_ 5d60 T swptst_ U s_wsfe 5e90 T trfind_ 6730 T trlist_ 6be0 T trlprt_ 7080 T trmesh_ 76a0 T trmshr_ 9d80 T troutp_ 9e80 T troutq_ 8190 T trplot_ 97e0 T trprnt_ 9fc0 T voronoi_ I can see one single difference in the compilation logs for tripack using R 2.6.2 vs R-rc (2008-04-15 r45347), and the same sources: in R 2.6.2, gcc uses the option -lgcc_s to produce the shared object, which is not used in R-rc. Command in R 2.6.2 is: [...] gcc -std=gnu99 -shared -L/usr/local/lib64 -o tripack.so inhull.o qsort.o tr ipack.o troutp.o troutq.o voronoi.o -L/usr/lib/gcc/x86_64-linux-gnu/3.4.6 -lg2c -lm -lgcc_s [...] I hope this helps. I'd be glad to provide more details if needed. Regards, Thibaut. > sessionInfo() R version 2.7.0 RC (2008-04-15 r45347) x86_64-unknown-linux-gnu locale: LC_CTYPE=fr_FR.UTF-8;LC_NUMERIC=C;LC_TIME=fr_FR.UTF-8;LC_COLLATE=fr_FR.UTF-8;LC_MONETARY=C;LC_MESSAGES=fr_FR.UTF-8;LC_PAPER=fr_FR.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=fr_FR.UTF-8;LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] tripack_1.2-11 loaded via a namespace (and not attached): [1] tools_2.7.0 ### Best regards, Thibaut. -- ## Thibaut JOMBART CNRS UMR 5558 - Laboratoire de Biométrie et Biologie Evolutive Universite Lyon 1 43 bd du 11 novembre 1918 69622 Villeurbanne Cedex Tél. : 04.72.43.29.35 Fax : 04.72.43.13.88 [EMAIL PROTECTED] http://lbbe.univ-lyon1.fr/-Jombart
Re: [Rd] Fortran underscore problem persists on Linux x86/64 (PR#11206)
Prof Brian Ripley wrote: > And your machine is? -- you haven't given the 'at a minimum' > information asked for in the posting guide. > > Neither example is reproducible on my Fedora 8 x86_64 systems (nor in > the case of tripack, on CRAN's). It will need someone with an > affected system to debug this. One possibility is that they are using > double underscores, where the code does not look right to me -- but > few systems do and this code is the same as in 2.6.2. > > For the record, 'iniaqua' is a not a valid Fortran entry point, and > all these issues will go away if you register your package's symbols. > > What does nm -g report on the affected DSOs? > > My mistake, I thought sessionInfo() would be enough. My system is an Ubuntu Dapper Drake (6.06.2 LTS, 64 bits version). R installed from the sources, same for the packages, using install.packages (one warning for tripack: an unmatched right brace in a manpage). My fortran and C compilers are respectively g77 and gcc: > g77 -dumpversion GNU Fortran (GCC) 3.4.6 (Ubuntu 3.4.6-1ubuntu2) > gcc --version gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) # This may be useful: > ld --version GNU ld version 2.16.91 20060118 Debian GNU/Linux # Your request: > nm -g /usr/local/lib64/R-rc/library/tripack/libs/tripack.so 1f40 T addcst_ 2270 T addnod_ 2820 T areap_ 2890 T bdyadd_ 29c0 T bnodes_ 1cc0 T border_ 0010c53c A __bss_start 2a40 T circum_ 2c40 T crtri_ w __cxa_finalize@@GLIBC_2.2.5 2cd0 T delarc_ 2eb0 T delnb_ 3050 T delnod_ U do_fio 0010c53c A _edata 3910 T edge_ 0010c568 A _end U e_wsfe a6c8 T _fini 4570 T getnp_ w __gmon_start__ 5010 T indxcc_ 1740 T inhull_ 14c0 T _init 5090 T insert_ 50c0 T intadd_ 51f0 T intsec_ 5370 T jrand_ w _Jv_RegisterClasses 5450 T left_ 5490 T lstptr_ 54c0 T nbcnt_ 54e0 T nearnd_ 1940 T onhull_ 5910 T optim_ 1d10 T qsort_ a620 T rmshnb_ 0010c550 B stcom_ 5b90 T store_ 5ba0 T swap_ 0010c560 B swpcom_ 5d60 T swptst_ U s_wsfe 5e90 T trfind_ 6730 T trlist_ 6be0 T trlprt_ 7080 T trmesh_ 76a0 T trmshr_ 9d80 T troutp_ 9e80 T troutq_ 8190 T trplot_ 97e0 T trprnt_ 9fc0 T voronoi_ I can see one single difference in the compilation logs for tripack using R 2.6.2 vs R-rc (2008-04-15 r45347), and the same sources: in R 2.6.2, gcc uses the option -lgcc_s to produce the shared object, which is not used in R-rc. Command in R 2.6.2 is: [...] gcc -std=gnu99 -shared -L/usr/local/lib64 -o tripack.so inhull.o qsort.o tr ipack.o troutp.o troutq.o voronoi.o -L/usr/lib/gcc/x86_64-linux-gnu/3.4.6 -lg2c -lm -lgcc_s [...] I hope this helps. I'd be glad to provide more details if needed. Regards, Thibaut. >> > sessionInfo() >> R version 2.7.0 RC (2008-04-15 r45347) >> x86_64-unknown-linux-gnu >> >> locale: >> LC_CTYPE=fr_FR.UTF-8;LC_NUMERIC=C;LC_TIME=fr_FR.UTF-8;LC_COLLATE=fr_FR.UTF-8;LC_MONETARY=C;LC_MESSAGES=fr_FR.UTF-8;LC_PAPER=fr_FR.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=fr_FR.UTF-8;LC_IDENTIFICATION=C >> >> >> >> attached base packages: >> [1] stats graphics grDevices utils datasets methods base >> >> other attached packages: >> [1] tripack_1.2-11 >> >> loaded via a namespace (and not attached): >> [1] tools_2.7.0 >> ### >> >> Best regards, >> >> Thibaut. > > -- ## Thibaut JOMBART CNRS UMR 5558 - Laboratoire de Biométrie et Biologie Evolutive Universite Lyon 1 43 bd du 11 novembre 1918 69622 Villeurbanne Cedex Tél. : 04.72.43.29.35 Fax : 04.72.43.13.88 [EMAIL PROTECTED] http://lbbe.univ-lyon1.fr/-Jombart-Thibaut-.html?lang=en http://adegenet.r-forge.r-project.org/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fortran underscore problem persists on Linux x86/64 (PR#11206)
And your machine is? -- you haven't given the 'at a minimum' information
asked for in the posting guide.
Neither example is reproducible on my Fedora 8 x86_64 systems (nor in the
case of tripack, on CRAN's). It will need someone with an affected system
to debug this. One possibility is that they are using double underscores,
where the code does not look right to me -- but few systems do and this
code is the same as in 2.6.2.
For the record, 'iniaqua' is a not a valid Fortran entry point, and all
these issues will go away if you register your package's symbols.
What does nm -g report on the affected DSOs?
On Sun, 20 Apr 2008, Thibaut Jombart wrote:
[EMAIL PROTECTED] wrote:
Full_Name: Thomas Petzoldt
Version: R 2.8.0 devel, svn version 45389
OS: Linux x86/64 Ubuntu 7.1
Submission from: (NULL) (217.235.62.12)
In contrast to all other tested operating systems a call of Fortran functions on
Linux x86/64 requires an appended underscore.
The problem occured with package deSolve
(http://r-forge.r-project.org/projects/desolve/)
See also:
http://tolstoy.newcastle.edu.au/R/e4/devel/08/04/1224.html
Relevant code snippets
In R:
getNativeSymbolInfo("iniaqua", PACKAGE = "deSolve")$address
Error in FUN("iniaqua"[[1L]], ...) :
no such symbol iniaqua in package deSolve
getNativeSymbolInfo("iniaqua_", PACKAGE = "deSolve")$address
attr(,"class")
[1] "NativeSymbol"
In Aquaphy.f:
subroutine iniaqua(odeparms)
external odeparms
double precision pars(19)
common /myparms/pars
call odeparms(19, pars)
return
end
cd //
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Well, thanks Thomas, I fell less alone now...
I seemingly had the same problem:
> library(tripack)
> example(tri.mesh)
tr.msh> data(tritest)
tr.msh> tritest.tr<-tri.mesh(tritest$x,tritest$y)
Erreur dans .Fortran("trmesh", as.integer(n), x = as.double(x1), y =
as.double(y1), :
le nom Fortran de symbole "trmesh" est introuvable dans la DLL pour le
package "tripack"
## (error says that "trmesh" cannot be found in the tripack DLL
## this does not happen on the same machine/OS with R.2.6.2
> getNativeSymbolInfo("trmesh", PACKAGE = "tripack")
Erreur dans FUN("trmesh"[[1L]], ...) :
no such symbol trmesh in package tripack
> getNativeSymbolInfo("trmesh_", PACKAGE = "tripack")
$name
[1] "trmesh_"
$address
attr(,"class")
[1] "NativeSymbol"
$package
DLL name: tripack
Filename: /usr/local/lib64/R-rc/library/tripack/libs/tripack.so
Dynamic lookup: TRUE
attr(,"class")
[1] "NativeSymbolInfo"
> sessionInfo()
R version 2.7.0 RC (2008-04-15 r45347)
x86_64-unknown-linux-gnu
locale:
LC_CTYPE=fr_FR.UTF-8;LC_NUMERIC=C;LC_TIME=fr_FR.UTF-8;LC_COLLATE=fr_FR.UTF-8;LC_MONETARY=C;LC_MESSAGES=fr_FR.UTF-8;LC_PAPER=fr_FR.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=fr_FR.UTF-8;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] tripack_1.2-11
loaded via a namespace (and not attached):
[1] tools_2.7.0
###
Best regards,
Thibaut.
--
##
Thibaut JOMBART
CNRS UMR 5558 - Laboratoire de Biométrie et Biologie Evolutive
Universite Lyon 1
43 bd du 11 novembre 1918
69622 Villeurbanne Cedex
Tél. : 04.72.43.29.35
Fax : 04.72.43.13.88
[EMAIL PROTECTED]
http://lbbe.univ-lyon1.fr/-Jombart-Thibaut-.html?lang=en
http://adegenet.r-forge.r-project.org/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fortran underscore problem persists on Linux x86/64 (PR#11206)
[EMAIL PROTECTED] wrote:
>Full_Name: Thomas Petzoldt
>Version: R 2.8.0 devel, svn version 45389
>OS: Linux x86/64 Ubuntu 7.1
>Submission from: (NULL) (217.235.62.12)
>
>
>In contrast to all other tested operating systems a call of Fortran functions
>on
>Linux x86/64 requires an appended underscore.
>
>The problem occured with package deSolve
>(http://r-forge.r-project.org/projects/desolve/)
>
>
>See also:
>
>http://tolstoy.newcastle.edu.au/R/e4/devel/08/04/1224.html
>
>Relevant code snippets
>
>In R:
>
>
>
>>getNativeSymbolInfo("iniaqua", PACKAGE = "deSolve")$address
>>
>>
>Error in FUN("iniaqua"[[1L]], ...) :
> no such symbol iniaqua in package deSolve
> > getNativeSymbolInfo("iniaqua_", PACKAGE = "deSolve")$address
>
>attr(,"class")
>[1] "NativeSymbol"
>
>
>In Aquaphy.f:
>
> subroutine iniaqua(odeparms)
>
> external odeparms
> double precision pars(19)
> common /myparms/pars
>
> call odeparms(19, pars)
>
> return
> end
>
>__
>R-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
>
Well, thanks Thomas, I fell less alone now...
I seemingly had the same problem:
> library(tripack)
> example(tri.mesh)
tr.msh> data(tritest)
tr.msh> tritest.tr<-tri.mesh(tritest$x,tritest$y)
Erreur dans .Fortran("trmesh", as.integer(n), x = as.double(x1), y =
as.double(y1), :
le nom Fortran de symbole "trmesh" est introuvable dans la DLL pour le
package "tripack"
## (error says that "trmesh" cannot be found in the tripack DLL
## this does not happen on the same machine/OS with R.2.6.2
> getNativeSymbolInfo("trmesh", PACKAGE = "tripack")
Erreur dans FUN("trmesh"[[1L]], ...) :
no such symbol trmesh in package tripack
> getNativeSymbolInfo("trmesh_", PACKAGE = "tripack")
$name
[1] "trmesh_"
$address
attr(,"class")
[1] "NativeSymbol"
$package
DLL name: tripack
Filename: /usr/local/lib64/R-rc/library/tripack/libs/tripack.so
Dynamic lookup: TRUE
attr(,"class")
[1] "NativeSymbolInfo"
> sessionInfo()
R version 2.7.0 RC (2008-04-15 r45347)
x86_64-unknown-linux-gnu
locale:
LC_CTYPE=fr_FR.UTF-8;LC_NUMERIC=C;LC_TIME=fr_FR.UTF-8;LC_COLLATE=fr_FR.UTF-8;LC_MONETARY=C;LC_MESSAGES=fr_FR.UTF-8;LC_PAPER=fr_FR.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=fr_FR.UTF-8;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] tripack_1.2-11
loaded via a namespace (and not attached):
[1] tools_2.7.0
###
Best regards,
Thibaut.
--
##
Thibaut JOMBART
CNRS UMR 5558 - Laboratoire de Biométrie et Biologie Evolutive
Universite Lyon 1
43 bd du 11 novembre 1918
69622 Villeurbanne Cedex
Tél. : 04.72.43.29.35
Fax : 04.72.43.13.88
[EMAIL PROTECTED]
http://lbbe.univ-lyon1.fr/-Jombart-Thibaut-.html?lang=en
http://adegenet.r-forge.r-project.org/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] AddComment (gram.y)
> >> anyone object to bringing it back?
> >>
> DM> Yes, I would.
>
> and so would probably almost everyone in R-core.
> We *did* think already back in the last millennium...
> and removed them for a good reason
> {IIRC, because there were always cases where they were attached
> to the wrong expression, and we were more or less convinced,
> there was no to do it "right" in all cases}.
>
>
Yes. Well, there was no _obvious_ way to do it right. If someone sets
out to do it right, we might want the result, but it is definitely not
as easy as reinstating the 1999 code, which would do fun stuff like
moving end-loop comments to the start of the loop (and in glm.fit, the
end-loop comment was, and still is, "## -- end IRLS iteration --"!!). It
requires a substantial parser rewrite.
The main issue is that you wold need the parser to retain more
information about the textual layout of its input, probably not only
about the comments, but also about line breaks. If you consider
moderately complex syntactical structures, like for loops and switch
expressions, all the points where you could potentially insert a
comment or break the line, and then try to insert that information in
the parse tree, chances are you come out utterly confused. Notice, in
particular, that everything is ambiguous, if you have two successive
expressions and a comment on the line in between, does it belong with
the former or the latter expression? And what about
plot(
x=foo, # abscissa
y=bar # ordinate
)
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
