Recent blog entries for LSchiere

bytesplit:
you get involved with a project by getting their source code. if you install via compiling the source you are all set, otherwise you probly have to find their home page. you then start reading the readme, and any other text files of that sort in the source code top directory, these will often explain things you may need to know at a latter point. then start looking at the source itself. at this point it might help if you know the developers, and expect this to take a significant amount of time. a project of any size will most likely not have a self-evident flow when you first look at it, the feel of the source will only come to you with time and expirience with it.

cvs helps alot. its a VERY powerful tool, and ment far more for developers than for people submitting patches, but the basic options are something you will be using. you'll need the commands cvs login cvs checkout cvs update and cvs diff

you can use cvs -H <command> ie cvs -H diff to get options on using a specific command. you will also either have to use the -d flag BEFORE the command or set the CVSROOT environment variable ie cvs -d :pserver:cvs.gaim.sf.net:/cvsroot/gaim checkout gaim will get you the copy of the gaim source code if you have previously run cvs login with the same -d flag contents.

the advantage to cvs for you, is that you are then working with the same code the developers are working with, instead of a body of code that is older, has some bugs fixed, some bugs introduced, some features removed, some features introuduced, so on. working with the same source code gives you a better chance of having your patch accepted.

you'll use the cvs diff command or the patch command to generate a patch. a patch is a list of differences between 2 versions of the same file(s). the patch command is also used to apply a patch. when you submit a patch, be it for a bug fix or a new feature, the developer(s) will read your patch to attempt to identify if its the correct fix/correct way to implement a new feature. keep in mind that some projects have style guidelines, for instance gaim does not allow gtk in some parts of the code. also keep in mind that while a given piece of code might fix your problem, it might introduce a problem for users in difference circumstances, so developers are at times very careful accepting patches, especially before they have a chance to get to know you and evaluate the quality of your work for themseleves. if two people submit the same patch, any number of things can happen, the developer might like the way one of you fixed the issue mroe than the other, or [s]he might simple use which ever was looked at first.

sometimes developers are able to get to your patch, evaluate it, and give you some feedback within a short period of time (a week or two), but that's the ideal. in real life, developers are working in their free time, are often over-worked and for good reasons or bad ones, feel under-appreciated. as a result, looking at patches sometimes gets delayed, so be patient with your developer.

tk:
for the most part you can just ignore bytesplit. at least untill he starts trying to track you down ;-) i think advogato at least knows very well the kind of responces to expect from him at this point
gaim
we have signing on with the blist loaded in its entirety pretty much working now. signing off still causes an immedate segfault. we also changed from using a GSList of persons in each group to using a GData and finding a person in a group with quarks (a glib construct, giving a 1:1 mapping between strings (ie the person name, which has to be unique in a given group), and an integer). in the process of making that conversion, we discovered quite a few things we were doing wrong, and got those fixed. the result is that while it still takes some time to load the buddy list on start, signing on happens FAST. very cool. now we just need to regain the ability to sign off ;-), and of course continue moving forward with the code to edit the list. i admit i've been procrastinating on that front; i'm not that great at coding a dialog from scratch and neither is faceprint, and i've been hoping the whole glibc issue in debian so that i could use glade-2 to write the dialog.
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>

20 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!