pyblosxom-users

[pyblosxom-users] hardcoding mtimes for stories in their metadata section

[Dieter P. <di...@pl...>]

Hi all,
is it possible to hardcode the mtime for a story in its metadata
section?
I.e. something like:

$ cat entries/post.txt
Title of the post
# mtime 2010-10-30 12:00:00
hello, (..)


I think these plugins are not appropriate for me: 
- "wrapper scripts" that change the mtime back to what
it was before editing (not very robust if you work on multiple systems)
- plugins who cache the mtime (I want to dictate what the mtime must
be, which is more robust)
- pyfilenamemtime, the plugin who stores the mtime as part of the
  filename is pretty close, but makes filenames messy, and I don't want
  to rename the file in my vcs just to change the date
- the w3cdate plugin is also interesting, it seems to be close to what I
  want, but it creates a new variable instead of updating the mtime.
  What's the point of that?

I think I will write a fork of the pyfilenamemtime plugin which uses
the metadata section instead of the filename.
Or am I missing something?

Dieter

Re: [pyblosxom-users] hardcoding mtimes for stories in their metadata section

[will kahn-g. <wi...@bl...>]

w3cdate adds a variable to the story plugin.  I don't know offhand if
that's needed anymore--I think PyBlosxom adds it on its own now.  That's
definitely not what you're looking for.

pyfilenamemtime is probably the closest.  The advantage of putting the
mtime in the filename is that it can be picked up from os.listdir rather
than forcing PyBlosxom to open, read, and parse every entry on your blog
for the metadata.  If you did something like pyfilenamemtime but instead
store the mtime in the metadata, I encourage you to add some caching so
that PyBlosxom doesn't have to open, read, and parse every entry in your
blog to assemble all the files and mtimes to sort and display in a blog
timeline.  I think something along the lines of what I do in tags would
work.

/will


On 11/01/2010 07:13 AM, Dieter Plaetinck wrote:
> Hi all,
> is it possible to hardcode the mtime for a story in its metadata
> section?
> I.e. something like:
> 
> $ cat entries/post.txt
> Title of the post
> # mtime 2010-10-30 12:00:00
> hello, (..)
> 
> 
> I think these plugins are not appropriate for me: 
> - "wrapper scripts" that change the mtime back to what
> it was before editing (not very robust if you work on multiple systems)
> - plugins who cache the mtime (I want to dictate what the mtime must
> be, which is more robust)
> - pyfilenamemtime, the plugin who stores the mtime as part of the
>   filename is pretty close, but makes filenames messy, and I don't want
>   to rename the file in my vcs just to change the date
> - the w3cdate plugin is also interesting, it seems to be close to what I
>   want, but it creates a new variable instead of updating the mtime.
>   What's the point of that?
> 
> I think I will write a fork of the pyfilenamemtime plugin which uses
> the metadata section instead of the filename.
> Or am I missing something?
> 
> Dieter
> 
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> pyblosxom-users mailing list
> pyb...@li...
> https://lists.sourceforge.net/lists/listinfo/pyblosxom-users
> 

Re: [pyblosxom-users] hardcoding mtimes for stories in their metadata section

[Tim G. <tg...@pr...>]

On Nov 01, 2010 at 12:13 PM +0100, Dieter Plaetinck wrote:
> Hi all,
> is it possible to hardcode the mtime for a story in its metadata
> section?

I wrote a nasty plugin that does this.  At this point, there is no caching 
and the code isn't exactly clean, but it does work.

Re: [pyblosxom-users] hardcoding mtimes for stories in their metadata section

[Dieter P. <di...@pl...>]

On Mon, 1 Nov 2010 08:55:41 -0400
Tim Gray <tg...@pr...> wrote:

> On Nov 01, 2010 at 12:13 PM +0100, Dieter Plaetinck wrote:
> > Hi all,
> > is it possible to hardcode the mtime for a story in its metadata
> > section?
> 
> I wrote a nasty plugin that does this.  At this point, there is no
> caching and the code isn't exactly clean, but it does work.

Aha, i thought I found such a thing at some point, but couldn't find it
back.
Where is this plugin?  I'll try it out, not too worried about the
performance hit right now, but if it becomes noticeable I can always add
caching.

Dieter

Re: [pyblosxom-users] hardcoding mtimes for stories in their metadata section

[Tim G. <tg...@pr...>]

On Nov 01, 2010 at 02:23 PM +0100, Dieter Plaetinck wrote:
> Aha, i thought I found such a thing at some point, but couldn't find it
> back.
> Where is this plugin?  I'll try it out, not too worried about the
> performance hit right now, but if it becomes noticeable I can always add
> caching.

Yeah it's on my huge list of things to do: add caching.  I'm using this on a 
site with about 450 posts right now though and don't notice too big of a 
performance hit.

Here's a link to it:
<http://dl.dropbox.com/u/100367/pymetatime.py>

Re: [pyblosxom-users] hardcoding mtimes for stories in their metadata section

[Dieter P. <di...@pl...>]

On Mon, 1 Nov 2010 09:56:02 -0400
Tim Gray <tg...@pr...> wrote:

> On Nov 01, 2010 at 02:23 PM +0100, Dieter Plaetinck wrote:
> > Aha, i thought I found such a thing at some point, but couldn't
> > find it back.
> > Where is this plugin?  I'll try it out, not too worried about the
> > performance hit right now, but if it becomes noticeable I can
> > always add caching.
> 
> Yeah it's on my huge list of things to do: add caching.  I'm using
> this on a site with about 450 posts right now though and don't notice
> too big of a performance hit.
> 
> Here's a link to it:
> <http://dl.dropbox.com/u/100367/pymetatime.py>

Thanks, this is actually another plugin then the one I was looking for.
I remember seeing a plugin like this somewhere but it had a comment
somewhere noting that "this is not very efficient, we need to read the
file in this step and pyblosxom will read the file itself as well, but
that's how it works now, so..." or something like that

Anyway I'll try out your plugin.
Notice that both the description for cb_prepare as well as the big
comment block on top of your file imply that they reset/ignore mtime
first, and then update using the info from the metadata.  This is not
correct, from looking at the code it seems that the pubdate can
override the mtime, but the mtime is not discarded if there is no
pubdate.

Dieter

Re: [pyblosxom-users] hardcoding mtimes for stories in their metadata section

[Tim G. <tg...@pr...>]

On Nov 01, 2010 at 03:11 PM +0100, Dieter Plaetinck wrote:
> Thanks, this is actually another plugin then the one I was looking for.

Yeah I wrote this from scratch the other month.

> Notice that both the description for cb_prepare as well as the big
> comment block on top of your file imply that they reset/ignore mtime
> first, and then update using the info from the metadata.  This is not
> correct, from looking at the code it seems that the pubdate can
> override the mtime, but the mtime is not discarded if there is no
> pubdate.

That is correct.  If there is not pubdate/pubtime, then the file's mtime is 
used.  If I recall correctly, the if those variables aren't set in the post 
file, $(pubtime), $(pubdate), $(displaytime), and $(displaydate) are all 
populated by the file's mtime, so you can use the same set of templates and 
mix files with hardcoded dates and files with mtime encoded dates.

I think cb_prepare's comment reflects that fact that during the cb_sortlist 
loop (which occurs before), a file's pubtime is set according to the mtime 
if #pubtime/#pubdate doesn't exist.  So once you get to cb_prepare, we DO 
ignore file's actual mtime - it's already been taking into account.

Re: [pyblosxom-users] hardcoding mtimes for stories in their metadata section

[Dieter P. <di...@pl...>]

On Mon, 1 Nov 2010 10:21:14 -0400
Tim Gray <tg...@pr...> wrote:

> On Nov 01, 2010 at 03:11 PM +0100, Dieter Plaetinck wrote:
> > Thanks, this is actually another plugin then the one I was looking
> > for.
> 
> Yeah I wrote this from scratch the other month.
> 
> > Notice that both the description for cb_prepare as well as the big
> > comment block on top of your file imply that they reset/ignore mtime
> > first, and then update using the info from the metadata.  This is
> > not correct, from looking at the code it seems that the pubdate can
> > override the mtime, but the mtime is not discarded if there is no
> > pubdate.
> 
> That is correct.  If there is not pubdate/pubtime, then the file's
> mtime is used.  If I recall correctly, the if those variables aren't
> set in the post file, $(pubtime), $(pubdate), $(displaytime), and
> $(displaydate) are all populated by the file's mtime, so you can use
> the same set of templates and mix files with hardcoded dates and
> files with mtime encoded dates.
> 
> I think cb_prepare's comment reflects that fact that during the
> cb_sortlist loop (which occurs before), a file's pubtime is set
> according to the mtime if #pubtime/#pubdate doesn't exist.  So once
> you get to cb_prepare, we DO ignore file's actual mtime - it's
> already been taking into account.

hmmm.. okay.
anyway, just tried your plugin, and it seems to works nicely.
What would be pretty cool, is if the pubdate is in the future, don't
show the story.  this would allow me to time precisely when i want to
publish a story at some point in the future.

Dieter

Re: [pyblosxom-users] hardcoding mtimes for stories in their metadata section

[Tim G. <tg...@pr...>]

On Nov 01, 2010 at 03:32 PM +0100, Dieter Plaetinck wrote:
> What would be pretty cool, is if the pubdate is in the future, don't
> show the story.  this would allow me to time precisely when i want to
> publish a story at some point in the future.

That would be convenient.  It's probably easily done by looping through 
entrylist at some point and comparing the current time to the post's time. 
If the post's time is later than the current time, remove it from entrylist.

I'm not sure which cb_xxxxx would be best suited for this.  I would think it 
should be done in a function that actually returns entrylist.  cb_sortlist 
would probably work nicely.  I'd add the check right before entrylist is 
reconstructed from entrylist2 in my plugin.

Re: [pyblosxom-users] hardcoding mtimes for stories in their metadata section

[seanh <sn...@gm...>]

On Mon, Nov 01, 2010 at 12:13:26PM +0100, Dieter Plaetinck wrote:
> Hi all,
> is it possible to hardcode the mtime for a story in its metadata
> section?
> I.e. something like:
> 
> $ cat entries/post.txt
> Title of the post
> # mtime 2010-10-30 12:00:00
> hello, (..)


My metadate plugin does exactly that:

http://github.com/seanh/PyBlosxom-metadate

I did ask for it to be put in the plugin registry ages ago. Looking at
the code now, I do wonder if there is a shorter way to implement it,
without all that code for parsing entry files (which obviously
duplicates code that exists somewhere in pyblosxom itself).

Re: [pyblosxom-users] hardcoding mtimes for stories in their metadata section

[Dieter P. <di...@pl...>]

On Mon, 1 Nov 2010 19:49:23 +0000
seanh <sn...@gm...> wrote:

> On Mon, Nov 01, 2010 at 12:13:26PM +0100, Dieter Plaetinck wrote:
> > Hi all,
> > is it possible to hardcode the mtime for a story in its metadata
> > section?
> > I.e. something like:
> > 
> > $ cat entries/post.txt
> > Title of the post
> > # mtime 2010-10-30 12:00:00
> > hello, (..)
> 
> 
> My metadate plugin does exactly that:
> 
> http://github.com/seanh/PyBlosxom-metadate
> 
> I did ask for it to be put in the plugin registry ages ago. Looking at
> the code now, I do wonder if there is a shorter way to implement it,
> without all that code for parsing entry files (which obviously
> duplicates code that exists somewhere in pyblosxom itself).
> 

Your plugin does more then i need :)
I use Tim's plugin which is noticeably simpler/shorter and seems
to do everything I need.

Dieter