pyblosxom-devel — Development Mailing List for pyblosxom

Re: [Pyblosxom-devel] Installing plugins

[Will Kahn-G. <wi...@bl...>]

There really isn't a "new" method.  The only thing that changed last week 
is that a bunch of plugins are now in the Pyblosxom.plugins package. 
Because of that, they're already on sys.path and you can just refer to 
them as "Pyblosxom.plugins.xyz" without specifying additional directories 
in your plugin_dirs.

Thus, to use comments with what's in git master, you can do:

py["plugin_dirs"] = []
py["load_plugins"] = ["Pyblosxom.plugins.comments"]


The things you've done in your plugin_dirs in this case won't help, but 
probably won't hinder you either.

Why do you think this isn't loading plugins?  What did you do to see if 
the plugins were being loaded or not?

/will


On Wed, 9 Nov 2011, Akai wrote:
> 
> Hi everyone,
>
> Sorry to be bugging you guys..
> I can't manage to install any plugins
> I tried the "new" method from the WHATSNEW file and the old ones from
> the other docs
> some of my attempts:
>
> py["load_plugins"] = ["Pyblosxom.plugins.comments"]
> py["plugin_dirs"] = [os.path.join(blogdir,
> "plugins"),"/home/sites/bloxblog/Pyblosxom/plugins"]
> etc..
>
> I'm running the current GIT head version if that helps, using CGI
> rendering (though I tried Paste as well)
>
> -Akai
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Pyblosxom-devel mailing list
> Pyb...@li...
> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel
>

[Pyblosxom-devel] Installing plugins

[Akai <ope...@gm...>]

Hi everyone,

Sorry to be bugging you guys..
I can't manage to install any plugins
I tried the "new" method from the WHATSNEW file and the old ones from
the other docs
some of my attempts:

py["load_plugins"] = ["Pyblosxom.plugins.comments"]
py["plugin_dirs"] = [os.path.join(blogdir,
"plugins"),"/home/sites/bloxblog/Pyblosxom/plugins"]
etc..

I'm running the current GIT head version if that helps, using CGI
rendering (though I tried Paste as well)

-Akai

[Pyblosxom-devel] merged 34-plugins into master

[Will Kahn-G. <wi...@bl...>]

I just merged the 34-plugins branch into master.  It seems fine.  I could 
use more help testing it, though.  I've made a lot of structural changes 
and updated the code for a lot of the plugins.

If you have 10 minutes today or tomorrow, helping me test would help a 
lot.

/will

[Pyblosxom-devel] nixed two mailing lists

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

I nixed the pyblosxom-checkins list (we haven't used it in years) and
the pyblosxom-announce list.  In retrospect, I should have said
something on each list before nixing it, but it's too late for that now.

That leaves us with two lists: pyblosxom-users and pyblosxom-devel.  I
think that's good for now.

/will

[Pyblosxom-devel] things i need your help with

[Will Kahn-G. <wi...@bl...>]

Hi all!

I did a bunch of pyblosxom docs work over the last few days while I had no 
power through judicious use of battery life on my laptop.  I'm feeling 
pretty good about doing a 1.5 final release soon.  However, I really need 
some help with some things:

1. I did a massive overhaul of plugins and documentation in the 34-plugins 
branch that needs testing and a second set of eyes.

Anyone who is interested in helping on this, just grab the 34-plugins 
branch and start testing and reading through the docs.

2. I need someone to do whatever it is you do with Freenode stuff to get 
the #pyblosxom channel registered so that we can get ops on it and change 
the topic and all that jazz.

We only need one person to do this, so if someone is interested, let me 
know.

3. I need someone to triage bugs in the bug tracker.  There are a bunch of 
bugs, some have been targeted at various milestones, but I don't really 
have a good sense of where things are at, what really needs to be in 1.5, 
what can be deferred and what's already done or isn't applicable any more.

If someone is interested in helping on this, go for it.  If you feel 
uncertain about making decisions, feel free to ping me on IRC with 
questions.  It's helpful to even just look at the issues you've created 
and bump them with current status.


Anyone who does anything, please reply to the list and let us know what 
you accomplished so that we can thank you and sing your praises!

That's it for now!  It's not glamorous work, but I really need the help 
moving through these things, otherwise Pyblosxom will continue at a 
glacial pace.  I really want to get 1.5 out the door--it's a _HUGE_ 
improvement over 1.4 and it'll make everyone's lives so much easier.

/will

Re: [Pyblosxom-devel] packages and projects

[Will Kahn-G. <wi...@bl...>]

Ok!  I'm going to go for the name change.


On Wed, 19 Oct 2011, Sebastian Spaeth wrote:
> 
> On Tue, 18 Oct 2011 21:16:58 -0400 (EDT), Will Kahn-Greene wrote:
>> 1. Change the name of the project from PyBlosxom to Pyblosxom.  Camel case
>> is so 90s anyhow.  This makes the package the same as the project name.
>
>> 2. Change the name of the package from Pyblosxom to pyblosxom or
>> PyBlosxom.  This is a ton of pain because it means all plugins have to
>> change.
>
>> Because I'm pain-averse these days, I'm inclined to go with option 1 and
>> change the name of the project to Pyblosxom.
>
> While #2 looks cleaner to me, I can feel the pain, and I'd say #1 is
> fine.
>
> Sebastian
>

Re: [Pyblosxom-devel] packages and projects

[Sebastian S. <Seb...@SS...>]

On Tue, 18 Oct 2011 21:16:58 -0400 (EDT), Will Kahn-Greene wrote:
> 1. Change the name of the project from PyBlosxom to Pyblosxom.  Camel case 
> is so 90s anyhow.  This makes the package the same as the project name.

> 2. Change the name of the package from Pyblosxom to pyblosxom or 
> PyBlosxom.  This is a ton of pain because it means all plugins have to 
> change.

> Because I'm pain-averse these days, I'm inclined to go with option 1 and 
> change the name of the project to Pyblosxom.

While #2 looks cleaner to me, I can feel the pain, and I'd say #1 is
fine.

Sebastian

[Pyblosxom-devel] packages and projects

[Will Kahn-G. <wi...@bl...>]

A while back, I (pretty sure it was me) moved things around and put 
PyBlosxom into the package Pyblosxom (upper-case P lower-case b).  That's 
different than the project name which is PyBlosxom.  In the Pyblosxom 
package is a pyblosxom module.  In the pyblosxom module is a PyBlosxom 
class.

Yes, seriously.  The only good thing I can say is that at least there 
isn't a pYbLOSXOM in there, too.

Anyhow, this is already a source of confusion, but the circumstances don't 
come up with enough frequency that I've decided to fix it.  Until now....

The pain of the current situation increases now that I'm moving core 
plugins into the Pyblosxom package (yes--one more round of the hokey pokey 
with the location of the plugins).  Because of this change, it's very 
likely that the confusion will cause problems for users since new users 
will be typing 'Pyblosxom.plugins.ladeedah' over and over again in the 
load_plugins list in their config.py files.

Further, after I make this change to plugins, the pain of changing the 
package name goes up astronomically.  So the time to fix it is now!

I see two options:

1. Change the name of the project from PyBlosxom to Pyblosxom.  Camel case 
is so 90s anyhow.  This makes the package the same as the project name.

Then we change the name of the PyBlosxom class to Pyblosxom and we're all 
set.  This last bit shouldn't be much pain--only the internals really use 
the PyBlosxom class.

2. Change the name of the package from Pyblosxom to pyblosxom or 
PyBlosxom.  This is a ton of pain because it means all plugins have to 
change.


Because I'm pain-averse these days, I'm inclined to go with option 1 and 
change the name of the project to Pyblosxom.

Does anyone object to a name change?

Does anyone have a better solution or something related that we should 
mull over?

/will

Re: [Pyblosxom-devel] [pyblosxom-devel] mtimes do not appear to hide future entries on pyblosxom-1.5rc3

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

is this compatible with plugins that fake mtime? (see "date" category @
http://pyblosxom.bluesock.org/registry/)

do we just need to pay attention to the order in which we load plugins,
or..?
from a quick glance, it also seems some plugins use different callbacks, so it may work with some, but not with others.
I.e. pyfilenamemtime does its thing in cb_filestat(), whereas
pymetatime uses cb_prepare() and cb_sortlist()

Dieter

On Sun, 28 Aug 2011 14:17:05 -0400
will kahn-greene <wi...@bl...> wrote:

> Currently you have to do the mtime-based filtering with a plugin
> which you've done.  If the plugin works, then that's probably fine.
> I can't think of anything offhand that would cause problems with the
> way you've implemented it.
> 
> Two things jump out at me, though.  First is that it looks like
> you're mixing tabs and spaces for indentation--that's bad Python
> programming. Second is that you're using filter and in this case it's
> better to use a list comprehension:
> 
>      data["entry_list"] = [e for e in data["entry_list"]
>              if e["timetuple"] <= now]
> 
> /will
> 
> 
> On 08/28/2011 12:48 PM, Mark David Dumlao wrote:
> > Hi,
> > After re-reading the docs and the mailing list, it appears to me
> > that my understanding regarding future mtimes was wrong.
> >
> > However, I do think it's a big convenience to write articles dated
> > in the future, so I looked into writing a callback for filtering
> > mtime.
> >
> > Is this an okay way to handle future mtimes?
> >
> > <snip>
> > import datetime
> > from datetime import datetime
> >
> > def cb_prepare(args):
> >          request = args["request"]
> > 	data = request.get_data()
> > 	now = datetime.now().timetuple()
> > 	data["entry_list"] = filter(lambda e: not e['timetuple']>
> > now, data["entry_list"])
> > </snip>
> >
> > On Sun, Aug 28, 2011 at 11:15 PM, Mark David
> > Dumlao<mad...@gm...>  wrote:
> >> Hi!
> >> I'm new to pyblosxom and I would like some clarification as to how
> >> mtimes work.
> >>
> >> As best as I understand, entries with an mtime later than today
> >> should not be displayed, whereas mtimes older than today should be
> >> displayed by the blog in decreasing order of date.
> >>
> >> Is this a correct understanding? If not, how can I help to make
> >> this happen, and in the meantime, what is the best way for me to
> >> write entries well in advance of their publish date?
> >> --
> >> This email is:    [x] actionable   [ ] fyi        [x] social
> >> Response needed:  [x] yes          [ ] up to you  [ ] no
> >> Time-sensitive:   [ ] immediate    [x] soon       [ ] none
> >>
> >
> >
> >
> 
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management 
> Up to 160% more powerful than alternatives and 25% more efficient. 
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> _______________________________________________
> Pyblosxom-devel mailing list
> Pyb...@li...
> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel

Re: [Pyblosxom-devel] [pyblosxom-devel] mtimes do not appear to hide future entries on pyblosxom-1.5rc3

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

Currently you have to do the mtime-based filtering with a plugin which 
you've done.  If the plugin works, then that's probably fine.  I can't 
think of anything offhand that would cause problems with the way you've 
implemented it.

Two things jump out at me, though.  First is that it looks like you're 
mixing tabs and spaces for indentation--that's bad Python programming. 
Second is that you're using filter and in this case it's better to use a 
list comprehension:

     data["entry_list"] = [e for e in data["entry_list"]
             if e["timetuple"] <= now]

/will


On 08/28/2011 12:48 PM, Mark David Dumlao wrote:
> Hi,
> After re-reading the docs and the mailing list, it appears to me that
> my understanding regarding future mtimes was wrong.
>
> However, I do think it's a big convenience to write articles dated in
> the future, so I looked into writing a callback for filtering mtime.
>
> Is this an okay way to handle future mtimes?
>
> <snip>
> import datetime
> from datetime import datetime
>
> def cb_prepare(args):
>          request = args["request"]
> 	data = request.get_data()
> 	now = datetime.now().timetuple()
> 	data["entry_list"] = filter(lambda e: not e['timetuple']>  now,
> data["entry_list"])
> </snip>
>
> On Sun, Aug 28, 2011 at 11:15 PM, Mark David Dumlao<mad...@gm...>  wrote:
>> Hi!
>> I'm new to pyblosxom and I would like some clarification as to how mtimes work.
>>
>> As best as I understand, entries with an mtime later than today should
>> not be displayed, whereas mtimes older than today should be displayed
>> by the blog in decreasing order of date.
>>
>> Is this a correct understanding? If not, how can I help to make this
>> happen, and in the meantime, what is the best way for me to write
>> entries well in advance of their publish date?
>> --
>> This email is:    [x] actionable   [ ] fyi        [x] social
>> Response needed:  [x] yes          [ ] up to you  [ ] no
>> Time-sensitive:   [ ] immediate    [x] soon       [ ] none
>>
>
>
>

Re: [Pyblosxom-devel] [pyblosxom-devel] mtimes do not appear to hide future entries on pyblosxom-1.5rc3

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

On Sun, 28 Aug 2011 23:15:27 +0800
Mark David Dumlao <mad...@gm...> wrote:

> Hi!
> I'm new to pyblosxom and I would like some clarification as to how
> mtimes work.
> 
> As best as I understand, entries with an mtime later than today should
> not be displayed, whereas mtimes older than today should be displayed
> by the blog in decreasing order of date.
> 
> Is this a correct understanding? If not, how can I help to make this
> happen, and in the meantime, what is the best way for me to write
> entries well in advance of their publish date?

I agree, date in future should mean "don't publish yet".
(I also suggested this a while ago and Will liked the idea)

which plugin are you using?

and what's up with your signature? it's interesting. is that dynamic? what generates it?

Dieter

Re: [Pyblosxom-devel] [pyblosxom-devel] mtimes do not appear to hide future entries on pyblosxom-1.5rc3

[Mark D. D. <mad...@gm...>]

Hi,
After re-reading the docs and the mailing list, it appears to me that
my understanding regarding future mtimes was wrong.

However, I do think it's a big convenience to write articles dated in
the future, so I looked into writing a callback for filtering mtime.

Is this an okay way to handle future mtimes?

<snip>
import datetime
from datetime import datetime

def cb_prepare(args):
        request = args["request"]
	data = request.get_data()
	now = datetime.now().timetuple()
	data["entry_list"] = filter(lambda e: not e['timetuple'] > now,
data["entry_list"])
</snip>

On Sun, Aug 28, 2011 at 11:15 PM, Mark David Dumlao <mad...@gm...> wrote:
> Hi!
> I'm new to pyblosxom and I would like some clarification as to how mtimes work.
>
> As best as I understand, entries with an mtime later than today should
> not be displayed, whereas mtimes older than today should be displayed
> by the blog in decreasing order of date.
>
> Is this a correct understanding? If not, how can I help to make this
> happen, and in the meantime, what is the best way for me to write
> entries well in advance of their publish date?
> --
> This email is:    [x] actionable   [ ] fyi        [x] social
> Response needed:  [x] yes          [ ] up to you  [ ] no
> Time-sensitive:   [ ] immediate    [x] soon       [ ] none
>



-- 
This email is:    [ ] actionable   [ ] fyi        [ ] social
Response needed:  [ ] yes          [ ] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [ ] none

[Pyblosxom-devel] [pyblosxom-devel] mtimes do not appear to hide future entries on pyblosxom-1.5rc3

[Mark D. D. <mad...@gm...>]

Hi!
I'm new to pyblosxom and I would like some clarification as to how mtimes work.

As best as I understand, entries with an mtime later than today should
not be displayed, whereas mtimes older than today should be displayed
by the blog in decreasing order of date.

Is this a correct understanding? If not, how can I help to make this
happen, and in the meantime, what is the best way for me to write
entries well in advance of their publish date?
-- 
This email is:    [x] actionable   [ ] fyi        [x] social
Response needed:  [x] yes          [ ] up to you  [ ] no
Time-sensitive:   [ ] immediate    [x] soon       [ ] none

[Pyblosxom-devel] pyblosxom 1.5rc3 released!

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

Release!
========

I just release PyBlosxom 1.5rc3.  For changes, take a look at the What's 
new chapter:

    http://pyblosxom.bluesock.org/1.5/whatsnew.html

Amongst other things, it continues to reduce the difficulties in 
configuring and debugging PyBlosxom and plugins.  I encourage everyone 
to upgrade.


Going forward
=============

There are still problems that I'd like to sort out for 1.5, but this is 
another big step towards getting there.

If you're interested in helping out, see the Milestone 1.5 link on the 
left side if the issue tracker at http://pyblosxom.bluesock.org/bugs/ .

If you find issues, please write up issues there or send something to 
the pyblosxom-devel mailing list.  Details on the website at 
http://pyblosxom.bluesock.org/ .

/will

Re: [Pyblosxom-devel] status: June 12th, 2011

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

Can you clone the pyblosxom-web repository, make the changes and send me 
a patch?

On 06/17/2011 02:10 PM, seanh wrote:
> On Sun, Jun 12, 2011 at 10:24:21PM -0400, will kahn-greene wrote:
>> I've overhauled the development docs accordingly:
>>
>>      http://pyblosxom.bluesock.org/static/development.html
>>
>> They assume you have a working knowledge of git currently.  I plan to
>> add links on how to learn git, but really don't want to host our own git
>> tutorial.  With that in mind, does the changes in the documentation make
>> sense?  Are they still hard to follow?  What specific changes would you
>> make?
>
> I think the instructions on that page are clear and useful.
> I'm fairly experienced with using git by myself and have only a little
> experience with using git to collaborate with others (some of what I
> know about collaboration I learned by submitting contributions to the
> pyblosxom docs). For me the instructions on that page are at a
> reasonable level of detail and are useful. I messed up at first by not
> using bugfix branches, these instructions would have prevented that.
>
> The main git website at http://git-scm.com/ has good links on how to
> learn git, maybe the pyblosxom site only needs one link to that site.
>
> I think the page could do with a sentence in the introductory section
> that says something like "The pyblosxom project uses
> [git](http://git-scm.com) for version-control and collaboration, and our
> git repositories are hosted on
> [gitorious](http://gitorious.org/pyblosxom/)." Currently the first you
> hear about git is when you see the git clone command in the
> instructions.  It actually took me a while to locate a link to the
> gitorious project page.
>
> It's also might be worth explicitly mentioning that people can create a
> free account on gitorious and host their own fork of pyblosxom in order
> to collaborate with us. This is sort of mentioned under "How to send us
> your changes" but I think it could be more explicit about the fact that
> using gitorious for this is free.
>
> Typo (missing word): "what our coding conventions (or should be)"
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Pyblosxom-devel mailing list
> Pyb...@li...
> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel
>

Re: [Pyblosxom-devel] status: June 12th, 2011

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

On Sun, Jun 12, 2011 at 10:24:21PM -0400, will kahn-greene wrote:
> I've overhauled the development docs accordingly:
> 
>     http://pyblosxom.bluesock.org/static/development.html
> 
> They assume you have a working knowledge of git currently.  I plan to 
> add links on how to learn git, but really don't want to host our own git 
> tutorial.  With that in mind, does the changes in the documentation make 
> sense?  Are they still hard to follow?  What specific changes would you 
> make?

I think the instructions on that page are clear and useful.
I'm fairly experienced with using git by myself and have only a little
experience with using git to collaborate with others (some of what I
know about collaboration I learned by submitting contributions to the
pyblosxom docs). For me the instructions on that page are at a
reasonable level of detail and are useful. I messed up at first by not
using bugfix branches, these instructions would have prevented that.

The main git website at http://git-scm.com/ has good links on how to
learn git, maybe the pyblosxom site only needs one link to that site.

I think the page could do with a sentence in the introductory section
that says something like "The pyblosxom project uses
[git](http://git-scm.com) for version-control and collaboration, and our
git repositories are hosted on
[gitorious](http://gitorious.org/pyblosxom/)." Currently the first you
hear about git is when you see the git clone command in the
instructions.  It actually took me a while to locate a link to the
gitorious project page.

It's also might be worth explicitly mentioning that people can create a
free account on gitorious and host their own fork of pyblosxom in order
to collaborate with us. This is sort of mentioned under "How to send us
your changes" but I think it could be more explicit about the fact that
using gitorious for this is free.

Typo (missing word): "what our coding conventions (or should be)"

[Pyblosxom-devel] status: June 12th, 2011

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

Hi!

I've been really busy the last few months and haven't gotten anything 
I've wanted to do on PyBlosxom done.  Things have cleared up a bit and I 
finally have some breathing space, but...  probably not for long since 
I'm on another aggressive software release schedule.

For June, I want to focus on the following three things:

1. work on pyblosxom 1.5 and finish it up

2. work on cleaning up the PyBlosxom and project documentation

3. clear out my queue of things people are waiting on me to do


I won't be able to get all of these things accomplished, but these are 
the things I am focusing on.

Today, I spent some time with gitorious and wrapped my head around merge 
requests (finally).  It makes a lot more sense now.  One thing that's 
really important for a merge request is that we switch the way we're 
doing contributions to make sure contributions are done in bugfix branches.

I've overhauled the development docs accordingly:

    http://pyblosxom.bluesock.org/static/development.html

They assume you have a working knowledge of git currently.  I plan to 
add links on how to learn git, but really don't want to host our own git 
tutorial.  With that in mind, does the changes in the documentation make 
sense?  Are they still hard to follow?  What specific changes would you 
make?


There are some things I want to clean up in the PyBlosxom core, but 
first I think I need to step back a bit, go through the issues in the 
1.5 roadmap, and make sure there are issues for all the things I think 
need to be in PyBlosxom 1.5.  Part of the issue here is that I've been 
away so long, that I don't really remember what I was doing.


There have been people popping up on #pyblosxom with questions.  As 
people ask questions, I need help identifying the root of the issues and 
addressing those issues in either the documentation or the code. 
Probably the best thing to do is copy and past the IRC conversation into 
an issue with a sentence or two identifying the issue and possible 
solutions.

I think that's where things are at.

If you're waiting on me for something, let me know.  I've got 2000 
emails in my inbox and I'm tossing around declaring email bankruptcy 
because I can't work through them all.

/will

Re: [Pyblosxom-devel] error handling, logging, debugging and trouble-shooting

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

I've replaced using cgitb with our own crash handler.  It's not
implemented as a sys.excepthook.  Instead it wraps the run_pyblosxom
method innards and thus will work in all PyBlosxom run-time contexts.

Why replace cgitb with our own crash handler?  The big reason was that I
want to enable this thing by default and the amount of information that
cgitb spills out is good for debugging, but too much for being a default
handler since it can potentially leak all kinds of information about
your setup, your configuration, what plugins you're using, ...

The new situation is a lot better and it should make it a lot easier to
trouble-shoot PyBlosxom for people setting up their blogs.  No more
commenting/uncommenting stuff in the pyblosxom.cgi file, no more
unhandled HTTP 500 messages from the web server, no more fishing through
web-server logs for the traceback, ...

I'd be interested in what people think about how it's implemented.

The one thing I'm on the fence about is whether to add a configuration
property that affects how much information shows up in the crash page.
Currently it shows a traceback and that traceback has file paths in it
which tell some information about the blog setup.  It'd be hard to scrub
that data, but it's easy to omit it if the user specifies to in the
configuration.

Is that worth doing?


On 04/02/2011 12:02 PM, will kahn-greene wrote:
> The Summary
> ===========
> 
> There have been several people hopping on IRC that have problems with
> PyBlosxom that are difficult to debug since all they see is a really
> helpful error message kind of like this one:
> 
>    A server error occurred
> 
> 
> Some of us know that that's probably an HTTP 500 error page from the
> web-server.  Other than that, we know nothing about what happened, what
> the circumstances were, or anything else that would be useful to solve
> the problem.
> 
> 
> The problem
> ===========
> 
> cgitb
> -----
> 
> First step I suggest when helping people trouble-shoot is to enable
> cgitb.  There's a line in pyblosxom.cgi that you can uncomment that
> enables this.  Enabling cgitb causes cgitb to bind to the
> sys.excepthook.  When an unhandled exception occurs, then cgitb does its
> thing and shows some useful information.  Several problems with this:
> 
> 1. since it's in pyblosxom.cgi, it's useless for people who don't run
> PyBlosxom as a CGI script
> 
> 2. the information is useful for developers and useless to everyone else
> 
> 3. there's no helpful information about what to do if you encounter a
> problem or even where the problem might lie (core?  plugins? ...)
> 
> 4. you only get the context at the point where PyBlosxom died--that may
> or may not be the origin of the actual problem
> 
> 
> logging
> -------
> 
> Moving along, PyBlosxom also has some logging infrastructure.  Neil has
> been kind enough to go look at this in detail because, as many have
> pointed out, it doesn't actually seem to log anything.  There's a bunch
> of logging infrastructure code in Pyblosxom/tools.py, but neither
> PyBlosxom nor the plugins actually do any logging.  So problems with this:
> 
> 1. nothing seems to do any actual logging
> 
> 2. the logging code doesn't look threadsafe because it's using a global
> cache
> 
> 
> verification
> ------------
> 
> We added some configuration verification stuff to PyBlosxom which you
> can run on the command line.  This enables PyBlosxom to tell you what's
> horribly wrong with your config.py file and also ask plugins to do the
> same.  The problem here is two-fold:
> 
> 1. since it's run from the command line and not the web-server, this
> can't point out any permissions issues
> 
> 2. most plugins don't implement verify_installation
> 
> 
> Solutions?
> ==========
> 
> So, I think we can all read that and come to the same conclusion: the
> situation sucks.  Amongst other things, it makes it really difficult to
> write an effective troubleshooting chapter for the PyBlosxom User Manual.
> 
> I'm tossing around the following things:
> 
> 1. Write our own exception hook that we can bind at the relevant entry
> points.  By doing this, we can be clever about the running context, we
> make the output PyBlosxom-specific, and we can direct people to the
> forums where we can help them.
> 
> 2. Change logging so that it:
> 
> 2.1. always logs to stderr
> 2.2. optionally logs to a log file
> 2.3. has less "clever" infrastructure overhead
> 2.4. keeps track of the last x logged items to display in the except hook
> 
> 3. Somehow rework the verify_installation stuff to be easier.  At a
> minimum, it should verify that required configuration parameters exist
> and this should be easy to add for a plugin developer.
> 
> 
> I bring this up now because I'm increasingly of the mind that problems
> with troubleshooting are awful enough that we should alleviate some of
> them for 1.5.  Amongst other things, it helps us solve a bunch of other
> problems more easily.  Also, I think solution 1 is easy to implement (an
> hour or two) and 2 might be, too.
> 
> Any thoughts on these?  Do these solutions seem like a good idea?
> 
> /will

Re: [Pyblosxom-devel] Circular dependency mess

[Neil S. <nei...@us...>]

On 05 Apr 13:38, will kahn-greene wrote:
> This is an easy fix--you just move the import for plugin_utils until
> where it's needed.

Done.  Good thing that, at the moment anyway, it was needed by just one
function.

> Generally, tools should be a leaf module--it shouldn't be importing
> anything else in PyBlosxom.  However the run_callbacks situation breaks
> that.
> 
> At some point, I want to relocate the callback stuff, but that's outside
> the scope of 1.5.

Understood.

> Are you seeing other circular dependency issues other than this one?

Not at the moment; though, if I do come across any more, I'll be sure to
fix them.  And if ever I should run into potential circular deps that
can't be fixed by just moving the import line, I'll be sure to let you know.
-- 
Neil Santos
Disgruntled Paradigms :: Code Monkey  //  Doing software The Right Way(TM)

[HTTP] neil.diosa.ph :: [XMPP] ne...@xm... :: [Y!M] neil_santos18

"Throwing a book of rules at a terrible programmer just creates a terrible
 programmer with a bruise on their head where the book bounced off."
                                                              -- Jeff Atwood

v4sw7LMYRhw5ln7pr5Fck4ma3u7OSLw2Gm3l7OArchi6e0t5Tb8/en7g6aI!sr9p-2/-4 hackerkey.com

Re: [Pyblosxom-devel] Fix time zone dependent tests

[Mikko V. <vm...@li...>]

On Thu, Apr 07, 2011 at 09:12:06PM -0400, will kahn-greene wrote:
> On 04/07/2011 08:50 PM, Mikko Varri wrote:
> >
> > If you have a chance, feel free to write the decorators.  Otherwise,
> > I'll probably do it tomorrow or so and ping you again.
> 
> I can definitely do this.  I'll check your change in and then switch it
> to a decorator.
> 

Cool! Thanks!

-vmj

Re: [Pyblosxom-devel] Fix time zone dependent tests

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

On 04/07/2011 08:50 PM, Mikko Varri wrote:
> On Thu, Apr 07, 2011 at 07:46:31PM -0400, will kahn-greene wrote:
>> 8edfe5b:
>>
>> The __force_tz and __restore_tz should be put in a decorator.  So if the
>> test fails at set_time, we're not put in a weird situation where
>> __force_tz has changed the environment, but __restore_tz never gets run.
>>
>> So then tests that need tz forced would be decorated.
>>
> 
> Sounds good.
> 
> I wrote it like that to minimize the "scope" of forced time zone (in
> the hopes that it would be clear which part of the test needs it).
> 
> But you're right, if set_time ever raises an exception, time zone
> wouldn't be restored.
> 
> If you have a chance, feel free to write the decorators.  Otherwise,
> I'll probably do it tomorrow or so and ping you again.

I can definitely do this.  I'll check your change in and then switch it
to a decorator.


>> c09e5e83:
>>
>> This one puzzles me.  The added comment is good.  However, the other
>> change is moving the w3cdate.  w3cdate is built off of the gmtuple which
>> is based in GMT.  Are you positive there's a problem here?  Can you
>> write a unit test that shows the problem?
> 
> Actually, there was no problem.  I just moved it so that the comment
> about locale dependency would refer to rfc822date alone.  w3cdate
> format does not have anything but digits, so unless I'm mistaken it is
> not locale dependent.
> 
> Only 8edfe5b was about fixing anything, the rest was about clearing up
> what code is locale dependent, what code is time zone dependent, and
> what code is generic.
> 
> Feel free to ignore this change if you think it has no value.  I don't
> mind.

That makes a lot more sense.  I'll check this one in, too, then.

Thank you!

/will

Re: [Pyblosxom-devel] Fix time zone dependent tests

[Mikko V. <vm...@li...>]

On Thu, Apr 07, 2011 at 07:46:31PM -0400, will kahn-greene wrote:
> I'm really sorry that it took so long.
> 

No problem at all.

> 
> 8edfe5b:
> 
> The __force_tz and __restore_tz should be put in a decorator.  So if the
> test fails at set_time, we're not put in a weird situation where
> __force_tz has changed the environment, but __restore_tz never gets run.
> 
> So then tests that need tz forced would be decorated.
> 

Sounds good.

I wrote it like that to minimize the "scope" of forced time zone (in
the hopes that it would be clear which part of the test needs it).

But you're right, if set_time ever raises an exception, time zone
wouldn't be restored.

If you have a chance, feel free to write the decorators.  Otherwise,
I'll probably do it tomorrow or so and ping you again.

> 
> c09e5e83:
> 
> This one puzzles me.  The added comment is good.  However, the other
> change is moving the w3cdate.  w3cdate is built off of the gmtuple which
> is based in GMT.  Are you positive there's a problem here?  Can you
> write a unit test that shows the problem?
> 
> 

Actually, there was no problem.  I just moved it so that the comment
about locale dependency would refer to rfc822date alone.  w3cdate
format does not have anything but digits, so unless I'm mistaken it is
not locale dependent.

Only 8edfe5b was about fixing anything, the rest was about clearing up
what code is locale dependent, what code is time zone dependent, and
what code is generic.

Feel free to ignore this change if you think it has no value.  I don't
mind.


-vmj

Re: [Pyblosxom-devel] Fix time zone dependent tests

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

I'm really sorry that it took so long.

I just added your repository as a remote and looked at the commits.  I
have these thoughts:

8edfe5b:

The __force_tz and __restore_tz should be put in a decorator.  So if the
test fails at set_time, we're not put in a weird situation where
__force_tz has changed the environment, but __restore_tz never gets run.

So then tests that need tz forced would be decorated.


c09e5e83:

This one puzzles me.  The added comment is good.  However, the other
change is moving the w3cdate.  w3cdate is built off of the gmtuple which
is based in GMT.  Are you positive there's a problem here?  Can you
write a unit test that shows the problem?


Again, I really apologize for taking so long.  Thank you for pinging me
again.

/will


On 04/07/2011 06:34 PM, Mikko Varri wrote:
> 
> On Fri, Mar 18, 2011 at 10:43:50PM -0400, will kahn-greene wrote:
>> On 03/18/2011 08:33 PM, Mikko Varri wrote:
>>> On Thu, Mar 17, 2011 at 09:40:30PM -0400, will kahn-greene wrote:
>>>>
>>>> Things I still need help with:
>>>>
>>>> 2. Running the unit tests.
>>>>
>>>
>>> I ran the unit tests on Slackware64 13.37rc2 and noticed that two
>>> tests were failing.  Both turned out to be time zone dependent, so I
>>> fixed the tests instead of the code under test.  You can see the
>>> change in my pyblosxom clone[1], change 8edfe5b[2].
>>>
>>> There's a couple of other changes, too, but they are not fixing any
>>> functionality.  Change 37c5602[3] is about a bit of documentation, and
>>> c09e5e8[4] moves the 'w3cdate' definition out of the setlocale scope.
>>>
>>> [1] http://gitorious.org/~vmj/pyblosxom/vmjs-pyblosxom/commits/master
>>>
>>> [2] http://gitorious.org/~vmj/pyblosxom/vmjs-pyblosxom/commit/8edfe5bba57796db24f54baea4bc3d3194400789
>>>
>>> [3] http://gitorious.org/~vmj/pyblosxom/vmjs-pyblosxom/commit/37c5602747d8e37e5713e4bad41a1494c2aeceb9
>>>
>>> [4] http://gitorious.org/~vmj/pyblosxom/vmjs-pyblosxom/commit/c09e5e83688a679aea687f73e702e49132a1debb
>>>
>>
>>
>> I'll take a look at these in the next day or two.
>>
> 
> Did you have a chance to take a look at these?
> 
> I merged your latest changes into my clone, so it should be easier to
> digest.
> 
> -vmj
> 
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> Pyblosxom-devel mailing list
> Pyb...@li...
> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel
> 

Re: [Pyblosxom-devel] Fix time zone dependent tests

[Mikko V. <vm...@li...>]

On Fri, Mar 18, 2011 at 10:43:50PM -0400, will kahn-greene wrote:
> On 03/18/2011 08:33 PM, Mikko Varri wrote:
> > On Thu, Mar 17, 2011 at 09:40:30PM -0400, will kahn-greene wrote:
> > >
> > > Things I still need help with:
> > >
> > > 2. Running the unit tests.
> > >
> > 
> > I ran the unit tests on Slackware64 13.37rc2 and noticed that two
> > tests were failing.  Both turned out to be time zone dependent, so I
> > fixed the tests instead of the code under test.  You can see the
> > change in my pyblosxom clone[1], change 8edfe5b[2].
> > 
> > There's a couple of other changes, too, but they are not fixing any
> > functionality.  Change 37c5602[3] is about a bit of documentation, and
> > c09e5e8[4] moves the 'w3cdate' definition out of the setlocale scope.
> > 
> > [1] http://gitorious.org/~vmj/pyblosxom/vmjs-pyblosxom/commits/master
> > 
> > [2] http://gitorious.org/~vmj/pyblosxom/vmjs-pyblosxom/commit/8edfe5bba57796db24f54baea4bc3d3194400789
> > 
> > [3] http://gitorious.org/~vmj/pyblosxom/vmjs-pyblosxom/commit/37c5602747d8e37e5713e4bad41a1494c2aeceb9
> > 
> > [4] http://gitorious.org/~vmj/pyblosxom/vmjs-pyblosxom/commit/c09e5e83688a679aea687f73e702e49132a1debb
> > 
> 
> 
> I'll take a look at these in the next day or two.
> 

Did you have a chance to take a look at these?

I merged your latest changes into my clone, so it should be easier to
digest.

-vmj

Re: [Pyblosxom-devel] Circular dependency mess

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

This is an easy fix--you just move the import for plugin_utils until
where it's needed.

Generally, tools should be a leaf module--it shouldn't be importing
anything else in PyBlosxom.  However the run_callbacks situation breaks
that.

At some point, I want to relocate the callback stuff, but that's outside
the scope of 1.5.

Are you seeing other circular dependency issues other than this one?


On 04/05/2011 09:37 AM, Neil Santos wrote:
> Been looking at liberally sprinkling logging support to a bunch of
> modules.  Now, wanting to start out nice and easy, I decided to start
> with plugin_utils.py.
> 
> Except tools.py import plugin_utils.py, and trying to use the logging
> facilities in the latter causes Python to call me names and question my
> lineage.  And I don't like it when programming languages do that to
> me. :P
> 
> I've this notion of further breaking down various modules, to try and
> get pyblosxom to the point that it's at least possible to include
> logging in the various modules without circular dependencies causing me
> to tear my hair out in sizable chunks.
> 
> I'm not sure how attached anyone is to the current structure, so I'm
> announcing my intention of doing so beforehand (to give way to
> objections and such).
> 
> This is, of course, a non-trivial change, hence this message.  I feel
> that this ought to be done before 1.5 is pushed out (with proper
> deprecation messages and such where appropriate, of course), though I
> wouldn't be suprised if this stretches far into 1.6, as I haven't really
> taken a very close look at how big a job it is.
> 
> I can probably post an update here if anyone's curious.
> 
> If there are no objections, I'll proceed to chopping up pyblosxom
> modules.  To start with, I want to move logging-related functions into
> its own module, as well as other, more minor, attendant changes: i.e.,
> deprecated_function() will need to relocated, or at least, I'd have to
> figure out how not to invoke Python's wrath at yet another breach of
> circular dependency conduct.
> 
> Let me know what you guys think.