sjh - mountain biking running linux vegan geek spice

[comp/blosxom] Another change to cache_timestamps for perl 5.10

Tue, 21 Apr 2009 11:28:00

Upgrading this server to lenny I finally have perl 5.10 on the system, this caused a problem with my blosxom plugin cache_timestamps. Using File::Find I previously had a sub routine wanted defined inside a scope with some variables available in that scope. However on upgrading to 5.10 this no longer worked.

It used to be something like this

{
   my (%h1,%h2);
   sub wanted {
      $h1{$File::Find::name} = "someval";
   }
   find (&wanted, "topdir");
}

However when I changed to perl 5.10 though the assignment seemed to work (blosxom runs without -w or use strict enabled) if I tried to display %h1 inside wanted or tried to use it like a hash I got a weird error "Bizarre copy of HASH in refgen" at the line of code I tried to use the variable as a hash. Looking at other uses of File::Find it seems everyone used anonymous subroutines from the call to find. I have changed the code to do the following.

{
   my (%h1,%h2);
   find (sub {
      $h1{$File::Find::name} = "someval";
   }, "topdir");
}

And now the hashes are in scope and not some so called Bizarre copy any more. The code for the cache_timestamps plugin can be found here and details about cache_timestamps are in my comp/blosxom category.

Update: found some details, rather than searching for the error message I started searching for variable scope changes in 5.10. Found this page talking about state variables being available in 5.10 as my variables are not persistent across scope changes.

[comp/blosxom] Why no comments?

Mon, 15 Aug 2005 21:48:00

So Mikal has often pointed out he uses a blog as a place for him to search for stuff or an extended bit of his brain (long term storage with a google interface). He also thinks of blog engines as neat CMS for a website, a good publishing engine. Mikal though also has comments enabled now days, which is more blog centric than a simple website. The idea of a community to make a blog more interesting for people as a whole exists, and appears valid even for sites with a really small readership.

I wonder if the primary reason I have not put comments on here is simply because of my own severe dislike of web forums? A few people have told me in the last few months that comments would be really neat here. Sites like Farkin (Australian Mountain Biking hangout) or most of the more popular blogs (Fafblog or Dooce (on her photos)) have comments and an active community. I personally can not imagine any reason to use Farkin when there is email or other mechanisms, maybe I am just sticking my head in the sand too much.

Like Mikal maybe I should try this comments thing on here some time.

All of this thought was inspired by reading a post about losing blog readers by the Tomato and Cucumber guy.

[comp/blosxom] Broken/Ugly bits on Mikal's site.

Tue, 26 Jul 2005 13:46:00

Well Mikal asked so I may as well respond. Not so much broken but damn wrong looking. Mikal still has broken/messed up css (screenshot). And those new tag things he is doing, putting an image next to the tag text, it looks oh so wrong, especially in an environment like ploa where it stands out all ugly and wrong compared to the rest of the things there. If you must link to two indexing/tag services can you not work out some way to do it without using images. Oh also the tag images render badly in the GTKHTML component (probably not as css compliant as gecko) I use by default with liferea.

Speaking of problems with bloggy web pages, one of the reasons I no longer use planet to read aggregates myself any more happened on ploa again yesterday. Michael Ellerman posted something which included text with tags not properly closed. When this is collected with lots of other posts all the posts below it in the page have a smaller text size. It would be a good idea if planet parsed the posts it includes to see if there are some of the common opening tags with no closing tag, such as bold, italic, font size, etc. No idea how much more that would complicate the planet code to include html parsing capability.

Of course one extremely hacky way to make that look cleaner that comes to mind is for planet to enclose each entry in a table cell, most browsers appear to close font and bold and italic state when table cells end. There may be a way to deuglyfy this stuff in css, after all the rest of Michael Ellerman's blog page is not affected in the same way as ploa.

[comp/blosxom] Andrew it too leet to use a small browser window

Wed, 20 Jul 2005 15:04:00

Actually Mikal I believe people have noticed problems with the css in Andrew's diary in the past.

Below is an email discussion I had with someone last week.

On Wed, Jul 13, 2005 at 09:43:05PM +1000, Some Person wrote:
> Does Andrew Pollock's blog break for you? I can't read it because the
> calendar breaks out of the left column and overwrites the right
> column. I can't see all of the left column (it stops half way through
> your name) and it doesn't scroll because it floats in an absolute
> position.
>
> I've tried firefox, my default browser and it's horrible. It's very
> slightly better in Konqueror and I admit I haven't tried lynx.
>
> Okay, I'm on a 15" CRT at home and I haven't used it on the 19 or the
> 30 inch LCD at work... but still...

On my monitor at work (1280x1024) it looks fine as the calendar is within
the floating left side margin area.

However on my laptop the calendar does indeed float over the text of posts
and make it harder to read, also the bottom of the floating bar is cut off a
bit. My laptop is 1024x768 though I have the browser windows a little
thinner than 1024.

> Do you see it cleanly?

See above

I pointed this out to Andrew about three months ago, he did not seem to care
much either way.

I admit I tend to read most of it in feeds anyway, I generally only load the
website up when I am referring to a post he made in one of my own.

> Anyway, good to see the guys blogging their trip to USAnia. I wish them well.

Indeed, though they still have not blogged a photo of an exotic US milk
carton, bastards...

        See You
            Steve

Of course what Andrew really needs right now is a bunch of idiot geeks applying pressure for him to waste time he probably does not have spare in order to fix something like this.

And yes Mikal you can not really comment with out a black kettle situation arising, after all your entries tend to spread out over/under your google ads and other such annoying things.

[comp/blosxom] Lack of easily available flavours and efficiency

Fri, 15 Jul 2005 22:57:00

Being you common all garden average Linux geek I have all the design capabilities of a brick. This well explains the look and feel of my diary and other sites I put online. Sometimes functional, never pretty. Thus I was quite disappointed when I went hunting a few times for pretty blosxom flavours with css and all the other stuff ready to go looking swish. There really do not appear to be many places to get hold of a wide variety of pre packaged blosxom flavours to look good. There are a fairly large number of flavours to add functionality, such as rss2 and other things, but that is quite different.

Thus when I was setting up WordPress on Calyx for Aaron this afternoon I was really quite impressed at the huge number of different WordPress Themes that are available. For Aaron I chose Ocadia but there really are a lot out there.

The other thing I suspect I will notice with this setup is it will be more efficient than blosxom. Mikal has run into issues trying to run blosxom dynamically, I could well have similar problems as the number of posts here increases. Blosxom is good for the small size and plugin architecture, however it does not run in a particularly effective manner, especially when you have huge numbers of posts, which it looks at in some manner every time it runs.

So long as Aaron does not get hit with loads of comment spam or similar the WordPress setup there will likely not use much resources on the server, partly due to the database back end of course, however I suspect using the php (effectively like using mod_perl with out need to open many files on disk due to the db) will help a lot also.

I keep thinking sing the new Inotify patches RML and others have been getting into the kernel is mighty tempting to make a blosxom style engine more efficient, though that would negate the simplicity and portability somewhat.

[comp/blosxom] Need a new different atom feed generator

Fri, 01 Apr 2005 19:03:00

I noticed some of the timestamps on my diary were messed up. I tracked it down to the time having the first digit in the hour removed from the time. I have not worked out exactly why but the atomfeed plugin I put in place on Wednesday is breaking the times. Mikal did ask my why I did not simply make the atom feeds with a flavour rather than this mechanism. The main reason was this is the thing I found to do it on the blosxom plugin page. For now I have disabled the plugin (so the atom feed link is broken currently) until I find an atom feed flavour I like.

[comp/blosxom] Added some feed formats

Wed, 30 Mar 2005 16:58:00

So for some random unknown reason I added rss 2.0 and atom feeds to my diary today. Mikal seems to think it is a good idea, anyway links are at the top and bottom of the page.

[comp/blosxom] More on plugins

Wed, 02 Feb 2005 18:54:00

Have I mentioned before that Mikal is evil? Ahh good I have. A few days back Mikal wrote his first blosxom plugin to implement technorati tags. Useful though it may be, it is not exactly what I am interested in. So it got me to thinking.

In the same way Tony has been known to put off completing easy action items as they are that easy... I have yet to write the story tag lookup thing the way I want it as it is easy. The technorati tags thing got me thinking of a harder class of problem though.

I notice Movable Type and some other diary software stuff allows entries to be placed in multiple categories. Blosxom gives you the concept of categories by letting you place files in a directory, the directory becomes the category. Blosxom does not easily support placing posts in more than one category.

If I wanted a post to show up in /mtb/gear and /comp/hardware or something (say a gps receiver I use when cycling) I have to choose one. It would be neat if I did not have to choose, but everything else still worked correctly.

Using symlinks or some top level database for the entries subroutine and other stuff may allow you to get some of the functionality, however other plugins are unlikely to work when a fundamental assumption is changed. This is because the posts are placed in a category, the category is not simply an attribute of the post. On my diary on the left I have the categorytree, calendar and flatarchives plugins displaying information. If the entries subroutine returned an entry for every file it found, yet some were symlinks and thus one entry only the calendar and flatarchives plugins would have incorrect counts. However if the entries routine only returns an entry for every real file and ignores extra entries that are only symlinks or a copy of an existing post in a different category the categorytree plugin will fail.

I am thinking of various ways to play with this such that I can keep the simplicity of blosxom (text files in directory structure) but allow multiple categories for a post. As I said Mikal is evil for distracting me once more. Maybe he wont be so evil once he returns from yet another trip to Microsoft headquarters in Seattle next week.

[comp/blosxom] RSS bandwidth usage

Wed, 22 Dec 2004 19:10:00

Mikal is an evil man, writing a blog entry I just had to respond to (with some research and fact checking) and thus using up time... (or I suppose I could simply stop this online diary thing, after all Andrew is of the opinion (possibly accurate) that I am addicted)

Anyway Mikal wondered why the rss standard could not simply add a field suggesting blog update frequency to rss feeds. Ignoring for a moment that rss is a bit of a mess and not really standardised (with rfcs and other such stuff), this suggestion requires clients to implement it properly, and would require all the feed formats (rss 0.9, rss 1, rss 2, atom, etc) to have this sort of functionality. I generally do not trust clients to implement standards properly, and these are not even real standards.

I mentioned to Mikal a recent post I had seen somewhere like BoingBoing about how someone had implemented a nice way to cut off people gobbling too much bandwidth at the server side. A bit of a google search found the entry I recalled seeing. This keeps track of UserAgent/ip, and takes note of feeders that abuse the system (constantly re fetching data they already have, etc), to do this one would need to keep track of this data in some manner which is non trivial and can use memory or disk. Also of course people behind a corporate proxy or firewall and those on roaming proxy's such as AOL subscribers may have problems with this implementation. The implementation discussed only throttles the feeders that abuse (consume more bandwidth than they should) so people using better clients will not be hit.

I have to say I do not particularly like either of the above implementation suggestions, Mikal's suggestion due to the need for compliant implementations and the fact I don't think predicting your update frequency is worth the effort. The server side enforced limiting due to added load and complexity on the server side and due to the limitations of the method. There really is no way to solve this that I can think of that is likely to catch on. What really needs to happen is rsync in the http protocol (rproxy) needs to be adopted in http servers and http clients.

[comp/blosxom] Bug fix in cache_timestamps

Thu, 18 Nov 2004 13:33:00

The cache_timestamps module I wrote (and mentioned earlier) had a bug, when you removed diary entries or moved them around it kept the reference to the old location in the cache and displayed it (with no content in the entry). This has been fixed. New version is available

[comp/blosxom] Cache Time stamps

Thu, 28 Oct 2004 18:44:00

This diary entry is about a new blosxom plugin I wrote, you can find the files related to this here (the files are cache_timestamps (the plugin) and cache_insert_ts.pl (a helper program).

I complained once or twice a while back about time stamp handling in blosxom. My complaints were centred around relying on the timestamp on the file system to work out he date of an entry and the order of all the entries. There are already some plugins that get around this in some manner, such as entries_index by the blosxom author, and entries_index_tagged (not available from the link there, google can find it).

The entries_index plugin keeps a cache of the time stamps of diary entries and uses the time stamps in the cache by preference. It adds time stamps for new files as they are found. This way if the time stamps change at a later date due to an edit or similar the cache retains the old time stamp.

The entries_index_tagged does the same as entries_index and takes it a step further. It allows you to have time stamps in some format in the diary entry header area. Read the code/docs if you want to know the details.

I wanted the capabilities of entries_index_tagged, with a slightly different way to read time stamps from the entries, also using the same format cache as the two already written. This way like entries_index_tagged if the cache is deleted it will still use the saved time stamps in the files rather than the system time stamps when it finds time stamps in the files. The reason I wanted a different format was I had already been adding time stamps to my diary entries since September as an html commented time stamp on the second line of the file (after the heading). For example . Also a few people suggested it would be cool if the plugin had the option to add such a tag to the entries if there was not one using the file system time stamp the first time it sees the file.

So I wrote the module, it works fine for all but adding the time stamps to the entries. The problem here is you need write access to the entries in order to add text to them. Also even with write access the utime(2) system call can not change the time stamp back to what it should be after editing the file unless you also own the file.

Anyway I ended up writing a small helper program that could theoretically be run from cron or similar as the owner to add the files time stamps and reset the mtime. This means you have the functionality even if you do not give write access to your diary entries by the web server uid.

With the add time stamps capability you can rely on the first time stamp being added so even if the file system time stamps get messed up at some point all files will have a time stamp and you need not remember to add one to each entry.

[comp/blosxom] Unable to grok %indexes

Wed, 27 Oct 2004 14:17:00

I am finally writing two blosxom plugins I have wanted to use for a while, none of the existing plugins are exactly what I want. (NIH syndrome possibly)

One of the plugins which creates a new entries sub routine is supposed to return %files and %indexes. Looking at the example code of existing blosxom plugins it is easy enough to work out what %files does, however %indexes is beyond me. Fortunately it is only used with static rendering, so I guess I can just leave a bug in the plugin that it will not work with static rendering.

The documentation for plugin developers is not too helpful, all it says is "The subroutine should return references to a hash of files and another of indexes to be built (in the case of static rendering)." and "When run, the subroutine returns references to the files it found and indexes to be constructed when building statically"

I could of course read the blosxom source (only 444 lines) to work it out, though I do not know if I care enough currently, I don't intend to statically render my blog and this is to scratch my own blog itch.