| *** niemeyer has quit IRC | 00:10 | |
| *** philiKON has quit IRC | 00:13 | |
| *** philiKON has joined #zope3-dev | 00:13 | |
| *** dobee has quit IRC | 00:21 | |
| *** gumpa-away has quit IRC | 00:40 | |
| *** mgedmin has quit IRC | 00:42 | |
| *** jinty has quit IRC | 00:44 | |
| *** fcorrea has left #zope3-dev | 00:51 | |
| *** niemeyer has joined #zope3-dev | 00:57 | |
| *** tonico has quit IRC | 00:58 | |
| *** dunny has quit IRC | 01:04 | |
| *** GaryPoster has quit IRC | 01:08 | |
| *** philiKON has quit IRC | 01:09 | |
| *** zbir has quit IRC | 01:14 | |
| *** russf has quit IRC | 01:15 | |
| *** philiKON has joined #zope3-dev | 01:18 | |
| *** natea has quit IRC | 01:29 | |
| *** projekt01 has joined #zope3-dev | 01:29 | |
| *** dunny has joined #zope3-dev | 01:58 | |
| *** yutakashino has joined #zope3-dev | 02:10 | |
| *** RaFromBRC|away is now known as RaFromBRC | 02:22 | |
| *** roman_ has quit IRC | 02:47 | |
| *** retsu__ has joined #zope3-dev | 03:14 | |
| *** rocky is now known as rocky|Zzz | 03:19 | |
| *** yutakashino has quit IRC | 03:40 | |
| *** yota has quit IRC | 03:56 | |
| *** jinty has joined #zope3-dev | 04:44 | |
| *** yutakashino has joined #zope3-dev | 05:30 | |
| *** jinty has quit IRC | 05:36 | |
| *** projekt01 has left #zope3-dev | 05:37 | |
| *** RaFromBRC has quit IRC | 06:07 | |
| *** rykomats has joined #zope3-dev | 06:21 | |
| *** benji has quit IRC | 06:36 | |
| *** povbot` has joined #zope3-dev | 07:12 | |
| *** povbot has quit IRC | 07:12 | |
| *** SteveA has quit IRC | 07:13 | |
| *** SteveA has joined #zope3-dev | 07:27 | |
| *** niemeyer has quit IRC | 07:39 | |
| *** retsu__ has quit IRC | 07:58 | |
| *** natea has quit IRC | 08:05 | |
| *** retsu__ has joined #zope3-dev | 08:06 | |
| *** natea has joined #zope3-dev | 08:06 | |
| *** febb has quit IRC | 08:30 | |
| *** RaFromBRC has joined #zope3-dev | 08:34 | |
| *** rykomats has quit IRC | 08:34 | |
| *** dobee has joined #zope3-dev | 08:35 | |
| *** philiKON has quit IRC | 08:44 | |
| *** SureshV has joined #zope3-dev | 08:51 | |
| *** eins has joined #zope3-dev | 08:52 | |
| *** dobee has quit IRC | 08:54 | |
| *** rocky|Zzz has quit IRC | 08:59 | |
| *** dobee has joined #zope3-dev | 09:31 | |
| *** hdima has joined #zope3-dev | 09:32 | |
| *** RaFromBRC has quit IRC | 09:40 | |
| *** russf has joined #zope3-dev | 09:42 | |
| *** retsu___ has joined #zope3-dev | 10:03 | |
| *** rykomats has joined #zope3-dev | 10:03 | |
| *** retsu__ has quit IRC | 10:09 | |
| *** tanghus has joined #zope3-dev | 10:13 | |
| *** jukart has joined #zope3-dev | 10:15 | |
| *** russf has quit IRC | 10:24 | |
| *** russf has joined #zope3-dev | 10:37 | |
| *** russf has quit IRC | 10:42 | |
| *** volvox has joined #zope3-dev | 12:02 | |
| *** romanofski has joined #zope3-dev | 12:18 | |
| romanofski | moin | 12:20 |
|---|---|---|
| *** vlado has joined #zope3-dev | 12:25 | |
| *** mkerrin has joined #zope3-dev | 12:29 | |
| *** Aiste has quit IRC | 12:39 | |
| *** rocky has joined #zope3-dev | 12:40 | |
| romanofski | hmpf... seems that the boston skin is missing from the zope 3.2 tarball on zope.org ?! | 12:45 |
| d2m | romanofski: true, and iirc the svn export of the skin wont work with the distribution | 12:47 |
| romanofski | oh.. alright | 12:47 |
| * romanofski checks again the 3.2 branch out | 12:48 | |
| *** dlk has joined #zope3-dev | 12:54 | |
| *** Aiste has joined #zope3-dev | 13:01 | |
| *** Pupeno has left #zope3-dev | 13:05 | |
| *** rock1 has joined #zope3-dev | 13:08 | |
| *** mgedmin has joined #zope3-dev | 13:08 | |
| *** rocky has quit IRC | 13:08 | |
| *** rock1 is now known as rocky | 13:08 | |
| *** J1m_ has joined #zope3-dev | 13:09 | |
| rocky | good morning | 13:10 |
| *** rock1 has joined #zope3-dev | 13:16 | |
| *** rocky has quit IRC | 13:20 | |
| *** rock1 is now known as rocky | 13:20 | |
| *** J1m_ has quit IRC | 13:26 | |
| *** jinty has joined #zope3-dev | 13:35 | |
| *** alga has joined #zope3-dev | 13:38 | |
| *** retsu___ has quit IRC | 13:49 | |
| *** dunny has quit IRC | 13:56 | |
| *** ignas has joined #zope3-dev | 14:04 | |
| *** nathany has joined #zope3-dev | 14:17 | |
| *** zbir has joined #zope3-dev | 14:25 | |
| *** yutakashino has quit IRC | 14:35 | |
| *** zagy has joined #zope3-dev | 14:39 | |
| *** yota has joined #zope3-dev | 15:15 | |
| *** philiKON has joined #zope3-dev | 15:31 | |
| *** J1m has quit IRC | 15:40 | |
| *** projekt01 has joined #zope3-dev | 15:46 | |
| *** alga has quit IRC | 15:46 | |
| *** GaryPoster has joined #zope3-dev | 16:21 | |
| *** jinty has quit IRC | 16:24 | |
| *** benji has joined #zope3-dev | 16:25 | |
| *** projekt01 has quit IRC | 16:27 | |
| *** jinty has joined #zope3-dev | 16:29 | |
| *** nathany_ has joined #zope3-dev | 16:30 | |
| *** nathany has quit IRC | 16:30 | |
| *** niemeyer has joined #zope3-dev | 16:31 | |
| *** nathany_ has quit IRC | 16:46 | |
| *** nathany_ has joined #zope3-dev | 16:47 | |
| *** jinty has quit IRC | 16:54 | |
| *** projekt01 has joined #zope3-dev | 16:59 | |
| projekt01 | GaryPoster, ayt? | 17:05 |
| GaryPoster | Hey, yes | 17:05 |
| projekt01 | do you know how the formlib get_rendered should work? | 17:05 |
| GaryPoster | not off-hand. lemme look. | 17:06 |
| projekt01 | This method is only working if setUpWidget is used. | 17:06 |
| *** alecm|away is now known as alecm | 17:06 | |
| projekt01 | It doesn' work with setUpInputWidget. I guess it's also useful with input forms. | 17:07 |
| projekt01 | or at least with AddForm's. | 17:07 |
| GaryPoster | So, one thing is that AIUI we eventually want to remove the non-setUpWidgets versions, because I think setUpWidgets can do the job of all of them | 17:08 |
| GaryPoster | I agree that it is a bug for the non-setUpWidgets to not have the get_rendered behavior | 17:09 |
| projekt01 | ok, perhaps we can add a setRenderedValue method in the form which is invoked if using get_rendered methods? | 17:09 |
| projekt01 | I guess if we use get_rendered this method should allways override also the field.default. | 17:10 |
| projekt01 | or not? | 17:10 |
| GaryPoster | The behavior in setUpWidgets is the desired behavior, and it seems that it should be portable to the other setUp*Widgets versions | 17:11 |
| GaryPoster | So my fix would be to change the setUp*Widgets to do the same thing. | 17:11 |
| GaryPoster | Does that make sense? | 17:12 |
| projekt01 | I guess if we use get_rendered, this method should allways the only one method which can set a value. | 17:12 |
| GaryPoster | In the default behavior, yes, I think that is right | 17:12 |
| GaryPoster | (it is form*lib* :-) ) | 17:13 |
| projekt01 | ;-) | 17:13 |
| *** efrerich has joined #zope3-dev | 17:13 | |
| projekt01 | Should we change this after the feature freeze? | 17:14 |
| GaryPoster | I think this is a bug: form fields offer the behavior in their API, but the behavior is only implemented if you use one of the possible form base classes. I'd argue it is a broken promise. | 17:15 |
| projekt01 | Hm, right, and I have a usecase for this. I guess this means that I should change it ;-) | 17:16 |
| GaryPoster | :-) sounds good to me | 17:16 |
| projekt01 | Do you think we should merge up the setUpWidget part now? | 17:17 |
| GaryPoster | ... | 17:19 |
| GaryPoster | I think that's too big of a change for this stage in the release process. | 17:20 |
| GaryPoster | I can ask Jim's opinion if you want, though | 17:20 |
| projekt01 | I guess not right now because I don't have to much time to write tests. | 17:21 |
| projekt01 | but I'll fix the usage of the get_render function now. Ok? | 17:22 |
| GaryPoster | well, arguably you would remove tests at most: tests should already exist for the base classes, which you would change to use setUpWidgets. If there are isolated tests for the setUp*Widgets, you'd remove them. | 17:23 |
| GaryPoster | But yes, just fixing get_render is fine by me | 17:23 |
| projekt01 | Ok, can you agree, if we use a get_render method this should be the only one which will set the value? | 17:24 |
| GaryPoster | yes | 17:24 |
| projekt01 | Ok, I will fix this. | 17:24 |
| projekt01 | thanks a lot | 17:24 |
| GaryPoster | np thank you | 17:25 |
| projekt01 | GaryPoster, which exception should I raise if get_rendered is set and readonly is True? | 17:29 |
| GaryPoster | Hm. This is when you are constructing the FormField? | 17:30 |
| GaryPoster | I don't think you need to raise an error | 17:31 |
| GaryPoster | look at setUpWidgets again-- | 17:31 |
| projekt01 | Yup, it's a result of a wrong form/field/interface construct. Probably a FormError? | 17:32 |
| GaryPoster | it uses get_rendered if ((we are ignoring the request, or it is readonly, or the widget doesn't have input) and form name is not in the data, and get_rendered is defined) | 17:33 |
| GaryPoster | therefore it is acceptable to set readonly to True and define a get_rendered | 17:33 |
| projekt01 | This should change to something like: | 17:35 |
| projekt01 | if form_field.get_rendered is not None: | 17:35 |
| projekt01 | if readonly: | 17:35 |
| projekt01 | raise interfaces.FormError(...) | 17:35 |
| projekt01 | elif ignore_request or readonly or not widget.hasInput(): | 17:35 |
| projekt01 | ... | 17:35 |
| projekt01 | or not? | 17:35 |
| *** gumpa has joined #zope3-dev | 17:35 | |
| projekt01 | This would make the get_rendered the *master* function and let ignore others if used. | 17:35 |
| projekt01 | Hm, this would mean that the get_rendered allways has to handle the form input. | 17:36 |
| GaryPoster | Ah, ok, so you want to change the behavior of setUpWidgets, and that is what you meant when you asked me "if we use a get_render method this should be the only one which will set the value?" | 17:37 |
| GaryPoster | No, I disagree then | 17:37 |
| GaryPoster | We need the behavior as is found in setUpWidgets. setUpWidgets should not need to be touched. | 17:37 |
| GaryPoster | For instance, in setUpInputWidgets | 17:38 |
| GaryPoster | Where now it is | 17:38 |
| projekt01 | Ok, I agree, this means we should use: | 17:38 |
| projekt01 | if form_field.get_rendered is not None and ignore_request: | 17:38 |
| projekt01 | if readonly: | 17:38 |
| projekt01 | raise interfaces.FormError(...) | 17:38 |
| projekt01 | elif ignore_request or readonly or not widget.hasInput(): | 17:38 |
| GaryPoster | if ignore_request: | 17:39 |
| GaryPoster | value = field.default | 17:39 |
| GaryPoster | widget.setRenderedValue(value) | 17:39 |
| *** jinty has joined #zope3-dev | 17:39 | |
| GaryPoster | if ignore_request: | 17:39 |
| GaryPoster | if form_filed.get_rendered is not None:value = field.default | 17:39 |
| GaryPoster | widget.setRenderedValue(value) | 17:39 |
| GaryPoster | Argh | 17:40 |
| GaryPoster | ignore that last one, I'll do it in an editor and paste it in | 17:40 |
| *** SureshV has quit IRC | 17:41 | |
| GaryPoster | if ignore_request: | 17:41 |
| GaryPoster | if form_field.get_rendered is not None: | 17:41 |
| GaryPoster | value = form_field.get_rendered(form) | 17:41 |
| GaryPoster | else: | 17:41 |
| GaryPoster | value = field.default | 17:41 |
| GaryPoster | widget.setRenderedValue(value) | 17:41 |
| projekt01 | Yes, that's correct for the setUpInputWidget. | 17:41 |
| GaryPoster | So what are you changing in your code snippet? :-) | 17:42 |
| projekt01 | But the setUpWidget follows other rules for get_rendered usage. | 17:42 |
| projekt01 | Does it really make sense if we use get_rendered and ignore this method in some usecase? | 17:42 |
| projekt01 | I guess if we use get_rendered, this is the method where is used in setRenderedValue. | 17:43 |
| projekt01 | I any usecase. otherwise it's confusing because of it's dependency on other parts. | 17:44 |
| GaryPoster | Let me say that back to you to see if I understand | 17:44 |
| projekt01 | ok | 17:44 |
| GaryPoster | If get_rendered is defined, and something else doesn't override it (as defined in the logic in the setUpWidgets code), it should provide the value for setRenderedValue | 17:45 |
| GaryPoster | Not all of the cases in setUpWidgets are pertinent to all of the setUp*Widgets, so the logic can be simpler in the other versions (e.g., the code I pasted) | 17:46 |
| projekt01 | what do you mean by something else override it? | 17:46 |
| GaryPoster | Just as I said before--use get_rendered if ((we are ignoring the request, or it is readonly, or the widget doesn't have input) and form name is not in the data, and get_rendered is defined) | 17:47 |
| projekt01 | I guess get_rendered should in any usecase do: | 17:47 |
| projekt01 | widget.setRenderedValue(form_field.get_rendered(form)) | 17:47 |
| projekt01 | otherwise we can't use the get_rendered method for override from.request values. | 17:48 |
| projekt01 | The question is, should get_rendered do this? | 17:48 |
| projekt01 | I think if get_rendered is responisbel for set the value in any case it's easier to understand what's going on. | 17:49 |
| GaryPoster | Ah! You want to override request values! You *want* to change the behavior in setUpWidgets! | 17:49 |
| projekt01 | No just that the get_rendered method is allways used. Which is the same if a request is given. | 17:50 |
| projekt01 | This means we need a default get_rendered which does handle the form.request values like now | 17:50 |
| projekt01 | So if no get_rendered is given we get the same behavior | 17:51 |
| projekt01 | But if a get_rendered method is used it will always be invoked. | 17:51 |
| GaryPoster | No, that's too big of a change, IMO. | 17:52 |
| GaryPoster | You want to do this on an individual field basis, so ignore_request is not good enough for you? | 17:52 |
| projekt01 | Ok, I agree, I didn't think of that at the beginning, but right now I think it's the correct behaviour. | 17:53 |
| projekt01 | It doesn't make sense to me that get_rendered sometimes is ignored. | 17:53 |
| projekt01 | I guess we have to think about that and perhaps write a proposal. | 17:54 |
| GaryPoster | If anything, perhaps it is a naming problem | 17:54 |
| GaryPoster | get_initial_rendered_value would be more apt | 17:55 |
| GaryPoster | if significantly more ugly | 17:55 |
| projekt01 | Yup, that is the behavior right now. But a post "setRenderedValue" concept is also missing? | 17:56 |
| GaryPoster | Well, that's changing what the user has typed/chosen, essentially...is that really what you want? | 17:57 |
| projekt01 | It whould let a developer to invoke a method for e.g. value conversion etc. | 17:58 |
| GaryPoster | Concrete example, maybe? | 17:58 |
| projekt01 | I need to set a value for a field if no value is given. | 17:58 |
| projekt01 | But not the default. | 17:59 |
| *** hdima has quit IRC | 17:59 | |
| projekt01 | This value comes form another instance | 17:59 |
| GaryPoster | set a value on the object, or in the form? | 17:59 |
| projekt01 | In the add or edit form. | 17:59 |
| projekt01 | Just provide a default value which is not defined in the interface. | 18:00 |
| projekt01 | This value comes from e.g. local utility | 18:00 |
| projekt01 | The main function is; if a edit form get reseted, the value from the utility schould be used in the edit form. | 18:02 |
| *** sawdog has joined #zope3-dev | 18:02 | |
| *** rykomats has quit IRC | 18:04 | |
| GaryPoster | And you don't want that value shown when the form is first drawn? | 18:05 |
| projekt01 | In the add form (initial) should the value get used from the utility for the new instance. | 18:06 |
| projekt01 | This could be done by what we discussed before | 18:06 |
| projekt01 | But the edit form should show the (default value stored in the utility) if I reset the form. | 18:07 |
| GaryPoster | What does "reset the form" mean in that context? | 18:10 |
| projekt01 | If I changed the values in the edit form and stored some "wrong" settings, | 18:10 |
| projekt01 | I can reset to some initial given values stored from the administrator in a utility | 18:11 |
| projekt01 | Let's say you have a complex input describing complex stuff and you changed this but it dodn't work. | 18:12 |
| projekt01 | Now you can get the initial working value back with " a kind of reset" form. | 18:13 |
| *** mexiKON has joined #zope3-dev | 18:14 | |
| projekt01 | I guess I will implement this part in the update method of my form. | 18:15 |
| projekt01 | Perhaps we can later think about a method like setRenderedValue() in fromlib | 18:17 |
| GaryPoster | (Sorry doing other things) Yes, that's what I would suggest. Maybe a proposal for the formlib change. I think I understand the use case, at least, although I would want to reset to the current values, not abstract values, which formlib allows | 18:17 |
| projekt01 | I have other usecases but they are to complex. Like a tree widget which I have to post process before I get a usefull value. | 18:18 |
| projekt01 | Ok, I will think about this part later. | 18:19 |
| GaryPoster | that again seems to be either the responsiblity of the form or of the widget. I do a lot of post-processing of form values, within the form code (i.e., no change to formlib needed) | 18:20 |
| projekt01 | Yes, that's correct but why not register such post process methods per widget rather then override the update method and doing it there? | 18:21 |
| *** philiKON has quit IRC | 18:21 | |
| projekt01 | The confusing part is the rendered_get method which suggest to do this for you. | 18:22 |
| GaryPoster | agreed, I think that is a problematic name, stemming from the | 18:22 |
| GaryPoster | eh, cross out the last three words ;-) | 18:22 |
| projekt01 | Ok, I think we should not change the formlib right now before we think again about this. | 18:24 |
| GaryPoster | OK, though I still agree that setUpInputWidgets et al should honor get_rendered the same way setUpWidgets does | 18:25 |
| projekt01 | As a kind of initial_get_rendered concept? | 18:26 |
| GaryPoster | right. So that the forms honor the interface of formfields | 18:27 |
| projekt01 | Ok, I can try to fix that. | 18:31 |
| GaryPoster | cool | 18:31 |
| *** eins has quit IRC | 18:36 | |
| *** vlado has quit IRC | 18:37 | |
| *** stub has quit IRC | 18:49 | |
| projekt01 | GaryPoster, can I change this: | 19:05 |
| projekt01 | def setUpInputWidgets(form_fields, form_prefix, context, request, | 19:05 |
| projekt01 | ignore_request=False): | 19:05 |
| projekt01 | to | 19:05 |
| projekt01 | def setUpInputWidgets(form_fields, form_prefix, context, request, | 19:05 |
| projekt01 | form=None, ignore_request=False): | 19:05 |
| GaryPoster | Oh, interesting | 19:05 |
| projekt01 | or should I define form=None inside the setUpWidget? | 19:06 |
| projekt01 | ;-) | 19:06 |
| GaryPoster | :-) | 19:06 |
| GaryPoster | No, we need the from to do this | 19:06 |
| GaryPoster | sorry from -- form | 19:08 |
| GaryPoster | I guess that change is reasonable | 19:08 |
| projekt01 | Ok I will run the tests and commit the changes, can double check it later? | 19:09 |
| GaryPoster | yes | 19:09 |
| *** volvox has quit IRC | 19:09 | |
| projekt01 | GaryPoster, it's in the trunk, let me know if I can merge it to the branch 3.3 | 19:17 |
| GaryPoster | k, will do. will try to ping you in an hour or so | 19:17 |
| projekt01 | Ok, I'm back later tonight, you can merge it or send me a mail if I'm not online. | 19:19 |
| GaryPoster | ok, will do. thanks | 19:19 |
| projekt01 | thanks to you | 19:19 |
| *** oferw has joined #zope3-dev | 19:56 | |
| *** oferw has quit IRC | 20:20 | |
| *** admp has joined #zope3-dev | 20:40 | |
| *** jinty has quit IRC | 20:44 | |
| *** d2m has quit IRC | 20:45 | |
| *** d2m has joined #zope3-dev | 20:46 | |
| *** d2m has joined #zope3-dev | 20:52 | |
| *** gumpa is now known as gumpa-away | 20:58 | |
| *** dlk has quit IRC | 21:00 | |
| *** nathany_ has quit IRC | 21:09 | |
| *** niemeyer_ has joined #zope3-dev | 21:11 | |
| *** niemeyer has quit IRC | 21:11 | |
| *** jinty has joined #zope3-dev | 21:14 | |
| *** jukart has left #zope3-dev | 21:16 | |
| *** niemeyer_ is now known as niemeyer | 21:16 | |
| *** mkerrin has quit IRC | 21:29 | |
| *** zbir has quit IRC | 21:31 | |
| *** RaFromBRC has joined #zope3-dev | 21:35 | |
| *** zbir has joined #zope3-dev | 21:37 | |
| *** benji has quit IRC | 21:43 | |
| efrerich | mexiKON: ayt? | 21:45 |
| *** admp has quit IRC | 21:53 | |
| mexiKON | efrerich, yes | 21:57 |
| efrerich | mexiKON: Con you close 555 in the Collector? (I changed the domain name) | 21:59 |
| efrerich | Con => Can | 21:59 |
| mexiKON | efrerich, sure. in what revisions on whatb ranches? | 22:00 |
| efrerich | a moment please | 22:02 |
| efrerich | 3.3: 68116 trunk: 68187 (hdima) I didn't know that there was a Collector issue | 22:07 |
| mexiKON | brb | 22:07 |
| *** dunny has joined #zope3-dev | 22:08 | |
| efrerich | I assume ther are more (old) issues which can be closed | 22:08 |
| efrerich | thx | 22:09 |
| *** ignas has quit IRC | 22:11 | |
| mexiKON | efrerich, done | 22:14 |
| *** efrerich has quit IRC | 22:21 | |
| mexiKON | does anyone know the difference between: | 22:41 |
| mexiKON | from pkgutil import extend_path | 22:41 |
| mexiKON | __path__ = extend_path(__path__, __name__) | 22:41 |
| mexiKON | and | 22:41 |
| mexiKON | import pkg_resources | 22:41 |
| mexiKON | pkg_resources.declare_namespace('zope') | 22:41 |
| mexiKON | ? | 22:41 |
| rocky | the latter is setuptools safe perhaps ? | 22:45 |
| mexiKON | i wonder whether they're compatible, incompatible or whether the setuptools one simply extends what the other one does | 22:46 |
| mexiKON | currently, zope3's zope/__init__.py does the pkg_resources thing | 22:46 |
| mexiKON | whereas zope2's zope/__init__.py does the pkgutil thing | 22:46 |
| *** Aiste has quit IRC | 22:57 | |
| rocky | my guess is pkg_resources is the clean setuptools way of doing it and pkgutil is the proprietary zope way | 23:00 |
| mexiKON | pkgutil is a std. python library | 23:00 |
| mexiKON | anyways, i wrote an email to the lists | 23:01 |
| rocky | oh, haha | 23:01 |
| rocky | sorry, i'm obviously clueless here | 23:01 |
| rocky | but i do know (or at least thought) pkg_resources belongs with the peak stuff | 23:01 |
| mexiKON | pkg_resources is setuptools stuff | 23:03 |
| mexiKON | part of the whole egg thing | 23:03 |
| rocky | right | 23:03 |
| rocky | peak stuff | 23:03 |
| mexiKON | :) | 23:05 |
| *** mgedmin has quit IRC | 23:09 | |
| *** Aiste has joined #zope3-dev | 23:25 | |
| *** niemeyer has quit IRC | 23:37 | |
| *** niemeyer has joined #zope3-dev | 23:39 | |
| *** zagy has quit IRC | 23:46 | |
| *** niemeyer has quit IRC | 23:59 | |
| *** niemeyer has joined #zope3-dev | 23:59 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!