Feb 27, 2007 9:55 pm
http://publicsvn.songbirdnest.com/trac/wiki/Nightly_Builds
But there WON’T be an RC4, darn you!
Well, unless you test it hard in the next day or two and find something bad.
If you do, you know what to do, right?
HINT: http://bugzilla.songbirdnest.com/
mig
ps: It has nothing to do with c0rn tac0z.
Feb 26, 2007 11:15 pm
http://publicsvn.songbirdnest.com/trac/wiki/Nightly_Builds
Yay! We fixed a few more bugs, and things are looking mighty stable!
Most specifically, we fixed the problem with locales not properly updating on machines when the application is updated. SUPPOSEDLY, you should never see those horrible entity error dialogs any longer.
If your current Songbird install is screwed up with an entity error, installing the RC2 should properly download a new locale to fix it!
If you’re lazy and don’t want to install RC2 right now, you can wait until tomorrow morning, when John says he’ll have the update files all updated and uploaded such that if you’re running RC1 you’ll go to RC2 automagically.
We love the magic.
mig
Feb 22, 2007 10:40 pm
http://publicsvn.songbirdnest.com/trac/wiki/Nightly_Builds
We had a big race to Zarro Boogs today. Ben lost on a reopen, so he had to go out in the rain and buy beer for the other devs.
So this is it! We’re in the stretch. If there’s nothing major tomorrow and over the weekend we’re shipping final next week! Hurrah!
It’s up to all of you, however, to help us make this release as stable as possible! Test test test!
And then report on those bugs like they’re spies for the enemy.
mig
Feb 21, 2007 7:03 pm
http://publicsvn.songbirdnest.com/trac/wiki/Nightly_Builds
WARNING! People using a different language locale than en-US should go to the translation site and install the new language extension BEFORE installing the new nightly build. If you don’t, you’ll have to delete your profile to get it to download the new locale. We’re working on fixing that.
But we’re still smashing bugs left and right to try to get a brand new version that’s up to specification.
And there’s a brand new supercool addon that Aus uploaded to allow you to use any USB Mass Storage device as a media device in Songbird:
http://addons.songbirdnest.com/extensions/detail/28
So go out there and get your test on, people!
mig
Feb 16, 2007 10:51 am
While working out some threading issues with our GStreamer core, I spent some time on #developers getting answers to some XPCOM threading questions I’ve had for a long time.
The first question was about when to use NS_IMPL_ISUPPORTS versus NS_IMPL_THREADSAFE_ISUPPORTS when implementing XPCOM components in C++. The difference is in the way the reference counting methods are implemented — the former manages the reference count in a non-thread safe way, and the latter manages it in a thread safe way. Additionally, when running a debug build, components that use NS_IMPL_ISUPPORTS will assert if they are AddRefed/Released by any thread other than the owning thread (the thread the component was created on).
Therefore, you should be using NS_IMPL_THREADSAFE_ISUPPORTS if your component will be reference counted on more than one thread. If this will never happen, you should use NS_IMPL_ISUPPORTS to avoid the additional overhead of thread safe reference counting.
Note that using NS_IMPL_THREADSAFE_ISUPPORTS in your component implementation does not relate to the thread saftey of the component’s implementation, just the reference counting methods. If you wish to declare the fact that your component is implemented in a thread safe way, you must implement nsIClassInfo and set the nsIClassInfo::THREADSAFE bit in your GetFlags implementation.
By setting the nsIClassInfo::THREADSAFE bit, you are ensuring the users of your component that your component’s implementation is thread safe, meaning there is no sequence of operations involving multiple threads that will put your component into an invalid state, observe the component to be in an invalid state, or violate any of the class’s invariants, preconditions, or postconditions (this definition of thread safety is adapted from IBM DeveloperWorks’ Java theory and practice: Characterizing thread safety).
As the implementor, not only must your make sure your implementation is thread safe, but the XPCOM components you collaborate with must also be thread safe. This is why a component that touches the DOM can never be declared as thread safe unless the access to the DOM is done through a proxy.
Thanks to brendan and shaver on #developers for taking the time to clear this up for me!
© 2005-2008 Pioneers of the Inevitable
