afuna_archive | Entries tagged with code

Really simple script for you guys today: Support: Summary in Title.

That appends the the request summary into the window title which lets you the request summary show up in your browser history. Meaning, you can just type in a partially remembered request summary in your browser address bar, and it'll (hopefully) pop up the URL to the request you're thinking of.

Works on Dreamwidth and LiveJournal. (Note that it may be conflicting with some other scripts? I had to drag it to the beginning of my list in the Greasemonkey settings for it to work on LiveJournal)

My morning was nicely cheered, seeing this entry in

changelog:

Fixing thread expansion on Safari.

(DW got a shoutout! As did I! And issue got fixed, hooray!)

Current Mood: chipper

For instance:


    foreach var string module ( $*modules_available ) {
        # FIXME: get the values in less hacky manner
        var string section = get_plural_phrase( 0, "module_${module}_section" );
        var int order = int(get_plural_phrase( 0, "module_${module}_order" ));

        $*module_sections{$section}[$order]=[$module];
    }

(but I should probably not let something like that creep into core. Long list of if-statements, it is.)

(Originally posted to Dreamwidth http://afuna.dreamwidth.org/6673.html)

Current Mood: geeky

Three new scripts. Wrote them late last year, never got around to publishing them:

LiveJournal Default Memory Security
Set a default initial security when creating new memories.

LiveJournal Rage Goggles
Inspired by Google's Mail Goggles, this script makes you solve a math problem, before you post that comment you know you're going to regret later. "Rage-goggled" ljuser-head shows up in the comment form to indicate that the script is active. Click on it for options: you can whitelist a journal temporarily or permanently.

LiveJournal Track from Navbar
Adds a convenience link to the navbar, pointing to the track this journal's entries page.

As always, the rest of my scripts can be found on my site.

One thing that has frustrated me about interacting with LiveJournal programmatically, is that ?format=light does not work on all pages. It's not really something that affects most users would notice, but certain (Greasemonkey) scripts would be much much easier to write if the entry/journal pages could be guaranteed to follow the same format.

Mostly I've kludged around it by working off of the archive pages, which respond to ?format=light, so I could get data consistently. I have a script which scrapes the lj-cut text, so it can be seen in the inbox which does this.

murklins has done me one better, with a script which lj-cuts your inbox, like the entry text. I do not know how I ever lived without this. Lifesaver. Adore, love. Seriously.

But for other pages, it's been a process of trial and error, trying to figure out whether ?format=light is supported (tag page supports it, showing a page based on s1shortcomings). Uh. Archive pages, as mentioned above. Reply pages and entry pages, obviously, using core, I think.

Not affected by ?format=light are friends and recent entries. LJ site scheme pages, meanwhile depend on the user's site scheme, unless you append ?usescheme=blah, which I always forget to /o\

It's all possible, but it can get messy depending on what you're trying to do. Which is why I love that LJ offers a mobile view. Love <3

The gist of it is that LiveJournal offers a minimalistic view for mobile phones/browsers (I suspect screenreaders could benefit). No header graphics, less junk overall, more consistent look/feel, and most importantly if you're hijacking it for scripting, it works consistently! To trigger, you need to supply the appropriate user agent:

GM_xmlhttpRequest({
   method: "GET",
   headers: {"User-Agent":"w"},
   url: $url_here,
   onload: function(details) {
       // do something with details.responseText
   });

The important part is the useragent line. The rest is just the normal stuff you need to fetch and process a page.

I haven't used it in an actual script. And since I don't play around with LJ much anymore, I'm not sure when I will. But it is a potential solution to what has up to now been a tedious problem.

Not the inside-inside, Perl guts, but trying to update all (DW) layout layers, to get all the updated features!

Long-term goal (actually, medium-term, because once the site goes live, everything needs to be stable, so I won't be able to do any drastic changes) is to turn this layout/feature chart entirely green. I know it's not possible; I can at least try what is reasonable.

~~One~~ The hard thing about developing with S2 "officially" is that the quickest (only?) way to get feedback on your changes is to apply the layout to your journal, use the S2 compiler (layeredit.bml), apply changes, check journal, rinse repeat. However, then you have to copy the updated layer to bin/upgrading/s2layers. I've found that last step error-prone: tedious to pick out the changes bit by bit and transfer them manually. If I try to replace the entire layer in one go, I find that I have a hard time copy-pasting more than a screenful in vi (hm, have I ever tried just truncating the file and then pasting everything into a blank file? I don't think I have. Maybe I should do have tried that before trying to work around it).

So, anyway! Perl script! You give it the name of the layout. It reads the updated version which is currently "live" (on your dev site ~~need to set the base URL; localhost works fine~~ reads from ljconfig.pl). It then updates the static file in bin/upgrading/s2layers. After that, just need to do cvsreport.pl or hg diff or svn diff or commit or whatever. I've stuck in my ~/bin, so I can run it from anywhere, which is pretty convenient:

http://afunamatata.com/scripts/dreamwidth/s2sync.old

(This assumes that $LJHOME is set properly, and live versus cvs directories are in their normal LJ-setup locations, though this is really more for DW, since it overwrites bin/upgrading in DW-free)

( Sample in action )

At some point, I may find it useful to modify it so that it accepts and upgrades multiple layouts (and themes??), but too much trouble to do so now, since I'm not touching themes at all.

And hopefully this will make development that much easier :) I was dreading keeping my live layout versus my diff-able layout in sync, but I am looking forward to coding this weekend now.

Update

exor674 just came up with a much prettier version <3 http://pastebin.com/f2fc673b3

I'm appropriating it for my own use.

Update2
Slightly tweaked version here: http://afunamatata.com/scripts/dreamwidth/s2sync!

(Basically, sanity check to make sure it's a layout layer, and also put the output directory into a variable, so that people who want to stick it straight into live instead of under cvs/ can change just the one line)

It now accepts either layer id (as a number), or layout name or redist_uniq, so either of these will work:

$ s2sync 333
$ s2sync bob/layout
$ s2sync bob

Also, output slightly changed:

dh-afuna@li-166:~/dw/cvs/dw-free$ s2sync 336
Can only handle layout layers at /dreamhack/8080-afuna/bin/s2sync line 33.
dh-afuna@li-166:~/dw/cvs/dw-free$ s2sync 333
bob/layout written to /dreamhack/8080-afuna/dw/cvs/dw-free/bin/upgrading/s2layers/bob/layout.s2

Current Mood: geeky

Damn. PHP also uses @$. First thing I thought when I saw it was, "Oh neat, it's dereferencing an array reference." Then I realized a) the variable on the LHS wasn't an array, and b) I was in the wrong language.

(It's used for error control instead, which is also neat in its own way, I guess.)

Current Mood: confused

I forgot that certain characters under certain conditions will cause parts of a word to be expanded as a variable in Perl. (In other words, my password was wrong because a portion of it was being recognized as a variable "$xyz", which was blank ;))

*whistles innocently*

The original twitter2lj.pl script is barely recognizable, as I had to redo the feed fetching, parsing, authentication, time(zone) handling, and posting to LJ. However! The HTML format of the output remains (mostly) the same.

Had to rework the feed-fetching-related stuff because the RSS feed has too few items (only 20). The archives XML file, which gives 80 items at a time, is in XML, but not RSS. They require different approaches to authentication as well. I feel a bit guilty about fetching directly from the archives instead of from latest items, but I only do it once a day, so it seems reasonable enough.

Given the problem with the password, the authentication for my RSS feed probably never worked. I just didn't notice it, because authenticating on that feed had no effect, given my settings!

For some reason, @lj_tags = ["tweets"]; was parsed as "array(0xblah)" when posted $lj->Setprop_taglist (in LJ::Simple). However, using @lj_tags = qw(tweets); works. As does using LJ::Simple::QuickPost. It's likely I've misunderstood something about the way lists work in Perl.
ETA: Ciaran has explained it to me :)
( [] indicates an array reference. I got that first line from the original code, which uses QuickPost, which expects an array reference, so it worked for that, but not when I switched to Setprop_taglist. Refreshing my memory about scalars vs lists vs references now *g*)

Now that it works, I have to resist the urge to redo it to optionally use JSON instead of XML (for the sake of those who had trouble installing the XML::Parser, since that would only affect a few people, and of those few people, I'm probably the only one who wants to do Twitter->LJ via this script). I also have to resist the urge to add options to grab other things available via the Twitter API.

So yay, my Twitter stuff archived here: http://afuna.livejournal.com/tag/tweets (backdated so that it doesn't double-spam, forchrissake).

<3

aveleh,

murklins,

ciaran_h for bearing with my babbling over IM (while I tried to figure out how to best tweak certain things *g*)

Back in January, I realized that you could probably figure out which individual tags filter you were viewing by using the (newly-added) parameter to each Userlite data_link:

3:09 AM me: hm
3:10 AM me: ma thinking of s2 at the moment
does this entry : http://community.livejournal.com/changelog/4356263.html mean that we can determine what tagspage we're on by checking the data link?
3:13 AM murklins: Looks like, but how do you check the data link?
3:14 AM me: Page has a hash of data links

I meant to play around with it, so I posted about it to remind myself, and then promptly forgot.

Then in May,

murklins(<3) needed to customize certain tags views, and reminded me about my idea:

12:51 AM murklins: Hey, this is how we find out if we're on a tags subset of the recent entries page right?
if ((size $this.data_links_order) > 0) {
  if ($this.data_link{"rss"}) {
    var Link dlink = $this.data_link{"rss"};
    if ($dlink.url->contains("?tag=")) {
      print "A Tags Page";
    }
  }
}
12:55 AM me: hee
I don't know :)
I don't tihnk I've ever seen that before
though the concept seems familiar, but my mind might be playing tricks on me
12:56 AM murklins: Oh, it was your idea! :)

And I remembered that I'd had that idea before, and decided to do something with it some day. (And then promptly forgot about it again.)

Then someone made an entry in

s2flexisquares asking whether it was possible to hide a sticky post when filtered by tags. And I was happy that I'd finally have a chance to play with the idea (almost a year after I first thought of it), so I wrote code and replied with it. Then she asked me whether it would be possible to make it so that you could show the sticky post only for certain tags, and after shaking off some rust I came up with this code.

It could be more flexible -- right now it won't work if you filter by multiple tags, but it's good enough, and I'm not crazy enough to try implementing a join/split function in S2.

(What if I made the tags an array instead of a hash? That would make it easier to input tag names -- ["tag1", "tag2"] instead of {"tag1"=>true, "tag2"=>true}, and it's unlikely that the list of tags this is used on would be long enough to affect performance either way.)

Other possibilities are to change colors or images depending on the tag that you're filtering by, or to change the behavior of entries with certain tags (for example, only show summaries for fic-related tags). And others! If you were motivated enough, you could make subtle changes to your layout for each tag you have. I'm not that motivated. :-)

Current Mood: accomplished

Abby, I'm making this for you (though anyone else can join in if they want). Post new script suggestions, ideas for improving current scripts, and bug reports here. Take a look at ~~my current Greasemonkey scripts~~ my current Greasemonkey scripts, and see if you think of anything!

(Poor man's tracker, ahaha)

Current Mood: working

The support requests status tracker script used to hang at around 300 total requests modified (or once around a hundred requests moved off the board.) Today, it processed "525 updated and 483 moved off this view for a total of 1008 requests changed" in an instant.

The changes I made to the code have worked out much better than I ever planned :-) Of course, the real problem was that earlier versions of the code were complete and utter crap. See, I made a couple of ( embarrassing rookie mistakes with arrays and string handling )

Note: pseudocode is because I'm too lazy to remember how I actually coded it in old versions. Real code is because I'm too lazy to figure out how to convert my current code to pseudocode.

Current Mood: geeky

The lack of sleep has been getting to me, and it's been making my dreams weird. So I shared a brief snippet of a dream with a friend:

<Afuna> earrlier I had a dream where I was debuginging, and the problem/solution was that it did not have any undernwear
( cut for typos, code, mention of underwear, and mention of underwear in code )

Current Mood: geeky

In case anyone wants to comment on the script but doesn't feel comfortable doing so on us.o, here is a good place. I'm assuming that anyone who wants to use that script has an LJ account, since the script itself is made to work with LJ!

---

Because it seems fitting, here's a script (not written by me!) which restores the appearance and formatting of the old update.bml page.

Also, I've finally posted the script to add a tagslist to update.bml. There's an easter egg in there of a sorts -- didn't bother to remove my uglification code, but it can't be activated unless you know the exact steps.

Ah, the stupid thing is that my script is not compatible with the first one, so unless someone (else) is willing to figure out how to fix that, you'll have to choose one or the other.

The information below is outdated; most updated info is in the script itself and probably also in the extended description over at us.o.
( Rough docu for my script. This text is also found within the script itself )