From Mark.Bravington at csiro.au  Thu Nov  5 02:51:13 2009
From: Mark.Bravington at csiro.au (Mark.Bravington at csiro.au)
Date: Thu, 5 Nov 2009 12:51:13 +1100
Subject: [Rd] parse_Rd and/or lazyload problem
In-Reply-To: <alpine.OSX.2.00.0911041508400.2863@luke-tierneys-macbook-pro-15.local>
References: <62C82B39B8A85E4B95A18F7F7B852F87055595B001@exvic-mbx03.nexus.csiro.au>,
	<4AEB61C4.4050300@stats.uwo.ca>
	<62C82B39B8A85E4B95A18F7F7B852F87055595B002@exvic-mbx03.nexus.csiro.au>,
	<4AEC4954.9070400@stats.uwo.ca>
	<62C82B39B8A85E4B95A18F7F7B852F87055595B003@exvic-mbx03.nexus.csiro.au>,
	<4AED9648.7080702@stats.uwo.ca>
	<62C82B39B8A85E4B95A18F7F7B852F87055595B005@exvic-mbx03.nexus.csiro.au>
	<4AEDEF70.5030004@stats.uwo.ca>
	<62C82B39B8A85E4B95A18F7F7B852F8705559AE070@exvic-mbx03.nexus.csiro.au>
	<4AF11EA4.7090705@userprimary.net>
	<alpine.OSX.2.00.0911041508400.2863@luke-tierneys-macbook-pro-15.local>
Message-ID: <62C82B39B8A85E4B95A18F7F7B852F87055757116D@exvic-mbx03.nexus.csiro.au>

Great-- thanks for the info.

For now, hopefully I can get the behaviour I want by sticking a .Call( 'R_lazyLoadDBflush'...) [as per 'detach'] before calling 'lazyLoad'. Seems to work on my examples, but please let me know if you don't think it'll work generally-- if not, I could presumably create the files under different names and then change them.

Is there merit in making 'makeLazyLoadDB' public, just as 'lazyLoad' already is? It's useful.

Mark

-- 
Mark Bravington
CSIRO Mathematical & Information Sciences
Marine Laboratory
Castray Esplanade
Hobart 7001
TAS

ph (+61) 3 6232 5118
fax (+61) 3 6232 5012
mob (+61) 438 315 623

luke at stat.uiowa.edu wrote:
> Here is a more stripped down variant generates and error on OS X for
> me: 
> 
>      mkEg <- function(tm) list(scrunge = as.POSIXct(tm))
> 
>      extract <- function(db) {
>  	e<- new.env()
>  	lazyLoad(db, e)
>  	as.list( e)
>      }
> 
>      eg <- mkEg("2009-11-04 12:49:53")
>      eg1 <- mkEg("2009-11-04 12:49:28")
> 
>      tools:::makeLazyLoadDB( eg, '/tmp/ll')
>      extract('/tmp/ll') # force; OK
> 
>      tools:::makeLazyLoadDB( eg1, '/tmp/ll')
>      extract('/tmp/ll')
> 
> Changing the second set of /tmp/ll makes the symptom go away.
> 
> I believe this comes down to unintended use of the lazyload mechanism
> -- in particular it is not intended that a database be rewritten
> after it has been loaded.  There is a chaching mechanism for improved
> performance on slow file systems, and I believe what is happening is
> that the new indices are being used to look in the old chached data.
> There might be some merit in having lazyLoad call R_lazyLoadDBflush. 
> 
> luke
> 
> On Tue, 3 Nov 2009, Seth Falcon wrote:
> 
>> Hi,
>> 
>> On 11/3/09 6:51 PM, Mark.Bravington at csiro.au wrote:
>>> 
>>> file.copy( 'd:/temp/Rdiff.Rd', 'd:/temp/scrunge.Rd') # Rdiff.Rd
>>> from 'tools' package source 
>>> 
>>> eglist<- list( scrunge=parse_Rd(  'd:/temp/scrunge.Rd'))
>>> tools:::makeLazyLoadDB( eglist, 'd:/temp/ll')
>>> e<- new.env()
>>> lazyLoad( 'd:/temp/ll', e)
>>> as.list( e) # force; OK
>>> 
>>> eglist1<- list( scrunge=parse_Rd(  'd:/temp/Rdiff.Rd'))
>>> tools:::makeLazyLoadDB( eglist1, 'd:/temp/ll')
>>> e<- new.env()
>>> lazyLoad( 'd:/temp/ll', e)
>>> as.list( e) # Splat
>>> 
>>> It doesn't make any difference which file I process first; the error
>>> comes the second time round.
>> 
>> If I adjust this example in terms of paths and run on OS X, I get the
>> following error on the second run:
>> 
>>> as.list(e) # Splat
>> Error in as.list.environment(e) : internal error -3 in R_decompress1
>> 
>> I haven't looked further yet.
>> 
>> + seth
>> 
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] parse_Rd and/or lazyload problem
Mark.Bravington at csiro.au