Re: [Rd] bug: sticky symbol refs? (PR#9555)
Dear Peter,
would the problem persist if you maintained your favorite set of R
functions in a proper package rather than in some .RData file?
Packages offer a lot of goodies such as namespaces, version numbers, man
pages.
Best wishes
Wolfgang
--
Wolfgang Huber EBI/EMBL Cambridge UK http://www.ebi.ac.uk/huber
[EMAIL PROTECTED] wrote:
>
> Hello. What happens in the following is that I create two simple functions, f
> and g, on the workspace. Then I
> replace g. When I then call f, it uses the old version of g. Now clearly, the
> circumstances for this to happen
> must be quite special and rare. But I'd say they're not pathological. It
> seems to require two things: 1) masked versions
> of f and g on a search position lower down the search list (but I'm not sure
> that's necessary), and 2) using
> source() to create the objects, but evaluated in a local environment, not the
> global one. I'm pretty confident that
> 2) is necessary for the bug.
>
> Practical impact: like I suppose many users, I maintain my own R functions in
> a .RData file which I've always got
> attached at pos 2. Periodically I dump() them to file, take that file to
> another site, and source() them in there.
> However I don't want all the functions to be created on search pos'n 1, so I
> have a wrapper my.source() which creates
> them in a local environment then copies from that down to search pos 2. So
> that's all fairly innocent, and probably
> not uncommon.
>
> How to reproduce:
>
> ## put this code in /temp/myFuns.R:
> `f` <-
> function (x)
> {
> g(x)
> }
> `g` <-
> function(x)
> {
> is.null(x)
> }
>
>
> # now create a fresh .RData and attach it at pos 2:
>> save(list = character(0), file = "/temp/.RData")# to create it
>> attach( "/temp/.RData", pos=2 )
>
> # now source() /temp/myFuns.R in a local env, then copy new objs to search
> pos 2:
>> newEnv <- new.env()
>> eval(expression(source(file = "/temp/myFuns.R", local = T)), envir=newEnv)
>> for( objName in objects(envir = newEnv, all.names = T) ) {
> assign(objName, get(objName, envir = newEnv), pos = 2)
> }
>
>> f <- f # copy from pos 2 to workspace; (needed?)
>> g <- g # copy from pos 2 to workspace; (needed?)
>> f(1) # gives correct answer
> [1] FALSE
>> g <- function(x) stop( "this is the new g" )
>> f(1) # gives wrong answer; uses the old g();
> [1] FALSE
>
> # now re-create f from scratch, assign under new name:
>> f2 <- eval( parse( text=deparse(f) ) )
>> f2(1) # gives correct answer
> Error in g(x) : this is the new g
>
> # note that the original f() continues to malfunction;
>
> --please do not edit the information below--
>
> Version:
> platform = i386-pc-mingw32
> arch = i386
> os = mingw32
> system = i386, mingw32
> status =
> major = 2
> minor = 4.1
> year = 2006
> month = 12
> day = 18
> svn rev = 40228
> language = R
> version.string = R version 2.4.1 (2006-12-18)
>
> Windows XP Professional (build 2600) Service Pack 2.0
>
> Locale:
> LC_COLLATE=English_United Kingdom.1252;LC_CTYPE=English_United
> Kingdom.1252;LC_MONETARY=English_United
>
> Kingdom.1252;LC_NUMERIC=C;LC_TIME=English_United Kingdom.1252
>
> Search Path:
> .GlobalEnv, file:/temp/.RData, file:c:/schupl/R/myRLib/.RData,
> file:c:/schupl/R/myFinanceLib/.RData, file:c:/schupl/R/recycler/.RData,
>
> package:stats, package:graphics, package:grDevices, package:utils,
> package:datasets, package:methods, Autoloads, package:base
> ---
>
> This e-mail may contain confidential and/or privileged infor...{{dropped}}
>
> __
> 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
[Rd] Garbage collector crashes after calling a C function
Dear listers, a few days ago I asked a question about a problem I had with a C function programmed by myself to be called from R. Thanks to your help, I have been able to look a bit further into it, so now I can be a bit more specific when telling what happens. The fact is that, when my C function finishes its execution (after calling it via the ".C" interface), R seems ok but then crashes when the garbage collector executes, giving a segmentation fault. As some of you suggested, I have executed my function with valgrind, and I get no memory errors, but some memory leaks (which I am not able to locate although compiling my program with the -c flag), and I also get the memory error from RunGenCollect: (which I suppose is causes the segmentation fault). You can see a small piece of the valgrind output below Using gctorture to make the garbage collector crash inside the execution of my program didn't work (my program finished). The question is: what are the typical programming errors that can make R garbage collector crash? Could it be because of these memory leaks? If so, how could I trace them? I have tried it, but running my program with gdb is not an easy task to do, as it performs a huge number of iterations. Thank you very much in advance for your help. I would appreciate any hint that could help me solve this tricky problem. Best regards, Xavier Solé. --- ### This is one of the memory leaks ==9370== 162 (160 direct, 2 indirect) bytes in 1 blocks are definitely lost in loss record 11 of 42 ==9370==at 0x4A19D35: malloc (vg_replace_malloc.c:149) ==9370==by 0x84490E0: ??? ==9370==by 0x844D346: ??? ==9370==by 0x4BBE1A2: do_dotCode (in /usr/lib64/R/lib/libR.so) ==9370==by 0x4BE9035: Rf_eval (in /usr/lib64/R/lib/libR.so) ==9370==by 0x4BEBA3F: do_set (in /usr/lib64/R/lib/libR.so) ==9370==by 0x4BE8E5E: Rf_eval (in /usr/lib64/R/lib/libR.so) ==9370==by 0x4BEAF0D: do_begin (in /usr/lib64/R/lib/libR.so) ==9370==by 0x4BE8E5E: Rf_eval (in /usr/lib64/R/lib/libR.so) ==9370==by 0x4BE9711: Rf_applyClosure (in /usr/lib64/R/lib/libR.so) ==9370==by 0x4BE9107: Rf_eval (in /usr/lib64/R/lib/libR.so) ==9370==by 0x4BEBA3F: do_set (in /usr/lib64/R/lib/libR.so) ### This is the RunGenCollect memory error ==9370== Invalid write of size 8 ==9370==at 0x4C1F73A: RunGenCollect (in /usr/lib64/R/lib/libR.so) ==9370==by 0x4C23E55: R_gc_internal (in /usr/lib64/R/lib/libR.so) ==9370==by 0x4C22DC3: Rf_cons (in /usr/lib64/R/lib/libR.so) ==9370==by 0x4C23AE1: Rf_allocList (in /usr/lib64/R/lib/libR.so) ==9370==by 0x4B6926B: installAttrib (in /usr/lib64/R/lib/libR.so) ==9370==by 0x4B69961: Rf_classgets (in /usr/lib64/R/lib/libR.so) ==9370==by 0x4B68DC1: Rf_setAttrib (in /usr/lib64/R/lib/libR.so) ==9370==by 0x4B69A40: do_classgets (in /usr/lib64/R/lib/libR.so) ==9370==by 0x4BE908E: Rf_eval (in /usr/lib64/R/lib/libR.so) ==9370==by 0x4BEB6FD: applydefine (in /usr/lib64/R/lib/libR.so) ==9370==by 0x4BEBAE3: do_set (in /usr/lib64/R/lib/libR.so) ==9370==by 0x4BE8E5E: Rf_eval (in /usr/lib64/R/lib/libR.so) ==9370== Address 0x10 is not stack'd, malloc'd or (recently) free'd [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Garbage collector crashes after calling a C function
Sorry, that was a mistake. You are right Antonio, I wanted to say the "-g" flag. Xavi. -Mensaje original- De: Antonio, Fabio Di Narzo [mailto:[EMAIL PROTECTED] Enviado el: dimecres, 7 / març / 2007 13:00 Para: Sole Acha, Xavi CC: r-devel@stat.math.ethz.ch Asunto: Re: [Rd] Garbage collector crashes after calling a C function 2007/3/7, Sole Acha, Xavi <[EMAIL PROTECTED]>: > Dear listers, > > > > a few days ago I asked a question about a problem I had with a C function > programmed by myself to be called from R. Thanks to your help, I have been > able to look a bit further into it, so now I can be a bit more specific when > telling what happens. > > > > The fact is that, when my C function finishes its execution (after calling it > via the ".C" interface), R seems ok but then crashes when the garbage > collector executes, giving a segmentation fault. > > > > As some of you suggested, I have executed my function with valgrind, and I > get no memory errors, but some memory leaks (which I am not able to locate > although compiling my program with the -c flag), In gcc, maybe you mean the '-g' flag > and I also get the memory error from RunGenCollect: (which I suppose is > causes the segmentation fault). You can see a small piece of the valgrind > output below > > > > Using gctorture to make the garbage collector crash inside the execution of > my program didn't work (my program finished). The question is: what are the > typical programming errors that can make R garbage collector crash? Could it > be because of these memory leaks? If so, how could I trace them? I have tried > it, but running my program with gdb is not an easy task to do, as it performs > a huge number of iterations. > > > > Thank you very much in advance for your help. I would appreciate any hint > that could help me solve this tricky problem. > > > > Best regards, > > > > Xavier Solé. > > > > --- > > ### This is one of the memory leaks > > ==9370== 162 (160 direct, 2 indirect) bytes in 1 blocks are definitely lost > in loss record 11 of 42 > > ==9370==at 0x4A19D35: malloc (vg_replace_malloc.c:149) > > ==9370==by 0x84490E0: ??? > > ==9370==by 0x844D346: ??? > > ==9370==by 0x4BBE1A2: do_dotCode (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4BE9035: Rf_eval (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4BEBA3F: do_set (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4BE8E5E: Rf_eval (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4BEAF0D: do_begin (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4BE8E5E: Rf_eval (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4BE9711: Rf_applyClosure (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4BE9107: Rf_eval (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4BEBA3F: do_set (in /usr/lib64/R/lib/libR.so) > > > > ### This is the RunGenCollect memory error > > ==9370== Invalid write of size 8 > > ==9370==at 0x4C1F73A: RunGenCollect (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4C23E55: R_gc_internal (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4C22DC3: Rf_cons (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4C23AE1: Rf_allocList (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4B6926B: installAttrib (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4B69961: Rf_classgets (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4B68DC1: Rf_setAttrib (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4B69A40: do_classgets (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4BE908E: Rf_eval (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4BEB6FD: applydefine (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4BEBAE3: do_set (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4BE8E5E: Rf_eval (in /usr/lib64/R/lib/libR.so) > > ==9370== Address 0x10 is not stack'd, malloc'd or (recently) free'd > > > > > [[alternative HTML version deleted]] > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Antonio, Fabio Di Narzo Ph.D. student at Department of Statistical Sciences University of Bologna, Italy __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Garbage collector crashes after calling a C function
2007/3/7, Sole Acha, Xavi <[EMAIL PROTECTED]>: > Dear listers, > > > > a few days ago I asked a question about a problem I had with a C function > programmed by myself to be called from R. Thanks to your help, I have been > able to look a bit further into it, so now I can be a bit more specific when > telling what happens. > > > > The fact is that, when my C function finishes its execution (after calling it > via the ".C" interface), R seems ok but then crashes when the garbage > collector executes, giving a segmentation fault. > > > > As some of you suggested, I have executed my function with valgrind, and I > get no memory errors, but some memory leaks (which I am not able to locate > although compiling my program with the -c flag), In gcc, maybe you mean the '-g' flag > and I also get the memory error from RunGenCollect: (which I suppose is > causes the segmentation fault). You can see a small piece of the valgrind > output below > > > > Using gctorture to make the garbage collector crash inside the execution of > my program didn't work (my program finished). The question is: what are the > typical programming errors that can make R garbage collector crash? Could it > be because of these memory leaks? If so, how could I trace them? I have tried > it, but running my program with gdb is not an easy task to do, as it performs > a huge number of iterations. > > > > Thank you very much in advance for your help. I would appreciate any hint > that could help me solve this tricky problem. > > > > Best regards, > > > > Xavier Solé. > > > > --- > > ### This is one of the memory leaks > > ==9370== 162 (160 direct, 2 indirect) bytes in 1 blocks are definitely lost > in loss record 11 of 42 > > ==9370==at 0x4A19D35: malloc (vg_replace_malloc.c:149) > > ==9370==by 0x84490E0: ??? > > ==9370==by 0x844D346: ??? > > ==9370==by 0x4BBE1A2: do_dotCode (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4BE9035: Rf_eval (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4BEBA3F: do_set (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4BE8E5E: Rf_eval (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4BEAF0D: do_begin (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4BE8E5E: Rf_eval (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4BE9711: Rf_applyClosure (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4BE9107: Rf_eval (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4BEBA3F: do_set (in /usr/lib64/R/lib/libR.so) > > > > ### This is the RunGenCollect memory error > > ==9370== Invalid write of size 8 > > ==9370==at 0x4C1F73A: RunGenCollect (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4C23E55: R_gc_internal (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4C22DC3: Rf_cons (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4C23AE1: Rf_allocList (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4B6926B: installAttrib (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4B69961: Rf_classgets (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4B68DC1: Rf_setAttrib (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4B69A40: do_classgets (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4BE908E: Rf_eval (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4BEB6FD: applydefine (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4BEBAE3: do_set (in /usr/lib64/R/lib/libR.so) > > ==9370==by 0x4BE8E5E: Rf_eval (in /usr/lib64/R/lib/libR.so) > > ==9370== Address 0x10 is not stack'd, malloc'd or (recently) free'd > > > > > [[alternative HTML version deleted]] > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Antonio, Fabio Di Narzo Ph.D. student at Department of Statistical Sciences University of Bologna, Italy __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Garbage collector crashes after calling a C function
On 3/7/2007 6:42 AM, Sole Acha, Xavi wrote: > Dear listers, > > > > a few days ago I asked a question about a problem I had with a C function > programmed by myself to be called from R. Thanks to your help, I have been > able to look a bit further into it, so now I can be a bit more specific when > telling what happens. > > > > The fact is that, when my C function finishes its execution (after calling it > via the ".C" interface), R seems ok but then crashes when the garbage > collector executes, giving a segmentation fault. > > > > As some of you suggested, I have executed my function with valgrind, and I > get no memory errors, but some memory leaks (which I am not able to locate > although compiling my program with the -c flag), and I also get the memory > error from RunGenCollect: (which I suppose is causes the segmentation fault). > You can see a small piece of the valgrind output below > > > > Using gctorture to make the garbage collector crash inside the execution of > my program didn't work (my program finished). The question is: what are the > typical programming errors that can make R garbage collector crash? Could it > be because of these memory leaks? If so, how could I trace them? I have tried > it, but running my program with gdb is not an easy task to do, as it performs > a huge number of iterations. > > > > Thank you very much in advance for your help. I would appreciate any hint > that could help me solve this tricky problem. The obvious guess is that you're writing out of bounds in some array. Remember to explicitly set the type of arrays you pass in to .C (e.g. as.double(1:10) is different from 1:10), and remember that R uses 1-based indexing (from 1 to 10 in the case above) whereas C uses 0 based indexing (from 0 to 9). I don't know what sort of tests valgrind does and why it doesn't notice an error in your code; it doesn't run in Windows, as far as I know. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] possible bug in model.frame.default
Dear list,
I may have found a bug in model.frame.default (called by the lm function).
The problem arises in my R dev version but not in my R 2.4.0.
Here is my config :
> version
_
platform
x86_64-unknown-linux-gnu
arch
x86_64
os
linux-gnu
system x86_64,
linux-gnu
status Under development
(unstable)
major
2
minor
5.0
year
2007
month
03
day
04
svn rev
40813
language
R
version.string R version 2.5.0 Under development (unstable) (2007-03-04
r40813)
Now a simple example to (hopefully) reproduce the bug (after a
rm(list=ls())):
> dat=data.frame(y=rnorm(10),x1=runif(10),x2=runif(10))
> weights=1:10/(sum(1:10))
> form <- as.formula("y~x1+x2")
# here is the error
> lm(form,data=dat,weights=weights)
Erreur dans model.frame(formula, rownames, variables, varnames, extras,
extranames, :
type (closure) incorrect pour la variable '(weights)'
(sorry, error message is in French)
As I said, these commands works using R.2.4.0 (same machine, same OS).
Moreover, the following commands work:
> temp=weights
> lm(form,data=dat,weights=temp)
This currently seems to cause a check fail in the ade4 package. I tried
to find out where the bug came from: all I found is the (potential) bug
comes from model.frame.default, and more precisely:
debug: data <- .Internal(model.frame(formula, rownames, variables,
varnames,
extras, extranames, subset, na.action))
Browse[1]>
Erreur dans model.frame(formula, rownames, variables, varnames, extras,
extranames, :
type (closure) incorrect pour la variable '(weights)'
I couldn't go further because of the .Internal. I tried to googlise
this, but I found no such problem reported recently.
Can anyone tell if this is actually a bug? (In case not, please tell me
where I got wrong).
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://biomserv.univ-lyon1.fr/sitelabo/pageperso.php?id_personne=178
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wish: Option to configure the default par() (PR#9545)
--nextPart4163908.Y9KBlY7Qjy Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 06 March 2007 17:56, Greg Snow wrote: > Another approach may be to use hooks (see ?setHook). The plot.new > function already has a hook, so you could do your option #1 > automatically by setting that hook. > > Better would be if all the graphics device functions had hooks (or a > common hook), then you could set that hook to set your graphics > parameters and they would be set every time a new graphics device was > started. Thanks for your suggestion. This does almost everything I want. Two small=20 drawbacks: 1) Setting par(bg=3D...) from the hook has no effect for the first graph pl= otted=20 in the new device. For this to work, the hook would need to be called=20 before .Internal(plot.new()) instead of afterwards in plot.new(). 2) Any par() parameters explicitely set in the call to X11()/postscript()..= =2E=20 will be overridded, instead of taking precendence over the defaults. =46or many purposes this method is really useful, however, so thanks again = for=20 pointing it out. Regards Thomas --nextPart4163908.Y9KBlY7Qjy Content-Type: application/pgp-signature -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBF7tTmEKRv+5DVNhgRAhZ4AJ9StffA3KSO+h4ONdkWE7A1JarXWACdF8vu pRW+6rL5DCS8iXppfxdIk88= =rKvB -END PGP SIGNATURE- --nextPart4163908.Y9KBlY7Qjy-- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] possible bug in model.frame.default
On 3/7/2007 9:47 AM, Thibaut Jombart wrote:
> Dear list,
>
> I may have found a bug in model.frame.default (called by the lm function).
> The problem arises in my R dev version but not in my R 2.4.0.
> Here is my config :
I don't see this bug in r40818 in Windows, and the log entry for r40817
looks like it may be relevant:
fixing a buglet that crept in from the change to have $ warn
when applied to an atomic vector
This modified model.R and the NAMESPACE file of the stats package.
Could you try a slightly newer build?
Duncan Murdoch
>
> > version
>
> _
> platform
> x86_64-unknown-linux-gnu
> arch
> x86_64
> os
> linux-gnu
> system x86_64,
> linux-gnu
> status Under development
> (unstable)
> major
> 2
> minor
> 5.0
> year
> 2007
> month
> 03
> day
> 04
> svn rev
> 40813
> language
> R
> version.string R version 2.5.0 Under development (unstable) (2007-03-04
> r40813)
>
> Now a simple example to (hopefully) reproduce the bug (after a
> rm(list=ls())):
>
> > dat=data.frame(y=rnorm(10),x1=runif(10),x2=runif(10))
> > weights=1:10/(sum(1:10))
> > form <- as.formula("y~x1+x2")
> # here is the error
> > lm(form,data=dat,weights=weights)
> Erreur dans model.frame(formula, rownames, variables, varnames, extras,
> extranames, :
> type (closure) incorrect pour la variable '(weights)'
>
> (sorry, error message is in French)
>
> As I said, these commands works using R.2.4.0 (same machine, same OS).
> Moreover, the following commands work:
> > temp=weights
> > lm(form,data=dat,weights=temp)
>
> This currently seems to cause a check fail in the ade4 package. I tried
> to find out where the bug came from: all I found is the (potential) bug
> comes from model.frame.default, and more precisely:
> debug: data <- .Internal(model.frame(formula, rownames, variables,
> varnames,
> extras, extranames, subset, na.action))
> Browse[1]>
> Erreur dans model.frame(formula, rownames, variables, varnames, extras,
> extranames, :
> type (closure) incorrect pour la variable '(weights)'
>
> I couldn't go further because of the .Internal. I tried to googlise
> this, but I found no such problem reported recently.
>
> Can anyone tell if this is actually a bug? (In case not, please tell me
> where I got wrong).
>
> Regards,
>
> Thibaut.
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SVG and tooltips, hyperlinks
Wolfgang Huber wrote: > Dear all, > > is there a good way to create SVG plots with R whose elements have > titles (tooltips) or act as hyperlinks? > > I am using the RSvgDevice package, which works great - but it doesn't > seem to support the notion that plot objects have titles or are act as > hyperlinks, so I am helping myself by giving the objects funny unique > colors and then postprocessing the .svg file. > > I wonder whether somebody has already implemented this in a more elegant > way. > > Best wishes >Wolfgang > Tony Plate posted an altered version of RSvgDevice on the finance list a couple of weeks ago. https://stat.ethz.ch/pipermail/r-sig-finance/2007q1/001261.html It does not do hyperlinks yet, but that should not be too difficult to do. Cheers, Romain -- Mango Solutions data analysis that delivers Tel: +44(0) 1249 467 467 Fax: +44(0) 1249 467 468 Mob: +44(0) 7813 526 123 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RJDBC
Thank you Simon.
I have used your script with Oracle and Mysql and both returns
[1] "Java-Object{java.sql.SQLException: No suitable driver}"
My script is the next:
library('rJava')
library('DBI')
library('RJDBC')
drv <-
JDBC("com.mysql.jdbc.Driver","C:\\Temporal\\mysql-connector-java-3.0.9-stable-bin.jar","'")
dbCheck("jdbc:mysql://localhost/foo","user","pwd")
I can connect with Oracle and Mysql by JDBC from another applications
with this jar. It contains com.mysql.jdbc.Driver.class or
oracle.jdbc.driver.OracleDriver.class
Can you help me?
Simon Urbanek escribió:
> Jose,
>
> On Mar 5, 2007, at 7:39 AM, Jose Sierra wrote:
>
>> I need help.
>>
>> I'm trying to connect with an Oracle DBMS and MySQL DBMS, I'm using
>> RJDBC package.
>>
>> My code is the next:
>>
>> library('rJava')
>> library('DBI')
>> library('RJDBC')
>>
>> //Mysql
>> drv <-
>> JDBC("com.mysql.jdbc.Driver","C:\\Temporal\\mysql-connector-java-3.0.9-stable-bin.jar","'")
>>
>>
>>
>> conn <- dbConnect(drv, "jdbc:mysql://localhost:3306/bd", "user",
>> "password")
>>
>> //Oracle
>> drv <-
>> JDBC("oracle.jdbc.driver.OracleDriver","C:\\Temporal\\classes12.jar","'")
>>
>> conn <-
>> dbConnect(drv,"jdbc:oracle:thin:@192.168.1.70:1521:SDS22","user","password")
>>
>>
>>
>> R always returns for oracle
>> "Error en .local(drv, ...) : Unable to connect JDBC to
>> jdbc:oracle:thin:@192.168.1.70:1521:SDS22"
>> and for mysql
>> "Error en .local(drv, ...) : Unable to connect JDBC to
>> jdbc:mysql://localhost:3306/bd"
>>
>
> It is very likely a problem with your DB connection or authentication.
> I have tested it with MySQL (I don't have Oracle) and it worked
> without problems. Please test it step-by-step to make sure that your
> DB is configured properly.
>
> Unfortunately RJDBC doesn't pass non-fatal SQL errors back to the
> user, so connection problems are not easy to debug, but you can try
> this to show the connection problem:
>
> dbCheck = function(url, user='', pwd='') {
> j = .jcall("java/sql/DriverManager", "Ljava/sql/Connection;",
> "getConnection", url, user, pwd, check=FALSE)
> x = .jgetEx()
> .jcheck()
> x
> }
>
> and use it like this:
>
> > dbCheck("jdbc:mysql://localhost/foo","user","pwd")
> [1] "Java-Object{java.sql.SQLException: Access denied for user
> 'user'@'localhost' (using password: YES)}"
> >
> > dbCheck("jdbc:mysql://localhost/foo","root","")
> [1] "Java-Object{java.sql.SQLException: Unknown database 'foo'}"
> > dbCheck("jdbc:mysql://bar/foo","root","")
>
> I'll see if I can provide some more helpful response in the dbConnect
> for the next release..
>
>
>> Another question:
>> I try to compile ROracle and RMysql for windows but i need Rdll.lib
>> and it need R.exp.
>
> No, you don't need those files, because R is linked directly. Simply
> follow the instructions for building R packages on Windows.
>
> Cheers,
> Simon
>
>
>
>
>
>
__
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] possible bug in model.frame.default
I don't see this bug (in r-devel r40818) but there are two changes between
40814 and 40818 that might have fixed it.
-thomas
On Wed, 7 Mar 2007, Thibaut Jombart wrote:
Dear list,
I may have found a bug in model.frame.default (called by the lm function).
The problem arises in my R dev version but not in my R 2.4.0.
Here is my config :
> version
_
platform
x86_64-unknown-linux-gnu
arch
x86_64
os
linux-gnu
system x86_64,
linux-gnu
status Under development
(unstable)
major
2
minor
5.0
year
2007
month
03
day
04
svn rev
40813
language
R
version.string R version 2.5.0 Under development (unstable) (2007-03-04
r40813)
Now a simple example to (hopefully) reproduce the bug (after a
rm(list=ls())):
> dat=data.frame(y=rnorm(10),x1=runif(10),x2=runif(10))
> weights=1:10/(sum(1:10))
> form <- as.formula("y~x1+x2")
# here is the error
> lm(form,data=dat,weights=weights)
Erreur dans model.frame(formula, rownames, variables, varnames, extras,
extranames, :
type (closure) incorrect pour la variable '(weights)'
(sorry, error message is in French)
As I said, these commands works using R.2.4.0 (same machine, same OS).
Moreover, the following commands work:
> temp=weights
> lm(form,data=dat,weights=temp)
This currently seems to cause a check fail in the ade4 package. I tried
to find out where the bug came from: all I found is the (potential) bug
comes from model.frame.default, and more precisely:
debug: data <- .Internal(model.frame(formula, rownames, variables,
varnames,
extras, extranames, subset, na.action))
Browse[1]>
Erreur dans model.frame(formula, rownames, variables, varnames, extras,
extranames, :
type (closure) incorrect pour la variable '(weights)'
I couldn't go further because of the .Internal. I tried to googlise
this, but I found no such problem reported recently.
Can anyone tell if this is actually a bug? (In case not, please tell me
where I got wrong).
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://biomserv.univ-lyon1.fr/sitelabo/pageperso.php?id_personne=178
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Thomas Lumley Assoc. Professor, Biostatistics
[EMAIL PROTECTED] University of Washington, Seattle__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] possible bug in model.frame.default
Please update to the latest snapshot
R version 2.5.0 Under development (unstable) (2007-03-05 r40816)
where all is well,
Thibaut Jombart wrote:
> Dear list,
>
> I may have found a bug in model.frame.default (called by the lm function).
> The problem arises in my R dev version but not in my R 2.4.0.
> Here is my config :
>
> > version
>
> _
> platform
> x86_64-unknown-linux-gnu
> arch
> x86_64
> os
> linux-gnu
> system x86_64,
> linux-gnu
> status Under development
> (unstable)
> major
> 2
> minor
> 5.0
> year
> 2007
> month
> 03
> day
> 04
> svn rev
> 40813
> language
> R
> version.string R version 2.5.0 Under development (unstable) (2007-03-04
> r40813)
>
> Now a simple example to (hopefully) reproduce the bug (after a
> rm(list=ls())):
>
> > dat=data.frame(y=rnorm(10),x1=runif(10),x2=runif(10))
> > weights=1:10/(sum(1:10))
> > form <- as.formula("y~x1+x2")
> # here is the error
> > lm(form,data=dat,weights=weights)
> Erreur dans model.frame(formula, rownames, variables, varnames, extras,
> extranames, :
> type (closure) incorrect pour la variable '(weights)'
>
> (sorry, error message is in French)
>
> As I said, these commands works using R.2.4.0 (same machine, same OS).
> Moreover, the following commands work:
> > temp=weights
> > lm(form,data=dat,weights=temp)
>
> This currently seems to cause a check fail in the ade4 package. I tried
> to find out where the bug came from: all I found is the (potential) bug
> comes from model.frame.default, and more precisely:
> debug: data <- .Internal(model.frame(formula, rownames, variables,
> varnames,
> extras, extranames, subset, na.action))
> Browse[1]>
> Erreur dans model.frame(formula, rownames, variables, varnames, extras,
> extranames, :
> type (closure) incorrect pour la variable '(weights)'
>
> I couldn't go further because of the .Internal. I tried to googlise
> this, but I found no such problem reported recently.
>
> Can anyone tell if this is actually a bug? (In case not, please tell me
> where I got wrong).
>
> Regards,
>
> Thibaut.
>
--
Robert Gentleman, PhD
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
PO Box 19024
Seattle, Washington 98109-1024
206-667-7700
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] possible bug in model.frame.default
Duncan Murdoch wrote: > On 3/7/2007 9:47 AM, Thibaut Jombart wrote: > >> Dear list, >> >> I may have found a bug in model.frame.default (called by the lm >> function). >> The problem arises in my R dev version but not in my R 2.4.0. >> Here is my config : > > > I don't see this bug in r40818 in Windows, and the log entry for > r40817 looks like it may be relevant: > > fixing a buglet that crept in from the change to have $ warn > when applied to an atomic vector > > This modified model.R and the NAMESPACE file of the stats package. > > Could you try a slightly newer build? > > Duncan Murdoch > You are right, this is fixed in R 40818. I naively didn't expect R dev version to change so quickly. Thanks. 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://biomserv.univ-lyon1.fr/sitelabo/pageperso.php?id_personne=178 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wish: Option to configure the default par() (PR#9545)
Here are a few ideas:
For #1 define:
"$.Par" <- function(x, FUN) {
par.default <- getOption("par.default")
if (!is.null(par.default)) do.call("par", par.default)
get(FUN, parent.frame())
}
Par <- structure(NA, class = "Par")
# and now one can preface any function with Par$ and it will
# call par and then the function. This eliminates an extra statement
# but does mean you have to preface plot, say, with Par$
# e.g.
options(par.default = list(bg = "light gray", las = 2))
Par$plot(1:10)
Par$boxplot(1:10)
For #2 do:
plot <- Par$plot
Another idea for #2 is to use the connect package. See:
http://code.google.com/p/r-connect/
On 3/6/07, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Full_Name: Thomas Friedrichsmeier
> Version: 2.4.1
> OS: linux (Debian unstable)
> Submission from: (NULL) (84.60.113.185)
>
>
> Summary: It would be nice to have a centralized option for setting default
> par()
> options for all devices and all plots. This would ease producing graphs in a
> customized but consistent way. Suggesting options("par.default").
>
> Example problem: Make all graphs look like
>
> par(bg="light gray", las=2)
>
> both on screen and for various produced file formats such as png() and
> postscript().
>
> Current situation: To solve the example problem, two approaches come to mind:
> 1) Always call par() before the next plot. This could be wrapped into a
> function
> to make it easier to stay consistent. E.g.:
>
> postscript()
> myDefaultPar() # calls par(bg="light gray", las=2)
> plot(...)
>
> 2) Create wrappers for all devices of interest, like e.g. (not quite correct,
> but good enough for this example):
>
> myX11 <- function(...) {
> X11(...)
> par(bg="light gray", las=2)
> }
>
> Both solutions work, but are not entirely elegant. The drawback of 1) is that
> you still need to add the given line manually at all places. The drawback of
> 2)
> is that a similar wrapper will have to be created (and used) for each
> different
> device.
>
> Wish:
> Add a new option: options("par.default"), similar to the existing
> options("par.ask.default"). This option would accept a list of all par
> settings
> to set a custom default for:
>
> options(par.default=list(bg="light gray", las=2))
>
> par() options specified while creating the device, in calls to plot() or in
> subsequent calls to par() would take precendence over options("par.default").
>
> __
> 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
[Rd] missing axes in irregular lattice plots (PR#9556)
In the lattice functions, if the first or last panel in a row or column is not at the edge of the array of panels there will be no axis drawn for that row or column, except that when the said panel is the last in the array its right y axis will be drawn. For example, > d<-data.frame(x=1:20, y=1:20, g=rep(LETTERS[1:4],len=20)) > library(lattice) > bwplot(floor(x/8)~y|g, layout=c(1,3), as.table=T, data=d) That bwplot() call should make 2 pages of panels with 3 panels on page 1 and 1 panel on page 2. The single panel on the second page has x tick marks at its top edge, but no tick marks or labels below it. Thus you have to look at the first page of panel to determine the x scale. In the second example (using the same data.frame) there are no x or y tick labels for any panel. > xyplot(y~x|g, layout=c(3,3), skip=c(T,T,F, F,F,T, T,F,T), as.table=T, data=d) This example is rather contrived, but might arise when one wants to omit panels with no data in them but to leave a hole in the array for unused factor levels in the given vector. Exactly the same problem happens in S-Plus. I patched it to put an axis on the first and last panels in each row and column, instead of only on the plots in position 1 and nrow (or ncol) of each row and column. One might also fix it by putting axes all around the array of plots, at the edge of the array. Perhaps you only want axes on rows and columns that have at least one plot in them. One might prefer to only attack the layout(1,n),as.table=T problem by making sure the last plot has x axis tick labels associated with it, just as the last plot always gets y axis tick labels associated with it. Bill Dunlap Insightful Corporation bill at insightful dot com 360-428-8146 "All statements in this message represent the opinions of the author and do not necessarily reflect Insightful Corporation policy or position." --please do not edit the information below-- Version: platform = i686-pc-linux-gnu arch = i686 os = linux-gnu system = i686, linux-gnu status = Under development (unstable) major = 2 minor = 5.0 year = 2007 month = 02 day = 05 svn rev = 40659 language = R version.string = R version 2.5.0 Under development (unstable) (2007-02-05 r40659) Locale: LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C Search Path: .GlobalEnv, package:lattice, package:stats, package:graphics, package:grDevices, package:utils, package:datasets, package:methods, Autoloads, package:base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Small inconsistency in serialize() between R versions and implications on digest()
Hi, I noticed that serialize() gives different results depending on R version, which has implications to the digest() function in the digest package. Note, it does give the same output across platforms. I know that serialize() is under development, but is this expected, e.g. is there some kind of header in the result that specifies "who" generated the stream, and if so, exactly what bytes are they? SETUP: R versions: A) R v2.4.0 (2006-10-03) B) R v2.4.1pat (2007-01-13 r40470) C) R v2.5.0dev (2006-12-12 r40167) This is on WinXP and I start R with Rterm --vanilla. Example: Identical serialize() calls using the different R versions. > raw <- serialize(1, connection=NULL, ascii=TRUE) > print(raw) gives: (A): [1] 41 0a 32 0a 31 33 32 30 39 36 0a 31 33 31 38 34 30 0a 31 34 0a 31 0a 31 0a (B): [1] 41 0a 32 0a 31 33 32 30 39 37 0a 31 33 31 38 34 30 0a 31 34 0a 31 0a 31 0a (C): [1] 41 0a 32 0a 31 33 32 33 35 32 0a 31 33 31 38 34 30 0a 31 34 0a 31 0a 31 0a Note the difference in raw bytes 8 to 10, i.e. > raw[7:11] (A): [1] 32 30 39 36 0a (B): [1] 32 30 39 37 0a (C): [1] 32 33 35 32 0a Does bytes 8, 9 and 10 in the raw vector somehow contain information about the R version or similar? The following poor mans test says that is the only difference: On all R versions, the following gives identical results: > raw <- serialize(1:1e4, connection=NULL, ascii=TRUE) > raw <- as.integer(raw[-c(8:10)]) > sum(raw) [1] 2147884 > sum(log(raw)) [1] 177201.2 If it is true that there is a R version specific header in serialized objects, then the digest() function should exclude such header in order to produce consistent results across R versions, because now digest(1) gives different results. Thank you Henrik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Small inconsistency in serialize() between R versions and implications on digest()
To follow up, I went ahead and generated "random" object to scan for a
common header for a given R version, and it seems to be that at most
the first 18 bytes are non-data specific, which could be the length of
the serialization header.
Here is my code for this:
scanSerialize <- function(object, hdr=NULL, ...) {
# Serialize object
raw <- serialize(object, connection=NULL, ascii=TRUE);
# First run?
if (is.null(hdr))
return(raw);
# Find differences between current longest header and new raw vector
n <- length(hdr);
diffs <- (as.integer(hdr) != as.integer(raw[1:n]));
# No differences?
if (!any(diffs))
return(hdr);
# Position of first difference
idx <- which(diffs)[1];
# Keep common header
hdr <- hdr[seq_len(idx-1)];
hdr;
};
# Serialize a first "random" object
hdr <- scanSerialize(NA);
for (kk in 1:100)
hdr <- scanSerialize(kk, hdr=hdr);
for (kk in 1:100) {
x <- sample(letters, size=sample(100), replace=TRUE);
hdr <- scanSerialize(x, hdr=hdr);
}
for (kk in 1:100) {
hdr <- scanSerialize(kk, hdr=hdr);
hdr <- scanSerialize(hdr, hdr=hdr);
}
cat("Length:", length(hdr), "\n");
print(hdr);
print(rawToChar(hdr));
On R v2.5.0 devel, this gives:
Length: 18
[1] 41 0a 32 0a 31 33 32 33 35 32 0a 31 33 31 38 34 30 0a
[1] "A\n2\n132352\n131840\n"
However, it would still be good to get an "official" statement from
one in the R-code team about the serialization header and where the
data section start. Again, I want to cut out as much as possible for
consistency between R version without loosing data dependent bytes.
Thanks
/Henrik
On 3/7/07, Henrik Bengtsson <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I noticed that serialize() gives different results depending on R
> version, which has implications to the digest() function in the digest
> package. Note, it does give the same output across platforms. I know
> that serialize() is under development, but is this expected, e.g. is
> there some kind of header in the result that specifies "who" generated
> the stream, and if so, exactly what bytes are they?
>
> SETUP:
>
> R versions:
> A) R v2.4.0 (2006-10-03)
> B) R v2.4.1pat (2007-01-13 r40470)
> C) R v2.5.0dev (2006-12-12 r40167)
>
> This is on WinXP and I start R with Rterm --vanilla.
>
> Example: Identical serialize() calls using the different R versions.
>
> > raw <- serialize(1, connection=NULL, ascii=TRUE)
> > print(raw)
>
> gives:
>
> (A): [1] 41 0a 32 0a 31 33 32 30 39 36 0a 31 33 31 38 34 30 0a 31 34
> 0a 31 0a 31 0a
> (B): [1] 41 0a 32 0a 31 33 32 30 39 37 0a 31 33 31 38 34 30 0a 31 34
> 0a 31 0a 31 0a
> (C): [1] 41 0a 32 0a 31 33 32 33 35 32 0a 31 33 31 38 34 30 0a 31 34
> 0a 31 0a 31 0a
>
> Note the difference in raw bytes 8 to 10, i.e.
>
> > raw[7:11]
> (A): [1] 32 30 39 36 0a
> (B): [1] 32 30 39 37 0a
> (C): [1] 32 33 35 32 0a
>
> Does bytes 8, 9 and 10 in the raw vector somehow contain information
> about the R version or similar? The following poor mans test says
> that is the only difference:
>
> On all R versions, the following gives identical results:
>
> > raw <- serialize(1:1e4, connection=NULL, ascii=TRUE)
> > raw <- as.integer(raw[-c(8:10)])
> > sum(raw)
> [1] 2147884
> > sum(log(raw))
> [1] 177201.2
>
> If it is true that there is a R version specific header in serialized
> objects, then the digest() function should exclude such header in
> order to produce consistent results across R versions, because now
> digest(1) gives different results.
>
> Thank you
>
> Henrik
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
