Thursday, July 30, 2009

Program Updating (r72)

Now that we're out of our 0.9.1 "stabilization mode" coding, it's time to start working on some more interesting things.

First up is the resurrection of the "Program Update" code. Updated the URLs to point to a PeerBlock-specific website, uploaded my own latest-update-checking script, and BOOM . . . nothing. Well, that's not entirely accurate - the program's updating the "Updating" UI to change the status to say "Update available, see (url)". The thing is, the program's supposed to pop up a window and tell you to download a new version, loading up the website in your browser for you if you choose to do so. Doesn't look like this code was working even in the PeerGuardian base code, but then again since the PeerGuardian update URL says the latest official version was built in 2005, I suppose nobody would really remember all that well whether it worked or didn't.

Either way, it's working now! PeerBlock will now check for updates, and will actually let you know if a new version is available. And it will pop up that window asking you if you'd like to be taken there. And it will take you there if you so choose.

Not as slick as an automatic update routine that does everything under the covers for you, but it should suffice for now. Speaking of which, I need to add an Enhancement Request to our issue-tracker to track that idea for future implementation...


Technical Details

The diffs are actually relatively straightforward, and the tracelog routines sprinkled throughout should help let you know what's going on in each section.

That said, there are a few hairy bits...

The way it works is the program stores a date-string for when it was compiled, sticks a number on the front of it to identify build-type, and calls this the BUILDSTR. We then open the URL for a PHP-based update-script, and pass it this BUILDSTR. The update-script then returns a string (in the same format), identifying the latest release for that build-type. PeerBlock then checks to see if the returned latest-version is greater than its BUILDSTR number, and if so gets ready to perform the update operation.

I updated this a bit to add a build-version to the end of it, and ended up needing to update a few key variables to type "unsigned long long" as a result - those numbers are getting awfully big! Also note that we should probably reduce the build-type #defines by a factor of 10 once 2010 rolls around; they're only so high because otherwise STRINGIFY ends up stripping the leading 0.

And for what it's worth, we never seem to real the else clause that starts on line 638 in updatelists.cpp. This is why the updatepg was never being set, which caused the "Update available, would you like to go there?" window to never be displayed.
Posted by at 5:38 PM

5 comments:

  2. Actually, I generally try to bundle up a bunch of fixes into one Interim Release for test-purposes - makes it easier for me to debug problems if there's only a limited number of versions out there that people could be running. It's also currently kind of painful to generate these builds, particularly the updating of all the places the program-version appears. Someday when I get time I'll create a better build-system, something that will be able to auto-magically do all that for me. At that point I'll reconsider generating new builds for each and every bugfix we checkin.

    For now, though, these sorts of entries on this blog serve two purposes. The first is to let people know that work is actually going on, since a week or more could otherwise go by without any word. In addition to that I'm trying to better-document the changes for future reference, either for me or in case someone someday has to come along and resurrect this project like I had to resurrect the PeerGuardian code - that's the purpose of the "Technical Details" section.
    ReplyDelete
  3. ok thanks for the detailed reply! makes perfect sense to me, i was just confused when you were talking about r72 and i've got r71 going!
    ReplyDelete
  4. I like seeing these updates. Nice to know you're getting some free time to fix stuff! Btw I don't think the update code ever functioned with PG2 ;)
    ReplyDelete
  5. ss18: Yeah, I can see how that could be confusing. The "r72" actually denotes the source-control revision level, meaning the revision of the code in the Google Code SVN. When used as a program version number this makes it easier for us to look at the exact source used to compile that version. When used in a post like this it's being used to describe the specific source-control "commit" I'm talking about here; this will hopefully make it easier to figure out WTF we were thinking when looking back at those code changes. =;)

    Praeses: Glad to hear you find these updates useful! I'm not too good about posting them sometimes (this r72 one is the most recent, and the code's up to r74 already!) but will try to do so, I swear. Like I said, ideally I'd love to document every commit with at least a short post here...
    ReplyDelete

Subscribe to: Post Comments (Atom)