[Rd] Dynamic load library problem using R 4.0.0
I'm having problems getting code that runs under 3.6.1 on MacOSX (and
Ubuntu)
to run the R version 4.0.0 on Windows. I have not tested R 4.0.0 on mac
(yet).
Key question: Has anything changed in R 4.0.0/Windows regarding how
dynamically loaded
libraries are accessed? Can someone please point me in the right direction?
WORKS On MacOSX Under:
R version 3.6.1 (2019-07-05) -- "Action of the Toes"
after dynamically loading ../../bin/qFVSie.so:
> getLoadedDLLs()$qFVSie
DLL name: qFVSie
Filename:
/Users/ncrookston/open-fvs/branches/NickDev/tests/APIviaR/../../bin/qFVSie.so
Dynamic lookup: TRUE
# expected output is correct:
> i=1
> .C("CfvsSpeciesCode",fvs_code="",fia_code="",plant_code="",
indx=as.integer(i))
$fvs_code
[1] "WP"
$fia_code
[1] "119"
$plant_code
[1] "PIMO3"
$indx
[1] 1
- from the nm command:
$ nm ../../bin/qFVSie.so | grep -i cfvsspeciescode
000a7980 T _CfvsSpeciesCode
Fails On Win10 Under:
R version 4.0.0 Under development (Rtools 4.0) (2019-11-23 r77455) --
"Blame Jeroen"
NOTE: The .dll is built using the most recent Rtools as advised by Jeroen.
> getLoadedDLLs()$qFVSie
DLL name: qFVSie
Filename:
C:/Users/nickc/open-fvs/branches/NickDev/tests/APIviaR/../../bin/qFVSie.dll
Dynamic lookup: TRUE
> i=1
> .C("CfvsSpeciesCode",fvs_code="",fia_code="",plant_code="",
indx=as.integer(i))
Error in .C("CfvsSpeciesCode", fvs_code = "", fia_code = "", plant_code =
"", :
C symbol name "CfvsSpeciesCode" not in load table
- from the nm command on Win10:
nm ../../bin/qFVSie.dll | grep -i cfvsspeciescode
707a21f0 T CfvsSpeciesCode
---
If advised to do so, I'll create a simple and fully reproducible example,
but perhaps
I missing something simple (like compiler switch needed to create my .dll
that has not
been necessary until now).
Thanks, Nick
--
Nicholas L. Crookston
Forestry Research Consultant
Moscow Idaho USA
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Dynamic load library problem using R 4.0.0
Case closed. My error was that I had not included an "export" option to
the linker and the symbols were not being exported (I was out of practice
building Window's dlls). The nm command output didn't help me. Thanks to
Tomas Kalibera and Jeroen Ooms for some helpful correspondence.
On Tue, Dec 3, 2019 at 1:41 PM Nicholas Crookston
wrote:
> I'm having problems getting code that runs under 3.6.1 on MacOSX (and
> Ubuntu)
> to run the R version 4.0.0 on Windows. I have not tested R 4.0.0 on mac
> (yet).
>
> Key question: Has anything changed in R 4.0.0/Windows regarding how
> dynamically loaded
> libraries are accessed? Can someone please point me in the right
> direction?
>
> WORKS On MacOSX Under:
> R version 3.6.1 (2019-07-05) -- "Action of the Toes"
> after dynamically loading ../../bin/qFVSie.so:
>
> > getLoadedDLLs()$qFVSie
> DLL name: qFVSie
> Filename:
>
> /Users/ncrookston/open-fvs/branches/NickDev/tests/APIviaR/../../bin/qFVSie.so
> Dynamic lookup: TRUE
>
> # expected output is correct:
> > i=1
> > .C("CfvsSpeciesCode",fvs_code="",fia_code="",plant_code="",
> indx=as.integer(i))
> $fvs_code
> [1] "WP"
> $fia_code
> [1] "119"
> $plant_code
> [1] "PIMO3"
> $indx
> [1] 1
>
> - from the nm command:
> $ nm ../../bin/qFVSie.so | grep -i cfvsspeciescode
> 000a7980 T _CfvsSpeciesCode
>
>
>
> Fails On Win10 Under:
> R version 4.0.0 Under development (Rtools 4.0) (2019-11-23 r77455) --
> "Blame Jeroen"
> NOTE: The .dll is built using the most recent Rtools as advised by Jeroen.
>
> > getLoadedDLLs()$qFVSie
> DLL name: qFVSie
> Filename:
>
> C:/Users/nickc/open-fvs/branches/NickDev/tests/APIviaR/../../bin/qFVSie.dll
> Dynamic lookup: TRUE
>
> > i=1
> > .C("CfvsSpeciesCode",fvs_code="",fia_code="",plant_code="",
> indx=as.integer(i))
> Error in .C("CfvsSpeciesCode", fvs_code = "", fia_code = "", plant_code =
> "", :
> C symbol name "CfvsSpeciesCode" not in load table
>
> - from the nm command on Win10:
> nm ../../bin/qFVSie.dll | grep -i cfvsspeciescode
> 707a21f0 T CfvsSpeciesCode
>
> ---
>
> If advised to do so, I'll create a simple and fully reproducible example,
> but perhaps
> I missing something simple (like compiler switch needed to create my .dll
> that has not
> been necessary until now).
>
> Thanks, Nick
>
> --
> Nicholas L. Crookston
> Forestry Research Consultant
> Moscow Idaho USA
>
--
Nicholas L. Crookston
Forestry Research Consultant
Moscow Idaho USA
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Julia
There are many experts on this topic. I'll keep this short. Newer Fortran Languages allow for call by value, but call by reference is the typical and historically, the only approach (there was a time when you could change the value of 1 to 2!). C "only" calls by value except that the value can be a pointer! So, havoc is just a * away. I'm very pleased to be on this list and read the discussion. Thank you Douglas Bates for sending the first message. I like R and will continue to use it. However, I also think that strict "call by value" can get you into trouble, just trouble of a different kind. I'm not sure we will ever yearn for "Julia ouR-Julia", but it is sure fun to think about what might be possible with this language. And having fun is one key objective. Nick Crookston 2012/3/5 oliver : > On Mon, Mar 05, 2012 at 03:58:59PM -0800, Hervé Pagès wrote: >> Hi Oliver, >> >> On 03/05/2012 09:08 AM, oliver wrote: >> >On Mon, Mar 05, 2012 at 03:53:28PM +, William Dunlap wrote: >> >>I haven't used Julia yet, but from my quick reading >> >>of the docs it looks like arguments to functions are >> >>passed by reference and not by value, so functions >> >>can change their arguments. My recollection from when >> >>I first started using S (in the course of a job helping >> >>profs and grad students do statistical programming, c. 1983) >> >>is that not having to worry about in-place algorithms changing >> >>your data gave S a big advantage over Fortran or C. >> >[...] >> > >> > >> >C also uses Call-by-Value. >> >> C *only* uses Call-by-Value. > [...] > > > Yes, that's what I meant. > > With "also" I meant, that it uses call-by-value, as some > other languages also do. > > > Ciao, > Oliver > > __ > 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] stringsAsFactors
I would like to see the default for stringsAsFactors set to FALSE. As for
posting descriptions of all the horrors, also post descriptions of the
ensuing increases in productivity that many will see as they no longer have
to go back and fix code that is not working because they forgot to add
as.is=TRUE,
or stringsAsFactors=FALSE. I have often spent a lot of time fixing
"reuseable code" that was developed using data coded as numeric (and
therefore not automatically converted to factors) and then applied to new
data that has some character data which was automatically converted.
In short, I think the default is causing problems that will go away. Lets
report those cases as well!
Duncan's judgement on these issues has been quite wise in the past. I'm
going to take him up on his suggestion and change my default. Lets see!
Nick Crookston
On Wed, Feb 13, 2013 at 5:39 AM, Duncan Murdoch wrote:
> On 13-02-13 8:30 AM, Milan Bouchet-Valat wrote:
>
>> Le mercredi 13 février 2013 à 12:33 +, Michael Dewey a écrit :
>>
>>> At 18:01 11/02/2013, Ista Zahn wrote:
>>>
FWIW my view is that for data cleaning and organizing factors just get
it the way. For modeling I like them because they make it easier to
understand what is happening. For example I can look at the levels()
to see what the reference group will be. With characters one has to
know a) that levels are created in alphabetical order and b) the
alphabetical order of the the unique values in the character vector.
Ugh. So my habit is to turn off stringsAsFactors, then explicitly
convert to factors before modeling (I also use factors to change the
order in which things are displayed in tables and graphs, another
place where converting to factors myself is useful but the creating
them in alphabetical order by default is not)
All this is to say that I would like options(stingsAsFactors=FALSE) to
be the default, but I like the warning about converting to factors in
modeling functions because it reminds me that I forgot to covert them,
which I like to do anyway...
>>>
>>> I seem to be one of the few people who find the current default
>>> helpful. When I read in a dataset I am nearly always going to follow
>>> it with one or more of the modelling functions and so I do want to
>>> treat the categorical variables as factors. I cannot off-hand think
>>> of an example where I have had to convert them to characters.
>>>
>> If the changes to modeling functions that are discussed in this thread
>> can finally be applied (i.e. a solution is found), characters would be
>> converted to factors automatically, so you would not notice the
>> difference. And if you need to change the order of levels of your
>> factors, calling factor(myVar, levels=c(...)) is the same, be myVar a
>> character or a factor.
>>
>
> I think most of the changes *have* been applied. Please try R-devel, and
> point out problems.
>
> The only change that I would like to apply but haven't (and probably
> won't) is to change the default for stringsAsFactors to FALSE. Users who
> think that is a bad idea can bolster their cases by setting
> options(stringsAsFactors=**FALSE), and posting descriptions of all the
> horrors that ensue.
>
> Duncan Murdoch
>
>
>
>> Incidentally xkcd has, while this discussion has been going on,
>>> posted something relevant
>>> http://www.xkcd.com/1172/
>>>
>> Truly hilarious, indeed. But beware, it sounds like an argument in favor
>> of the change, while you are lobbying against it. :-p
>>
>>
>> Regards
>>
>>
>>
>>
>>>
>>> Best,
Ista
On Mon, Feb 11, 2013 at 12:50 PM, Duncan Murdoch
wrote:
> On 11/02/2013 12:13 PM, William Dunlap wrote:
>
>>
>> Note that changing this does not just mean getting rid of "silly
>> warnings".
>> Currently, predict.lm() can give wrong answers when stringsAsFactors
>> is
>> FALSE.
>>
>> > d <- data.frame(x=1:10, f=rep(c("A","B","C"), c(4,3,3)),
>> y=c(1:4,
>> 15:17, 28.1,28.8,30.1))
>> > fit_ab <- lm(y ~ x + f, data = d, subset = f!="B")
>> Warning message:
>> In model.matrix.default(mt, mf, contrasts) :
>> variable 'f' converted to a factor
>> > predict(fit_ab, newdata=d)
>> 1 2 3 4 5 6 7 8 9 10
>> 1 2 3 4 25 26 27 8 9 10
>> Warning messages:
>> 1: In model.matrix.default(Terms, m, contrasts.arg =
>> object$contrasts)
>> :
>> variable 'f' converted to a factor
>> 2: In predict.lm(fit_ab, newdata = d) :
>> prediction from a rank-deficient fit may be misleading
>>
>> fit_ab is not rank-deficient and the predict should report
>> 1 2 3 4 NA NA NA 28 29 30
>>
>
>
> In R-devel, the two warnings about factor conversions are no longer
> given,
> but the predictions are the same and the warning about rank
>
deficiency still
