Wednesday, December 17, 2008

0.3 Release Submitted

Well, I've submitted my third patch, which I will be considering as my 0.3 release. Whether or not it gets accepted remains to be seen but I feel like I've done enough to submit a good 0.3.

Most of the issues I needed to correct were minor things such as naming conventions, however there were also some other issues that ted pointed out that I needed to fix.

The first was a change to the data block. Ted didn't like the fact that the SRCSRVTRG variable was set to HTTP_EXTRACT_TARGET. Instead he wanted this variable to point to a local target because SRCSRVTRG was supposed to resolve to the path that the file is extracted to. What I found is that while this is true for a CVS extraction, I believe it serves a different purpose when used for HTTP extraction.

When I run srctool on a pdb using the old CVS implementation, I see entries like this:

[e:\fx19rel\winnt_5.2_depend\mozilla\layout\style\nsrulenode.h] cmd: cvs.exe -d checkout -r 1.64 -d 1.64 -N mozilla/layout/style/nsRuleNode.h

As you can see, the header file has a "cmd" which is run to retrieve the source file. The SRCSRVTRG is then set as a local path to tell srcsrv where to dump the file. However, in my HTTP implementation srctool showed this:

[c:\mozilla\src\toolkit\xre\nsupdatedriver.h] trg: 

As you can see, the files no longer use a "cmd" but a "trg". I wasn't sure if this was related to HTTP_EXTRACT_TARGET or SRCSRVTRG so I experimented by changing SRCSRVTRG to ted's recommendation, and srctool showed this:

[c:\mozilla\src\toolkit\xre\nsupdatedriver.h] trg: C:\mozilla\symbols\xul.pdb\.... 

The trg was now the location of the xul.pdb file. This showed me that SRCSRVTRG was being used to determine where the file was located, and thus was being used differently than if the source server was using CVS. Testing in Visual Studio proved this, as the source server didn't know where to find the file. So, to sum things up, SRCSRVTRG had to remain the way it was.

I was also asked to remove the SRCSRVCMD command from the data block, as it wasn't being set to anything. I assumed I needed it as the srcsrv documentation said it was a required variable, but it turns out that I didn't need it so I was happy to remove it.

So, I was ready to submit a new patch when I found out that my entire solution didn't work in Visual Studio 2005! I had been testing on 2008 the entire time and it worked like a dream, however 2005 didn't seem to know how to do HTTP retrieval. After discussing this with ted and sending him my stuff, he got it working fine in WinDBG (I had tried WinDBG myself without any success but I must have done something wrong in the setup) so in the end not working in 2005 was ok with ted, he speculated that perhaps srcsrv wasn't properly implemented in 2005 and I'm inclined to agree based on what I've seen in my testing.

So, now that I've resolved these issues I feel confident about getting my project implemented in the tree. Maybe not with this patch, but eventually.

Tuesday, December 9, 2008

0.3 Update #2, failed review again :(

Well, it seems ted has found some more problems with my patch so I'll have to try again. I'm still very optimistic that I can get this done on time however I'm in the middle of exam week so it will take some time before my next patch is created. Stay tuned.

Monday, December 1, 2008

0.3 Update

Well, it's been awhile since my last post but I'm in overdrive mode for some of my other classes so unfortunately I've gotten a little behind on my 0.3. Luckily, I believe I'm close to having my patch accepted.

I guess I should explain that my first review didn't go so well. Ted pointed out a few things that he didn't like about my patch (one of which was a dumb mistake on my part) but fortunately none of the required changes was difficult (mostly naming conventions and a syntax error inside of the data block) and Ted even mentioned that my patch was close. So, I've uploaded my next patch and I'm hoping for the best.