Menu
▾
▴
pyblosxom-devel
|
From: will kahn-g. <wi...@bl...> - 2011-03-18 01:40:43
|
I had a really busy day and didn't get as much done as I wanted. I think the sprint week went really well. Looks like we spent a lot of time on the web-site and on documentation with some time on a few other things. I also helped someone upgrade from a 1.4.something to a 1.5-git blog and that went swimmingly. The 1.5 milestone has grown, but I'm feeling pretty good about it nonetheless. I'm currently working on factoring Dieter's and Sean's thoughts on the web-site into a web-site overhaul. I think doing a chunk of this before a 1.5 release is important since it's the best way to find plugins and documentation. Having a sucky web-site sucks. A couple of days ago, I said I'd throw together an outline for the new site, send it to the list, and then we could banter it about. I'm thinking instead I'm going to throw a new site together that's "good enough" and fixes the egregious issues the current one has. Then I'll move on to other things blocking the 1.5 release. After 1.5 is out, we can go back and properly work through the web-site as a group. Things I still need help with: 1. Testing PyBlosxom 1.5 in git works on your blog. 2. Running the unit tests. 3. Going through the bugs in the 1.5 milestone and triaging the ones I pulled from SourceForge. You can recognize them because they have "ID:" in the title. This is mostly a testing and triaging exercise. While the sprint week is over, we still haven't released 1.5. Any help towards that laudable goal is immensely appreciated! /will |
|
From: Neil S. <nei...@us...> - 2011-03-18 11:32:45
|
On Fri, Mar 18, 2011 at 09:40, will kahn-greene <wi...@bl...> wrote: > Things I still need help with: > > 1. Testing PyBlosxom 1.5 in git works on your blog. I can confirm that 1.5-git works on my blog (I plan on running it solely using bleeding edge code--provided it checks out on my local dev setup first, of course). -- Neil Santos Disgruntled Paradigms :: Code Monkey // Doing software The Right Way(TM) [Web] neil.diosa.ph :: [MSN] nei...@ho... :: [Y!M] neil_santos18 v4sw7LMYRhw5ln7pr5Fck4ma3u7OSLw5Gm3g/l7SL/i6e0t4Vb8en7g5aI!sr9p-2/-4 hackerkey.com |
|
From: Dieter P. <di...@pl...> - 2011-03-18 13:34:18
|
On Fri, 18 Mar 2011 19:31:57 +0800 Neil Santos <nei...@us...> wrote: > On Fri, Mar 18, 2011 at 09:40, will kahn-greene <wi...@bl...> wrote: > > > Things I still need help with: > > > > 1. Testing PyBlosxom 1.5 in git works on your blog. > > I can confirm that 1.5-git works on my blog (I plan on running it > solely using bleeding edge code--provided it checks out on my local > dev setup first, of course). i also updated my dev and production setup to the latest git code. seems to works fine. i was kinda surprised to see the newly introduced usage of '::', i.e. changes like: -Here's an example of what to put in config.py: +Here's an example of what to put in config.py:: Is this because we use RST as described on http://www.python.org/dev/peps/pep-0316/ ? Dieter |
|
From: will kahn-g. <wi...@bl...> - 2011-03-18 14:21:18
|
Yes! We've actually been using `reST`_ and `Sphinx`_ for a while, but occasionally there are typos like the below that need to be fixed. I occasionally even use it in email! .. reST: http://docutils.sourceforge.net/rst.html .. Sphinx: http://sphinx.pocoo.org/ On 03/18/2011 09:34 AM, Dieter Plaetinck wrote: > On Fri, 18 Mar 2011 19:31:57 +0800 > Neil Santos <nei...@us...> wrote: > >> On Fri, Mar 18, 2011 at 09:40, will kahn-greene <wi...@bl...> wrote: >> >>> Things I still need help with: >>> >>> 1. Testing PyBlosxom 1.5 in git works on your blog. >> >> I can confirm that 1.5-git works on my blog (I plan on running it >> solely using bleeding edge code--provided it checks out on my local >> dev setup first, of course). > > i also updated my dev and production setup to the latest git code. seems to works fine. > > i was kinda surprised to see the newly introduced usage of '::', i.e. changes like: > > -Here's an example of what to put in config.py: > +Here's an example of what to put in config.py:: > > Is this because we use RST as described on > http://www.python.org/dev/peps/pep-0316/ ? > > Dieter |
|
From: Neil S. <nei...@us...> - 2011-03-18 13:07:03
|
On Fri, Mar 18, 2011 at 09:40, will kahn-greene <wi...@bl...> wrote: > Things I still need help with: > > 3. Going through the bugs in the 1.5 milestone and triaging the ones I > pulled from SourceForge. You can recognize them because they have "ID:" > in the title. This is mostly a testing and triaging exercise. In the interests of getting my feet wet, here's a minor fix for issue 29 on the tracker: http://dollhouse.diosa.ph/cgit/cgit.cgi/pyblosxom/commit/?id=48d8d0080b652a38aaff2998fed00e131c255dbb Sorry, couldn't figure out how to add a new note to the bug report. :P -- Neil Santos Disgruntled Paradigms :: Code Monkey // Doing software The Right Way(TM) [Web] neil.diosa.ph :: [MSN] nei...@ho... :: [Y!M] neil_santos18 v4sw7LMYRhw5ln7pr5Fck4ma3u7OSLw5Gm3g/l7SL/i6e0t4Vb8en7g5aI!sr9p-2/-4 hackerkey.com |
|
From: Mikko V. <vm...@li...> - 2011-03-19 00:49:25
|
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. > Hi Will, 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 -vmj |
|
From: will kahn-g. <wi...@bl...> - 2011-03-19 02:43:59
|
Awesome! Thank you so much! I'll take a look at these in the next day or two. 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. >> > > Hi Will, > > > 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 > > > -vmj > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Pyblosxom-devel mailing list > Pyb...@li... > https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel > |
|
From: Mikko V. <vm...@li...> - 2011-04-07 22:34:30
|
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 |
|
From: Mikko V. <vm...@li...> - 2011-04-08 00:51:06
|
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 |
|
From: will kahn-g. <wi...@bl...> - 2011-04-07 23:46:43
|
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 > |
|
From: will kahn-g. <wi...@bl...> - 2011-04-08 01:12:20
|
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 |
|
From: Mikko V. <vm...@li...> - 2011-04-08 07:53:45
|
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 |
Thanks for helping keep SourceForge clean.
X