*** SureshZ has quit IRC | 00:06 | |
*** MJ has quit IRC | 00:08 | |
*** MJ has joined #zope3-dev | 00:09 | |
*** tarek_ has quit IRC | 00:12 | |
*** clueck has quit IRC | 00:14 | |
*** tarek_ has joined #zope3-dev | 00:16 | |
*** srichter has joined #zope3-dev | 00:17 | |
*** ksmith has joined #zope3-dev | 00:19 | |
*** vlado_ has quit IRC | 00:19 | |
*** ChanServ sets mode: +o srichter | 00:22 | |
*** bskahan has quit IRC | 00:23 | |
*** tarek_ has quit IRC | 00:28 | |
*** tarek has joined #zope3-dev | 00:29 | |
*** povbot` has joined #zope3-dev | 00:38 | |
*** Aiste has quit IRC | 00:38 | |
*** Aiste has joined #zope3-dev | 00:39 | |
*** mnemoc has left #zope3-dev | 00:43 | |
*** povbot has quit IRC | 00:52 | |
*** J1m has quit IRC | 00:57 | |
yota | srichter: hein Stephan :) Twisted integration in Zope 3 is complete ? | 01:16 |
---|---|---|
srichter | not in the trunk | 01:17 |
srichter | mkerrin still needs to fix up the FTP support | 01:18 |
*** niemeyer has quit IRC | 01:18 | |
yota | must I learn twisted ? | 01:24 |
yota | because a book is out and I asked myself if I buy it | 01:24 |
srichter | no, you don't have to learn twisted | 01:31 |
srichter | the default installation will provide an extended zope.conf file that let's you setup the servers | 01:31 |
srichter | however, if you want to make use dsome of twisted's features, you need to learn twsited of course | 01:31 |
*** ksmith has left #zope3-dev | 01:38 | |
yota | srichter: do you think it's possible to implement new protocol with twisted/zope3 ? | 01:41 |
srichter | yep | 01:41 |
srichter | this will be one of the major advantages of the merge | 01:41 |
yota | fuck... graat! | 01:41 |
yota | s/aa/ea | 01:42 |
yota | zope3 will be a devil :] | 01:42 |
*** hazmat has quit IRC | 01:50 | |
*** Alef has quit IRC | 01:54 | |
*** jinty has joined #zope3-dev | 02:07 | |
*** yota has quit IRC | 02:29 | |
*** kaczordek has joined #zope3-dev | 02:59 | |
*** stub has joined #zope3-dev | 03:05 | |
*** gintas has quit IRC | 03:47 | |
*** _projekt01 has joined #zope3-dev | 04:19 | |
*** projekt01 has quit IRC | 04:19 | |
*** jinty has quit IRC | 04:28 | |
*** SureshZ has joined #zope3-dev | 04:39 | |
*** bskahan has joined #zope3-dev | 04:43 | |
*** _projekt01 has quit IRC | 04:59 | |
*** roym` has quit IRC | 05:04 | |
*** tarek has quit IRC | 05:12 | |
*** SureshZ has left #zope3-dev | 05:28 | |
*** bskahan has quit IRC | 05:34 | |
*** genconc has quit IRC | 07:59 | |
*** d2m has quit IRC | 08:00 | |
*** tvon|x31 has joined #zope3-dev | 08:13 | |
*** tvon has quit IRC | 08:13 | |
*** sashav has quit IRC | 08:27 | |
*** genconc has joined #zope3-dev | 09:16 | |
*** BjornT has quit IRC | 09:28 | |
*** tanghus has quit IRC | 09:37 | |
*** mexiKON has joined #zope3-dev | 09:48 | |
*** sashav has joined #zope3-dev | 09:49 | |
*** sashav_ has joined #zope3-dev | 09:56 | |
*** philiKON has quit IRC | 10:05 | |
*** sashav has quit IRC | 10:07 | |
*** yota has joined #zope3-dev | 10:10 | |
*** MJ has quit IRC | 10:15 | |
*** tvon|x31 is now known as tvon | 10:16 | |
*** BjornT has joined #zope3-dev | 10:19 | |
*** tanghus has joined #zope3-dev | 10:38 | |
*** tvon has quit IRC | 10:38 | |
*** ignas has quit IRC | 10:42 | |
*** MJ has joined #zope3-dev | 10:52 | |
*** projekt01 has joined #zope3-dev | 10:53 | |
*** ignas has joined #zope3-dev | 11:08 | |
*** niemeyer has joined #zope3-dev | 11:12 | |
projekt01 | srichter, ayt? | 11:18 |
*** seb__ has joined #zope3-dev | 11:25 | |
*** seb__ is now known as yotaff | 11:25 | |
*** tarek has joined #zope3-dev | 11:41 | |
*** lucia12345 has quit IRC | 12:02 | |
*** projekt01 has quit IRC | 12:02 | |
*** clueck has joined #zope3-dev | 12:10 | |
*** regebro has joined #zope3-dev | 12:21 | |
*** mgedmin has joined #zope3-dev | 12:27 | |
*** vinsci has quit IRC | 12:37 | |
*** ignas has quit IRC | 12:43 | |
*** ignas has joined #zope3-dev | 12:43 | |
*** vlado has joined #zope3-dev | 12:44 | |
*** vinsci|2 has joined #zope3-dev | 13:00 | |
*** vinsci|2 is now known as vinsci | 13:04 | |
*** clueck has quit IRC | 13:12 | |
*** projekt01 has joined #zope3-dev | 13:28 | |
projekt01 | srichter, ayt? | 13:52 |
srichter | in a bit | 13:53 |
srichter | I have to boot first | 13:53 |
projekt01 | I found a bug in the publisher's new implementation, can you help? | 13:53 |
srichter | yeah, I will in a bit | 13:53 |
projekt01 | There is a ascii to unicode convert problem | 13:53 |
projekt01 | body = ('%s\n<base href="%s" />\n%s' % | 13:53 |
projekt01 | (body[:index], self._base, body[index:])) | 13:53 |
projekt01 | ...take your boot time and tell me if you are ready ;-) | 13:54 |
srichter | ok | 13:54 |
*** vlado has quit IRC | 13:54 | |
*** regebro has quit IRC | 13:55 | |
mgedmin | projekt01, and what is the problem? | 14:01 |
mgedmin | 'ascii_string %s' % (unicode_string,) returns a unicode string | 14:02 |
*** Alef has joined #zope3-dev | 14:02 | |
mexiKON | oh geez, are we still inserting that <base /> junk??? | 14:02 |
mexiKON | argh, can't we get rid of that in the pbulisher and make it part of the skin, if it is all that necessary? | 14:02 |
SteveA | maybe it would help to get rid of default views | 14:03 |
mgedmin | mexiKON, you mean you want the standard page template to have <base tal:attributes="href ..." /> somewhere in it? | 14:03 |
mexiKON | why not? | 14:04 |
* SteveA says random stuff | 14:04 | |
mexiKON | i find it distrubing that the publisher mangles my HTML | 14:04 |
SteveA | you don't need the mangling if you never use default views | 14:04 |
SteveA | and always make sure that your URLs don't end in '/' | 14:05 |
SteveA | the publisher could do that | 14:05 |
*** andrew_m has left #zope3-dev | 14:05 | |
mexiKON | why not default views? | 14:05 |
mgedmin | mexiKON, relative links in /foo/container vs /foo/container/ vs /foo/container/index.html | 14:06 |
mexiKON | right | 14:06 |
SteveA | http://.../foo actually has http://.../foo/default-view published | 14:06 |
mexiKON | yup | 14:06 |
SteveA | i suppose defaullt views would be okay | 14:06 |
SteveA | if you always redirect from foo to foo/ | 14:06 |
*** stub has quit IRC | 14:06 | |
mexiKON | if self._base (see code snippet above) can be computed in the publisher, it can alsob e computed in a view class and be used by the template | 14:07 |
mexiKON | i'm just arguing that the place for <base /> right now isn't ideal | 14:07 |
mexiKON | SteveA, yup | 14:07 |
SteveA | make the default policy redirecting to ..../ | 14:07 |
mexiKON | SteveA, i was just about to suggest redirection | 14:07 |
SteveA | rather than using base | 14:07 |
SteveA | make an interface for views | 14:07 |
SteveA | IAmAViewThatKnowsAboutBase | 14:07 |
SteveA | and if the publisher publishes that, it doesn't redirect | 14:07 |
SteveA | or IAmAViewThatWantsMyBaseSet | 14:07 |
SteveA | for the publisher to do what it does now | 14:08 |
SteveA | there -- a 30 line proposal in the works | 14:08 |
SteveA | especially now that jim's looking at making views that want to be published provide an explicit interface | 14:08 |
SteveA | rather than the current vague interface | 14:08 |
mexiKON | we already have that | 14:08 |
mexiKON | IBrowserPUblisher for example | 14:08 |
SteveA | that is not an interface views provide to say "i am a publishable view" | 14:09 |
SteveA | the interface is vague | 14:09 |
mgedmin | I do not like IBrowserPublisher | 14:09 |
mexiKON | ok | 14:09 |
SteveA | it is "__call__ probably, and assume the result is unicode except when it isn't" | 14:09 |
mexiKON | i still think that zope.publisher sin't the right place to set <base /> | 14:09 |
mexiKON | even if we introduce a knob | 14:09 |
mexiKON | whatever that knob might be | 14:09 |
mexiKON | zope.publisher shouldn't know about html at all | 14:09 |
SteveA | okay | 14:09 |
mgedmin | agreed | 14:10 |
SteveA | okay... | 14:10 |
SteveA | so if a view provides not IAmAPublishableView | 14:10 |
SteveA | but IAmAViewThatWantsBaseSet | 14:10 |
SteveA | then the publisher adapts it to IAmAPublishableView | 14:10 |
SteveA | then the adapter can set base | 14:10 |
mexiKON | do we really want post-processing mangling? IIRC the cmf, plone, etc. have a <base /> in their skin templates | 14:11 |
SteveA | i think this conversation would be a good thing to capture in the form of a braindump proposal | 14:12 |
* mgedmin idly wonders if backwards compatibility is important here or not | 14:12 | |
SteveA | btw, launchpad now has facilities to track the metadata of specification for projects. | 14:12 |
mexiKON | mgedmin, that's a good question, but i think it can easily be tackled | 14:12 |
SteveA | mgedmin: not if it is to go into Zope 4 ;-) | 14:12 |
srichter | when I discussed the base thing with Jim, he just said: .... but it is sooo useful. | 14:13 |
SteveA | really though, the publisher is something that should be re-done | 14:13 |
mgedmin | Zope 3000 | 14:13 |
mexiKON | srichter, there are a lot of other things that are sooo useful | 14:13 |
mexiKON | still we don't do them for good reasons | 14:13 |
SteveA | it is a component, and we shouldn't be shy of reimplementing components | 14:13 |
SteveA | the problem at present is, the interface of published stuff is too vague | 14:14 |
SteveA | i'm +1 on making <base> more explicit | 14:14 |
SteveA | how that can be done is something that needs wider discussion | 14:14 |
SteveA | the best way would be a short proposal, and a ping to the list after that | 14:14 |
srichter | look, I am just giving you his opinion, nothing more | 14:15 |
* mexiKON wants generation of html where it belongs: in templates | 14:15 | |
mexiKON | srichter, yeah, no problem | 14:15 |
* SteveA puts a $10 bounty on a proposal for this | 14:16 | |
mexiKON | srichter, btw, already voted? ;) | 14:16 |
mexiKON | mgedmin, backward compat is pretty easy. right now, the publisher only inserts base if there isnt' a base in there already, so we update templates to generate the base, generate deprecation warnings in the publisher and remove it from the publisher in 2 releases | 14:18 |
SteveA | i'd say... make publisher generate base only for views that don't have an explicit "I'm a publishable view" interface | 14:19 |
SteveA | so ones that have that new thing never get <base> | 14:19 |
mexiKON | i'm not sure if that knob is appropriate | 14:20 |
mexiKON | a browser page from a template is could say "I'm a publishable view" and its skin macro still doesn't happen to provide <base /> | 14:20 |
mexiKON | in fact, some customizer comes in, supplies its own skin that doesn have <base />. then the browser page makes a false statement | 14:21 |
SteveA | ?? | 14:21 |
mexiKON | ok, lemme rewind | 14:22 |
SteveA | we're talking deprecation here. and new stuff shouldn't use deprecated features. IAmAPublishableView is new stuff. | 14:22 |
mexiKON | right | 14:22 |
mexiKON | but IAmAPublishableView has little to do with the skin macro it uses | 14:22 |
mexiKON | a browser page could provide IAmAPublishableView and still use a skin (because that's a deployment thing, a skin) that doesn't have <base /> | 14:23 |
mexiKON | plus, it seems to me a bit overengineered | 14:23 |
mexiKON | we just say that in the future, skin templates are required to handle <base /> themselves | 14:23 |
mexiKON | for a period of 2 releases, we still support older skin templates that don't have it | 14:24 |
projekt01 | I think it's a good idea that the page template is responsible for the <base /> tag. | 14:25 |
projekt01 | But how can I fix this encoding error right now? Any idea if there is more like this invoked? | 14:25 |
mexiKON | projekt01, can you post the error somewhere? | 14:25 |
mgedmin | projekt01, you did not answer my question | 14:25 |
projekt01 | mgedmin, sorry I didn't see it | 14:26 |
projekt01 | mexiKON, I try to reproduce it, it was on a customer server. | 14:26 |
mexiKON | *shrug* runniing the trunk on a customer server? | 14:27 |
projekt01 | mgedmin, ok, that's a good question, I try to setup it again... | 14:27 |
projekt01 | mexiKON, there is a test server because they use i818n with french. | 14:28 |
projekt01 | i818n/i18n | 14:29 |
mgedmin | projekt01, well, my question was "what is your problem" | 14:29 |
mgedmin | 'cause that line of code you quoted looks right to me | 14:29 |
mgedmin | (unless an 8-bit string appears somewhere) | 14:30 |
projekt01 | mgedmin, yes I setup the app on my workspace, will take a couple minutes, I'm right back with the error message. | 14:30 |
projekt01 | mgedmin, there is a asscii encoding error | 14:30 |
*** jinty has joined #zope3-dev | 14:33 | |
*** stub has joined #zope3-dev | 14:33 | |
SteveA | is self._base unicode? | 14:34 |
mexiKON | self._base is request.getURL() | 14:37 |
SteveA | so, that'll be unicode i think | 14:38 |
SteveA | hence the encoding error | 14:38 |
SteveA | ascii should not be miscable with unicode. | 14:38 |
SteveA | that has been a problem for python since unicode was introduced | 14:38 |
mgedmin | SteveA, you get encoding errors if and only if you mix two strings with non-ASCII characters -- one unicode string, one 8-bit string | 14:38 |
SteveA | a solution for zope would be to insist that no non-unicode comes back from views | 14:39 |
SteveA | now, the IAmAPublishableView interface would help here | 14:39 |
mgedmin | pure 7-bit ascii strings are completely interchangeable with unicode strings that only have ascii chars | 14:39 |
SteveA | as the interface would no longer be vague | 14:39 |
mgedmin | everywhere (except zope.schema) | 14:39 |
mgedmin | SteveA, what about serving binary files? | 14:39 |
SteveA | also, using a bytesdata() type explicitly for non-unicode stuff | 14:39 |
SteveA | would help a lot | 14:39 |
mgedmin | restricting views to unicode is not a solution | 14:39 |
SteveA | i'm not saying that | 14:39 |
SteveA | i'm saying that the interface should be clear and specific | 14:40 |
SteveA | perhaps the interface would say "always return something along with its encoding" | 14:40 |
SteveA | or it would say "IAmAPublishableUnicodeProvidingView" | 14:40 |
SteveA | and there would be another to provide bytes | 14:40 |
SteveA | the bytes / unicode thing has caught launchpad folk out before now | 14:40 |
SteveA | for example, generating RDF stuff, setting the content type to application/xml-rfd | 14:41 |
mgedmin | do you think that restricting a single view to only one or the other is reasonable? | 14:41 |
SteveA | and the publisher expects a string, not unicode | 14:41 |
SteveA | so, when you return unicode, it barfs a lot | 14:41 |
*** Alef has quit IRC | 14:41 | |
SteveA | yes, a view should return either unicode or bytesdata | 14:41 |
* mgedmin agrees that views like /get?doc=file.txt, /get?doc=file.png are ugly | 14:42 | |
SteveA | that view needs to take responsibility for saying what charset / encoding it will use | 14:42 |
SteveA | so, no problem there | 14:42 |
SteveA | it just needs to take responsibility | 14:42 |
* mexiKON wonders why the str type doesn't suffice for bytesdata | 14:42 | |
SteveA | or, have an API to tell the publisher when the publisher should take responsibility and when it should not | 14:42 |
mgedmin | mexiKON, the problem is that sometimes you use str for pure ASCII data, and sometimes you use str for bytesdata | 14:43 |
SteveA | mexiKON: because people do not consistently use unicode for "human readable text strings" | 14:43 |
mgedmin | there ought to be two distinct types | 14:43 |
mexiKON | there are. unicode and str | 14:43 |
mgedmin | it is OK to mix Unicode and str-that-is-absolutely-guaranteed-to-only-contain-ascii-data | 14:43 |
SteveA | mexiKON: python basically encourages you to use ascii strings for human readable ascii text | 14:43 |
SteveA | python is flawed here | 14:43 |
mgedmin | it is a BUG if you mix Unicode and str-that-might-sometimes-contain-nonascii-data | 14:43 |
mexiKON | ok, so it should be discouraging | 14:43 |
mexiKON | mgedmin, right | 14:43 |
SteveA | so, zope should work around it by providing a bytesdata type | 14:43 |
SteveA | so people can use unicode OR bytesdata | 14:44 |
SteveA | and plain str becomes deprecated, for publishing | 14:44 |
mexiKON | IMO, mixing str and unicode should never have been allowed. such things as sys.defaultencoding etc. are just plain evil | 14:44 |
projekt01 | mgedmin, on my machine is everything working ??? | 14:44 |
mgedmin | projekt01, do you have a traceback somewhere in a logfile perhaps? | 14:46 |
mgedmin | mexiKON, +1 for sys.defaultencoding | 14:46 |
mgedmin | mexiKON, +1 for sys.defaultencoding being EEEEVIL | 14:46 |
projekt01 | mgedmin, I will check the z3 trunk verison | 14:46 |
projekt01 | mgedmin, Ok I go to get it. | 14:46 |
mgedmin | mexiKON, -1 for requiring me to sprinkle my source code with u'...' when all I need is a pure ASCII string constant | 14:46 |
mexiKON | agreed | 14:47 |
wiggy | can't you tell python everything in your script is unicode? | 14:47 |
mexiKON | but notice that that ASCII string constant is really bytes... like in C, a chain of characters | 14:47 |
mgedmin | that's an implementation detail I do not care about | 14:47 |
mgedmin | for all I care it could pack 8 7-bit characters into 7 bytes of memory | 14:48 |
mexiKON | well, it's not | 14:48 |
mexiKON | you want an ascii constant | 14:48 |
mexiKON | you make it either unicode or bytesdata (==str) | 14:48 |
SteveA | bytesdata derives from str | 14:48 |
* mgedmin wishes for an asciistr type that raises exceptions when you try to get 8-bit characters into it | 14:48 | |
mexiKON | right, that is feasible | 14:49 |
mexiKON | have asciistr, str, unicode | 14:49 |
mgedmin | is basestring an abstract class? | 14:49 |
mexiKON | i think so | 14:50 |
mexiKON | >>> basestring('') | 14:51 |
mexiKON | Traceback (most recent call last): | 14:51 |
mexiKON | ... | 14:51 |
mexiKON | TypeError: The basestring type cannot be instantiated | 14:51 |
mgedmin | then maybe we could have an asciistring type that is a subclass of basestring and a superclass of both str and unicode | 14:51 |
mgedmin | it can be automatically promoted to either of them | 14:52 |
SteveA | having asciistr isn't useful i think | 14:52 |
mgedmin | sadly, forbidding any combination of str and unicode would break backwards compatibility | 14:52 |
SteveA | because 'foo' is still a str | 14:52 |
mgedmin | unless from __future__ import pure_strings? | 14:52 |
* mgedmin is way out of his depth and will shut up now | 14:53 | |
SteveA | lunchtime, lithuanians | 14:53 |
mexiKON | mgedmin, +1 for pure_strings | 14:54 |
mexiKON | foo = '' | 14:54 |
mexiKON | type(foo) == asciistr | 14:54 |
mexiKON | foo = b'' | 14:54 |
mexiKON | type(foo) == str == bytesdata | 14:54 |
* mexiKON goes to lunch | 14:55 | |
*** andrew_m has joined #zope3-dev | 14:59 | |
projekt01 | mgedmin, I cant' reproduce it, on the customer test server is everything OK after restart. | 15:01 |
projekt01 | mgedmin, Is it possible that a runtime error happens and required a restart? The view which runs into the error is working well. | 15:03 |
*** benji_york has joined #zope3-dev | 15:15 | |
*** tvon has joined #zope3-dev | 16:03 | |
*** stub has quit IRC | 16:07 | |
*** mexiKON is now known as philiKON | 16:10 | |
projekt01 | benji_york, do you know the zpkg well? | 16:37 |
benji_york | nope, I need to learn it, but haven't yet | 16:39 |
projekt01 | perhaps you can answer a question. Is it possible to use zpkg for export a workspace described in a source map and use the exported tar extract for building another installer? | 16:41 |
philiKON | projekt01, the tar already contains an installer | 16:42 |
benji_york | hmm, I really don't know | 16:42 |
projekt01 | Yes, I know, but I like to use another one. | 16:42 |
projekt01 | another/better ;-) | 16:42 |
philiKON | zpkg's tar archives are really designed to be used with the zpkg installer | 16:43 |
*** anguenot has joined #zope3-dev | 16:44 | |
projekt01 | but the zpkg installer isn't good a installer since it will install everything to the python install dir and you can't have different version | 16:44 |
projekt01 | It's more a UI for a install script ;-) | 16:45 |
*** fdrake has joined #zope3-dev | 16:45 | |
philiKON | projekt01, that's not true | 16:46 |
philiKON | projekt01, by *default*, IOW, if you give install.py no other arguments, it installs into python site-packages | 16:46 |
philiKON | projekt01, but you can specify --home | 16:46 |
philiKON | e.g. python install.py --home=/usr/local/Zope-3.1.0 | 16:46 |
philiKON | projekt01, in fact, the generated Makefile (it's generated by the configure script) does exactly that | 16:47 |
projekt01 | philiKON, I can't install z3 3.1 and 3.2 for python 2.4 with the installer! | 16:47 |
philiKON | ? | 16:47 |
philiKON | sure you can | 16:47 |
philiKON | try the line i gave you above | 16:47 |
projekt01 | both of then install the source to the python 2.4 location | 16:47 |
projekt01 | Ah, Ok, I have to try this | 16:48 |
philiKON | the --home switch changes the installation target | 16:48 |
fdrake | projekt01, what's the right way to tell Subversion to run in an alternate locale? I tried "LANG=de svn help", but that failed (it told me it couldn't set the locale). | 16:49 |
fdrake | it might be I just don't have the alternate locales installed on my Ubuntu box, also | 16:50 |
*** deo has joined #zope3-dev | 16:50 | |
projekt01 | fdrake, I don't know, I'm also not sure why on my windows some messages are in german and some in english, reported form the command "svn cat path" | 16:50 |
philiKON | fdrake, afaik LANG is the right env var | 16:50 |
philiKON | fdrake, you probably indeed need to install svn locales | 16:51 |
fdrake | the language mix is likely incomplete i18n/l10n in svn | 16:51 |
projekt01 | fdrake, I think so | 16:51 |
projekt01 | fdrake, did you see my other question about using the zpkg in relation to another install builder? | 16:53 |
* fdrake is trying to figure out what he needs to install... | 16:53 | |
projekt01 | This bugfix is working for me: | 16:54 |
projekt01 | if "directory" in err or "Verzeichnis" in err: | 16:54 |
projekt01 | ;-) | 16:54 |
fdrake | that won't help anyone from Nuxeo, though, would it? ;-) | 16:55 |
projekt01 | No, let add them the french word for directory ;-) | 16:55 |
philiKON | fdrake, maybe zpkg should set the LANG env var to 'C' for svn | 16:56 |
projekt01 | Really bad that no code get reported there additional to the message. | 16:56 |
projekt01 | Is there no other way to find the difference between directory and files? | 16:57 |
fdrake | that's likely more reliable than me figuring out how to set locales properly, and get translations installed | 16:57 |
fdrake | "svn info" only works on checked-out stuff | 16:58 |
philiKON | fdrake, btw, ever thought about using the subversion python bindings? | 16:58 |
fdrake | and that code is trying to figure out what to do with what's going to be checked out | 16:59 |
fdrake | i hadn't, since they might not be installed | 16:59 |
fdrake | also, Jim's made them segfault a bit while playing with them lately | 16:59 |
philiKON | :( | 16:59 |
projekt01 | Ok | 16:59 |
fdrake | they're built using SWIG, which I consider reason enough to avoid them | 16:59 |
projekt01 | I think a lang env would be OK for now. | 16:59 |
fdrake | can you try running zpkg w/ LANG=C for now, and let me know if it fixes that problem for you? | 17:00 |
philiKON | fdrake, yeah | 17:00 |
projekt01 | philiKON, perhaps python bindings are a good idea for this. | 17:00 |
projekt01 | Lang=C, you mean LANG=DE | 17:01 |
fdrake | no, LANG=C, to avoid the localization | 17:01 |
fdrake | i'm searching for a string in the output | 17:01 |
fdrake | that string gets translated if I do nothing | 17:01 |
projekt01 | Ah, Ok let me setup and try it, I will come back to you later | 17:01 |
fdrake | ok | 17:02 |
philiKON | fdrake, btw: http://paste.plone.org/3901 | 17:02 |
philiKON | so, LANG=de isn't enough | 17:02 |
philiKON | needs to be de_DE | 17:02 |
*** sashav_ has quit IRC | 17:02 | |
fdrake | philiKON, LANG=de_DE doesn't work for me, so I'm probably missing some bit of locale support | 17:08 |
philiKON | prolly | 17:08 |
fdrake | LANG=C works fine though :-) | 17:08 |
projekt01 | fdrake, can you tell me the command where you are suing with LANG=C ? | 17:13 |
fdrake | LANG=C svn help | 17:15 |
fdrake | (LANG=C should use the untranslated text straight from the executable, so it should work for everyone) | 17:15 |
philiKON | projekt01, are you on windows? | 17:15 |
projekt01 | Yup | 17:15 |
mgedmin | fdrake, you might want to use LC_ALL=C | 17:16 |
mgedmin | as far as I understand POSIX, LC_MESSAGES overrides LANG, while LC_ALL overrides both LC_MESSAGES and LANG | 17:16 |
philiKON | projekt01, set LANG=C | 17:16 |
fdrake | ah, even better | 17:16 |
mgedmin | (and then there's GNU's non-POSIX $LANGUAGE which overrides everything...) | 17:16 |
projekt01 | Ok set LANG=C is working | 17:17 |
projekt01 | svn: URL 'svn://svn.zope.org/repos/main/Zope3/tags/Zope-3.1.0b1/zopeskel' refers to a directory | 17:17 |
projekt01 | is the reported message | 17:17 |
projekt01 | no "Verzeichnis" anymore | 17:18 |
philiKON | not having used the zope 3 catalog, how does it do less than zope 2's zcatalog as it is always said? | 17:18 |
*** kaczordek has quit IRC | 17:19 | |
*** deo has quit IRC | 17:19 | |
projekt01 | fdrake, did you see my question about using the exported build source for another installer? | 17:19 |
fdrake | i see the emails, but haven't read them all yet | 17:20 |
fdrake | one thing at a time :-) | 17:20 |
*** regebro has joined #zope3-dev | 17:22 | |
projekt01 | no problem | 17:22 |
fdrake | one down, and the kids only got into one fight... | 17:30 |
andrew_m | can it be that something with ftp is broken in zope svn? something with "__call()__ takes 3 arguments.. " when trying to connect.. | 17:31 |
srichter | projekt01: are you getting my private messages to you? | 17:33 |
projekt01 | yes, I'm reading the source.... | 17:34 |
srichter | ok | 17:34 |
fdrake | projekt01, have you looked at the -t command line option for zpkg? | 17:35 |
projekt01 | no, what's that? | 17:35 |
fdrake | it builds the tree w/out making a tarball | 17:36 |
fdrake | would that help with what you're doing? | 17:36 |
fdrake | your message wasn't very clear; sorry. | 17:36 |
projekt01 | Ok, and how can I build a distribution form that source? with build_ext? | 17:37 |
*** ignas has quit IRC | 17:37 | |
fdrake | This is where I got confused; I'm not sure what you're trying to do. | 17:37 |
*** ignas has joined #zope3-dev | 17:37 | |
fdrake | That tree is essentially an unpacked source distribution as it is. | 17:38 |
projekt01 | I like to use the zpkg for asamble a source from different repositories and this exports use to build a running version | 17:38 |
fdrake | Everything that distutils can do should already be supported. | 17:38 |
projekt01 | It looks very different with all this own folders for sub-packages. | 17:38 |
fdrake | you want to run directly from the zpkg-constructed tree? | 17:38 |
projekt01 | Yes | 17:39 |
fdrake | I'm afraid that was never a use-case for zpkg here. | 17:39 |
projekt01 | Yes, I see | 17:39 |
fdrake | Your best bet is to install from that tree, or build a platform package. | 17:40 |
fdrake | bdist_dumb, or bdist_wininst | 17:40 |
projekt01 | Then zpkg doesn't export the code in a usable way for build and running it out of the exported structure | 17:41 |
fdrake | you can build using "python setup.py build" | 17:41 |
fdrake | but that just compiles things and copies the package tree intro build/* | 17:41 |
projekt01 | Yes, that's what I'm looking for. | 17:42 |
fdrake | but that doesn't look like an installation either | 17:42 |
fdrake | (but closer) | 17:42 |
fdrake | you can use "python setup.py install --home <target>" to install outside the Python installation | 17:43 |
fdrake | might require Python 2.4 on Windows | 17:43 |
projekt01 | I just need a working/running build | 17:43 |
fdrake | I *think* that's when I added that. | 17:44 |
projekt01 | Ok, I use Python 2.4 | 17:44 |
fdrake | we're going to be looking at creating a "build-out" mechanism that uses zpkg to do some of the work | 17:45 |
fdrake | but I don't know just when | 17:45 |
fdrake | hopefully Benji and I will have time to talk about it next week to figure out how we want it to work | 17:46 |
projekt01 | Is this not correct, zpkg is exporting source code from different repositories defined in map's to one workspace. In a next step you can build a distribution. | 17:46 |
fdrake | Guess you missed my zpkg presentation at Wednesday's Fredericksburg ZPUG. :-) | 17:46 |
fdrake | That is not correct. | 17:46 |
projekt01 | of corse ;-( | 17:46 |
andrew_m | error: uncaptured python exception, closing channel <zope.server.ftp.server.FTPServerChannel connected 127.0.0.1:55132 at 0x408787cc>(exceptions.TypeError:__call__() takes exactly 3 arguments (4 given) [/home/andrew/opt/ZopeX3-svn/src/zope/server/linereceiver/linetask.py|service|43] [/home/andrew/opt/ZopeX3-svn/src/zope/server/ftp/server.py|cmd_cwd|175] [/home/andrew/opt/ZopeX3-svn/src/zope/server/ftp/publisher.py|type|45] [/home/andrew/opt/ | 17:47 |
andrew_m | ZopeX3-svn/src/zope/server/ftp/publisher.py|_execute|108]) | 17:47 |
fdrake | zpkg exports lots of different packages from various repositories (including the local disk) into separate workspaces (for zpkg purposes), and then knits material from those into a distribution | 17:47 |
andrew_m | any ideas anyone? | 17:47 |
projekt01 | fdrake, the first part is Ok, but is there no good way to use this workspace/export as a base for other install builder tools? that's what I'm looking for. | 17:49 |
srichter | andrew_m: yep, it's a failure due to the publisher refactorings | 17:49 |
fdrake | I don't think so. | 17:49 |
srichter | andrew_m: somewhere an outstream is specified where it is not expected | 17:50 |
fdrake | Most of the time you can point zpkg to existing checkouts, which can be shared with a working environment for development or distribution building. | 17:50 |
andrew_m | srichter: aha.. and can you think of a quick and dirty fix? this happens with a fresh svn checkout of zope / fresh instance when connecting via ftp | 17:50 |
fdrake | but that doesn't need zpkg | 17:50 |
srichter | andrew_m: find the spot where it happens, don't pass in the outstream and check in the fix with a test ;-) | 17:51 |
projekt01 | fdrake, I'm interested in the dependency where get recognized by the zpkg and will get automaticly exported. | 17:51 |
andrew_m | srichter: sounds neither quick nor dirty | 17:52 |
andrew_m | ;) | 17:52 |
fdrake | projekt01, look in zpkgtools/app.py in build_distribution() | 17:54 |
srichter | andrew_m: it will be the only way | 17:54 |
srichter | andrew_m: you should not be afraid of fixing bugs | 17:54 |
andrew_m | srichter: any idea if that problem is also there in 3.1 RC2? | 17:55 |
*** ignas has quit IRC | 17:56 | |
srichter | andrew_m: definitely not; this error is due to recent publisher changes | 17:57 |
andrew_m | srichter: ok, thanks.. we'll revert to RC2 here then for now | 17:58 |
projekt01 | fdrake, Ok, when is this method used and what's the result? | 17:58 |
projekt01 | srichter, is there a named sample or did I overlook it? | 18:00 |
*** d2m has joined #zope3-dev | 18:00 | |
srichter | andrew_m: you should at least report the problem in the collector | 18:00 |
srichter | otherwise 3.2 will be broken for you too | 18:00 |
srichter | projekt01: I am still finishing the named code | 18:01 |
andrew_m | i will | 18:01 |
projekt01 | srichter, ah Ok, it looks very clean right now | 18:01 |
srichter | projekt01: you mean the "pagelet" namespace, right? | 18:01 |
projekt01 | yes | 18:01 |
srichter | I have this ready in a few moments | 18:02 |
projekt01 | there is only pagelets: used in the sample. right? | 18:02 |
projekt01 | cool | 18:02 |
fdrake | projekt01: that's the main function that builds the output tree; it's called from the run() method | 18:02 |
projekt01 | fdrake, Ok, but not runnable in some way | 18:02 |
srichter | projekt01: yep | 18:04 |
projekt01 | drake, this means the zpkg isn't usable for doing only the first step (assamble code from repostories defined in maps) for other install builders. | 18:04 |
fdrake | I'm not surprised. The tree zpkg puts together is a bit on the strange side from where I stand. Jim and I have spent a lot of time hashing this out, and I'm not sure that either of us are really happy with it (though I suspect Jim is happier with it than I am). | 18:05 |
projekt01 | fdrake, because the logic of this exported structure is only known in additional python code (means only zpkg knows how to build a ditribution) | 18:06 |
projekt01 | ;-) | 18:06 |
fdrake | right | 18:06 |
fdrake | I'd be happy to see suggestions for improvements. I'd like to encourage you to write up a preferred tree structure and post to the zpkg mailing list about it. | 18:07 |
projekt01 | I don't care about the tree structure. For me it is much more important what I can do with this structure with less then possible coding. | 18:08 |
fdrake | Then what you want is a much simpler structure, right? | 18:09 |
projekt01 | I like to see that the very usefull collection part of zpkg is useable for other tasks. | 18:09 |
projekt01 | Why do we not use the same structure like the repositories have? | 18:10 |
projekt01 | This source is running out of the box after build the C-extensions | 18:11 |
fdrake | Jim wanted to keep each component separately installable, so each one actually includes a setup.py with everything it needs. | 18:11 |
fdrake | If we drop that requirement, then we can have a tree that's much simpler and more usable for other tasks. | 18:11 |
projekt01 | Ah, that's why we get a very proprietary structure. | 18:12 |
fdrake | Yes. | 18:12 |
fdrake | The distribution itself is unusable for anything but installation as a result. | 18:13 |
projekt01 | I'm not sure if it's possible to use a simply structure, but if so, we can use zpkg for other tasks too. | 18:13 |
fdrake | I consider this unfortunate myself, but that's personal opinion. | 18:13 |
projekt01 | I really, really like to see zpkg working for running checkouts where dependency get correct recognized ;-) | 18:14 |
projekt01 | The other (build dist) part should be decoupled in some way | 18:14 |
fdrake | We probably could use a simpler structure, but we'd have to handle metadata differently in the distribution than in the checkouts (at least somewhat). | 18:14 |
projekt01 | Then the SETUP.cfg and DEPENDENCY.cfg make more sense to me. | 18:14 |
fdrake | currently, SETUP.cfg is only needed at build/install time; it's used to drive distutils. | 18:15 |
fdrake | DEPENDENCIES.cfg is only used for distribution construction, but defines constraints on future versions of the implementation | 18:16 |
fdrake | PACKAGE.cfg is strictly a distribution construction thing, and can (and should!) be avoided for most things | 18:17 |
projekt01 | Does zpkg provide a "install additional packages" for a installed z3 concept? | 18:17 |
fdrake | PUBLICATION.cfg is similar | 18:17 |
fdrake | not sure what you mean | 18:17 |
fdrake | as in "install more stuff into my Z3 installation", or "install more stuff into my Z3 instance"? | 18:18 |
projekt01 | Can you use zpkg for checkout additional z3 packages like the ldap package at svnzope.org | 18:18 |
projekt01 | "install more stuff into my Z3 instance" | 18:19 |
fdrake | if it's in CVS or SVN, it should be able to use it | 18:19 |
fdrake | that depends on what you want done with ZCML slugs | 18:19 |
projekt01 | that's what admins will do ;-) | 18:19 |
fdrake | currently, ZCML slugs get installed into zopeskel/etc/package-includes/, which only makes sense for the installation | 18:20 |
fdrake | if the SETUP.cfg for a package says to use etc/package-includes/ instead, it should be installed into the instance | 18:21 |
fdrake | I think it's a problem that you have to make that decision in the package, but that's the current state | 18:21 |
projekt01 | you mean if you checkout additional packages with zpkg to a instance? | 18:21 |
projekt01 | Yup, I agree, this should be a checkout descision | 18:21 |
fdrake | no; this is an installation thing; you don't checkout packages into instances | 18:21 |
fdrake | either way, it's installation of the package | 18:22 |
projekt01 | sorry, I mean checkout a package with zpkg into a instance. (install) | 18:22 |
fdrake | the current pattern should be: | 18:22 |
fdrake | 1. install Z3 from the distro | 18:22 |
fdrake | 2. install any additional packages you want to share among instances | 18:23 |
fdrake | 3. create instances | 18:23 |
fdrake | 4. install instance-specific packages | 18:23 |
fdrake | you control where packages get installed (in all cases) using "python setup.py install --home <where>" | 18:24 |
fdrake | but which installations will make sense depends on how ZCML slugs are destined based on SETUP.cfg | 18:24 |
projekt01 | you say in step 4.) you can install additional packages to a specific instance, right? | 18:25 |
fdrake | I have some ideas on how to improve that, but it means the zpkg "runtime" portion remains involved in installation, or something gets added in Z3 as a helper for package installation | 18:25 |
fdrake | right | 18:26 |
fdrake | those packages need to specify etc/package-includes/ as the destination for ZCML slugs, though | 18:26 |
projekt01 | Then I can install the z3 trunk itself to a location without the build step, right? | 18:26 |
fdrake | you can use "python setup.py install --home <instance>" to add packages to an instance | 18:26 |
projekt01 | It's more a zpkg and SETUP.cfg controlled checkout. | 18:27 |
fdrake | the build step is implied by the install step for distutils | 18:27 |
fdrake | like Z3 itself? | 18:28 |
projekt01 | Yes, but do the dependency get recognized with install --home. I don't think so? | 18:28 |
fdrake | dependencies are handled when the distribution is built, and only then | 18:28 |
projekt01 | Do you know the active state perl installer? | 18:28 |
fdrake | nope | 18:28 |
projekt01 | perhaps there is anpther name for this package tool or whatever this is called. | 18:29 |
*** J1m has joined #zope3-dev | 18:29 | |
projekt01 | Ok, I try the install --home option and try to use this source for use a different install builder. | 18:31 |
fdrake | that's probably your best bet for now | 18:32 |
*** sashav has joined #zope3-dev | 18:34 | |
projekt01 | Hope to see zpkg produce reusable workspace source in the future ;-) | 18:34 |
projekt01 | fdrake, many thanks | 18:34 |
fdrake | np | 18:35 |
projekt01 | fdrake, or perhaps we have to start a that tool we spoke about with benji_york for checkout project based source code from repositories. | 18:36 |
projekt01 | I guess a project based source code checkout and build tool would be very useful | 18:38 |
*** GaryPoster has joined #zope3-dev | 18:39 | |
fdrake | yes, it would be | 18:40 |
J1m | srichter, ayt? | 18:40 |
fdrake | in fact, we have such a thing internally | 18:40 |
fdrake | still might not be what you're looking for, though :-) | 18:40 |
*** GaryPoster has quit IRC | 18:41 | |
*** GaryPoster has joined #zope3-dev | 18:43 | |
benji_york | fdrake and projekt01, it's not internal any more, the buildout was put up on the sandbox a couple days ago, I intend do announce its availability today | 18:43 |
srichter | J1m: yep | 18:43 |
fdrake | cool! | 18:43 |
J1m | srichter, what are the plans for 3.1? | 18:45 |
srichter | oh, darn, I totally forgot | 18:46 |
fdrake | that's a good plan :-) | 18:46 |
projekt01 | benji_york, cool, does buildbot support additional repositories? | 18:47 |
srichter | I was going to ask again if anyone needed to make more chackins for RC3? | 18:47 |
fdrake | srichter: not me | 18:47 |
srichter | GaryPoster: benji_york: fdrake: Are you guys all set? | 18:47 |
GaryPoster | srichter: yes, I'm actually really eager for it :-) | 18:47 |
srichter | I remember there was a range of bugs that needed addressing | 18:47 |
GaryPoster | All of the ones I was following (and that we intended to address for this version) are handled | 18:48 |
srichter | great; I think you mainly worked out the locale issue right? | 18:48 |
benji_york | srichter, I am | 18:48 |
benji_york | projekt01, I'm not sure what you mean by "additional repositories"; if you mean can it fetch things from more than one svn repo, then yes | 18:50 |
projekt01 | Yes, cool | 18:50 |
benji_york | projekt01, there is an example buildout at svn://svn.zope.org/repos/main/Sandbox/zc/buildout/trunk/example | 18:52 |
benji_york | just check that out, change to the directory you checked it out into and run build.py | 18:52 |
benji_york | it will take a while because it builds Python and libxml2 (as examples of how to do things like that), but after it's done you can look around | 18:53 |
benji_york | there are no docs and some rough edges, but it's a good start | 18:53 |
projekt01 | benji_york, what does the skeleton mean in the buildbot? | 18:53 |
srichter | GaryPoster: Can you give me a sentence of what you fixed? | 18:54 |
srichter | fdrake: did we update zpkgtools since RC 2? | 18:54 |
benji_york | it is used by the "instance" recipe to build an instance, other than that it is not required | 18:55 |
*** MJ has quit IRC | 18:56 | |
projekt01 | benji_york, does it mean if I like to run/build tiks packages I have to place them also to the package-includes? | 18:57 |
GaryPoster | srichter: sure. ported Stuart Bishop's work in pytz and zope.i18n to address broken and misleading timezone code (i.e., one issue was broken and another was misleading :-) ). Fixed apidoc to handle extended paths, so that zope packages could be installed in software instances without apidoc losing knowedge of the core zope code. | 18:57 |
benji_york | projekt01, if you have ZCML I wouldn't add it to the skeleton, I'd have the recipe add the slug to the package-includes of the instance (but I'm not entirely sure of what/why you're asking) | 18:59 |
*** baldtrol has joined #zope3-dev | 18:59 | |
srichter | GaryPoster: I think you did not merge the API doc fixes to the 3.1 branch | 18:59 |
srichter | I don;t see anything in my archives about that | 18:59 |
GaryPoster | Hm, think I did. will check | 19:00 |
GaryPoster | (That's where I needed it :-) ) | 19:00 |
GaryPoster | revision 38348 | 19:01 |
srichter | ok, thanks | 19:01 |
fdrake | srichter, there have been changes, but I don't think you should update anything for 3.1.0 at all | 19:01 |
srichter | ok | 19:01 |
projekt01 | benji_york, why is the build bot not a z3 app and has some views for a UI and uses the twisted task scheduler for run nightly builds ;-) | 19:03 |
benji_york | you'll have to talk to the buildbot people about that :) | 19:04 |
srichter | projekt01: because it is a well-known twisted project; there is no home-made code | 19:04 |
projekt01 | Ah, Ok | 19:05 |
*** vlado_ has joined #zope3-dev | 19:14 | |
*** MJ has joined #zope3-dev | 19:24 | |
*** M1 has joined #zope3-dev | 19:27 | |
*** MJ has quit IRC | 19:28 | |
*** M1 is now known as MJ | 19:28 | |
*** christi has joined #zope3-dev | 19:30 | |
*** christi has left #zope3-dev | 19:31 | |
J1m | srichter, what are the plans for 3.1? :) | 19:32 |
srichter | J1m: you mean now that I speeded out RC 3? | 19:33 |
srichter | :-) | 19:33 |
srichter | I hope I just make it the final next week | 19:33 |
J1m | Great. Thanks. :) | 19:33 |
srichter | I am getting faster with the release thingy :-) | 19:37 |
*** tarek has quit IRC | 19:39 | |
srichter | the trick with publishing content on Zope.org is definitely to specify the effective date when changing the state | 19:41 |
*** yotaff has quit IRC | 19:44 | |
*** vlado_ has quit IRC | 19:44 | |
*** niemeyer_ has joined #zope3-dev | 19:45 | |
*** niemeyer has quit IRC | 20:01 | |
*** niemeyer_ has quit IRC | 20:05 | |
GaryPoster | Many thanks srichter!! And yes, you generally need both dates on zope.org, AFAICT. | 20:48 |
srichter | ok, I always only specify the first and this seems to work recently | 21:02 |
*** anguenot has quit IRC | 21:06 | |
*** GaryPoster has quit IRC | 21:13 | |
*** sashav has quit IRC | 21:18 | |
*** sashav has joined #zope3-dev | 21:19 | |
*** GaryPoster has joined #zope3-dev | 21:22 | |
*** bradb has quit IRC | 21:22 | |
*** baldtrol has left #zope3-dev | 21:23 | |
*** bradb has joined #zope3-dev | 21:23 | |
*** efge has quit IRC | 21:26 | |
d2m | There is a 'private' SWRelease file now in http://www.zope.org/Products/Zope3/3.1.0c3 folder, actually blocking anonymous access to the folder (and the downloads) | 21:27 |
d2m | srichter, ok - its been published that second | 21:29 |
*** clueck has joined #zope3-dev | 21:32 | |
srichter | yep, it was probably Tim | 21:32 |
*** regebro has quit IRC | 21:35 | |
*** Theuni has quit IRC | 21:47 | |
*** Alef has joined #zope3-dev | 21:50 | |
fdrake | projekt01: What version of Windows are you using? | 21:52 |
fdrake | (trying to figure out the quoting problem you reported) | 21:53 |
*** jinty has quit IRC | 21:57 | |
*** Aiste has quit IRC | 22:01 | |
*** BjornT has quit IRC | 22:02 | |
*** Alef has quit IRC | 22:03 | |
*** clueck has quit IRC | 22:07 | |
*** mgedmin has quit IRC | 22:11 | |
philiKON | srichter, i think you have a "bug" in the release announcement for zope 3.1 | 22:15 |
philiKON | srichter, zope.app.recorder isn't part of zope 3.1 | 22:15 |
srichter | ok, I'll remove it next time | 22:16 |
philiKON | i asked this earlier, but it was eaten by the zpkg discussion: | 22:24 |
philiKON | i haven't looked too closely at the zope 3 catalog; it is always said that it does less than zope2's zcatalog. what does it do less? i mean, it still takes care of indexes and allows queries... | 22:25 |
srichter | can I do <tal:block repeat="item ..." replace="item" /> ? | 22:26 |
philiKON | afaik yes | 22:27 |
srichter | ok | 22:27 |
philiKON | the execution order is something like define, repeat, replace|{attributes, content} | 22:28 |
projekt01 | fdrake, ayt? | 22:36 |
projekt01 | fdrake, win XP | 22:37 |
fdrake | hey | 22:40 |
fdrake | ok, did you get my email? | 22:40 |
fdrake | there's another follow-on question there | 22:40 |
projekt01 | in the svnloader.py at line 317 I'm using (cmd = 'svn cat %s' % url) intead of (cmd = 'svn cat "%s"' % url) | 22:40 |
fdrake | do you actually get an error when the quotes are included at that point? | 22:41 |
projekt01 | didn't read the mail, will do it in 15 minutes... | 22:41 |
fdrake | what, specifically? | 22:41 |
projekt01 | no error just abort | 22:41 |
projekt01 | an there was a report that a temp folder where generated | 22:42 |
projekt01 | I think it is something like a general finish on error where I run into. | 22:43 |
fdrake | interesting | 22:44 |
fdrake | is this with a specific Zope 3 release? | 22:44 |
projekt01 | fdrake, I'm back, this was with 3.0.1b. | 22:50 |
projekt01 | Just like described in srichters readme for a windows build on www.zope.org | 22:50 |
fdrake | ok, I'll see what turns up | 22:52 |
projekt01 | fdrake, I will run the code again now. just wait a minute. | 22:52 |
fdrake | would that be the MakingARelease page? | 22:53 |
projekt01 | Yes, there is a small link pointing to windows notes from srichter I guess | 22:53 |
srichter | no, it's from Tim | 22:54 |
projekt01 | fdrake, the code is running now with svn cat "the svn url". | 22:54 |
projekt01 | ok | 22:54 |
projekt01 | I was wrong with this issue. It's working since I set the right language. | 22:55 |
projekt01 | fdrake, sorry for that, but now the zpkg works on windows too. with "set LANG=C" set in the DOS box | 22:57 |
srichter | projekt01: will it be okay, if I move the pageletchooser and boston skin to branch for now and check in my pagelet redesign? | 23:00 |
srichter | projekt01: I need your help in fixing them; I am quiet lost ;-) | 23:01 |
fdrake | projekt01, that's good news; thanks! | 23:01 |
projekt01 | fdrake, thanks to you. | 23:02 |
* srichter feels like projekt01 is ignoring him today | 23:04 | |
projekt01 | sorry didn't you see my private window? | 23:05 |
projekt01 | srichter> Roger, will it be okay, if I move the pageletchooser and boston skin to branch for now and check in my pagelet redesign? | 23:05 |
projekt01 | <srichter> this way you can help me fix the other components :-) | 23:05 |
projekt01 | <srichter> I am quiet lost, especially with the boston skin | 23:05 |
projekt01 | <projekt01> Ok, we can do this | 23:05 |
projekt01 | <projekt01> srichter are you moved this part allready? I have a lot of changes for the zope.app.skintools package. Should I checkin this first? | 23:05 |
projekt01 | <srichter> ping | 23:05 |
projekt01 | <projekt01> pong | 23:05 |
projekt01 | <projekt01> I guess you have to move th | 23:05 |
srichter | I am not getting those messages; strange | 23:05 |
*** srichter has left #zope3-dev | 23:05 | |
*** srichter has joined #zope3-dev | 23:06 | |
*** ChanServ sets mode: +o srichter | 23:06 | |
projekt01 | can I commit my pending work, that we have them in the branch too? | 23:06 |
projekt01 | I have still uncommited code for the boston skin and the skintools in my workspace | 23:06 |
srichter | projekt01: yeah, switch your working copy to the branch and commit there | 23:07 |
srichter | projekt01: currently the branch is a copy of the trunk, so you can do an svn switch to it | 23:07 |
projekt01 | Ok, did you allready add a branch? | 23:08 |
srichter | yeah | 23:08 |
projekt01 | Do you know, can I switch my workspace without loosing my uncommited work? | 23:09 |
srichter | svn switch ... | 23:09 |
*** fdrake has left #zope3-dev | 23:11 | |
srichter | svn switch svn+ssh://svn.zope.org/repos/main/Zope3/branches/pagelet-rework . | 23:11 |
srichter | projekt01: do you have a moment? | 23:18 |
projekt01 | Yes, just running the functional tests and I'm read to commit | 23:19 |
srichter | ok | 23:19 |
projekt01 | srichter, Done, I'm ready to work on the pagelet till the german elections starts on sunday night ;-) | 23:25 |
srichter | cool | 23:25 |
srichter | I am about to check in the new code to the trunk | 23:25 |
srichter | we then need to merge the pagelet package to the branch | 23:25 |
srichter | and all hell will break loose :-) | 23:26 |
andrew_m | hmm.. any idea anyone where zope.app.locking has gone in zope 3.1c3? or will that not be available in 3.1? | 23:26 |
projekt01 | Cool, I will switch back to the trunk | 23:26 |
srichter | andrew_m: was it in 3.0? | 23:26 |
projekt01 | Hey, do you know there are many out there who use this pagelet system. | 23:26 |
andrew_m | dunno, been in svn trunk for ages though | 23:26 |
projekt01 | Hope they don't work on the weekend ;-) | 23:27 |
philiKON | andrew_m, zope.app.locking isn't in 3.1? | 23:27 |
philiKON | andrew_m, zope.app.locking isn't in 3.1. | 23:27 |
andrew_m | philiKON: at least i cannot find it under that name | 23:27 |
andrew_m | searched for *lock* | 23:27 |
philiKON | sorry, last sentence counts | 23:27 |
philiKON | it's a statement | 23:27 |
srichter | andrew_m: that does not mean anything; there is a lot of stuff in the core that is not in the release | 23:27 |
andrew_m | ahh.. | 23:27 |
philiKON | andrew_m, it's just not in the release for 3.1 | 23:27 |
* andrew_m tries to find an svn release with ftp working and locking | 23:29 | |
srichter | use the 3.1 branch I would assume | 23:29 |
andrew_m | srichter: tnx, i'll try that first | 23:32 |
srichter | projekt01: the new pagelet code is in | 23:33 |
projekt01 | srichter, Ok it's landed in my workspace | 23:35 |
projekt01 | where can we start? | 23:35 |
srichter | we need to merge the new pagelet code to the pagelet-rework branch | 23:35 |
srichter | then I think the first task should be to fix the boston skin and skintools | 23:36 |
srichter | btw, we should flatten skintools a bit | 23:36 |
projekt01 | if they get merged to the branch. | 23:36 |
srichter | the browser directory is too much | 23:36 |
srichter | no, only merge the zope.app.pagelet package | 23:36 |
srichter | also, I really want to understand the use cases for pageletchooser | 23:37 |
srichter | your use case was full of macro talk, and that did not make sense after the refactorings at all | 23:37 |
projekt01 | I would like to rename the skintools to ui if possible. This would also make the rework easy. | 23:37 |
projekt01 | Ok | 23:37 |
srichter | ok | 23:38 |
srichter | I think we also want to move skintools into boston for now | 23:38 |
srichter | because noone is using it at this point | 23:38 |
srichter | other than boston | 23:38 |
projekt01 | but this part is generic and I use it different skins without the boston skin. | 23:39 |
srichter | ok | 23:39 |
projekt01 | I think the skin and additional shared pagelet viewlets should be in different packages | 23:40 |
projekt01 | Is the zope.app.demo.pagelet working? | 23:40 |
*** SureshZ has joined #zope3-dev | 23:43 | |
srichter | projekt01: no, I think we can remove it | 23:43 |
srichter | projekt01: it is far too complex anyways | 23:43 |
srichter | the README.txt has now a concise example | 23:43 |
srichter | if you feel strong about zope.app.demo.pagelet, we could fix it though | 23:44 |
srichter | projekt01: ok, the branch now has the trunk pagelet version | 23:44 |
projekt01 | Ok, I agree, perhaps we can add a better demo later which is more useful | 23:45 |
projekt01 | Ok, I will take a look to the branch | 23:45 |
srichter | right | 23:46 |
srichter | I think the README.txt will be good as a simple demo and boston will be a complex one | 23:46 |
srichter | projekt01: do you mind if I give you another call? | 23:48 |
srichter | projekt01: I need to understand pageletchooser | 23:48 |
projekt01 | That's no problem | 23:48 |
projekt01 | srichter, go to http://www.ch.amadeus.com for a sample use case where I can describe. | 23:50 |
J1m | srichter, I can't get to the release anonymously | 23:52 |
J1m | waaaa | 23:53 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!