Team Chat Logs

2007 0
Mo	Tu	We	Th	Fr	Sa	Su
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31
<<	<		>	>>

alect: trac-pocoo starts existing as soon as the auth stuff in trac was refactored :D

s/was/is/

<alect>

mitsuhiko: i had a bit of a think about that. trac is able to provide a guarantee that a username is authenticated. if pocoo had a mechanism to accept this guarantee it could work

[01:11:38]

<alect>

ie. if pocoo's authentication layer is extensible, trac could provide the necessary details

[01:13:11]

alect: it is

[01:13:21]

pocoo would use the stuff provided by trac

[01:13:36]

alect: my idea was to create a wsgi gateway that serves pocoo at /discussion or /forum

[01:13:47]

<alect>

right

[01:13:49]

and puts the trac context/environment into the wsgi environment so that pocoo can access it

[01:14:07]

<alect>

so if we do that, plus use trac as the auth layer...

[01:14:10]

<alect>

hi cboos

[01:14:22]

additionally the trac pocoo plugin would ship a clean pocoo theme without html header footer etc and adds the trac header footer after catching the pocoo output

[01:14:46]

alect: the only problem: how to handle user registration in pocoo

[01:15:01]

because usually you want non core developers to register in forums

[01:15:04]

<alect>

can we not use the trac registration?

[01:15:11]

<alect>

AccountManager has user registration

[01:15:21]

alect: i'm waiting for that to come into the trac core :)

[01:15:47]

<alect>

i have my doubts that will happen

[01:15:53]

hmm

[01:16:09]

<alect>

plus there's no actual reason to wait...just have AccountManager as a dependency of the plugin

[01:19:25]

<alect>

mitsuhiko: is there documentation on the plugin architecture used by pocoo?

[01:34:53]

re

[01:35:08]

alect: yeah. give me a second

[01:36:37]

alect: there is just the package description: http://api.pocoo.org/pocoo.pkg-module.html

[01:36:44]

it's not much there

[01:38:08]

<alect>

aha

[01:38:25]

alect: the main idea is: multiple inheritance instead of interfaces

[01:38:36]

and plugins appear in the pocoo.pkg.* namespace

[01:38:51]

that's explained here: http://api.pocoo.org/pocoo.context-module.html

[01:38:56]

<alect>

yeah, so i read. which file is the core api in?

[01:39:06]

<alect>

cool :)

[01:39:15]

alect: most of it is in pocoo.context

[01:39:19]

the import stuff in pocoo.ihook

[01:39:28]

the actual packages are below pocoo.pkg

[01:39:37]

the wsgi application in pocoo.application

[01:40:13]

alect: oh. and the Component superclass is in the pocoo __init__.py to avoid circular imports

[01:41:49]

alect: ah. part of the documentation is directly on the api.pocoo.org main page

[01:41:56]

i guess we should improve that :D

[01:43:19]

<alect>

:)

[01:52:56]

alect: Another external hack needs to be cleaned from the repo

[01:54:22]

<alect>

so i saw

[01:54:45]

*grumble*peoplenotreading*grumble*

[01:54:47]

<alect>

should probably add a checkbox "Do you need Subversion?" to NewHack.py

[01:54:59]

<alect>

except people will simply not read that anyway

[01:55:40]

Use blink tags, that always gets people to pay attention

[01:58:19]

<alect>

mitsuhiko: so, only having skim read, this is my read on it... your config file defines which classes are plugins. plugins simply use MI to define their "interfaces".

[01:59:29]

alect: http://trac.pocoo.org/wiki/TracPocoo

[01:59:54]

alect: yeah. sort of

[02:00:52]

the package.conf exists because we plan a plugin distribution platform. there you upload zip files then and the server parses the package.conf to know what's inside the package without having to import the files which does not work because of arbitrary code

[02:01:34]

a package can register plugins also without that config file but it's not recommended

[02:01:56]

<alect>

and you use <base>.__subclasses__() for getting the actual "implementations"?

[02:02:28]

alect: no. that would not be context safe (we can have multiple pocoo instances in the same python process)

[02:02:29]

<alect>

wb cboos

[02:02:41]

each component is registered on the context

[02:02:51]

<cboos>

hello alect

[02:02:53]

<cboos>

hello mitsuhiko

[02:02:55]

either automatically by the package.conf or if a plugin provides a setup() function

[02:03:07]

<alect>

ah

[02:03:13]

on the context is a component registry in form of a dict

[02:03:35]

each registered table, middleware, component or theme is known to the context

[02:03:37]

<alect>

i don't quite see why simply finding the subclasses would not be context safe...the object is not instantiated

[02:04:03]

alect: because we have multiple import paths for plugins

[02:04:08]

and a state of the art import hook ^^

[02:04:22]

and the objects are instanced on first access

[02:05:44]

<cboos>

mitsuhiko: yeah, I glimpsed over the ihook stuff of pocoo yesterday, was interesting, though as usual with the ihook stuff I don't really get it

[02:06:19]

<cboos>

... what I was interested in was ideas for loading source files directly from the SVN repository, re pydoc plugin ;)

[02:06:56]

cboos: the ihook stuff is higher black magic i must admit

[02:07:20]

but it works pretty well and we are quite happy :)

[02:07:53]

<cboos>

the problem with it is that it's hard to see 1/ what the API really is, 2/ how to use it

[02:08:05]

<alect>

cboos; have you seen the pythondoc macro?

[02:08:10]

<alect>

it solves all those shit problems with pydoc

[02:08:21]

<alect>

swapoff.org/pyndexter/docs

[02:08:31]

cboos: the ihook is not bound to the api

[02:08:45]

you can completely bypass it on context creation

[02:09:13]

<cboos>

well, I meant the ihook api itself

[02:09:15]

<cboos>

(the API for making use of ihook)

[02:09:26]

cboos: ah. yeah

[02:09:29]

that's a problem

[02:09:42]

and the new import hook implementation is quite broken

[02:10:06]

cboos: birkenfeld is a python developer so it was easy for us to implement an import hook :D

[02:10:17]

<cboos>

I thought I could digest any kind of API, but this one is really giving me the impression I can't even get what it's supposed to do ...

[02:10:36]

<cboos>

can you lend us your birkenfeld please? ;)

[02:10:45]

haha

[02:11:23]

cboos: have you seen the import hook pep?

[02:11:30]

<cboos>

yeah

[02:11:38]

<alect>

so what would using this mechanism actually gain us?

[02:11:41]

except of a small addition for context resolving we implement importers defined there

[02:11:54]

<alect>

multiple Environments per thread

[02:12:32]

alect: we used it to move plugins into pocoo.pkg.PACKAGENAME

[02:12:47]

and load them from zip files and folders in both the instance folder and pocoo module

[02:12:58]

by making sure that each pocoo context has it's own packages

[02:13:05]

<cboos>

alect: my idea with ihook was that it would be able to load the code from the repos, i.e. that the import found in a file located in the repos could work (the goal being to use pydoc)

[02:13:16]

<alect>

ok. we use setuptools for that

[02:13:26]

<alect>

which covers all of those criteria i believe

[02:13:35]

<alect>

cboos: yeah, i know

[02:14:13]

<alect>

cboos: pythondoc is the answer

[02:14:25]

alect: beside moving packages under pocoo.pkg.FOOBAR :)

[02:14:45]

<alect>

mitsuhiko: yeah...but what's the actual advantage of that?

[02:15:06]

<alect>

it's neater

[02:15:13]

well you can use a namespace package to the same effect

[02:15:14]

<alect>

logically neater

[02:15:27]

alect: no matter from where the packages come, they always are on the same import location

[02:15:38]

the core package is not different from, say, the pony package

[02:16:47]

<alect>

eg. import pocoo.pkg.core?

[02:16:51]

<alect>

is that what you mean?

[02:17:29]

<alect>

coderanger: that would be good

[02:18:02]

<alect>

my main objection to setuptools is that you end up with crap sprayed all through site-packages

[02:18:04]

alect: I remember some talk of having trac plugins use tracext. as a namespace

[02:18:09]

<alect>

although with a global plugin dir that's not that big a deal anymore

[02:18:20]

<alect>

yeah i remember something to that effect

[02:18:28]

alect: I don't install plugins to site-packages anymore

[02:18:35]

alect: jep

[02:19:14]

alect: yeah. site-packages is overrated

[02:19:28]

the python import system should be able to resolve packages better

[02:19:34]

like the ruby system does

[02:19:51]

if foo/bar/baz does not exist in . it starts looking in the next in the load path. even if foo exists here

[02:19:56]

python gives up thne

[02:20:25]

<alect>

yeah

[02:21:26]

mitsuhiko: Setuptools should really get integrated into python proper

[02:48:34]

<alect>

mitsuhiko: the TracPocoo page is cool :)

[02:49:47]

<cboos>

mitsuhiko: so, IIUC, for getting the subclasses of a class, there are two ways: use __subclasses__ or use the meta-class, right?

[02:52:25]

cboos: if the metaclass tracs the subclasses, yes

[02:52:43]

<cboos>

tracks, you meant ;)

[02:53:00]

cboos: argh. sure ^^

[02:53:12]

<alect>

mitsuhiko: it'd also be good if the TracPocoo plugin could render individual comments and discussions. that way they could be accessible through macros and embedded into pages

[02:53:12]

i just see 'trac' everywhere :D

[02:53:18]

<alect>

don't we all

[02:53:31]

<cboos>

welcome in the Trac Zone, as alect says ;)

[02:53:33]

<alect>

or did you mean: "i just see [http://trac.edgewall.org trac] everywhere"

[02:54:19]

alect: no problem. pocoo can access the renderer

[02:54:30]

<cboos>

mitsuhiko: what was the issue you mention with __subclasses__ and threads? any ref on that?

[02:54:31]

the trac can access pocoo functions as well

[02:54:40]

<alect>

mitsuhiko: excellent

[02:54:44]

cboos: no problems with threads

[02:55:01]

just that every pocoo context instance has it's own class collection

[02:55:08]

and __subclasses__ does not trac that

[02:55:18]

argh. track

[02:55:25]

<cboos>

hehe

[02:55:47]

<alect>

heheh

[02:56:01]

<cboos>

ok, so at this point, we could simply use __subclasses__ and be done ...

[02:56:41]

<cboos>

... looks like I'll never go back to ruby for serious stuff ;)

[02:56:42]

cboos: you could even change implements() so that it adds interfaces as parent classes to the class

[02:57:18]

cboos: you worked with ruby?

[02:57:24]

<cboos>

well, I was on something else actually; trac_k_ing the Context subclasses

[02:57:37]

ah

[02:57:57]

<cboos>

yes, Ruby is my mother tongue as a script language ;)

[02:58:27]

<cboos>

s/is/was/ :(

[02:59:01]

<cboos>

but there are things in Python I definitely like better, like the object system, for a start ;)

[02:59:22]

<alect>

cboos: you thinking we should just use __subclassess__ for Context? removing the need for ResourceSystem altogether...

[02:59:40]

<cboos>

maybe, yes

[02:59:55]

<alect>

hmm

[02:59:55]

cboos: yeah. the object system is really great. but i wish there were blocks in python

[03:00:01]

<cboos>

I'm trying to see where it leads, currently, first applying your patch from yesterday

[03:00:30]

<cboos>

not a real pb, as you can create nested defs in python

[03:00:30]

<alect>

can you leave that?

[03:00:34]

<alect>

i've got more for that patch

[03:00:45]

<alect>

i'll upload it in a sec'

[03:00:52]

<cboos>

please show me, yes

[03:00:56]

cboos: true. and generators are also kicking ass

[03:01:12]

most of the time you use blocks for iteration anyway

[03:01:17]

<alect>

http://swapoff.org/files/cleaner-context.diff

[03:02:01]

<alect>

refresh :)

[03:03:21]

<alect>

using __subclasses__ seems a bit un-tracish though

[03:04:08]

<alect>

plus it would not be possible to disable it as a component

[03:04:23]

<alect>

well, without more hoops

[03:04:45]

<cboos>

good point

[03:04:52]

.oO( write a filter function )

[03:07:08]

<cboos>

realm = None => realm = '' (for repr) ?

[03:07:34]

<cboos>

but besides that, it's great, you saved me typing this ;)

[03:07:54]

<cboos>

well, typing Ctrl+K mostly ;)

[03:08:33]

<alect>

heh

[03:08:45]

<alect>

'' sounds good to me

[03:08:54]

<cboos>

see why I insisted that we go on a bit in the branch? I was quite sure that we could improve the stuff a lot ... we're getting there now

[03:09:12]

<alect>

yeah definitely

[03:09:55]

<alect>

you're updating Context.__call__ to return the right subclass?

[03:11:23]

<cboos>

was disconnected at the wrong time ...

[03:11:33]

<cboos>

I was about to say: (if everything is ok that is, I'm about to test the patch...)

[03:13:00]

<alect>

missed one thing...

[03:13:38]

<alect>

trac.wiki.api:148

[03:13:45]

<alect>

remove self.realm from that call

[03:14:35]

<cboos>

yes, I'm seeing that error too

[03:15:09]

<cboos>

+ need to pass the version

[03:15:51]

<cboos>

def get_resource(self):

[03:15:52]

<cboos>

from trac.wiki.model import WikiPage

[03:15:54]

<cboos>

version = self.version

[03:15:55]

<cboos>

if version == -1:

[03:15:57]

<cboos>

version = None

[03:15:58]

<cboos>

return WikiPage(self.env, self.id, version=version)

[03:16:22]

<cboos>

I'm not that confortable with (version == -1) meaning "latest version",

[03:16:25]

<alect>

aah, didn't notice you'd added a ersion to Context

[03:16:39]

<alect>

yeah. why not None?

[03:16:49]

<cboos>

I'd prefer to keep using version == None for that, yes

[03:17:02]

<cboos>

but there's an issue with that in __call__

[03:17:30]

<cboos>

how would you differentiate 1/ not passing the version argument (means: keep the existing self.version in case of copy)

[03:17:38]

<cboos>

2/ requesting the latest version?

[03:17:50]

<cboos>

you can't use None in both case...

[03:17:53]

<cboos>

better idea?

[03:19:13]

<alect>

i'm not sure what you mean by "keep the existing self.version in case of copy"

[03:19:19]

<alect>

what copy are we talking about?

[03:19:32]

<cboos>

copy of context, not creating a child context

[03:19:42]

<cboos>

i.e. context(abs_urls=True)

[03:19:57]

<cboos>

same resource, different mean to access it

[03:20:07]

<alect>

aah

[03:20:24]

why not use copy() for that

[03:20:33]

<cboos>

that was not so clear until now ;) but __call__ is clearer about this now

[03:21:01]

<alect>

we could remove that functionality

[03:21:13]

<alect>

so that __call__ *always* creates a child context

[03:21:32]

<cboos>

mmh, well ..

[03:21:45]

<alect>

and use context.abs_urls=True directly

[03:22:33]

<cboos>

problem is I do that in the template, I needed a functional way to do it and __call__ is perfect for that

[03:23:21]

<alect>

why not have 'href' and 'abs_href'

[03:23:24]

<alect>

in the Context

[03:23:41]

<cboos>

maybe an explicot copy() copy call instead...

[03:24:00]

<cboos>

removing 'abs_href' is one of the great benefit of the Context ;)

[03:24:28]

<cboos>

all the wiki renderers don't have to worry what the context of use is, they just use href

[03:24:40]

copy.copy is probably the cleanest way to do it

[03:24:41]

<cboos>

no more if format == 'rss' hacks all over the place...

[03:24:41]

<alect>

aah, yes

[03:25:12]

<alect>

Context.update(abs_href=True, ...) perhaps?

[03:25:38]

<cboos>

no,don't think it's a good idea to /modify/ the context, better create a copy

[03:26:13]

<alect>

yeah

[03:26:21]

<cboos>

coderanger: what's that copy.copy, is that the equivalent of object.dup ? ;)

[03:26:43]

the copy module provides copy and deepcopy

[03:26:46]

<cboos>

2.3 compatible?

[03:26:48]

cboos: copy.copy is a wrapper around core copy functions and __copy__ / __deepcopy__

[03:26:52]

cboos: 2.2 even

[03:27:04]

which you implement in __copy__ and ... what he said

[03:27:36]

<alect>

overkill i think, plus it doesn't let you "copy and update' in one call

[03:27:45]

<alect>

which is necessary for the templating

[03:28:22]

<cboos>

well, we could implement the Context.copy(abs_urls=None) method using that

[03:28:35]

cboos: dict is doing that

[03:29:05]

<cboos>

but maybe overkill, I don't know; the advantage would be not having to have to update the list of properties...

[03:29:39]

<cboos>

mitsuhiko: you mean something like other.__dict__.update(self.__dict__) ?

[03:29:59]

cboos: no. i meant a .copy() method

[03:30:13]

<cboos> well, we could implement the Context.copy(abs_urls=None) method using that

[03:30:40]

cboos: i'm still trying to understand what's your discussion is about :)

[03:30:45]

<cboos>

ah ;)

[03:30:59]

something about context duplication

[03:31:04]

<cboos>

well, without the code at hand, it's not that easy ... wai

[03:31:06]

<cboos>

wait

[03:32:03]

<cboos>

(damn connection speed < 10k today, wtf...)

[03:32:22]

<alect>

heh

[03:32:36]

<alect>

you have the dodgiest internet connection :)

[03:32:42]

alect: no

[03:33:06]

<alect>

man this kensington trackball roxors

[03:33:20]

<cboos>

(unbelievable, I have ADSL, and usually I have between 300 and 500 Kb/s ...)

[03:34:02]

alect: http://paste.pocoo.org/show/657/

[03:34:49]

<alect>

a paste plugin for trac would be cool

[03:34:55]

<alect>

hahah

[03:34:59]

<alect>

thta is impressive :)

[03:35:11]

alect: that's skydsl

[03:35:32]

(when it's raining)

[03:35:37]

<alect>

satellite?

[03:35:41]

<alect>

or actual dsl?

[03:35:57]

alect: it's internet over satellite

[03:36:10]

at least that's what sascha told me

[03:36:21]

<alect>

impressively crap

[03:36:25]

apparently the dsl infrastructure in germany does only exist in and around big cities

[03:37:00]

alect: as a result of that they reintroduced ISDN flatrates :D

[03:37:36]

<cboos>

so mitsuhiko, alect and me were talking about the Context class (http://trac.edgewall.org/browser/sandbox/security/trac/resource.py#L83) and making modifying __call__ to always return a child context and moving the copy case in a specific copy(abs_iurls=None) method. As you can see there are lots of properties (and maybe more in the future) so I wonder if it's worth using copy.copy or...

[03:37:38]

<cboos>

...another hack, or just go through the list, like we do in __init__.

[03:38:15]

<alect>

explicit

[03:39:03]

cboos: so you want to create an exact copy of the context and modify some attributes on it?

[03:39:11]

<cboos>

yep

[03:39:27]

<cboos>

in one go, as we're in a template

[03:39:46]

c = object.__new__(Context)

[03:39:53]

c.__dict__.update(self.__dict__)

[03:40:00]

c.__dict__.update(**kwargs)

[03:40:00]

?

[03:41:08]

<cboos>

... something like that, yes ;)

[03:41:35]

<cboos>

the above by passes Context.__init__, right?

[03:41:57]

cboos: object.__new__(Foo) is like Foo.allocate in ruby :)

[03:42:01]

so yes. doesn't call __init__

[03:42:43]

<cboos>

alect: like in __init__ ?

[03:43:16]

<alect>

yeah exactly

[03:43:26]

<alect>

just like __call__() does it now

[03:45:05]

The problem is are there any attrs that should be deepcopyed?

[03:45:32]

<cboos>

and risk to forget to copy a few things... just like __call__ does it now by loosing the _perm ;)

[03:45:45]

<cboos>

coderanger: no

[03:46:11]

<cboos>

shallow copy is ok, unless I'm mistaken

[03:46:19]

<alect>

coderanger is right. if extra attributes are added that actually require deep copying

[03:46:25]

I think the default copy implementation looks like it should suffice for that part of this

[03:46:55]

<alect>

too much magic is uncool

[03:47:09]

morning

[03:47:11]

<alect>

and prone to side-effects

[03:47:11]

<cboos>

coderanger: ok, you're right after all, there could be in the future a .properties property ...

[03:47:16]

coderanger: do you ever sleep? ;-)

[03:47:47]

<alect>

eg. if __init__() does something additional in the future, the copy() method will not suffice

[03:47:51]

cboos: still, even in that case you can do two shallow copies

[03:48:05]

chrismir: At odd hours

[03:49:04]

coderanger: heh, that would explane it ( at least if you mean odd as not even, not the 'weird' odd)

[03:49:31]

<alect>

either way you have to be careful when you add/modify attributes

[03:49:35]

<cboos>

ok ok, so alect, how do we proceed? did you fix line 147 (not bothering with the version stuff for now?) maybe you could commit that; then I'll go on with the __call__/copy split

[03:49:42]

<alect>

but at least explicitly, it's clear

[03:49:46]

<alect>

ok

[03:49:50]

<alect>

sounds good :)

[03:50:18]

<cboos>

alect, yes, I think explicit is better than implicit, for now (hm, already heard that somewhere, ... ;) )

[03:51:22]

<alect>

hehe

[03:51:31]

coderanger: you've got me thinking and I'm considering setting up an eclipse / python environment and focus on learning pyhton and trac code

[03:52:23]

my insanity is becoming infectious :)

[03:52:30]

haha

[03:53:03]

Is there only one python plugin for eclipse, or are there more and can you recommend me one?

[03:54:36]

<alect>

ooh and then mylar!

[03:54:46]

<alect>

trac bugs in eclipse!

[03:54:56]

<alect>

does eclipse have vi key bindings?

[03:55:25]

alect: unfortunately not

[03:55:29]

chrismir: No idea, I swear my textmate :)

[03:55:32]

er, by

[03:55:36]

also, nano

[03:55:37]

<alect>

that is weak!

[03:55:38]

coderanger: textmate doesn't have either

[03:56:01]

<alect>

i seriously can't use any non-vi editor for extended periods anymore

[03:56:12]

moded editors make me sad

[03:56:26]

<alect>

cboos: okay committed. also renamed IResourceMapper to IContextProvder to reflect its new purpose

[03:56:28]

alect: same problem here

[03:56:38]

<alect>

vim is gold

[03:56:40]

nano is great. I use it all the time. But only for small bass scripts etc

[03:56:41]

but those textmate snippets are something i would like in vim too

[03:56:46]

bash*

[03:56:54]

<alect>

although i haven't sat down and figured out omnicomplete yet

[03:56:57]

<alect>

textmate snippets?

[03:57:29]

alect: yeah. cls<Tab> inserts class (cursor here)Name(bases): pass etc

[03:57:38]

and each time you press tab it jumps one position forward

[03:57:44]

classname -> parameters -> pass statement

[03:58:07]

Actually Mylar is the reason I started investigating Trac.

[03:58:27]

<alect>

mitsuhiko: omnicomplete in vim does that

[03:58:47]

I saw Mylar had 3 slot plugins. bugzilla, some other and trac

[03:58:52]

<alect>

with calls at least

[03:59:00]

<alect>

eg. def func(a, b, c): pass

[03:59:00]

bugzilla is, well... yuk

[03:59:06]

alect: doesn't omnicomplete just shows me an autocompletion?

[03:59:19]

<alect>

fu<tab> -> func(<tab> -> func(a, b, c)

[03:59:39]

<alect>

omnicomplete does introspection

[03:59:43]

<alect>

it's quite impressive

[03:59:49]

alect: yeah. and that works quite well

[03:59:50]

<alect>

and very customisable

[03:59:59]

but snippets like in textmate still aren't possible

[04:06:34]

alect: do you know how to install a vimball?

[04:07:00]

<alect>

nope, not heard of them

[04:07:10]

<alect>

though vim could seriously use a packaging mechanism of some sort

[04:07:15]

<alect>

which i assume is what they are?

[04:07:36]

alect: no idea. i just found a vim plugin that enables textmate style snippets which is a "vimball"

[04:08:31]

<alect>

nice :)

[04:11:55]

alect: woa. it really works

[04:13:48]

<alect>

wb cboos

[04:13:56]

<alect>

> cboos: okay committed. also renamed IResourceMapper to IContextProvder to reflect its new purpose

[04:14:17]

<cboos><

Context Navigation

January 14, 2007

2007 0
Mo	Tu	We	Th	Fr	Sa	Su
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31
<<	<				>	>>

2007 0
Mo	Tu	We	Th	Fr	Sa	Su
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31
<<	<				>	>>

2007 0
Mo	Tu	We	Th	Fr	Sa	Su
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31
<<	<				>	>>