Re: [Rd] S4 and connection slot [Sec=Unclassified]

[Wacek Kusnierczyk]

Martin Morgan wrote:

[...]




## Attempt two -- initialize
setClass("Element",
 representation=representation(conn="file"))

setMethod(initialize, "Element", function(.Object, ..., conn=file()) {
callNextMethod(.Object, ..., conn=conn)
})

new("Element")
## oops, connection created but not closed; gc() closes (eventually)
## but with an ugly warning
## > gc()
##used  (Mb) gc trigger  (Mb) max used  (Mb)
## Ncells   717240  38.41166886  62.4  1073225  57.4
## Vcells 3795 284.9   63274729 482.8 60051033 458.2
## > gc()
##used  (Mb) gc trigger  (Mb) max used  (Mb)
## Ncells   715906  38.31166886  62.4  1073225  57.4
## Vcells 37335626 284.9   63274729 482.8 60051033 458.2
## Warning messages:
## 1: closing unused connection 3 ()

setClass("ElementX", contains="Element")
## oops, two connections opened (!)


yes, that's because of the nonsense double call to the initializer while 
creating a subclass.  the conceptual bug in the s4 system leads to this 
ridiculous behaviour in your essentially correct and useful pattern.


vQ

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] S4 and connection slot [Sec=Unclassified]

[Troy Robertson]

Thanks guys,

I wasn't having a problem storing active connections in slots initially.  They 
were opened during initialisation of the object and then a routine ran through 
and closed them all before the program exited.

I have now implemented them as environment stored objects as a way around the 
slot problem (along with all the rest of the class data members so that object 
passing is more efficient without all the memcpying).  So much for S4 slots.

Troy


> -Original Message-
> From: Martin Morgan [mailto:mtmor...@fhcrc.org]
> Sent: Tuesday, 30 June 2009 5:12 AM
> To: Stavros Macrakis
> Cc: Troy Robertson; r-devel@R-project.org
> Subject: Re: [Rd] S4 and connection slot [Sec=Unclassified]
>
> Stavros Macrakis wrote:
> > On Mon, Jun 29, 2009 at 9:19 AM, Martin Morgan  > <mailto:mtmor...@fhcrc.org>> wrote:
> >
> > ...I'm not sure that including a connection in a slot is going to be
> > a good
> > idea, though -- a connection has reference-like semantics, so you
> can
> > end up with multiple objects pointing to the same connection, Also
> when
> > an object is garbage collected the connection will not be closed
> > automatically.
> >
> >
> > I'm not sure I understand your point here.  Having multiple objects
> > refer to the same connection seems like a perfectly reasonable and
> > useful thing, and garbage collection should work just fine -- when *all*
> > of the objects referring to that connection are unreachable, then the
> > connection is unreachable and will itself be garbage collected.  No?
>
> I meant that, in practice, there were enough additional pitfalls that I
> wouldn't choose this route (placing a connection in an S4 slot) for
> myself. These little experiments were enough to make me cautious...
>
> setOldClass(c("file", "connection"))
>
> ## Attempt one -- prototype
> setClass("Element",
>  representation=representation(conn="file"),
>  prototype=prototype(conn=file()))
>
> ## oops, all instances share a single connection
>
> close(new("Element")@conn)
> ## oops, all new instances now have a closed (invalid) connection
>
>
> ## Attempt two -- initialize
> setClass("Element",
>  representation=representation(conn="file"))
>
> setMethod(initialize, "Element", function(.Object, ..., conn=file()) {
> callNextMethod(.Object, ..., conn=conn)
> })
>
> new("Element")
> ## oops, connection created but not closed; gc() closes (eventually)
> ## but with an ugly warning
> ## > gc()
> ##used  (Mb) gc trigger  (Mb) max used  (Mb)
> ## Ncells   717240  38.41166886  62.4  1073225  57.4
> ## Vcells 3795 284.9   63274729 482.8 60051033 458.2
> ## > gc()
> ##used  (Mb) gc trigger  (Mb) max used  (Mb)
> ## Ncells   715906  38.31166886  62.4  1073225  57.4
> ## Vcells 37335626 284.9   63274729 482.8 60051033 458.2
> ## Warning messages:
> ## 1: closing unused connection 3 ()
>
> setClass("ElementX", contains="Element")
> ## oops, two connections opened (!)
> ## > showConnections()
> ##   description class  mode text   isopen   can read can write
> ## 3 ""  "file" "w+" "text" "opened" "yes""yes"
> ## 4 ""  "file" "w+" "text" "opened" "yes""yes"
>
> And while completely expected the action-at-a-distance of references has
> the usual risks
>
> > x <- y <- new("Element")
> > close(x...@conn)
> > y
> An object of class "Element"
> Slot "conn":
> Error in summary.connection(x) : invalid connection
>
> One place I know where S4 and connections are used effectively is in the
> AnnotationDbi package in Bioconductor (I did not participate in
> developing this package, so am probably misrepresenting its
> implementation). Here there is a database connection. But it is stored
> in an environment in an S4 class. This part of the class is used
> essentially as a singleton -- AnnotationDbi creates packages containing
> instances, and users load the package and hence single instance; the
> interface never exposes the connection itself to copying. The database
> functionality exposed to the user is read-only, and querying the
> connection does not change it's state (other than opening it if it were
> closed). I think the underlying connection has C code to tidy itself up
> appropriately (and quietly) when eventually garbage collected. So yes,

Re: [Rd] S4 and connection slot [Sec=Unclassified]

[Martin Morgan]

Stavros Macrakis wrote:
> On Mon, Jun 29, 2009 at 9:19 AM, Martin Morgan  > wrote:
> 
> ...I'm not sure that including a connection in a slot is going to be
> a good
> idea, though -- a connection has reference-like semantics, so you can
> end up with multiple objects pointing to the same connection, Also when
> an object is garbage collected the connection will not be closed
> automatically.
> 
> 
> I'm not sure I understand your point here.  Having multiple objects
> refer to the same connection seems like a perfectly reasonable and
> useful thing, and garbage collection should work just fine -- when *all*
> of the objects referring to that connection are unreachable, then the
> connection is unreachable and will itself be garbage collected.  No?

I meant that, in practice, there were enough additional pitfalls that I
wouldn't choose this route (placing a connection in an S4 slot) for
myself. These little experiments were enough to make me cautious...

setOldClass(c("file", "connection"))

## Attempt one -- prototype
setClass("Element",
 representation=representation(conn="file"),
 prototype=prototype(conn=file()))

## oops, all instances share a single connection

close(new("Element")@conn)
## oops, all new instances now have a closed (invalid) connection


## Attempt two -- initialize
setClass("Element",
 representation=representation(conn="file"))

setMethod(initialize, "Element", function(.Object, ..., conn=file()) {
callNextMethod(.Object, ..., conn=conn)
})

new("Element")
## oops, connection created but not closed; gc() closes (eventually)
## but with an ugly warning
## > gc()
##used  (Mb) gc trigger  (Mb) max used  (Mb)
## Ncells   717240  38.41166886  62.4  1073225  57.4
## Vcells 3795 284.9   63274729 482.8 60051033 458.2
## > gc()
##used  (Mb) gc trigger  (Mb) max used  (Mb)
## Ncells   715906  38.31166886  62.4  1073225  57.4
## Vcells 37335626 284.9   63274729 482.8 60051033 458.2
## Warning messages:
## 1: closing unused connection 3 ()

setClass("ElementX", contains="Element")
## oops, two connections opened (!)
## > showConnections()
##   description class  mode text   isopen   can read can write
## 3 ""  "file" "w+" "text" "opened" "yes""yes"
## 4 ""  "file" "w+" "text" "opened" "yes""yes"

And while completely expected the action-at-a-distance of references has
the usual risks

> x <- y <- new("Element")
> close(x...@conn)
> y
An object of class "Element"
Slot "conn":
Error in summary.connection(x) : invalid connection

One place I know where S4 and connections are used effectively is in the
AnnotationDbi package in Bioconductor (I did not participate in
developing this package, so am probably misrepresenting its
implementation). Here there is a database connection. But it is stored
in an environment in an S4 class. This part of the class is used
essentially as a singleton -- AnnotationDbi creates packages containing
instances, and users load the package and hence single instance; the
interface never exposes the connection itself to copying. The database
functionality exposed to the user is read-only, and querying the
connection does not change it's state (other than opening it if it were
closed). I think the underlying connection has C code to tidy itself up
appropriately (and quietly) when eventually garbage collected. So yes,
connections and multiple references to them can be useful.

Martin


>-s
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] S4 and connection slot [Sec=Unclassified]

[Paul Gilbert]

There may be a problem that objects with slots can persist into new 
sessions (i.e. be saved)  but I think connections die when a session 
ends, so whatever is in the slot is no longer valid.


Paul

Stavros Macrakis wrote:

On Mon, Jun 29, 2009 at 9:19 AM, Martin Morgan  wrote:



...I'm not sure that including a connection in a slot is going to be a good
idea, though -- a connection has reference-like semantics, so you can
end up with multiple objects pointing to the same connection, Also when
an object is garbage collected the connection will not be closed
automatically.




I'm not sure I understand your point here.  Having multiple objects refer to
the same connection seems like a perfectly reasonable and useful thing, and
garbage collection should work just fine -- when *all* of the objects
referring to that connection are unreachable, then the connection is
unreachable and will itself be garbage collected.  No?

   -s

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



La version française suit le texte anglais.



This email may contain privileged and/or confidential information, and the Bank 
of
Canada does not waive any related rights. Any distribution, use, or copying of 
this
email or the information it contains by other than the intended recipient is
unauthorized. If you received this email in error please delete it immediately 
from
your system and notify the sender promptly by email that you have done so. 




Le présent courriel peut contenir de l'information privilégiée ou 
confidentielle.
La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute 
diffusion,
utilisation ou copie de ce courriel ou des renseignements qu'il contient par une
personne autre que le ou les destinataires désignés est interdite. Si vous 
recevez
ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans 
délai à
l'expéditeur un message électronique pour l'aviser que vous avez éliminé de 
votre
ordinateur toute copie du courriel reçu.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] S4 and connection slot [Sec=Unclassified]

[Stavros Macrakis]

On Mon, Jun 29, 2009 at 9:19 AM, Martin Morgan  wrote:

> ...I'm not sure that including a connection in a slot is going to be a good
> idea, though -- a connection has reference-like semantics, so you can
> end up with multiple objects pointing to the same connection, Also when
> an object is garbage collected the connection will not be closed
> automatically.


I'm not sure I understand your point here.  Having multiple objects refer to
the same connection seems like a perfectly reasonable and useful thing, and
garbage collection should work just fine -- when *all* of the objects
referring to that connection are unreachable, then the connection is
unreachable and will itself be garbage collected.  No?

   -s

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] S4 and connection slot [Sec=Unclassified]

[Martin Morgan]

Troy Robertson wrote:
> Right you are Martin,
> 
> When you simplify things right down your code below works.
> 
> I had kept getting the error below:
> 
> Error in validObject(.Object) :
>   invalid class "KrillEnvironment" object: class for slot "datafileConn" 
> ("file")
> 
> But now realise that it is when the class extends '.environment' and passes 
> through the .xData slot:

I think the problem now is that the object is not initialized properly,
specifically that the 'datafileConn' slot is NULL, but should be 'file'.
This is true of the simpler case as well

> setClass("Element", representation=representation(datafileConn="file"))
[1] "Element"
> validObject(new("Element"))
Error in validObject(new("Element")) :
  invalid class "Element" object: invalid object for slot "datafileConn"
in class "Element": got class "NULL", should be or extend class "file"

datafileConn needs to be assigned appropriately in the class prototype
(but then all instances would inherit the same connection) or in the
initialize method.

I'm not sure that including a connection in a slot is going to be a good
idea, though -- a connection has reference-like semantics, so you can
end up with multiple objects pointing to the same connection, Also when
an object is garbage collected the connection will not be closed
automatically.

Martin

> 
> setClass("Element",representation=representation(datafileConn="file"), 
> contains=".environment")
> 
> setMethod("initialize", "Element",
>   function(.Object,.xData=new.env(parent=emptyenv())) {
> .Object <- callNextMethod(.Object, .xData=.xData)
> return(.Object)
>   }
> )
> 
> s <- new("Element")
> 
> 
> Not sure why that changes things though?
> 
> Troy
> 
>> -Original Message-
>> From: Martin Morgan [mailto:mtmor...@fhcrc.org]
>> Sent: Monday, 29 June 2009 2:21 PM
>> To: Troy Robertson
>> Subject: Re: [Rd] S4 and connection slot [Sec=Unclassified]
>>
>> Troy Robertson wrote:
>>> Hi all,
>>>
>>>
>>>
>>> I am having a problem trying to declare a slot representation to hold a
>> file connection.
>>> With V2.8.0 I had been using:
>>>
>>>
>>>
>>> setClass("Element",
>>>
>>> representation(
>>>
>>> [other slots removed],
>>>
>>> datafileConn= setOldClass(c("file","connection"))
>>>
>>> )
>>>
>>> )
>>>
>> I think
>>
>> setOldClass(c("file", "connection"))
>>
>> setClass("Element",
>>  representation=representation(datafileConn="file"))
>>
>> getClass("file")
>> getClass("Element")
>>
>> but I don't usually use S3 classes so I'm not sure...
>>
>> Martin
>>
>>>
>>> This resulted in a warning but still ran okay.
>>>
>>>
>>>
>>> No however with V2.9.0 I am getting an error:
>>>
>>>
>>>
>>> Error in representation(state = "list", initialState = "list", polygons
>> = "list",  :
>>>   element 12 of the representation was not a single character string
>>>
>>>
>>>
>>> How can I declare a slot of the appropriate class?  The strings
>> "connection", "file" fail.
>>>
>>>
>>> Troy
>>>
>>>
>>>
>>>
>>>
>>> Troy Robertson
>>>
>>> Database and Computing Support Provider
>>>
>>> Southern Ocean Ecosystems, ERM/Fish
>>>
>>> Australian Antarctic Division
>>>
>>> Channel Highway, Kingston 7050
>>>
>>> PH: 03 62323571
>>>
>>> troy.robert...@aad.gov.au
>>>
>>>
>>>
>>>
>>>
>> __
>> _
>>> Australian Antarctic Division - Commonwealth of Australia
>>> IMPORTANT: This transmission is intended for the addressee only. If you
>> are not the
>>> intended recipient, you are notified that use or dissemination of this
>> communication is
>>> strictly prohibited by Commonwealth law. If you have received this
>> t

Re: [Rd] S4 and connection slot [Sec=Unclassified]

[Troy Robertson]

Right you are Martin,

When you simplify things right down your code below works.

I had kept getting the error below:

Error in validObject(.Object) :
  invalid class "KrillEnvironment" object: class for slot "datafileConn" 
("file")

But now realise that it is when the class extends '.environment' and passes 
through the .xData slot:

setClass("Element",representation=representation(datafileConn="file"), 
contains=".environment")

setMethod("initialize", "Element",
  function(.Object,.xData=new.env(parent=emptyenv())) {
.Object <- callNextMethod(.Object, .xData=.xData)
return(.Object)
  }
)

s <- new("Element")


Not sure why that changes things though?

Troy

> -Original Message-
> From: Martin Morgan [mailto:mtmor...@fhcrc.org]
> Sent: Monday, 29 June 2009 2:21 PM
> To: Troy Robertson
> Subject: Re: [Rd] S4 and connection slot [Sec=Unclassified]
>
> Troy Robertson wrote:
> > Hi all,
> >
> >
> >
> > I am having a problem trying to declare a slot representation to hold a
> file connection.
> >
> > With V2.8.0 I had been using:
> >
> >
> >
> > setClass("Element",
> >
> > representation(
> >
> > [other slots removed],
> >
> > datafileConn= setOldClass(c("file","connection"))
> >
> > )
> >
> > )
> >
>
> I think
>
> setOldClass(c("file", "connection"))
>
> setClass("Element",
>  representation=representation(datafileConn="file"))
>
> getClass("file")
> getClass("Element")
>
> but I don't usually use S3 classes so I'm not sure...
>
> Martin
>
> >
> >
> > This resulted in a warning but still ran okay.
> >
> >
> >
> > No however with V2.9.0 I am getting an error:
> >
> >
> >
> > Error in representation(state = "list", initialState = "list", polygons
> = "list",  :
> >
> >   element 12 of the representation was not a single character string
> >
> >
> >
> > How can I declare a slot of the appropriate class?  The strings
> "connection", "file" fail.
> >
> >
> >
> > Troy
> >
> >
> >
> >
> >
> > Troy Robertson
> >
> > Database and Computing Support Provider
> >
> > Southern Ocean Ecosystems, ERM/Fish
> >
> > Australian Antarctic Division
> >
> > Channel Highway, Kingston 7050
> >
> > PH: 03 62323571
> >
> > troy.robert...@aad.gov.au
> >
> >
> >
> >
> >
> __
> _
> >
> > Australian Antarctic Division - Commonwealth of Australia
> > IMPORTANT: This transmission is intended for the addressee only. If you
> are not the
> > intended recipient, you are notified that use or dissemination of this
> communication is
> > strictly prohibited by Commonwealth law. If you have received this
> transmission in error,
> > please notify the sender immediately by e-mail or by telephoning +61 3
> 6232 3209 and
> > DELETE the message.
> > Visit our web site at http://www.antarctica.gov.au/
> >
> __
> _
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel

___

Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not 
the
intended recipient, you are notified that use or dissemination of this 
communication is
strictly prohibited by Commonwealth law. If you have received this transmission 
in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232 
3209 and
DELETE the message.
Visit our web site at http://www.antarctica.gov.au/
___

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] S4 and connection slot [Sec=Unclassified]

[Troy Robertson]

Hi all,



I am having a problem trying to declare a slot representation to hold a file 
connection.

With V2.8.0 I had been using:



setClass("Element",

representation(

[other slots removed],

datafileConn= setOldClass(c("file","connection"))

)

)



This resulted in a warning but still ran okay.



No however with V2.9.0 I am getting an error:



Error in representation(state = "list", initialState = "list", polygons = 
"list",  :

  element 12 of the representation was not a single character string



How can I declare a slot of the appropriate class?  The strings "connection", 
"file" fail.



Troy





Troy Robertson

Database and Computing Support Provider

Southern Ocean Ecosystems, ERM/Fish

Australian Antarctic Division

Channel Highway, Kingston 7050

PH: 03 62323571

troy.robert...@aad.gov.au




___

Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not 
the
intended recipient, you are notified that use or dissemination of this 
communication is
strictly prohibited by Commonwealth law. If you have received this transmission 
in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232 
3209 and
DELETE the message.
Visit our web site at http://www.antarctica.gov.au/
___

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel