
<!DOCTYPE rss PUBLIC  "-//Netscape Communications//DTD RSS 0.91//EN"
"http://my.netscape.com/publish/formats/rss-0.91.dtd">
<rss version="0.91">
<channel> 
<title></title> 
<link>http://www-int.stsci.edu/~bsimon/weblog.cgi</link> 
<description>The work log of Bernie Simon</description> 
<language>en</language> 
<item>
<title>RepairMetatda Resurfaces</title>
<link>http://www-int.stsci.edu/~bsimon/weblog.cgi/post/301120165103.html</link>
<description>
&lt;p&gt;If you're wondering where I've been for the past three days, I was
attending YAPC::NA in Toronto. Today Mike tested the repairMetadata
fix I submitted and during the test it filled up the /tmp
directory. So the fix was rejected. At first I thought changing from
using subtransactions to transactions, but that did not solve the
problem. Then Greg suggested the problem might not be with
repairMetadata itself, but with the folder copy that was part of the
test. Running repairMetadata directly showed that indeed that was the
case. So technically the fix is "correct", but it does not solve the
problem it was supposed to. I'll have to step back and think of the
best approach to the problem, maybe increasing the size of /tmp or
looking at the copy code to see if there's any obvious way to cut down 
on the /tmp disk space used.&lt;/p&gt;

&lt;p&gt;I'll be on vacation up through July 11th, see you July 12th.&lt;/p&gt;
</description>
</item>

<item>
<title>Badlinks</title>
<link>http://www-int.stsci.edu/~bsimon/weblog.cgi/post/241119645129.html</link>
<description>
&lt;p&gt;My bad links checker script was throwing a segmentation error. The
problem seems to be that I set a timeout on parsing an individual page 
and the asynchronous exit the timeout caused left the script in an
invalid state. So I removed the timeout, but now face the problem the
timeout wasmeant to cure: html pages that take a very long time to
parse and hang the script.&lt;/p&gt;
</description>
</item>

<item>
<title>This and That</title>
<link>http://www-int.stsci.edu/~bsimon/weblog.cgi/post/231119559208.html</link>
<description>
&lt;p&gt;I moved the change to repairMetadata into CVS and wrote up a test plan 
for it. I tested Leigh's conference registration form. It passed. Then 
I reworked Mike's metrics scripts to support the POSKey testing.&lt;/p&gt;
</description>
</item>

<item>
<title>PAR</title>
<link>http://www-int.stsci.edu/~bsimon/weblog.cgi/post/221119472672.html</link>
<description>
&lt;p&gt;I was in late because of a doctor's appointment. I spent the whole
day working on my self-asessment.&lt;/p&gt;

</description>
</item>

<item>
<title>Transactions</title>
<link>http://www-int.stsci.edu/~bsimon/weblog.cgi/post/211119386827.html</link>
<description>
&lt;p&gt;I modified repairMetadata in STCatalogAware.py so that it uses
subtransactions and then tested the change. I still need to install
the change in cvs and write up the test plan. We tried once more to
install the Palm desktop software on the Macintosh and failed
again. I'll have to contact the folks at Alphasmart. I answered a user 
question on how to set up cvs (CNSHD533045).&lt;/p&gt;
</description>
</item>

<item>
<title>Palm Phonebook</title>
<link>http://www-int.stsci.edu/~bsimon/weblog.cgi/post/201119301998.html</link>
<description>
&lt;p&gt;I pulled the problem report on the LDAP to palm download out of the 
stack of problems i've been determinedly ignoring. LDAP to PC palm
works fine. LDAP to outlook doesn't work and LDAP to Mac Palm is
undetermined: I had trouble installing the Palm software on my Mac.&lt;/p&gt;
</description>
</item>

<item>
<title>Check It Out</title>
<link>http://www-int.stsci.edu/~bsimon/weblog.cgi/post/171119041929.html</link>
<description>
&lt;p&gt;I looked at repairMetadata and decided there was no bug, though it
would be nice to be able to switch off recursion. I checked up on my
YAPC information to make sure I have all my ducks in a row. There's
bus service between the airport and conference center, so I can afford 
the cost of a taxi. Hooray! I talked with Mike about what turned out
to be a rewrite problem. Dan will handle the fix.&lt;/p&gt;
</description>
</item>

<item>
<title>Back to the Grind</title>
<link>http://www-int.stsci.edu/~bsimon/weblog.cgi/post/161118955719.html</link>
<description>
&lt;p&gt;I'm back at work after a week and a half vacation. I spent a lot of 
time going through old email. We met and discussed Anne's memo on Zope 
risk assessment as well as meeting and talking about the proposed
poskey error. Greg pointed out a possible problem with repairMetadata
that I will have to investigate.&lt;/p&gt;
</description>
</item>

<item>
<title>More Poskey</title>
<link>http://www-int.stsci.edu/~bsimon/weblog.cgi/post/031117832995.html</link>
<description>
&lt;p&gt;Craig reported my permissions fix didn't pass the test. I checked
and it had not been checked out of CVS. We'll need to discuss and
document our CVS procedures. I worked with Greg some more on the
Poskey problem. We outlined our proposed solution and then started
working on a new, more conservative solution.&lt;/p&gt;
</description>
</item>

<item>
<title>A Problem solved</title>
<link>http://www-int.stsci.edu/~bsimon/weblog.cgi/post/021117746125.html</link>
<description>
&lt;p&gt;I worked with Greg today on two problems. The first was configuring 
the development and test versions on remedy, which was pretty
straightforward. The second was figuring out a way to fix the last
stubborn poskey error. We finally hit on a method that copies the
contents of the object to a new object, clears the object and copies
it back. So now we're ready to fix the production database.&lt;/p&gt;
</description>
</item>

</channel>
</rss>
