search for: lee99

...ght be. I'll leave well enough alone. Many thanks for helping me learn about this. Geoff PS Apologies if I have sent too much to the list about this topic - if so let me know (gently please), so I can be better behaved in the future. -----Original Message----- From: Geoff Lee [mailto:geoff.lee99 at gmail.com] Sent: Saturday, 14 March 2015 9:30 AM To: 'John Chambers' Cc: 'r-devel at r-project.org' Subject: RE: [Rd] Understanding why "no metadata object found ... not exported?" warnings from the methods package exist, and what they mean Very many thanks indeed Joh...

Hi I am seeking to understand why the methods package (to be specific `methods:::.findOrCopyClass` when called by `setIs` when called by `setClass`) emits a warning message such as ` class "SpatialLinesNULL" is defined (with package slot 'rgeos') but no metadata object found to revise subclass information---not exported? Making a copy in package 'minweSpatialNULL `

...espace be loaded, to access (presumably) the class object? Or the copy made silently somewhere? It's probably true that the warning is not being seen by the owner of the package that could fix the problem. > > John > > > > On Mar 12, 2015, at 1:47 PM, Geoff Lee <geoff.lee99 at gmail.com> wrote: > >> Hi >> >> >> >> I am seeking to understand why the methods package (to be specific >> `methods:::.findOrCopyClass` when called by `setIs` when called by >> `setClass`) emits a warning message such as >> >> &g...

...ge has. So, should that namespace be loaded, to access (presumably) the class object? Or the copy made silently somewhere? It's probably true that the warning is not being seen by the owner of the package that could fix the problem. John On Mar 12, 2015, at 1:47 PM, Geoff Lee <geoff.lee99 at gmail.com> wrote: > Hi > > > > I am seeking to understand why the methods package (to be specific > `methods:::.findOrCopyClass` when called by `setIs` when called by > `setClass`) emits a warning message such as > > > > ` class "SpatialLinesNULL&q...

Hi Duncan, Many thanks (yet again). With the hint given by your earlier email (viz that currently loadNamespace expects a 3rd component called name in the list that is used for the versionCheck argument) I had another look at what was going on with my toy examples yesterday evening. I'm still working on my issue, but thus far I have: 1) Confirmed that internal calls to loadNamespace

This is an enquiry not so much about what the code for loadNamespace does, but rather about the intent and design of loadNamespace, and how it interacts with the `::` function, which seems to me to follow a slightly different philosophy. It is not an urgent question - the issue that started me wondering has been resolved another way - but I would like to complete my understanding of this aspect

Hi I'm still exploring the R programming universe, so if this is being asked in the wrong place, or in the wrong way (e.g. too verbose or lacking in crucial detail or in the wrong format) please let me know I am trying to understand when the version constraints for packages which appear in the Imports field of a DESCRIPTION file are checked. Along the way I've hit a snag

Many thanks Duncan for the quick response. A bug is a relief in a way. I've been digging my way deeper into this (and learning more as I go) for several days now - but it is a diversion from (a diversion from) my main goal :-( Is there somewhere specific I should report or log the bug or will that happen from this mailing-list automatically? (I have seen the Bug Tracking link on the

Hi Duncan The difference is that in your call to loadNamespace, the versionCheck list has 3 components (name, op and version), whereas the documentation only mentions 2 (op and version). loadNamespace 'works' for me provided I add a third component to the list (even a nonsense one). What I haven't yet had the fortitude to do is track down through the code to see what the arguments