| *** srichter has quit IRC | 00:16 | |
| *** srichter has joined #zope3-dev | 00:52 | |
| *** alga has joined #zope3-dev | 01:15 | |
| J1m | srichter, ayt? | 01:42 |
|---|---|---|
| *** alga_ has joined #zope3-dev | 01:48 | |
| *** alga has quit IRC | 01:48 | |
| *** J1m has quit IRC | 02:17 | |
| *** alienoid has quit IRC | 03:13 | |
| *** hazmat_ has joined #zope3-dev | 03:19 | |
| *** omegadan has joined #zope3-dev | 03:20 | |
| *** hazmat has quit IRC | 03:22 | |
| *** d2m has quit IRC | 03:23 | |
| *** lodragan has joined #zope3-dev | 03:25 | |
| *** omegadan has quit IRC | 03:28 | |
| *** `anthony has quit IRC | 05:17 | |
| *** tav|offl1ne has joined #zope3-dev | 05:23 | |
| *** tav|offline has quit IRC | 05:23 | |
| *** alga_ has quit IRC | 05:26 | |
| *** hazmat_ has quit IRC | 06:14 | |
| *** hazmat_ has joined #zope3-dev | 06:44 | |
| *** `anthony has joined #zope3-dev | 06:50 | |
| *** povbot` has joined #zope3-dev | 07:27 | |
| *** povbot has quit IRC | 07:27 | |
| *** sashav_ has quit IRC | 07:32 | |
| *** apauley has joined #zope3-dev | 07:55 | |
| *** hazmat_ is now known as hazmat | 08:08 | |
| *** ChanServ sets mode: +o hazmat | 08:08 | |
| *** sashav has joined #zope3-dev | 08:51 | |
| *** SteveA has joined #zope3-dev | 08:53 | |
| *** SteveA has joined #zope3-dev | 08:54 | |
| *** d2m has joined #zope3-dev | 08:56 | |
| *** zagy has joined #zope3-dev | 09:24 | |
| *** `anthony has quit IRC | 09:32 | |
| *** Aiste has quit IRC | 09:35 | |
| *** bskahan has quit IRC | 09:53 | |
| *** Aiste has joined #zope3-dev | 09:54 | |
| *** stub has joined #zope3-dev | 10:24 | |
| *** Aiste has quit IRC | 10:24 | |
| *** hazmat has quit IRC | 10:28 | |
| *** Theuni has joined #zope3-dev | 10:28 | |
| *** Aiste has joined #zope3-dev | 10:55 | |
| *** jhauser has joined #zope3-dev | 11:24 | |
| *** MalcolmC has joined #zope3-dev | 12:01 | |
| *** sashav_ has joined #zope3-dev | 12:12 | |
| *** Aiste has quit IRC | 12:14 | |
| *** Aiste has joined #zope3-dev | 12:19 | |
| *** vlado has joined #zope3-dev | 12:48 | |
| *** sashav has quit IRC | 13:13 | |
| *** `anthony has joined #zope3-dev | 13:35 | |
| VladDrac | using zope3 stuff standalone is actually pretty easy... I just wonder if I'm doing things the right way :) | 13:42 |
| philiKON | hehe | 13:48 |
| *** J1m has joined #zope3-dev | 13:51 | |
| VladDrac | it also provides me with quite alot of insight | 13:51 |
| VladDrac | enough insight to say: writing your own zcml directives is cool :) | 13:51 |
| *** regebro has joined #zope3-dev | 14:00 | |
| *** dc\off has joined #zope3-dev | 14:41 | |
| *** J1m has quit IRC | 14:44 | |
| *** d2m has quit IRC | 14:56 | |
| *** srichter has quit IRC | 14:57 | |
| regebro | Hmmm.... I have a leeeteeel problem I need to brainstorm.... | 15:00 |
| regebro | I'm making a calendar. | 15:01 |
| regebro | Every event in the calendar needs to have it's own workflow state (invidet(/rejected/accepted) | 15:01 |
| regebro | So, I'm thinking, every calendar stores it's events as proxies to the real event, which are stored in a separate storage. | 15:02 |
| regebro | This is good, because it ties in well with the other need: Having separate storages, so we can connect to different calendar servers (exchange, Kolab, that sort of thing). | 15:02 |
| regebro | So far, so good. | 15:03 |
| regebro | But, since the storage might not be persistent to Zope, how the heck do I adapt the "real" event to my proxy event? | 15:03 |
| regebro | Please read this and ask me questions, because I'm stuch in a mode of thinking that doesn't work and that I can't get out from! :) | 15:04 |
| VladDrac | I'm not really seeing the problem | 15:04 |
| VladDrac | you somehow have a handle to the 'remote' event | 15:05 |
| VladDrac | i.e. a filesystem file, so whenever your objects methods are invoked you access the file | 15:05 |
| regebro | Yes, but of course, the evet-proxy object does not know how to access the file. So, I need an adapter that adapts between the file and IEvent, basically. | 15:07 |
| regebro | Hmmm.... That adapter can be created when I create the proxy, but it does not have to store the handle to the real event object... | 15:07 |
| VladDrac | so you'd need a IRemoteEvent interface and different implementations for different storages, and adapt IRemoveEvent to IEvent (which might be actually no adaption at all) | 15:08 |
| VladDrac | you might need some custom zcml to configure your removeevent | 15:09 |
| regebro | Yeah, right. So that could solve the problem, by the adapter knowing what to do. | 15:09 |
| regebro | If the real object is a ZODB object, I can simply store a reference to that object directly. ... or can I? | 15:10 |
| jhauser | why not use a publisher for the events? | 15:10 |
| regebro | publisger? | 15:10 |
| jhauser | the event has some form of id | 15:10 |
| regebro | yup. | 15:10 |
| jhauser | a publisher knows how to create an event object from the id | 15:11 |
| jhauser | this object can then be adapted | 15:11 |
| jhauser | i use publisher for all access to repositories or stores | 15:11 |
| regebro | That sounds intriguing. | 15:11 |
| jhauser | so I can use one store with different application specific publishers | 15:12 |
| regebro | I know nothing about publishers... | 15:12 |
| jhauser | its not a special software but an idea | 15:13 |
| jhauser | we implement publisher as global utilities | 15:13 |
| regebro | I think my main problem now is how to get hold of the real object transparently without having to look it up for each attribute access. | 15:13 |
| jhauser | so the view can call the publisher, get the object and do things with it | 15:13 |
| regebro | Well, I'm obviously going to have some sort of calendar utility/service where you call getEvent(event_id) to get the object. That is not a problem. | 15:14 |
| regebro | I just don't want to do that 5 times every request. | 15:15 |
| regebro | _v_ helps a bit. | 15:15 |
| jhauser | in z2 you could perhaps use a ram cache for this | 15:16 |
| regebro | Yeah, maybe. Well, I should be able to start off with just using _v_realobject and checking that it really exists before I do something. | 15:17 |
| jhauser | or the store can implement a cache | 15:17 |
| jhauser | but then you bind the object to some persistent object, which always needs to be present | 15:18 |
| regebro | Yeah, but I still have to (since this is Five) traverse to the store and ask for it every time, in that case... | 15:18 |
| regebro | I think the stores need a cache anyway, for that matter, if it'sexternal to the ZODB. | 15:18 |
| jhauser | ah you can store it in the view or not? | 15:19 |
| regebro | Well, I was thinking of keeping the view out of this completely. ;) | 15:20 |
| regebro | And let the proxy object handle it transparently. | 15:20 |
| jhauser | haha ok, but the normal behaviour of a view is to store a context | 15:20 |
| regebro | Yeah, you are right. And that would solve things, but I'm not sure how to do that. | 15:21 |
| regebro | Hmm, I can experiment a bit. | 15:21 |
| regebro | Let the view create the adapter between the proxy and the real object, and use that as a context. I havenät fiddled with views that much. | 15:22 |
| regebro | I'll take a look at it. Thanks! | 15:22 |
| regebro | Meh! Makes it hard to unit test... ;) | 15:23 |
| jhauser | yes, that's true | 15:23 |
| jhauser | or at least I haven't learned it yet | 15:24 |
| *** srichter has joined #zope3-dev | 15:33 | |
| *** ChanServ sets mode: +o srichter | 15:34 | |
| *** Voblia has joined #zope3-dev | 15:57 | |
| apauley | srichter: hi | 16:05 |
| apauley | I've just done step 1 of adding a content object | 16:06 |
| apauley | I'm impressed with how much work Zope does for free in generating a view | 16:07 |
| apauley | anyway, I have to run | 16:08 |
| *** apauley has quit IRC | 16:09 | |
| regebro | jhauser, VladDrac: Well, that solves it I thing. The proxy now stores nothing that the id if the real event. | 16:12 |
| regebro | Every time you then need to actually ACCESS it, you get a multiadapter between the proxy and the storage. | 16:12 |
| jhauser | nice | 16:13 |
| regebro | Which in turn returns an even that will do what ever is needed. Now I'm gonna see how this works in a real context. ;) | 16:13 |
| regebro | I suspect the view will need to do something tricky too, as I need to pretend that I'm actually working on the proxy (to geth absolute:urls correct and such). | 16:13 |
| jhauser | hm, this starts to smell | 16:15 |
| *** mgedmin has joined #zope3-dev | 16:15 | |
| jhauser | why have absolute_url generated by the object | 16:15 |
| regebro | Yeah, but much less than it did 30 minutes ago. :P | 16:15 |
| jhauser | haha | 16:15 |
| regebro | Because it's the proxy object that generates absolute_url... | 16:16 |
| regebro | When you view the object, you want the crumbtrail to show path/to/my/calendar/event | 16:16 |
| jhauser | from my external view I would think of a calendar as an application you call on some context, probably a site or a group | 16:16 |
| regebro | not /portal_calendar/storage/67876682768 | 16:16 |
| * mgedmin is interested in calendaring | 16:17 | |
| *** lodragan has left #zope3-dev | 16:17 | |
| regebro | jhauser "call on"? | 16:17 |
| *** vlado_ has joined #zope3-dev | 16:17 | |
| regebro | I don't really understand what you mean with that... | 16:17 |
| jhauser | you start with a persistent place, site, groupfolder or such | 16:17 |
| jhauser | for this you want to have a calendar | 16:18 |
| regebro | Yup. | 16:18 |
| jhauser | this is an application | 16:18 |
| *** vlado has quit IRC | 16:18 | |
| jhauser | so from there the application should overtake the path handling | 16:18 |
| jhauser | everything after the /path/calendar should be handled by calendar and not some magic traversal | 16:18 |
| regebro | Well, that's all easy to *say* "overtake the path handling". Much less easy to do. I don't think Zope traversal is especially magic... | 16:19 |
| jhauser | so calendar has a traverser_before_publish where it can intercept the url traversal and take over | 16:19 |
| jhauser | I mean the event object does not need to know the absolute_url and such | 16:20 |
| jhauser | that's my point | 16:20 |
| regebro | Why? Every event needs to be have an object stored under calendar anyhow, so there is nothing to take over. | 16:20 |
| regebro | foo/calendar/anevent will by standards zope traversale return the "anevent" object under calendar. No need for any magick traversal. | 16:21 |
| *** alga has joined #zope3-dev | 16:21 | |
| jhauser | but you do it differently, because you store the events somewhere else to reuse them | 16:21 |
| regebro | Ah, yes. And no. | 16:21 |
| jhauser | in different calendars | 16:21 |
| regebro | Every different calendar that has an event, will have a proxy event stored in the calendar. There is no magic traversal involved. | 16:22 |
| regebro | This is needed, because every calendar needs it's own event instance, so it can have it's own workflow state. | 16:22 |
| jhauser | right | 16:23 |
| regebro | The tricky part here is, that when I open this proxy event for editing, any attribute defined in the Interface, should be proxied. | 16:24 |
| regebro | To the real event. | 16:24 |
| regebro | Nothing else should. | 16:24 |
| mgedmin | def __getattr__(self, name): | 16:25 |
| mgedmin | if name in IFoo: | 16:25 |
| regebro | mgedmin: Yup, that's what I use. | 16:25 |
| mgedmin | return getattr(self._realobject, name) | 16:25 |
| regebro | The question is how to knit everything together using adapters. I'm half way there. | 16:26 |
| SteveA | personally, i construct a class using descriptors | 16:26 |
| regebro | Which means: My unit tests works. ;) But now I'm gonna make it work in views as well. | 16:26 |
| SteveA | for doing this | 16:26 |
| SteveA | i have a decorates(IBar) syntax | 16:26 |
| SteveA | for adapters that decorate | 16:27 |
| jhauser | this does currently not work with five and zope2 | 16:27 |
| VladDrac | blah.. I'm trying to load zcml in two stages (one stage to setup a basic system, one to do application specific stuff).. doesn't work to well :( | 16:28 |
| regebro | But it's an interesting idea. | 16:28 |
| VladDrac | stuff registered in the first stage gets lost in the second (with context=None), can't figure out what an appropriate context would be | 16:28 |
| *** tvon has quit IRC | 16:40 | |
| VladDrac | guess I'll have to read the configuration in a single run then :( | 16:47 |
| SteveA | use an override for the app-specific parts, perhaps? | 16:49 |
| VladDrac | you mean overrides.zcml? | 16:52 |
| *** J1m has joined #zope3-dev | 16:52 | |
| VladDrac | never mind, this is just not working | 16:52 |
| SteveA | one way is using overrides.zcml | 16:53 |
| VladDrac | now getUtility can't find my utility anymore.. probably more context related stuff that I don't understand | 16:53 |
| VladDrac | steve: I'm trying to use zcml etc outside zope3 - I have to start the zcml machinery myself, so no default 'zope3 behavious' such as overrides.zcml | 16:54 |
| VladDrac | I was hoping to make a separate package that would do some simple initailization and then use that from my application and have it load additional, 'local' configuration | 16:54 |
| VladDrac | but I can't get it to work | 16:54 |
| philiKON | SteveA, what does your decorates(IFoo) do? | 16:59 |
| SteveA | i can write an adapter: | 17:00 |
| SteveA | class AdaptIFooToIBar: | 17:00 |
| SteveA | implements(IBar) | 17:00 |
| SteveA | decorates(IFoo) | 17:00 |
| philiKON | ah, so it's like adapts()? | 17:00 |
| philiKON | ah, wait, i think i get it | 17:00 |
| SteveA | def methodToOverrideOfIFoo(self): | 17:01 |
| philiKON | it's a decorator also, eh? | 17:01 |
| SteveA | # do it differently | 17:01 |
| SteveA | in this example, IBar extends IFoo | 17:01 |
| philiKON | so, it's like subclassing, but on an interface/adapter level | 17:01 |
| SteveA | the decorates(IFoo) makes any names not claimed by the class implementation into descriptors that pass through to the context of the adapter | 17:01 |
| philiKON | yeah, neat | 17:02 |
| SteveA | i'll see about releasing this code | 17:02 |
| SteveA | i don't think it will be a problem | 17:02 |
| philiKON | that'd be cool | 17:02 |
| philiKON | not that it's particularly sophisticated | 17:03 |
| SteveA | it isn't, but it has nice tests etc. | 17:03 |
| philiKON | right | 17:03 |
| philiKON | why duplicate the work | 17:03 |
| *** tvon has joined #zope3-dev | 17:16 | |
| *** dc\off has quit IRC | 17:19 | |
| *** bskahan has joined #zope3-dev | 17:23 | |
| *** dc\off has joined #zope3-dev | 17:24 | |
| VladDrac | raise ComponentLookupError("Could not adapt %r to" | 17:29 |
| VladDrac | zope.configuration.config.ConfigurationExecutionError: zope.component.exceptions.ComponentLookupError: 'Could not adapt <zope.configuration.config.ConfigurationMachine object at 0x4022646c> to IServiceService' | 17:29 |
| * VladDrac sobs | 17:29 | |
| *** mkerrin has joined #zope3-dev | 17:36 | |
| *** sashav_ has quit IRC | 17:37 | |
| *** Theuni has quit IRC | 17:54 | |
| *** dc\off is now known as dreamcatcher | 17:57 | |
| *** kinder has joined #zope3-dev | 18:07 | |
| VladDrac | ok | 18:26 |
| VladDrac | I give up | 18:26 |
| VladDrac | zope3 cannot be used standalone by (relative) newbies | 18:26 |
| VladDrac | (unfortunate because it would be a cool way to learn more) | 18:27 |
| *** vlado__ has joined #zope3-dev | 18:27 | |
| Damascene | what's the problem? | 18:27 |
| Damascene | actually, i am a newbie as well, so i doubt i could help! :) | 18:27 |
| philiKON | VladDrac, say, what's the problem | 18:30 |
| philiKON | this shouldn't be too hard | 18:30 |
| philiKON | what do you need to do? | 18:30 |
| VladDrac | I want to use utilities, adapters, interfaces, zcml outside of zope, basically | 18:31 |
| VladDrac | afaik, zope3 can do most registrations/parsing using some sort of global state | 18:32 |
| VladDrac | but strangely enough my lookups fail | 18:32 |
| *** vlado_ has quit IRC | 18:35 | |
| philiKON | have you looked at Five? | 18:38 |
| VladDrac | I have | 18:41 |
| philiKON | is it something else you need? | 18:41 |
| *** vlado__ has quit IRC | 18:41 | |
| VladDrac | sorry my head hurts - gotta stop this z3 thing now - brb :) | 18:42 |
| *** vlado__ has joined #zope3-dev | 18:42 | |
| philiKON | ok :) | 18:43 |
| *** tziade has joined #zope3-dev | 18:43 | |
| tziade | dreamcatcher: hi | 18:44 |
| dreamcatcher | hi | 18:44 |
| tziade | dreamcatcher: small Five question | 18:44 |
| tziade | why is BrowserView based on Acquisition.Explicit ? | 18:44 |
| philiKON | tziade, for permission purposes | 18:45 |
| tziade | it gives us problems (efge@nuxeo speaking here) | 18:45 |
| dreamcatcher | to be able to evaluate security settings, otherwise the user folder where your user is defined wouldnt be reachable | 18:45 |
| philiKON | otherwise views won't be able to inherit a zope2 security context | 18:45 |
| dreamcatcher | it gives me problems too, we need to fix that eventually | 18:45 |
| tziade | hm... | 18:45 |
| philiKON | tziade, what kind of problems? | 18:45 |
| philiKON | tziade, because you want to use new-style stuff? | 18:45 |
| tziade | pb is that view.context is then weirdly wrapped | 18:45 |
| dreamcatcher | philiKON: acquisition problems | 18:46 |
| philiKON | tziade, well, yes, acquisition wrapped | 18:46 |
| tziade | I don't find the original aq-wrapping of the context | 18:46 |
| dreamcatcher | you get [<context>, <view>, <context>, <container>, <container-parent> ...] | 18:46 |
| dreamcatcher | in aq_chain | 18:46 |
| tziade | yes | 18:46 |
| tziade | ok I see the reasons, I'll try to work around the aq_chain in my code | 18:48 |
| tziade | thx | 18:48 |
| dreamcatcher | if you eventually find a better fix, let us know | 18:48 |
| tziade | ok will do | 18:49 |
| *** kinder has quit IRC | 18:49 | |
| *** vlado__ has quit IRC | 18:57 | |
| *** vlado has joined #zope3-dev | 18:58 | |
| tziade | ok the pb was in my tests, I added view = view.__of__(context) after creating it and before using it | 18:59 |
| *** Fosten has joined #zope3-dev | 19:03 | |
| tziade | ok the pb was in my tests, I added view = view.__of__(context) after creating it and before using it | 19:04 |
| tziade | bye all | 19:05 |
| *** tziade has left #zope3-dev | 19:05 | |
| *** vlado has quit IRC | 19:07 | |
| *** vlado has joined #zope3-dev | 19:08 | |
| *** alga has quit IRC | 19:16 | |
| *** alga has joined #zope3-dev | 19:16 | |
| *** dreamcatcher has quit IRC | 19:33 | |
| *** regebro has quit IRC | 19:34 | |
| *** Fosten has left #zope3-dev | 19:40 | |
| *** MalcolmC has quit IRC | 19:41 | |
| *** alga has quit IRC | 19:41 | |
| *** vlado has quit IRC | 19:44 | |
| *** mkerrin has left #zope3-dev | 19:47 | |
| *** mexiKON has joined #zope3-dev | 19:49 | |
| *** philiKON has quit IRC | 20:10 | |
| *** hazmat has joined #zope3-dev | 20:11 | |
| *** dreamcatcher has joined #zope3-dev | 20:13 | |
| *** mexiKON is now known as philiKON | 20:20 | |
| *** d2m has joined #zope3-dev | 20:31 | |
| *** alga has joined #zope3-dev | 20:39 | |
| *** dreamcatcher has quit IRC | 21:12 | |
| *** dreamcatcher has joined #zope3-dev | 21:14 | |
| *** dreamcatcher has left #zope3-dev | 21:16 | |
| *** jhauser_ has joined #zope3-dev | 21:30 | |
| *** jhauser has quit IRC | 21:40 | |
| *** tvon has quit IRC | 21:44 | |
| *** SteveA has quit IRC | 22:00 | |
| *** stub has quit IRC | 22:20 | |
| *** tvon has joined #zope3-dev | 22:38 | |
| *** hazmat has quit IRC | 23:09 | |
| *** hazmat has joined #zope3-dev | 23:13 | |
| *** hazmat is now known as haz-food | 23:14 | |
| *** tvon has quit IRC | 23:31 | |
| *** upsidedown has joined #zope3-dev | 23:31 | |
| *** upsidedown has left #zope3-dev | 23:38 | |
| * mgedmin has a problem | 23:44 | |
| mgedmin | I had a Data.fs that used zope.app.pau | 23:44 |
| mgedmin | I went to ++etc++site, unregistered the principal folder and LocalPAU, removed the registrations, removed the component | 23:45 |
| mgedmin | then I upgraded Zope 3 | 23:45 |
| mgedmin | then I went to ++etc++site, added LocalPluggableAuthentication and PrincipalFolder | 23:45 |
| mgedmin | but when I try to register the principal folder, I get a system error | 23:45 |
| mgedmin | Can't pickle <class 'zope.app.pau.interfaces.ISearchableAuthenticationPlugin'>: import of module zope.app.pau.interfaces failed | 23:46 |
| mgedmin | I do not understand where zope.app.pau comes from | 23:46 |
| mgedmin | recursive grep through the sources reveals that the only occurence of 'zope.app.pau' is in Data.fs | 23:46 |
| mgedmin | (in an old transaction, I assume) | 23:46 |
| mgedmin | field.interface in the request is zope.app.authentication.interfaces.ISearchableAuthenticationPlugin, according to the error log | 23:47 |
| * mgedmin is stumped | 23:47 | |
| J1m | I fear you have an entry for it in your utility service. | 23:50 |
| * J1m starts zope to investigate ... | 23:51 | |
| J1m | mgedmin, what happens if you go to your local utilities service? | 23:53 |
| *** haz-food is now known as hazmat | 23:53 | |
| *** ChanServ sets mode: +o hazmat | 23:53 | |
| J1m | mgedmin, ayt? | 23:54 |
| mgedmin | J1m, I do not see it in the local utilities service | 23:55 |
| mgedmin | besides, I removed the old PrincipalFolder, and zope3 wouldn't allow me to do that if it were used, would it? | 23:55 |
| J1m | I can't see your local utilities service, so, no I can't | 23:55 |
| mgedmin | that's why I had to explicitly unregister the registrations, then explicitly remove the registrations | 23:55 |
| J1m | Are you looking at: | 23:55 |
| J1m | http://localhost:8080/++etc++site/default/Utilities/@@utilities.html | 23:56 |
| mgedmin | and only then I could actually remove the principal folder and LocalPAU utility | 23:56 |
| J1m | ? | 23:56 |
| * mgedmin nods | 23:56 | |
| mgedmin | I see five utilities there | 23:56 |
| J1m | Do you see an entry for the principal folder? | 23:56 |
| mgedmin | error reporting, principal annotation, authentication (the one I just added), cliend id manager, session data container | 23:56 |
| mgedmin | that's all | 23:56 |
| mgedmin | no principal folders | 23:56 |
| mgedmin | neither there are any in /++etc++site/default/RegistrationManager/@@index.html | 23:57 |
| J1m | I think you'll have to delete and recreate your utilities service. | 23:57 |
| J1m | I think there is probably an empty entry in the utilities service containing a registration stack for the missing interafce. | 23:58 |
| J1m | I think there is probably an empty entry in the utilities service containing a registration stack for the missing interaface. | 23:58 |
| J1m | I think there is probably an empty entry in the utilities service containing a registration stack for the missing interface. | 23:58 |
| mgedmin | I have a backup of the Data.fs | 23:59 |
| J1m | The good news is that I think Stephan's work will do away with registration stacks | 23:59 |
| mgedmin | and I also have a copy of the old Zope3 tree | 23:59 |
| mgedmin | would I see that entry in the utilities service if I looked with the old Zope? | 23:59 |
| mgedmin | perhaps I could remove it then? | 23:59 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!