grimsniffer: (Default)
I just found out (month late, I know) that the new linux kernel FINALLY includes 3D support for my graphics driver.
Maybe I'll soon get a chance to actually gauge the full performance of my laptop for the first time.
I can't be arsed to compile it on my own, because out of previous experience, a custom kernel tends to wreck havoc through Kubuntu update - and I can't be arsed to make maintaining my home PC a full time job. So I just prefer to let the Kubuntu update do its thing every few months (I know I've complained about this very updater in a previous post - I suppose laziness comes before forethought and practicality).
A little bit of reading showed that the new Kubuntu 10.04, codenamed Lucid Lynx (I seriously can't wait for when they rollback through the alphabet and reach the letter F...) will include this new Kernel. Well, just four more months to wait.

In other news - I finally tackled bug-2075 completely. It was one of those "I keep thinking I'm done, but then discover this weird scenario which forces me to rewrite everything". Like bug-2169, this one also required quite a bit of code-rewriting.
I haven't submitted a patch yet because I need to clean up the code (quite some rewriting was done, as I said)... Will get 'round to it tonight, I hope.
New stuff this does:
* Changing the email you get when you send a copy to yourself to "You sent [[username]] a message" (it used to be "[[your username]] sent [[your username]] a message").
* Changed the corresponding email body text to link to the profile, journal, etc. of the person you sent the message *to*.
* Changed the subject of the copy message itself in your DW mailbox to include a preceding "Copy of: " - just to make things more clear.
* Added limited support to sending a copy of a message you sent to multiple recipients... I wanted to add full support (stuff like you getting an email saying "You sent X, Y and Z a message on Dreamwidth", but because of the way compose.bml is written, it would have required considerable rewriting... and since it was just a "nice to have" extra thing and not mentioned in the bug requirements, I wrote that off as something to do at another time.

I've got another minor bug assigned to me. Hope to solve that rather quickly, and then will start working on the HTTPS browsing mode feature.
grimsniffer: (pic#377996)
Well, just a brief post in the "I hope someone finds this helpful" category.
I'm using Vi (or more accurately Vim) to edit code on DW. And in the past few weeks of doing so I've added some dw-specific tweaks to my .exrc file beyond the usual spam that's there. So here they are, in case anyone else wants to use them:


# To adhere to the programming guidelines, tab size and spaces as tabs.
set tabstop=4
set shiftwidth=4

# Just for convenience's sake. Not really DW specific but some DW Vi stuff depends on it.
syntax enable
set cindent
color delek

# Getting Vim to recognize bml files as perl files for purposes of syntax highlighting.
filetype on
au BufNewFile,BufRead *.bml set filetype=perl


grimsniffer: (Default)
Excerpt from a conversation I had at the workplace (exact details aren't provided for reasons of NDA):

System Architect: The frames are filtered into several different categories, each category having its own set of parameters which tell the device how to treat packets from that category. We then--
Me (Application Integration): Wait, what did you say they were filtered by?
SA: This parameter.
Me: But this parameter is one of the parameters in the category they are filtered TO...
SA: Yes.
Me: Well, if they're labeled by the initial filter as members of one category and then the category parameters label them a second time, we can have a situation where frames are labeled as members of a category which the very same category denies they are members of. We could also have a situation where frames are labeled as members of just one category, while three categories see them as members.
SA: I don't see a problem with that.
Me: ...
SA: Well, the user will simply have to be careful not to create such a situation.
Me: facedesks


In other news, I say this a lot (especially to myself), but I'm nearly done with bug-2169. It was somewhat challenging at several places, especially figuring Storable out (thanks [personal profile] afuna!), but if nothing unexpected happens - right now it's just doing some writing (I almost wrote "finger work" but then thought better of it :) ), and cleaning up the code. So we should have (better) draft support soon, yay!

Up next is the HTTPs browsing bug. Though I might want to take a short hiatus with some minor bugs, because this last one has taken quite some work all in all, and the HTTPs one likely won't take any less.
grimsniffer: (Default)
Well, bug-154 is currently fixed and waiting for a review and eventually a commit. My fix seems to pass all scenarios I can think of, but with me not yet knowing the Dreamwidth site very well, I won't be surprised if it has to be edited a little.
The bug involved the "Reply" and "Thread from Start" links not appearing in comments that are opened in new pages (having the ?replyto argument).

The core2.s2 file has a print_interaction_links() function that's in-charge of printing the interaction links to entry and reply comments (Those Link/Reply/Thread From Start etc.) comments you see under each post and entry you read.
This function had a conditional that would display the "Parent" and "Thread from Start" links only if their values were not null in the hashref passed to said function by ReplyPage.pm. So then it was just a matter of going to ReplyPage.pm, finding the hash and adding the relevant values. For some reason (which still escapes me) the hash-ref wouldn't accept variables declared earlier in ReplyPage.pm, even if they were in the same scope as it is. Meaning I couldn't use the various objects already declared creating the comment itself. So I basically had to declare these values in the hashref by creating a comment object out of the dtalkid I already had, and assigning its parent_url() return value to the value in the hashref (or the threadroot_url() return value, to the threadroot_url value in the hashref). This passed it all to print_interaction_links() in core2.s2 and voila! All works. Tested it in quite a few scenarios (comments of entries, comments of comments, entries as parents, heavily nested comments, different themes, etc.), and it seemed to work well. Let's see if someone manages to find something I've missed.

I was planning on publishing a proper walkthrough (and crosspost it to [site community profile] dw_dev_training), detailing my work process in solving this bug - but since this was my first bug working on Dreamwidth, the learning process was rather complicated. Took me about a week on-and-off to figure it out, and I'm not sure I can recreate all the phases I went through. I'll take a look at my notes in the coming days and see if I can glean the proper workflow (or at least the major parts of it).

Now starting work on bug-2208. Hopefully it won't take me as long.

Bug-154

Dec. 9th, 2009 08:09 am
grimsniffer: (Default)
Well, I'm currently working on bug-154. I plan on posting a full walkthrough when I'm done... but for now I'm still banging my head against it.
It seemed at first like a rather trivial thing, but after a few nights of work, and quite a few hours of sleep lost over it, I learned better.
Yesterday evening I managed to find where the ?replyto pages are generated, or at least I think I did. At the time of this writing I'm pretty convinced they're created through talkpost.bml, passing the 'replyto' argument to the $init variable (I'm not by my private server, so can't really be sure what this variable points at, but it should be easy enough to find out).

I think it's mostly taking me so long because looking for stuff in the DW code is a rather messy process with which I'm not yet fully familiar - and talkpost.bml specifically is a monstrosity beyond words. I'm told it's going to be overhauled, or better yet - completely replaced - soon.
Just before I went to sleep, I decided to do a CVS update - mostly to clean all the debugging crap I've been putting in the code through my attempts to try and figure stuff out. But the hour was late, and I wasn't thinking straight - so I ended up vanila-ing my server. Shouldn't be too hard to fix, but I definitely took that as a "time to go to bed" sign.
Lesson learned: don't do major codehack steps when you're not fully awake. Or well - who am I kidding, lesson-not-learned-for-the-hundredth-time.

I'll keep at it during the weekend, hopefully I'll make some progress.

After I get it done (and post the walkthrough), I plan on posting a tutorial here regarding my torrent downloading setup at home (rtorrent+GNU Screen+a perl Email fetching and parsing script).
For now though, after I got this out of my system - back to the stuff they pay me for: delving through IGMP and OMCI.

Profile

grimsniffer: (Default)
grimsniffer

February 2010

S M T W T F S
 123456
78910111213
14151617181920
2122 2324 252627
28      

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags