"Andy Carlson" said:
> I did some checks today to see if my sitescooper installation was behaving
> 'as advertised' with respect to caching. It wasnt.
> After some debugging, I found 2 problems...
> The first one has already been reported on the list, but its effect on
> caching has not (IIRC) been pointed out. I'm running on Win2K using the
> multipage plucker format and getting the following error:-
>
> eval failed: Usage: Win32::Process::constant(name) at
> C:/Perl/lib/Win32/Process.pm line 113.
>
> Unfortunately this trashes the tail end of the sitescooper run, before the
> cache entries get committed to the DB file.
argh, bad news!
> Unfortunately, the caching still didnt work as expected after doing this.
> More debugging found the problem. In CacheSingleton.pm there's a method
> called get_cached_page. The first thing it does is prefix its parameter
> ($ptr) with the name of the page cache directory. The snag is that $ptr
> already has the directory in it.
>
> commenting out this...
>
> # my $pagefile = $self->{factory}->{pagecachedir}.$SLASH.$ptr;
>
> and replacing with this...
>
> my $pagefile = $ptr;
>
> caused caching to start working as expected.
>
> What I'm not sure of is whether the above fix fits in with the intended
> design of CacheSingleton (it might be that $ptr shouldnt have the directory
> in it in the first place).
OK -- I'll take a look at that. BTW does this still occur with the
'bleeding edge' code? (it's been a while since there was a release :( )
I'd really appreciate if a Win32 perl person could take a look at the
Win32::Process::constant(name) bug BTW :( I'm not going to get a chance
for a while.
--j.
_______________________________________________
Sitescooper-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/sitescooper-talk
