Re: [Rd] Managing DLLs with the same names in an R session
Hi, Patrick,
We have ported Rgraphviz to Win64, and we had the same issue.
Basically we have to compile graphviz from the scratch (because there is no
graphviz binaries on Win64) and rename graph.dll to graphviz-graph.dll.
Thanks,
Alex
On Fri, Apr 24, 2009 at 11:07 AM, Patrick Aboyoun wrote:
> Thanks Brian. I'll stop trying to hack the code to work and opt for the dll
> rename option.
>
> Patrick
>
>
>
> Prof Brian Ripley wrote:
>
>> On Fri, 24 Apr 2009, Patrick Aboyoun wrote:
>>
>> I am having a problem using two DLLs with the same name, but obviously
>>> located in different directories, in an R session. The troublesome package
>>> is the (Bioconductor) Rgraphviz package. It relies on (3rd party software)
>>> graphviz and imports functions from (Bioconductor) package graph.
>>> Unfortunately, the current stable release of graphviz for Windows
>>>
>>> http://www.graphviz.org/pub/graphviz/stable/windows/graphviz-2.22.2.msi
>>>
>>> contains a graph.dll in its bin directory. The situation is that
>>> Rgraphviz needs to link to the graph.dll from graphviz,
>>>
>>> E:\paboyoun>..\biocbld\bbs-2.4-bioc\R\bin\R CMD build Rgraphviz
>>> [...omitting output...]
>>> ** libs
>>> making DLL ...
>>> [...omitting output...]
>>> gcc -shared -s -o Rgraphviz.dll tmp.def LL_funcs.o Rgraphviz.o
>>> RgraphvizInit.o agopen.o agread.o agwr
>>> ite.o bezier.o buildEdgeList.o buildNodeList.o doLayout.o
>>> graphvizVersion.o init.o -LC:/Graphviz2.22/
>>> bin -lgvc -lgraph -lcdt -Le:/biocbld/bbs-2.4-bioc/R/bin -lR
>>> [...omitting output...]
>>>
>>> but at run time R dispatches to the graph.dll from the graph package to
>>> resolve the symbols.
>>>
>>> R-2.9> Sys.which("graph.dll")
>>> graph.dll
>>> "C:\\GRAPHV~1.22\\bin\\graph.dll"
>>> R-2.9> library(Rgraphviz)
>>> Loading required package: graph
>>> Loading required package: grid
>>>
>>> << Message box appears: The procedure entry point agclose could not be
>>> located in the dynamic link library graph.dll >>
>>>
>>> Running Rterm.exe through the DependencyWalker software, I see that the
>>> gvc.dll and cdt.dll graphviz libraries are properly loaded, but the
>>> graph.dll dependency of Rgraphviz.dll links to the graph.dll library from
>>> the graph package. I tried passing the DLLpath for graphviz to the
>>> library.dynam function call when loading Rgraphviz.dll in the .onLoad
>>> function within Rgraphviz and it had no effect. I also tried
>>> library.dynam.unload/dyn.unload-ing the graph.dll from the graph package and
>>> then loading the Rgraphviz.dll followed by the reloading of the graph.dll
>>> from the graph package and the graph.dll dependencies become broken to the
>>> point that a call out to a graph.dll results in a GPF.
>>>
>>> Is is possible to manage DLLs with the same name from R or do I need to
>>> rename one of the DLL names to make them unique?
>>>
>>
>> On Windows, the latter is the only completely reliable solution that we
>> know of. We've been here with iconv.dll, and had to rename the R copy to
>> Riconv.dll as a result. (Unfortunately, it depends on the version of
>> Windows and even the service pack installed. AFAICS some versions of Windows
>> only allow one DLL of a given name to be loaded by a single process, here
>> the R process.)
>>
>> There are (older?) Unix-alike OSes with similar issues.
>>
>>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Alex Chen, Ph.D.
Software Engineer & Research Scientist
REvolution Computing
1100 Dexter Avenue N, Suite 250
Seattle, WA 98109
P: 206-577-4778 x3209 | www.revolution-computing.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] incorrect output and segfaults from sprintf with %*d (PR#13675)
On Fri, Apr 24, 2009 at 14:40, Wacek Kusnierczyk
wrote:
> maech...@stat.math.ethz.ch wrote:
>>
>> =A0 =A0 vQ> sprintf has a documented limit on strings included in the ou=
tput using the
>> =A0 =A0 vQ> format '%s'. =A0It appears that there is a limit on the leng=
th of strings included
>> =A0 =A0 vQ> with, e.g., the format '%d' beyond which surprising things h=
appen (output
>> =A0 =A0 vQ> modified for conciseness):
>> =A0 =A0 >>>
>>
>> =A0 =A0 vQ> ... and this limit is *not* documented.
>>
>> =A0 =A0 MM> well, it is basically (+ a few bytes ?)
>> =A0 =A0 MM> the same =A08192 =A0limit that *is* documented.
>>
>> indeed, I was right with that..
>>
>
> hmm, i'd guess this limit is valid for all strings included in the
> output with any format? =A0not just %s (and, as it appears, undocumentedl=
y
> %d)?
yes.
>> =A0 =A0 vQ> while snprintf would help avoid buffer overflow, it may not =
be a
>> =A0 =A0 vQ> solution to the issue of confused output.
>>
>> =A0 =A0 MM> I think it would / will. =A0We would be able to give warning=
s and
>> =A0 =A0 MM> errors, by checking the =A0snprintf() =A0return codes.
>>
>> My current working code gives an error for all the above
>> examples, e.g.,
>>
>> =A0> sprintf('%d', 1)
>> =A0Error in sprintf("%d", 1) :
>> =A0 =A0required resulting string length is > maximal 8191
>>
>> it passes =A0'make check-devel' and I am inclined to commit that
>> code to R-devel (e.g. tomorrow).
>>
>> Yes, the documentation will also have to be amended, but apart
>> from that, would people see a big problem with the "8192" limit
>> which now is suddenly of greater importance
>> {{as I said all along; =A0hence my question to Wacek (and the
>> =A0 R-develers) =A0if anybody found that limit too low}}
>>
>
> i didn't find the limit itself problematic. =A0(so far?)
ok.
> btw. (i do know what that means ;)), after your recent fix:
>
> =A0 =A0sprintf('%q%s', 1)
> =A0 =A0# Error in sprintf("%q%s", 1) :
> =A0 =A0# =A0use format %f, %e, %g or %a for numeric objects
>
> =A0 =A0sprintf('%s', 1)
> =A0 =A0# [1] "1"
>
> you may want to add '%s' (and '%x', and ...) to the error message. =A0or
> perhaps make it say sth like 'invalid format: ...'. =A0the problem is not
> that %q is not applicable to numeric, but that it is not a valid format
> at all.
yes. As a matter of fact, "%q%s" is dealt with as *one* format
chunk, since "%q" is
not a valid format.
The code I have just committed now gives a longer erro message, that
should be more helpful.
Thank you for the suggestion!
> there's also an issue with the additional arguments supplied after the
> format: =A0any superfluous arguments are ignored (this is not documented,
> as far as i can see),
I think we should signal an error if there are too many arguments.
Could anyone think of a case where the current behavior is desirable ?
> but they *are* evaluated nevertheless, e.g.:
>
> =A0 =A0sprintf('%d', 0, {print(1)})
> =A0 =A0# "1"
> =A0 =A0# [1] "0"
>
> it might be a good idea to document this behaviour.
actually I think it should be changed to be more strict (see above).
Thank you for the constructive feedback!
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] printCoefmat() with all-zero first column (PR#13677)
> m<-matrix(c(0,1),ncol=2) > printCoefmat(m) [,1] [,2] [1,] NaN1 Warning messages: 1: In min(x) : no non-missing arguments to min; returning Inf 2: In max(x) : no non-missing arguments to max; returning -Inf 3: In log(c(Inf, -Inf), 10) : NaNs produced > sessionInfo() R version 2.9.0 beta (2009-04-08 r48309) i386-apple-darwin9.6.0 locale: en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base Thomas Lumley Assoc. Professor, Biostatistics tlum...@u.washington.eduUniversity of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] incorrect output and segfaults from sprintf with %*d (PR#13667)
Martin Maechler wrote:
>
>>> MM> well, it is basically (+ a few bytes ?)
>>> MM> the same 8192 limit that *is* documented.
>>>
>>> indeed, I was right with that..
>>>
>>>
>> hmm, i'd guess this limit is valid for all strings included in the
>> output with any format? not just %s (and, as it appears, undocumentedly
>> %d)?
>>
>
> yes.
>
so it's perhaps easiest to change
" There is a limit of 8192 bytes on elements of 'fmt' and also on
strings included by a '%s' conversion specification."
to sth like
" There is a limit of 8192 bytes on elements of 'fmt' and also on
strings included in the output by any conversion specification."
it's in fact so easy that even i should be able to do it.
[1 minute later...] i see you've fixed this one, too.
>> btw. (i do know what that means ;)), after your recent fix:
>>
>>sprintf('%q%s', 1)
>># Error in sprintf("%q%s", 1) :
>># use format %f, %e, %g or %a for numeric objects
>>
>>sprintf('%s', 1)
>># [1] "1"
>>
>> you may want to add '%s' (and '%x', and ...) to the error message. or
>> perhaps make it say sth like 'invalid format: ...'. the problem is not
>> that %q is not applicable to numeric, but that it is not a valid format
>> at all.
>>
>
> yes. As a matter of fact, "%q%s" is dealt with as *one* format
> chunk, since "%q" is
> not a valid format.
> The code I have just committed now gives a longer erro message, that
> should be more helpful.
>
yes, but
sptinf('%q%s', 1)
still suggests that one uses %{f,e,g,a} for numerics, while %s is pretty
much valid, too. you see, in c sprintf(buffer, "%s", 1) is destined to
cause a segfault, but in r it works -- so the error message is slightly
misleading, as it suggests %s is *not* valid for numerics.
> Thank you for the suggestion!
>
yo welcum
>
>> there's also an issue with the additional arguments supplied after the
>> format: any superfluous arguments are ignored (this is not documented,
>> as far as i can see),
>>
>
> I think we should signal an error if there are too many arguments.
>
agree. but it might be more complex than it appears:
sprintf('%3$s', 1, 2, 3)
should *not* complain about too many args, despite just one conversion
spec in the format. interestingly,
sprintf('%3$s', , , 3)
# error: argument is missing, with no default
> Could anyone think of a case where the current behavior is desirable ?
>
well, one scenario might be that one wants to print a collection of
items with an arbitrary format, supplied by the users, e.g.
foo = function(fmt) {
a = ...
b = ...
...
s = sprintf(fmt, a, b, ...)
... }
without having to examine the format to establish which values are
needed. in the current state, sprintf would use those it would need to
use with a particular format, with no undesirable complaints.
>
>> but they *are* evaluated nevertheless, e.g.:
>>
>>sprintf('%d', 0, {print(1)})
>># "1"
>># [1] "0"
>>
>> it might be a good idea to document this behaviour.
>>
>
> actually I think it should be changed to be more strict (see above).
>
strict in which sense? enforce a constraint on the number of arguments
to that needed by a specific format? or do you mean evaluation of only
those arguments that are needed in a format? or both?
what about:
sprintf('%2$s', {print(1)}, 2)
# too many arguments?
# should 1 be printed?
sprintf('%2$s', , 2)
# too few arguments?
# missing value? (yes, sprintf is .Internal, but...)
> Thank you for the constructive feedback!
>
not much to thank for... certainly, it's the first time my feedback is
called 'constructive'. i'm making progress, am i not?
btw., thank you for the fixes. i appreciate your efforts a lot.
best,
vQ
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Closed-source non-free ParallelR ?
Stavros Macrakis-2 wrote: > > > I do not know of any compiler licenses that place restrictions on what > you can do with code compiled under them, though I suppose they could > in principle. The restrictions typically come if you link to libraries > provided with the compiler. > > These restrictions definitely exist. For example, you can not legally run programs created with an educational version of a compiler in support of commercial or governmental purposes. Intel provides free compilers for non-commercial software development, with licenses that I think preclude the use of any created programs for governmental purposes. -- View this message in context: http://www.nabble.com/Closed-source-non-free-ParallelR---tp23170843p23221398.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] Error in X11() : X11 module cannot be loaded
Hi,
we are using R installed on several linux computer - mostly debian lenny
and also ubuntu, all 64 bit. Approx.two week ago, I started getting the
following error when I tried to plot().
Error in X11() : X11 module cannot be loaded
In addition: Warning message:
In X11() : unable to load shared library
'/usr/lib64/R/modules//R_X11.so':
/usr/lib/libcairo.so.2: symbol png_set_expand_gray_1_2_4_to_8, version
PNG12_0 not defined in file libpng12.so.0 with link time reference
This error occurs now on all five computer we are using (due to
aupdate???)
we are using R version 2.7.1 (2008-06-23) installed using aptitude from
repositories.
Does anybody have idea what is going on?
Petr
DISCLAIMER: This email and any files transmitted with it...{{dropped:7}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R build fails during make when configured with "--with-x=no" (PR#13665)
It should be fixed now.
Cheers,
Simon
On Apr 20, 2009, at 6:58 AM, Peter Dalgaard wrote:
j...@ku.edu wrote:
If R is configured using the "--with=x=no" option, then the make
fails with the
following error:
make[1]: *** [R] Error 1
make[1]: Leaving directory `/home/jeet/Scratch/r-build/on-frontend/
R-2.9.0/src'
make: *** [R] Error 1
The problem appears to be with the "src/modules/Makefile".
Specfically, lines
26-29:
@for d in "$(R_MODULES)"; do \
(cd $${d} && $(MAKE) $@) || exit 1; \
done
Here, R_MODULES is blank, resulting in the "cd" command
transferring to the
user's home directory, where, of course, no Makefile is found
resulting in the
error above.
(Even more "fun" would ensue if in fact there were a Makefile
there...)
Work-around appears to be to simply disable loop if R_MODULES is
empty.
Shell script and Make portability is a pain in the derriere, but
offhand, those double quotes just look wrong:
viggo:~/>for i in "" ; do echo $i; done
viggo:~/>for i in ; do echo $i; done
viggo:~/>for i in "foo bar" ; do echo $i; done
foo bar
viggo:~/>for i in foo bar ; do echo $i; done
foo
bar
Notice that the versions with quotes invariably do the Wrong Thing
--
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
~~ - (p.dalga...@biostat.ku.dk) FAX: (+45)
35327907
__
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
