changelog
- Thu, 13 Nov 2008 07:22:39 +0000
- by Mark Doliner <markdoliner@pidgin.im> [Thu, 13 Nov 2008 07:22:39 +0000] rev 24615
- msn_slplink_remove_slpcall() shouldn't be responsible for setting
slpcall->slplink to NULL. In fact, msn_slp_call_destroy() shouldn't
even call msn_slplink_remove_slpcall() until it knows that it doesn't
need the slplink anymore. So move the call to
msn_slplink_remove_slpcall() further down in that function.
Now we no longer need the return value from msn_switchboard_release().
That return value, by the way, was dumb. If you're no longer using
the MsnSwitchBoard then you're not using it and you shouldn't care
if it was destroyed or not.
- Thu, 13 Nov 2008 06:57:20 +0000
- by Mark Doliner <markdoliner@pidgin.im> [Thu, 13 Nov 2008 06:57:20 +0000] rev 24614
- Make msn_slp_call_timeout static
- Thu, 13 Nov 2008 06:43:48 +0000
- by Mark Doliner <markdoliner@pidgin.im> [Thu, 13 Nov 2008 06:43:48 +0000] rev 24613
- Move msn_slplink_send_msgpart() that it doesn't need a forward declaration
and make it static
- Thu, 13 Nov 2008 06:30:33 +0000
- by Mark Doliner <markdoliner@pidgin.im> [Thu, 13 Nov 2008 06:30:33 +0000] rev 24612
- Didn't mean to check this assert in. I mean, it's probably bad if it
happens. I think it'll lead to a crash later on. Or at least some
invalid memory accesses.
- Thu, 13 Nov 2008 06:28:03 +0000
- by Mark Doliner <markdoliner@pidgin.im> [Thu, 13 Nov 2008 06:28:03 +0000] rev 24611
- slplink->swboard will only be null if slplink->session is null. This
should never happen, so this should be a g_return_if_fail() and
not just a simple if(bad)return;
- Thu, 13 Nov 2008 06:18:53 +0000
- by Mark Doliner <markdoliner@pidgin.im> [Thu, 13 Nov 2008 06:18:53 +0000] rev 24610
- Get rid of slplink->local_user because it's a copy of
msn_user_get_passport(session->user), which is the same as account->username,
which is stupid
- Wed, 12 Nov 2008 11:30:51 +0000
- by Mark Doliner <markdoliner@pidgin.im> [Wed, 12 Nov 2008 11:30:51 +0000] rev 24609
- Use libtool to build static archives when --with-static-prpls is passed
to configure. Does anyone know why we weren't using libtool before? We
were building old-fashioned .a files. But libtool archives (.la) can
contain either static or shared libraries.
I found it a lot easier to get static prpl compilation working after
making this change (that is to say, it worked). Without this I got this
error, which is probably fixable, but consistently using libtool seems
like it makes things easier:
*** Warning: Linking the shared library libpurple.la against the
*** static library ../libpurple/protocols/msn/libmsn.a is not portable!
/usr/bin/ld: ../libpurple/protocols/msn/libmsn.a(libmsn_a-msn.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
../libpurple/protocols/msn/libmsn.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
- Wed, 12 Nov 2008 09:40:05 +0000
- by Mark Doliner <markdoliner@pidgin.im> [Wed, 12 Nov 2008 09:40:05 +0000] rev 24608
- It should be more efficient to just use g_mallc() and then manually
null terminate the buffer, right?
- Wed, 12 Nov 2008 09:32:10 +0000
- by Mark Doliner <markdoliner@pidgin.im> [Wed, 12 Nov 2008 09:32:10 +0000] rev 24607
- Move a few lines to eliminate the need for the "wasted" variable here.
I think this is simpler.
- Wed, 12 Nov 2008 09:10:29 +0000
- by Mark Doliner <markdoliner@pidgin.im> [Wed, 12 Nov 2008 09:10:29 +0000] rev 24606
- The "processing" flag basically says "this connection is busy, don't
destroy it yet, wait until it's done processing."
I don't think there's any reason for us to set processing to TRUE just
because we're connecting. I think this is a holdover from before our
purple_proxy_connect() could be canceled. But now that it's cancelable,
if we want to kill the connection we can cleanly cancel the connect
without worrying about the callback being triggered.
