| * benji_york is away: I'm busy | 00:10 | |
| *** SteveA_ is now known as einheit | 00:20 | |
| *** tav has joined #zope3-dev | 00:23 | |
| *** tav has quit IRC | 00:28 | |
| *** Alef has quit IRC | 00:37 | |
| *** hazmat has joined #zope3-dev | 00:38 | |
| *** yota has quit IRC | 00:50 | |
| *** einheit has quit IRC | 00:51 | |
| *** ignas has quit IRC | 00:51 | |
| *** ignas has joined #zope3-dev | 00:52 | |
| *** ChrisW has joined #zope3-dev | 01:09 | |
| ChrisW | hmmm, no philiKon? | 01:10 |
|---|---|---|
| *** tiredbones has joined #zope3-dev | 01:38 | |
| srichter | ChrisW: he is sleeping | 01:50 |
| ChrisW | *sigh* | 01:50 |
| ChrisW | I'm looking for kupu-knowledgeable people | 01:51 |
| ChrisW | looks like a great piece of software with zero useful documentation :-( | 01:51 |
| *** _method has joined #zope3-dev | 02:24 | |
| *** _method is now known as jmethod | 02:25 | |
| jmethod | Does anyone know about this error from svn trunk? ConfigurationError: ('Unknown directive', u'http://namespaces.zope.org/zope', u'role') | 02:28 |
| jmethod | In securitypolicy.zcml? | 02:28 |
| *** jmethod has quit IRC | 02:31 | |
| *** ChrisW has quit IRC | 02:37 | |
| *** benji_york is now known as benji | 02:41 | |
| *** benji is now known as benji_york | 02:42 | |
| *** benji_york is now known as benji_york_zope | 02:42 | |
| *** benji_york_zope is now known as benji | 02:44 | |
| *** newpers has joined #zope3-dev | 02:57 | |
| newpers | with 1 person working, how long should it take to complete a project that allows users to pick themes and build websites around the chosen themes. a user registration/credit card system is also needed. | 03:05 |
| benji | hard to say newpers, does this theoretical person already know Zope 3? | 03:06 |
| newpers | it's me! | 03:07 |
| newpers | haha | 03:07 |
| newpers | no, not really | 03:07 |
| * benji is so supprised | 03:07 | |
| newpers | haha | 03:07 |
| * newpers is laughing out loud, btw | 03:07 | |
| *** Alef has joined #zope3-dev | 03:08 | |
| benji | my dead-pan delivery works really well over IRC | 03:08 |
| newpers | heh | 03:08 |
| benji | for building websites TTW, you might want to check out (the still young) CPS Skins for Zope 3 | 03:08 |
| newpers | thanks | 03:09 |
| benji | newpers, note that it is *really* alpha so far, but you might get something out of it | 03:10 |
| newpers | i could work on the other aspects of the system, then | 03:10 |
| benji | what kind of credit card processing are you doing? | 03:10 |
| newpers | to be determined | 03:11 |
| benji | oh, in that case, it'll take one week to get it working | 03:11 |
| newpers | haha | 03:11 |
| newpers | it's hard to find good humor on irc | 03:12 |
| newpers | but i've managed to do so | 03:12 |
| benji | where? | 03:12 |
| newpers | :) | 03:12 |
| newpers | one week! i'll give you $12 an hour | 03:12 |
| benji | lol! | 03:13 |
| newpers | :P | 03:13 |
| newpers | well, thanks for the CPS Skins heads up | 03:16 |
| benji | NP | 03:16 |
| *** hazmat has quit IRC | 03:34 | |
| *** Alef has quit IRC | 04:16 | |
| *** tvon has quit IRC | 04:39 | |
| *** MacYET has joined #zope3-dev | 06:09 | |
| *** benji has quit IRC | 06:43 | |
| *** newpers has quit IRC | 06:54 | |
| *** MacYET has left #zope3-dev | 07:00 | |
| *** haruki has joined #zope3-dev | 07:28 | |
| *** yota has joined #zope3-dev | 07:36 | |
| *** dobee has joined #zope3-dev | 07:48 | |
| *** yota has quit IRC | 07:53 | |
| *** yota has joined #zope3-dev | 07:56 | |
| *** bskahan has joined #zope3-dev | 08:12 | |
| *** yota has quit IRC | 08:22 | |
| *** method has joined #zope3-dev | 08:23 | |
| *** method is now known as jmethod | 08:24 | |
| jmethod | File "/usr/local/zope/Zope-3/src/zope/app/server/main.py", line 69, in debug db = multi_database(options.databases)[0][0] | 08:27 |
| jmethod | NameError: global name 'multi_database' is not defined | 08:27 |
| jmethod | , anyone? | 08:27 |
| *** zagy has quit IRC | 08:37 | |
| *** sashav has quit IRC | 08:37 | |
| *** zagy has joined #zope3-dev | 08:45 | |
| *** zagy has quit IRC | 08:49 | |
| *** zagy has joined #zope3-dev | 08:50 | |
| *** jmethod has quit IRC | 08:54 | |
| *** natea has quit IRC | 08:57 | |
| *** natea has joined #zope3-dev | 08:58 | |
| *** hdima has joined #zope3-dev | 09:28 | |
| *** gdsgdsgvdd has joined #zope3-dev | 09:40 | |
| gdsgdsgvdd | i am implementing a cookie based authemtication, and getting an error--Attribute error - 'None type' object has no attribue ID | 09:42 |
| gdsgdsgvdd | what does this mean... what could be the problem | 09:43 |
| *** yota has joined #zope3-dev | 09:45 | |
| gdsgdsgvdd | please can someone help! | 09:45 |
| *** MJ has quit IRC | 10:00 | |
| *** tarek has joined #zope3-dev | 10:09 | |
| *** sashav has joined #zope3-dev | 10:09 | |
| *** yota has quit IRC | 10:12 | |
| *** tekNico has joined #zope3-dev | 10:15 | |
| *** sashav_ has joined #zope3-dev | 10:16 | |
| *** ChrisW has joined #zope3-dev | 10:23 | |
| *** dobee_ has joined #zope3-dev | 10:27 | |
| *** dobee has quit IRC | 10:28 | |
| gdsgdsgvdd | i have used None type object in cookieAuth.py adapter file ----if username is None -then this-else- | 10:28 |
| *** ChrisW has left #zope3-dev | 10:29 | |
| *** sashav has quit IRC | 10:29 | |
| *** sashav_ is now known as sashav | 10:29 | |
| gdsgdsgvdd | is the error --Nonetype object has no attribue id-- pointing to the None in the cookieAuth.py file | 10:29 |
| *** dobee_ has quit IRC | 10:51 | |
| *** dobee has joined #zope3-dev | 10:51 | |
| *** MJ has joined #zope3-dev | 10:53 | |
| *** yota has joined #zope3-dev | 11:06 | |
| *** dobee has quit IRC | 11:08 | |
| *** dobee has joined #zope3-dev | 11:14 | |
| *** dobee_ has joined #zope3-dev | 11:25 | |
| *** dobee has quit IRC | 11:25 | |
| *** dobee_ has quit IRC | 11:31 | |
| *** dobee has joined #zope3-dev | 11:32 | |
| *** dobee has quit IRC | 11:37 | |
| *** dobee has joined #zope3-dev | 11:38 | |
| *** gdsgdsgvdd has quit IRC | 11:57 | |
| *** Theuni has joined #zope3-dev | 12:39 | |
| *** klaus has joined #zope3-dev | 12:42 | |
| *** regebro has joined #zope3-dev | 12:46 | |
| *** MrTopf has joined #zope3-dev | 12:49 | |
| *** mkerrin has joined #zope3-dev | 13:10 | |
| *** ignas has quit IRC | 13:33 | |
| *** tarek has quit IRC | 13:33 | |
| *** mgedmin has joined #zope3-dev | 13:34 | |
| *** tarek has joined #zope3-dev | 13:37 | |
| *** stub has joined #zope3-dev | 13:40 | |
| *** stub is now known as luv_u_long_time_ | 13:41 | |
| *** luv_u_long_time_ is now known as stub | 13:41 | |
| *** haruki has quit IRC | 13:43 | |
| *** J1m has joined #zope3-dev | 14:04 | |
| *** clueck has joined #zope3-dev | 14:20 | |
| *** niemeyer has joined #zope3-dev | 14:26 | |
| clueck | hmm, the docstring of zope.app.authentication.session.SessionCredentialsPlugin gives an interactive example. I think there's something missing: Between line 117 and 118 there should be a line with the following code: | 14:28 |
| clueck | >>> sessionSetUp() | 14:28 |
| clueck | otherwise one is not able to access the creddentials in subsequent requests | 14:30 |
| clueck | credentials | 14:30 |
| clueck | -- maybe it is a didactic missing ;-) | 14:33 |
| J1m | this is called on line 102 | 14:35 |
| J1m | isn't that enough? | 14:35 |
| J1m | (It is confusing that it is reimported later.) | 14:35 |
| *** J1m has quit IRC | 14:36 | |
| clueck | oh, yes, I' sorry - I was indeed confused be the reimport | 14:37 |
| *** zbir has quit IRC | 14:46 | |
| *** roym has joined #zope3-dev | 14:46 | |
| roym | What is the simplest possible way to set up a simple hierarchy like | 14:48 |
| roym | A/B/C, so that I can do: traverse(root, '/A/B/C') in my unit tests. | 14:48 |
| roym | Does creating a BaseStorage and adding objects to it automatically | 14:48 |
| roym | make them traversable? | 14:48 |
| roym | Specifically, here is what I tried: | 14:58 |
| roym | from ZODB.DB import DB | 14:58 |
| roym | from ZODB.FileStorage import FileStorage | 14:58 |
| roym | db = DB(FileStorage('/tmp/fileStorage')) | 14:58 |
| roym | from zope.app.folder import Folder | 14:58 |
| roym | 14:58 | |
| roym | root = db.open().root() | 14:58 |
| roym | root['item'] = Folder() | 14:58 |
| roym | from zope.app import zapi | 14:58 |
| roym | zapi.traverse(root, '/item') | 14:58 |
| roym | 14:58 | |
| roym | And I get: | 14:59 |
| roym | 14:59 | |
| roym | TypeError: ('Could not adapt', {'item': <zope.app.folder.folder.Folder object at 0x402e912c>}, <InterfaceClass zope.app.traversing.interfaces.ITraverser>) | 14:59 |
| srichter | have you registered the traversal adapters? | 15:00 |
| roym | would placelesssetup do that? I haven't called it | 15:00 |
| srichter | no | 15:00 |
| srichter | setup.setUpTraversal() | 15:01 |
| roym | I added that, and now I see: | 15:02 |
| roym | AttributeError: 'PersistentMapping' object has no attribute '__parent__' | 15:02 |
| roym | sorry: | 15:03 |
| roym | File "/usr/local/Zope3-trunk/src/zope/app/location/traversing.py", line 84, in getRoot | 15:03 |
| roym | context = context.__parent__ | 15:03 |
| roym | AttributeError: 'PersistentMapping' object has no attribute '__parent__' | 15:03 |
| srichter | ahh, root != your Zope 3 root folder | 15:03 |
| srichter | it is the root of the ZODB | 15:03 |
| srichter | look into z.a.appsetup on how you get the Zope 3 root | 15:04 |
| srichter | or just do list(root.keys()) | 15:04 |
| *** stub has quit IRC | 15:04 | |
| srichter | mkerrin: have you made up your mind about fixing SOAP ;-) | 15:04 |
| srichter | mkerrin: have you made up your mind about fixing WebDAV (I meant) ;-) | 15:06 |
| *** ignas has joined #zope3-dev | 15:15 | |
| roym | I looked at the .txt file in z.a.appsetup; it seems that to set up the zope3 root folder correctly, one needs to call: | 15:21 |
| roym | bootstrap.bootStrapSubscriber(interfaces.DatabaseOpened(db)) | 15:21 |
| roym | is this strictly needed always? | 15:22 |
| mgedmin | if you want to create the root folder and various local utilities in a potentially empty storage, then yes | 15:23 |
| mgedmin | if you have a populated database, then no | 15:23 |
| roym | I needed this for "from scratch" kind of testing.. so I guess it is yes. Thanks! | 15:24 |
| *** philiKON has joined #zope3-dev | 15:48 | |
| mkerrin | srichter: (just back from lunch) - once I get the FTP thing checked in then I will look at WebDAV. | 15:58 |
| srichter | great | 16:01 |
| *** zbir has joined #zope3-dev | 16:01 | |
| srichter | mkerrin: I just want to know, because I am making release schedule decisions in my head :-) | 16:01 |
| tarek | srichter, btw, are you planning to add the xml introspection stuff in the release, or it will be later in another release ? | 16:04 |
| mkerrin | srichter: right - The FTP bug will be fixed today - but I haven't figured out how long the WebDAV thing will take me. | 16:07 |
| *** andres has joined #zope3-dev | 16:09 | |
| *** stub has joined #zope3-dev | 16:11 | |
| srichter | tarek: it is in the trunk, right? | 16:11 |
| srichter | mkerrin: ok | 16:11 |
| *** benji has joined #zope3-dev | 16:15 | |
| tarek | srichter, nope, still in the branch i think, (or did you merged it already ?) | 16:15 |
| srichter | tarek: no, but feel free to merge it and add the hooks, so it will be in the release | 16:15 |
| srichter | tarek: I think the code is really cool and other people will benefit from it | 16:16 |
| tarek | ok i'll do that. when do you plan to do the release ? | 16:16 |
| *** d2m has joined #zope3-dev | 16:18 | |
| srichter | tarek: mid-December | 16:19 |
| tarek | oki | 16:19 |
| srichter | philiKON: did you make any progress with respect to the deprecation warning thingy? | 16:24 |
| *** niemeyer is now known as nie_lunch | 16:26 | |
| philiKON | sorry, not yet | 16:26 |
| srichter | ok | 16:29 |
| *** alga has joined #zope3-dev | 16:31 | |
| *** J1m has joined #zope3-dev | 16:42 | |
| klaus | philiKON: today I have compiled Zope-3.1.0 / Python 2.4.2 with gcc 4 on Mac OS 10.4.2 without any problems. | 16:51 |
| philiKON | great | 16:52 |
| *** hdima has quit IRC | 17:02 | |
| *** efge has joined #zope3-dev | 17:10 | |
| *** nie_lunch is now known as niemeyer | 17:13 | |
| *** whit has joined #zope3-dev | 17:15 | |
| *** faassen has joined #zope3-dev | 17:16 | |
| *** sashav has quit IRC | 17:19 | |
| *** stub has quit IRC | 17:23 | |
| *** tvon has joined #zope3-dev | 17:30 | |
| *** clueck has quit IRC | 17:33 | |
| *** bliv has joined #zope3-dev | 17:35 | |
| *** alga has quit IRC | 17:46 | |
| *** philiKON has quit IRC | 17:52 | |
| andres | Is there any generic implementation for createandadd when you use zope.formlib? | 17:54 |
| benji | andres, the AddFormBase class includes one, but it depends on subclasses providing a create method | 17:56 |
| andres | benji, so, nothing like in AddView | 17:56 |
| benji | not that I know of, but adding your own create method shouldn't be too hard, you have to subclass AddForm anyway | 17:57 |
| *** natea is now known as natea|away | 17:57 | |
| *** mgedmin has quit IRC | 17:58 | |
| *** ignas is now known as ignas|phood | 17:58 | |
| *** tarek has quit IRC | 18:00 | |
| *** tarek has joined #zope3-dev | 18:01 | |
| *** faassen has quit IRC | 18:01 | |
| jinty | er, the mysqldbda prints connection info (including the password) on the stdout | 18:02 |
| jinty | aside from randomly breaking my doctests, its a security issue | 18:02 |
| jinty | anyone mind if I clean it up | 18:03 |
| J1m | nope | 18:03 |
| benji | J1m, I have a quick question... | 18:04 |
| J1m | k | 18:04 |
| benji | I was working on a personal project this weekend and needed to run several doctests while changing the server config between runs, I think I've figured out how to get FunctionalTestSetup to reload the config, but all the other state (component system mainly) is still there... | 18:05 |
| benji | ...so my question is: is there an easy way to reset all of Z3's internal datastructures? | 18:06 |
| *** zagy_ has joined #zope3-dev | 18:06 | |
| *** natea|away has quit IRC | 18:06 | |
| srichter | benji: can you elaborate, because I am working on a ZCML-based reload right now? | 18:06 |
| benji | :) | 18:07 |
| *** natea has joined #zope3-dev | 18:07 | |
| srichter | here is my approach | 18:07 |
| J1m | benji, no, that's why zcml-based layers can't be torn down and why the test runner has to use subprocesses. | 18:07 |
| srichter | if you reload a ZCML file, none of the registrations are executed | 18:07 |
| benji | I was working on a test framework for my quick start, and needed to load a working zope, run some doctests, change the ZCML, run some other doctests, etc. | 18:07 |
| J1m | benji, hy not use layers? | 18:07 |
| srichter | but ehenever a global object is referred to, its module gets reloaded | 18:08 |
| benji | J1m, I'm not sure layers apply, but I'll take a look next time I play with it | 18:08 |
| benji | I'm really excited about the generall approach though, I have a pretty good manual testing framework at this point | 18:09 |
| J1m | benji, if you don't really need all state to be reset, you might get by with less. | 18:09 |
| benji | J1m, the thing is, I wan the DB to remain intact, just simulate a server stop and restart | 18:09 |
| J1m | (Me wishes Python disn't have reload. It is an attractive nuisance.) | 18:10 |
| J1m | (Me wishes Python didn't have reload. It is an attractive nuisance.) | 18:10 |
| srichter | benji: on this case, do a placeless tear down and a ZCML reload | 18:10 |
| * benji agrees with J1m | 18:10 | |
| benji | srichter, will that unregister adapters (for instance)? | 18:10 |
| srichter | benji: yeah, the teardown will do that | 18:11 |
| benji | ok, I'll have to look into that | 18:11 |
| J1m | (I notice srichter stepping into a tar pit of reload madness.) | 18:11 |
| J1m | tearDown doesn't unto all zcml-defined changes, unfortunately. | 18:11 |
| J1m | undo | 18:12 |
| benji | ah, that's what I was afraid | 18:12 |
| benji | of | 18:12 |
| J1m | It does undo any component registrations. | 18:12 |
| srichter | it does not undo setting of global variables, right? | 18:12 |
| srichter | but other than that, what is it not doing? | 18:13 |
| *** zagy has quit IRC | 18:13 | |
| benji | I might have to look into running my tests with a file based storage, so I can run my tests in subprocess es | 18:13 |
| J1m | srichter, nothing | 18:14 |
| J1m | benji, it all depends on how pristine you need to make things. | 18:14 |
| benji | don't really know, I'm testing what the user would do, and the user would restart Zope, so it needs to be a reasonable approximation of that | 18:15 |
| srichter | J1m: I wanted to talk to you about my approach as well :-) | 18:15 |
| srichter | I was thinking on allowing reloading of selected ZCML files | 18:16 |
| srichter | first, you load the meta directives (can be cached probably) | 18:16 |
| J1m | srichter, I still don't know what your approach is -- or what problem it is trying to solve. | 18:16 |
| srichter | J1m: ok, problem first: people want to be able to reload their code changes without tearing down and bringeing up the entire server again | 18:17 |
| J1m | why is that? | 18:17 |
| srichter | I agree with you that with doctests, this is probably less needed, but people want it, so I am at least want to explore it a bit | 18:17 |
| srichter | J1m: because it makes their development faster | 18:18 |
| benji | srichter, it might be safer and more rewarding to make restart *much* faster, then we'd get the right semantics with the benefits | 18:18 |
| srichter | I have seen MAC people wait over 10 seconds to start up Zope | 18:18 |
| srichter | benji: we have looked at alternatives there as well, but did not get very far | 18:19 |
| benji | srichter, on windows pressing control-c can take that long just to stop Z3 (no matter how fast the machine) | 18:19 |
| srichter | benji: most of the time is spent converting dotted names to objects | 18:19 |
| srichter | benji: and that lookup cannot be cached any way easily | 18:20 |
| srichter | (I am assuming the resolve method on the context is maximally optimized) | 18:20 |
| J1m | why would you assume that? | 18:20 |
| benji | I'm just very afraid of reload that works 99% of the time, the poor 1% are going to be seriously burned | 18:21 |
| J1m | what makes you think resolve is taking most of the time? | 18:21 |
| J1m | srichter, I agree with Benji, reload is a trap. | 18:21 |
| srichter | benji: that's the case in the Zope 2 world right now too, and people still use it like crazy | 18:21 |
| J1m | The author of that product regrets it. | 18:21 |
| benji | "attractive nuisance" :) | 18:21 |
| srichter | J1m: I am pretty sure the POV guys told me they did some experiments in that regard | 18:22 |
| J1m | Hm | 18:22 |
| * benji writes a royalty check to the person that coined the term "attractive nuisance" | 18:22 | |
| srichter | in fact they tried caching the ZCML before | 18:22 |
| J1m | The ZCML could be made far more cacheable than it is now. | 18:23 |
| J1m | and it | 18:23 |
| srichter | I think the main issue here was that we generate types that cannot be imported, right? | 18:23 |
| J1m | and it's behavior could be improved. | 18:23 |
| srichter | otherwise we could just write pickle dumps of the actions | 18:24 |
| J1m | Basically, we do too much in the first phase. | 18:24 |
| J1m | we should do much less and return picklable actions. | 18:24 |
| srichter | how could the behavior be improved? | 18:24 |
| benji | I wonder if some of the "too much" first phase stuff (like creating interfaces that will be used in phase 2) should be moved to a phase 1.5 | 18:24 |
| srichter | ok, I agree | 18:24 |
| J1m | we could move much of the work we do in phase 1 to phase 2. | 18:25 |
| J1m | This could include class generation, etc. | 18:25 |
| srichter | do you have any idea of a preferred approach? | 18:25 |
| J1m | Note that, in the long term, I'd like to move away from class generation. | 18:25 |
| SteveA | (considered harmful ;-) ) | 18:25 |
| SteveA | i'm moving away from class generation for launchpad. | 18:25 |
| SteveA | it makes things so much more obvious for users and people debugging | 18:26 |
| J1m | A basic tenent of formlib is that things should be defined in python. | 18:27 |
| J1m | srichter, I tried to suggest this as a sprint topic, but I was too late. | 18:27 |
| J1m | so, aproach: | 18:27 |
| J1m | - rewrite handlers so that they generate actions that are basically just data. | 18:27 |
| J1m | - have the actions invole things that do the work we do now. | 18:28 |
| J1m | (This will improve semantics of a number of things.) | 18:28 |
| J1m | - If actions are picklable, then cache actions and use cahed actions unless zcml file has changed. | 18:28 |
| * srichter listens till Jim says he is done | 18:28 | |
| J1m | Some care would be needed to handle conditional execution. | 18:29 |
| J1m | done. | 18:29 |
| benji | J1m, does moving some things to phase 2 preclude some of the things we do now (e.g. generating Interfaces that other actions act uppon) | 18:29 |
| J1m | Um, preclude? | 18:29 |
| J1m | no | 18:30 |
| benji | like the mimetype stuff... it generates interfaces that must be available before phase 2 starts, how would you do that in this new scheem? | 18:30 |
| srichter | can you give me a concrete example of step 1 and 2? | 18:30 |
| srichter | J1m: I guess we should make more use of factory classes | 18:31 |
| J1m | benji, the interfaces aren't needed when phase 2 starts. They aren't needed until there is an action that tries to register something for them. | 18:31 |
| J1m | srichter, I don't know what you mean. I know you are familiar with phases 1 and 2. | 18:31 |
| benji | ok, so why did we think it was neccesary to create them in phase 1? | 18:32 |
| J1m | benji, because currently, they are used in phase 1. | 18:32 |
| J1m | when we compute the actions, we pass the interfaces as arguments. | 18:32 |
| benji | ahh, ok | 18:32 |
| srichter | ok, to be more specific, in the context of a browser:page registration, how shoudl a data-driven action look like? | 18:32 |
| J1m | For example, the adapter directive resolves the interface and passes the resolved interface as an argument to the action. | 18:33 |
| srichter | right | 18:33 |
| J1m | srichter, it should wrap up the data it needs and pass that to the action. | 18:33 |
| J1m | srichter, things like the template name, security info, whatever. | 18:34 |
| srichter | ok, would it pass an interface object or the dotted name? | 18:34 |
| SteveA | maybe an object that has the dotted name as data, but can give you the interface | 18:35 |
| J1m | Note that validation of basic types (e.g. strings, ids, etc.) can be done in the first phase. In my early profiling, I noticed that lots of time was spend in schema validation. I think that this would mostly avoid that. | 18:35 |
| J1m | srichter, dotted name | 18:35 |
| J1m | Note that the dotted name could be normalized in phase 1 (and the result of normalization cached). | 18:36 |
| srichter | so how would the GlobalObject field do validation; it could not do much anymore... | 18:36 |
| J1m | GlobalObject would: | 18:36 |
| J1m | - return a normalized dotted name | 18:37 |
| J1m | - add an action to verify that the name is valid. | 18:37 |
| J1m | The verification would be done in phase 2. | 18:37 |
| srichter | interesting | 18:37 |
| benji | so, we want to do as *much* in phase 1 as we can and the result still be pickleable (so when phase 1 is cacheable, we cache expensive stuff) | 18:37 |
| J1m | Or what SteveA suggested could be better. | 18:37 |
| J1m | The valud if a glbal object is a callable that does the resolution and generates a useful error if it fails. | 18:38 |
| J1m | benji, right | 18:38 |
| J1m | s/valud/value | 18:38 |
| * benji wonders why J1m uses Vim syntax for his substitutions :) | 18:39 | |
| J1m | BTW another important way to speed things, as SteveA has pointed out in the past, is to use less zcml. | 18:39 |
| J1m | After 3.2, I'd like to have us spend some time on whitling z3 down so that it is smaller. | 18:40 |
| srichter | yeah, that's another thing | 18:40 |
| J1m | Begin defining a core. | 18:40 |
| srichter | I would really like to separate the browser directives from the other directives | 18:41 |
| J1m | By thn, I hope that the packaging technology will have matured to the point that it is easier for people to get what they want without bloating z3. | 18:41 |
| srichter | in schooltool, we often want the Python code, but none of the registrations | 18:41 |
| SteveA | J1m: i'd be interested in hosting a sprint on whittling Z3 down | 18:41 |
| J1m | also, as the "layer" model matures, I think it will provide a vehicle for faster reloads during development. | 18:41 |
| Theuni | hmm | 18:42 |
| * Theuni takes a look on the current sprint schedule | 18:42 | |
| SteveA | vilnius is nice in the spring / summer. when's 3.2 scheduled? | 18:42 |
| J1m | Basically, because layers are minimal configurations that exercise packages. | 18:42 |
| benji | SteveA, 3.2 is scheduled for December | 18:43 |
| J1m | 3.2 is scheduled to be released in December. | 18:43 |
| SteveA | spring is more like april. still, vilnius is interesting in the middle of winter too ;-) if you like snow and cold. | 18:43 |
| J1m | :) | 18:44 |
| Theuni | I might take the snow if someone else picks the cold ... | 18:44 |
| J1m | Feature freeze for the summer release is May 1. | 18:44 |
| J1m | BTW, we are seriously running out of time for 2.9/3.2. | 18:45 |
| J1m | I have a bunch of z2 security work for 2.9. | 18:45 |
| J1m | The five folks have a lot of work too and could probably use some help. | 18:45 |
| Theuni | J1m: depending on my 5-week plan, I _might_ be able to help out a bit. | 18:46 |
| Theuni | I have to get warm with some things again, though. | 18:46 |
| srichter | btw, I am pretty much set on the Zope 3 side of things :-) | 18:47 |
| srichter | I am going to send a mail warning people that the freeze is coming up, but that's about it | 18:48 |
| J1m | Good. I still need to integrate the new test runner. | 18:48 |
| J1m | Good! | 18:48 |
| J1m | Freeze Nov 1! | 18:48 |
| J1m | I've been waiting until the test runner had all of the important capabilities of the old one.... | 18:48 |
| *** tiredbones has left #zope3-dev | 18:49 | |
| benji | J1m, any capabilities still remain unadded? | 18:50 |
| J1m | - tests for gc threshold setting | 18:50 |
| J1m | - memory leak debugging and tests. I definately don't have time for what I want in the long run, but I'd like to at least have what the current test runner has. | 18:51 |
| J1m | That's all I can think of. | 18:51 |
| benji | ok | 18:52 |
| *** MJ has quit IRC | 18:58 | |
| *** klaus has quit IRC | 19:00 | |
| andres | One question: you can do __setitem__.precondition = ItemTypePrecondition... | 19:11 |
| andres | How can you get that on runtime? | 19:11 |
| andres | from the implementation of the container. | 19:11 |
| J1m | Look at zope.app.container.constraints for examples. | 19:12 |
| *** sashav has joined #zope3-dev | 19:14 | |
| *** klaus has joined #zope3-dev | 19:20 | |
| regebro | Aha... so views are looked up (in 3.0 at least) via a special view.traverser? | 19:22 |
| regebro | I ment view traverser. :) That was not supposed to look like a dotted name. :) | 19:22 |
| srichter | that is still true for 3.1 and 3.2 | 19:25 |
| regebro | OK, good to know. Five isn't using it, namely. | 19:27 |
| srichter | I cannot talk about five | 19:27 |
| regebro | No, of course. It just ment that the traversal refactoring of Five I'm trying now had a hiccup. :) | 19:28 |
| srichter | I see | 19:28 |
| *** klaus has quit IRC | 19:29 | |
| *** mgedmin has joined #zope3-dev | 19:30 | |
| regebro | The question is if the best fix is to implement a special Five traversePathElement, or implement proper namespace traversal or do a hack. ;) | 19:31 |
| regebro | I probably need to try all of the, as usual. :) | 19:31 |
| *** klaus has joined #zope3-dev | 19:32 | |
| *** klaus has left #zope3-dev | 19:36 | |
| *** suse-joe has joined #zope3-dev | 19:38 | |
| suse-joe | Hi! I've got a question on interfaces: I can either | 19:39 |
| *** ignas|phood is now known as ignas | 19:39 | |
| suse-joe | use implements(Interface) or define the interfaces a class implements in ZCML, right? | 19:39 |
| benji | right, suse-joe | 19:40 |
| suse-joe | is the first one still encouraged or should all "implements" definitions be done in ZCML if possible? | 19:40 |
| benji | the first is recommended if the interface is "intrinsic" to the class, in other words does the class intentionally implement the interface | 19:41 |
| benji | the ZCML directive is usually reserved for marker interfaces (interfaces with no implementable bits) or imposing an interface on a third-party package that didn't know it was implementing an interface when it was written | 19:41 |
| suse-joe | Does this distinction have any practical implications (like performance hits or so)? Or is it just an unwritten rule? | 19:43 |
| srichter | anything in ZCML is configurable | 19:46 |
| srichter | no implications on performance | 19:47 |
| *** tekNico has quit IRC | 19:51 | |
| *** tekNico has joined #zope3-dev | 19:51 | |
| *** tekNico has left #zope3-dev | 19:52 | |
| *** tarek has quit IRC | 19:52 | |
| suse-joe | Is there a Z3 equivalent of the good old acl_users folder or do I have to use the Pluggable Authentication Utility? | 20:04 |
| *** alga has joined #zope3-dev | 20:14 | |
| *** regebro has quit IRC | 20:19 | |
| *** tiredbones has joined #zope3-dev | 20:19 | |
| *** jukart has joined #zope3-dev | 20:25 | |
| srichter | suse-joe: you have to use the Authentication Utility | 20:27 |
| srichter | of course you can use ZCML to define your users as well | 20:27 |
| suse-joe | srichter: ZCML: Sure. But I want to manage them TTW ;-) | 20:28 |
| srichter | well, then use pau | 20:28 |
| srichter | as you suggested | 20:29 |
| suse-joe | The default Principal Folder is a bit of a PITA ATM because I have to provide both the login name and an object name. | 20:29 |
| srichter | no, it is not PITA | 20:29 |
| srichter | because setting id == login is a security hole | 20:30 |
| suse-joe | But it's buggy. ;-) If I don't specify the object name it uses numbers, starting with 1. If I want to change those and use an existing login name I can't do that. Seems the name check checks against the login name. | 20:31 |
| suse-joe | Security hole: Explain | 20:32 |
| *** alga has quit IRC | 20:32 | |
| *** efge has quit IRC | 20:32 | |
| srichter | because the id is sometimes displayed in the UI | 20:32 |
| srichter | displaying the login name in the UI is a bad idea | 20:32 |
| suse-joe | ACK | 20:33 |
| suse-joe | But it seems in all cases I'll need to write my own frontend for user management if I want to do anything more serious than just testing. | 20:35 |
| srichter | yep, which is the point | 20:35 |
| srichter | we do not want you to use any default thing :-) | 20:35 |
| suse-joe | With Zope2's acl_users I could use it out of the box in many cases. | 20:35 |
| srichter | the default UI for PAU is far too geeky for the user to use | 20:36 |
| suse-joe | And I am far too lazy to want to rewrite user management for every app. ;-) So what Zope3 needs IMHO is lots of good defaults. Needn't be part of the core distribution, but they should be available and easy to use. | 20:38 |
| srichter | feel free to contribute to Z3ECM and similar projects | 20:40 |
| mkerrin | should the debugzope and zopectl scripts now use the zope.app.twisted package instead of the zope.app.server | 20:41 |
| srichter | mkerrin: yes | 20:42 |
| mkerrin | srichter: cool - I will fix it then | 20:42 |
| *** VladDrac has quit IRC | 20:43 | |
| srichter | thanks a lot | 20:44 |
| J1m | Perhaps it would be useful to provide some wizards for pau that asked the user a few questions and created a fully configured pau for them. | 20:44 |
| J1m | This could be a nice add-on project for someone. | 20:44 |
| *** zagy_ has quit IRC | 20:45 | |
| suse-joe | I'm thinking about adding things like that (new project wizards, configuration wizards, ...) to an IDE (e.g. eric3). Now that the road away from Zope2's "everything TTW" paradigm has been taken I think that makes more sense than doing those things as part of the Zope web UI. | 20:49 |
| suse-joe | That said, writing a AJAX-style full-fledged Zope IDE as a web app would be a fun project, too. ;-) | 20:50 |
| *** niemeyer has quit IRC | 20:54 | |
| andres | can i make zope.formlib return a macro easily? It doesnt seem so, or? | 20:56 |
| *** MJ has joined #zope3-dev | 20:58 | |
| andres | because else they arent very useable. | 21:02 |
| *** sashav has quit IRC | 21:05 | |
| *** sashav has joined #zope3-dev | 21:07 | |
| *** niemeyer has joined #zope3-dev | 21:10 | |
| *** VladDrac has joined #zope3-dev | 21:13 | |
| srichter | J1m: I think Python's reload() function does not like interfaces ;-) | 21:17 |
| srichter | at least it seems it cannot reload any modules that contains interface declarations | 21:18 |
| srichter | another pointer it does not work well | 21:18 |
| srichter | (I wonder whether this is true for all meta classes) | 21:19 |
| SteveA | srichter: i remember shane's reloader involved just deleting the module from sys.modules | 21:22 |
| SteveA | and not using reload. | 21:22 |
| srichter | thanks | 21:23 |
| srichter | I'll try that | 21:23 |
| *** jukart has left #zope3-dev | 21:26 | |
| J1m | abandon all hope, ye who reload | 21:28 |
| srichter | :-) | 21:29 |
| srichter | I just thought about it some more and ZCML caching will not help the slow MAC users at all | 21:29 |
| srichter | since it still ahs to read a lot of files | 21:29 |
| srichter | and their FS is soo damn slow | 21:29 |
| J1m | so you'll drive them insane with non-robust reload. | 21:30 |
| J1m | I'm not sure i beleave the slow fs thing. | 21:31 |
| srichter | mmh, I dunno | 21:31 |
| srichter | I wonder, whether global object could put a proxy around the object it looked up, which can observes changes | 21:36 |
| J1m | Please note that I have no desire to help you try to make reload work. | 21:37 |
| srichter | I know, I'll definitely want to tackle the other apporach for 3.3 | 21:37 |
| *** natea is now known as nate | 21:38 | |
| *** nate is now known as natea|away | 21:38 | |
| J1m | Another alternative that I would like to have pursues (after 3.2) is persistent modules for prototyping. | 21:39 |
| *** nederhoed has joined #zope3-dev | 21:39 | |
| J1m | persistent modules get much closer to working "reload" although even they have dark corners. | 21:39 |
| srichter | right, that is probably the right approach | 21:40 |
| benji | "persistent" as in "located in ZODB"? | 21:40 |
| srichter | benji: yeah, we have already code for that | 21:40 |
| * benji thinks he'll hate modules in the database | 21:40 | |
| J1m | benji should try squeak. :) | 21:41 |
| J1m | One might possibly learn from persistent modules to make reloadable modules. | 21:41 |
| benji | I would me much more inclinde to take that route | 21:41 |
| J1m | These would use the same principles but with state stored on the FS. | 21:41 |
| srichter | I wonder whether one could just convert regular modules to persistent modules and stick those into sys.modules | 21:43 |
| benji | "state" being source code? | 21:43 |
| J1m | benji, sort of | 21:43 |
| J1m | srichter, no, that's not good enough. | 21:43 |
| J1m | benji, well, yes. | 21:43 |
| benji | good | 21:43 |
| *** MrTopf has quit IRC | 21:43 | |
| J1m | The state of a module is contained in it's source code. | 21:43 |
| J1m | You would need reloadable modules to contain reloadable objects, including reloadable functions and classes. | 21:44 |
| srichter | ah, right | 21:44 |
| J1m | Then one would need to use the same sort of approach as used by persistent modules to upload them. | 21:44 |
| benji | I hope that all these reloadable things will be visually indistinguishable from "regular" python code | 21:45 |
| J1m | Possibly, this could be a popular PEP. | 21:45 |
| J1m | benji, well, one option would be to make regular python functions and classes reloadable. | 21:45 |
| benji | right | 21:45 |
| J1m | actually, functions are the trickiest, I think. | 21:46 |
| benji | hmm, this seems like a round-about way to think of how to make modules reloadable :) | 21:46 |
| * J1m thinks this would make a fine PEP. | 21:46 | |
| J1m | How is it round about. | 21:46 |
| J1m | Our experience tells us that: | 21:47 |
| J1m | - Python reload is broken. | 21:47 |
| J1m | - We've learned a lot about how to do it right in Jeremy's persistent module experiments. | 21:47 |
| J1m | BTW, He might be willing to collaborate on a PEP. | 21:47 |
| J1m | BTW, IMO, modules cannot be implicitly reloadable. | 21:48 |
| J1m | All modules are not reloadable. | 21:48 |
| J1m | IMO, a module is only reloadable if *all* of it's state is captured by it's source code. | 21:49 |
| J1m | This means, it's state should not be mutated except through reload. | 21:49 |
| srichter | so basically nothing is added/revmoed afterwards | 21:49 |
| J1m | assuming that you desire sanity. | 21:49 |
| benji | right, I'm just saying that going from "we want reloadable modules" to "persistent modules (in ZODB) are reloadable, we should use those" to "yeah, but I want the source on the FS, so we'll make persistant modules with their state on the FS" seems less direct than just saying "how can we make (some subset) of modules reloadable" | 21:49 |
| J1m | or modified. | 21:49 |
| benji | yep | 21:50 |
| srichter | I think this is an acceptable requirement | 21:50 |
| J1m | well, persistent modules attack th same problem and we should reuse what we've learned about them. | 21:50 |
| J1m | It's probably not too late to start something for Python 2.5. | 21:51 |
| J1m | You have a lot more time for Python 2.5 than you do for Zope 3.2. :) | 21:51 |
| srichter | :-) | 21:51 |
| benji | J1m, yeah, I wasn't saying that, I just worry that the "persistent modules on the FS" would lead to a wacky implementation; the knowlege from persistent modules, on the other hand, is definately needed for this | 21:53 |
| J1m | OTOH, Py 2.5 is a lot closer than py 2.6, so I wouldn't wait long if you wanted to make sane reload work any time soon. | 21:53 |
| J1m | I expect you could reuse a lot of implementation. | 21:53 |
| benji | yep, I wasn't saying that either, nevermind | 21:54 |
| J1m | (It would be sort of nice if reloadable modules could prevent changes, except through reload. | 21:54 |
| J1m | ) | 21:54 |
| *** deo has joined #zope3-dev | 21:56 | |
| *** einheit has joined #zope3-dev | 22:01 | |
| *** einheit is now known as SteveA_ | 22:02 | |
| *** alga has joined #zope3-dev | 22:05 | |
| *** mgedmin has quit IRC | 22:27 | |
| *** BjornT has quit IRC | 22:29 | |
| *** BjornT has joined #zope3-dev | 22:29 | |
| *** alga has quit IRC | 22:31 | |
| *** jinty has left #zope3-dev | 22:31 | |
| *** natea|away is now known as natea | 22:34 | |
| *** BjornT has quit IRC | 22:37 | |
| *** BjornT has joined #zope3-dev | 22:37 | |
| *** suse-joe has left #zope3-dev | 22:39 | |
| *** mkerrin has quit IRC | 22:40 | |
| *** BjornT_ has joined #zope3-dev | 22:42 | |
| *** BjornT has quit IRC | 22:58 | |
| *** nederhoed has quit IRC | 23:20 | |
| *** natea is now known as natea|away | 23:24 | |
| J1m | srichter, ayt? | 23:40 |
| *** SteveA_ is now known as einheit | 23:44 | |
| srichter | J1m: yep | 23:44 |
| *** benji has quit IRC | 23:49 | |
| J1m | srichter, sorry for not responding right away. I got distracted. :) | 23:50 |
| J1m | Do you have a reference for the Java content-provider definition? | 23:50 |
| *** einheit has quit IRC | 23:51 | |
| srichter | J1m: I searched the Web when I was writing the docs | 23:54 |
| srichter | I thought JSR 168 had one too | 23:54 |
| srichter | hold on | 23:54 |
| VladDrac | can someone reboot zope.org? :) | 23:55 |
| srichter | darn, I don't have the JSR 168 PDF anymore | 23:55 |
| srichter | ok, I do | 23:55 |
| srichter | do you have it as well? | 23:56 |
| J1m | yes | 23:56 |
| J1m | I see no reference to content provider. | 23:56 |
| srichter | it might have been in one of the referenced papaers | 23:56 |
| J1m | doing "find" for provider. | 23:56 |
| J1m | The proposal more or less hinges on standard terminology, but gives no reference to the standard. | 23:57 |
| J1m | It makes it hard to determine if the terminology is applicable to what you propose. | 23:58 |
| J1m | I'm unclear what the motivation of content providers is. | 23:58 |
| srichter | I remember looking it up for the content provider README | 23:58 |
| J1m | I woish you had included a reference in the readme. | 23:58 |
| J1m | wish | 23:58 |
| J1m | We commonly look up subviews. Widgets are a good example. | 23:59 |
| srichter | me too :-( | 23:59 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!