Older blog entries for LSchiere (starting at number 26)

cmiller
its nice to see that someone realizes that evolution is a theory. if you look at ID/evolution debates, you will often see evolution's supporters reference "the fact of evolution" so apparently even scientists don't understand that distinction.

YEAH!!!!!!
gaim
we got the loading of the blist.xml at start up working now. makes it so that i can get online with oscar for the first time in a couple weeks. very nice. it takes forever and a day to see something outside of the terminal to show gaim's running now though, we'll have to change that. but loading the blist.xml only once is such an improvement, i think its worth the increased delay in startup. while i'd of course like to see that delay reduced, i'm not sure how it could be accomplished. now that i can get online again, and also now that we don't have to worry about editing only parts of a given person, we can start moving forward again. on the downside, i think i may have introduced some bugs with blist possition, and i know i introduced at least one with signing an account off.

I'm back from vacation, had alot of fun in florida. most good. on the down side, i seem to have caught some virus on the way home or something, cause i've had a quesy stomach all yesterday and continuing today. not fun at all.

gaim
faceprint and chipx86 kept the tree in sync with gaim's main tree and got things mostly usable. one annoying bug with multiple accounts left on the online tab, and of course gtk styles continue to be a pain, especially in the tooltips. Sean decided he wants new dialogs that i write to be in gtk2, not gtk1.2, so faceprint and i have to start the blist editing work part way over again. given that neither of us know gtk2, and that i'm not all that great with gtk1.2 even, this will be non-trivial. not too much seems to have happened with gaim's main tree, at least not as much as i'd hoped based on some of the things sean was saying before i left. The new preferences are finally in place, but they have significant bugs. That's what happens when you code something in isolation, it just doesn't get the testing it needs. BUT, that's why we have cvs, and why we haven't released 0.60 yet, that and the fact sean wants the 0.60 release to coincide with the next trillian release.

I saw chipx86's article, and i have to agree with him for the most part, though i'm certainly guiltly of falling into mini-holy wars more often than he is. in the end, what i MOST agree with is the reply complaining about the lazy users and the way they ask for help. Before my vacation, i respond to a significant portion of the help requests that hit #gaim and the source forge bug tracker, support tracker, and forum. a recent example is perfect for several reasons. a user posted an inflamitory "bug" report yesterday. its a report that duplicates 10 or so previous reports, 3 of which had been marked as "invalid" in the past week or so. as i said, i'm not feeling well, so irritably, i responded very harshly, i'm not proud of that. fortunately it was a reasonable perosn on the other end, and in a series of posts, he came to understand why we don't consider it a bug, and how my work on person support will remove the issue anyway by 0.61 or 0.62 depending on how fast faceprint and i can get the blist editing working. (both numbers assume current release rates, not the 2 week schedule we used to have), but it goes to show how easily people forget that thier personal uses of a project might not exactly correspond with how developers see things, and also how easy it is for people to fall into insulting when they meet less clued people.

31 Jul 2002 (updated 31 Jul 2002 at 18:06 UTC) »
gaim:
calling person_number and buddy_number so many times slowed things down to the point aim kicked me off. got it working again by storing the value of buddy_number, person_number and group_number and only calling each once. however, in the process of discovering that *_number was the problem and that storing the value was thus the solution, we managed to break write_person. we also discovered that signing off wasn't aware of the fact that groups now contain persons, and fixing that temporarily introduced a ton of segfaults. it have been our efforts there that broke write_person, but either way, the result is the same. leaving tomorrow for florida, so faceprint and chipx86 will be the only ones working on it for a couple weeks.
gaim:
working on tracking down segfaults. its a slow and tedious process. Got the initial values for the dialog to add or edit a person to work correctly, the sizing issues still aren't all solved though, and it still doesn't actually DO anything. on the plus side, with a little help from cmorgan, we have absolute placement of persons and groups working. I'm not sure, but i think i might only be allowing one instance of each person_name though, instead of one per group. will have to check up on that. showed #gaim on opn a screenshot with absolute placement working, so that AIM, Y!M, irc, and jabber icons were scattered through each group, got alot of interest. Nice to see that faceprint and i aren't the only ones interested in this working out. gtk critical warnings are incredibly useless. they produce a ton of output telling you something is wrong without giving you one shread of ability to tell WHERE it went wrong in your code. but we are making progress, I started using it as my main instance of gaim tonight, which is a big changeover, considering how nearly 24/7 i try to be online. i think i'll have to change back when go to bed though.

okay, so after some work insanely early for a saturday, faceprint discovered we were wrong last night. its not libxode that eats 100Mb of memory on signon. its our own add_buddy (surprise surprise). or if not add_buddy, something it calls. so today i get to figure out what.

chipx86
that will be cool. i'm not holding my breath though ;-)

singularly unproductive day. discovered libxode is leaky. fairly majorly. looked towards fixing a couple of more random segfaults in gaim. discovered why our "ordered" insert isn't acting very ordered, i need to write a GComparFunc. in fact, i need one for groups, one for persons, and one for buddies. but i didn't write them yet. faceprint started making the other protocols person-aware. that's a good thing: freaky things happen when you sign on a protocol that isn't person-aware. (for those who aren't familiar with what i'm doing, faceprint and i are working on a gaim source tree, re-doing the buddy list internals and display to support what i call persons, where a person is a collection of buddies that are all the same real-life person. everybuddy calls this concept a "contact".). I've also started in on the blist manipulation code, I've got a dialog that will eventually allow you to add/edit a person mostly displaying right, now i just have to make it do stuff and display data and not just widgets.

in other gaim news, some idiot has been posting to the gaim-devel list. on one hand, its great that the list is actually getting used. on the other hand, we've explained why encrypting the .gaimrc provides a false sense of increased security umpteen times now. People don't seem to even listen beyond the fact that we disagree. they know it all; us developers know nothing. chipx86 will be posting an entry to our faq giving a summery of what he and i had to repeat again in a series of emails today, that way we can hopefully reduce future instances of this request to a reference to the faq. which leads to my second most frequent gripe: chipx86 and i go to the trouble to write a faq that answers a significant number of the questions that hit the sourceforge forum, the #gaim irc channel, and the bug and support requests. but no one reads the faq, even though its linked to from gaim's home page. sometimes they don't even read it if you tell them to go directly there (give them the url). what's worse is when they try to tell me that their question isn't answered, when i wrote that part of the faq. </end gripe>

YEAH!!!!!!!! it looks like we finally have the new buddy list online tab display for gaim working! only bugs left will be the odd ones that you don't hit right off the bat with a couple minutes of use. its not quite doing priority right, faceprint has started work towards fixing that tonight, and tomorrow i can start looking at the edittree code to let you manipulate the list contents. I'm a month behind unfortunately, which means I won't finish this before i go on vacation next week. I'm looking forward to vacation, but i'm not looking forward to 2.5 weeks of inactivity just as sean gets ready to move towards a very feature rich 0.60 release and gaim's official repository starts changing. Hopefully faceprint will keep on top of things while i'm gone and we won't have to catch back up too much. I'm finding that debuging goes much more easily when i have someone (faceprint) to help me work through things with than when i'm working alone. also learning alot about gtk, which is half of why i started doing this. so i can't complain too much i guess, things aren't going badly, just not as well as i nievely had hoped.

still debugging person support in gaim, found quite a few bugs in the online tab display, but still butting my head against 3 of them: 1)gtk crital warnings, 2)doing something wrong with log_timers so a person doesn't sign off correctly. 3)this is the most troublesome: 2 accounts on the same protocol seem to work fine, but 2 accounts on different protocols, only the first on seems to display. very odd.

vacation is coming up, am looking forward to heading down to florida for 2 weeks :-), even though it does mean summer is almost over :-(

got things compiling, with much help from chipx86. faceprint figured out where the corruption was happening, I got that fixed. having a TON of problems with set_buddy(), and since that's called whenever someone comes online, goes away, or idle, or in any other way changes status, getting that working is a big deal. it would help if i understood gtk a little bit better. it would also help if the gtk critical warnings gave me a little more information...

17 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!