[Zope-dev] Another mystery for you ;-)
Hi Steve, Since you found the external methods arguments thing interesting, here's another challenge for you... ;-) (it's actually from the same nav_tree method) I was trying to use 'if o in REQUEST.PARENTS' to expand branches on the way to the currently displayed object and was running into trouble which lead me to try out the following code: `REQUEST.PARENTS[0]`+`o`+`o==REQUEST.PARENTS[0]`+`o is REQUEST.PARENTS[0]` Now, this renders the following in the case where the branch _should_ expand: Folder instance at 88cbb30Folder instance at 88cbb3000 What I don't understand is how two objects, apparently at the same memory location, return false from both 'object1==object2' and 'object1 is object2'. Again, any ideas? cheers, Chris The only vaguely related thing I can think of is that this is happening 'cos I'm working in a version and the folder object has been changed and REQUEST.PARENTS contains the unchanged version while o contains the changed version. If this is causing it, it's a bug ;-) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Another mystery for you ;-)
Chris Withers wrote: I was trying to use 'if o in REQUEST.PARENTS' to expand branches on the way to the currently displayed object and was running into trouble which lead me to try out the following code: `REQUEST.PARENTS[0]`+`o`+`o==REQUEST.PARENTS[0]`+`o is REQUEST.PARENTS[0]` Now, this renders the following in the case where the branch _should_ expand: Folder instance at 88cbb30Folder instance at 88cbb3000 What I don't understand is how two objects, apparently at the same memory location, return false from both 'object1==object2' and 'object1 is object2'. Smells like an Acquisition Wrapper misunderstanding :-) http://www.zope.org/Members/michel/Projects/Interfaces/AcquisitionWrappedObject Use the aq_self or aq_parent attribute to do your comparisons to get your object out of its magic acquisition wrapper. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Another mystery for you ;-)
Steve Alexander wrote: Smells like an Acquisition Wrapper misunderstanding :-) You should change your name to Jim... ...or have you been bitten by this before? Do you know if objects in PARENTS are acquisition wrapped? cheers and much we're-not-worthy'ing, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Zope 2.1.6 packages
hi all, from my own experience i know user nobody is 99 and group nobody is the same on linux, but BSDs seem to have another convention there. on a FreeBSD box i looked at right now nobody was user 65534 or so. as chris mcdonough remarked earlier in this thread, it is much more important to get acquanted to your version of tar and use it so that your untarring user gets ownership. there is no way anyone could package up a zope distribution to make the ownerships suitable for all possible users out there. i think common sense is, as always, a better guide than expecting that things will magically be perfect. jens -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Steve Alexander Sent: Wednesday, July 12, 2000 06:40 To: Alexandre A. Drummond Barroso Cc: [EMAIL PROTECTED] Subject: Re: [Zope-dev] Zope 2.1.6 packages "Alexandre A. Drummond Barroso" wrote: It would be a good idea to change the user/group that owns any file in the Zope tree to nobody.nobody before packaging the product (src and linux packages) instead of delivering with user 509. When this user number is already used, and someone is testing Zope as a simple user (not root) the user can loose the control of the files when unpack the package. Anyway, it's a simple task and will take almost no time from you. Thanks in advance, Is nobody always user/group 99 on unix systems in general? -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.1.6 packages
in this case, apache installation seems to be magically perfect :^) or, in other words, zope is a great tool, but still needs a better installation. K. hi all, from my own experience i know user nobody is 99 and group nobody is the same on linux, but BSDs seem to have another convention there. on a FreeBSD box i looked at right now nobody was user 65534 or so. as chris mcdonough remarked earlier in this thread, it is much more important to get acquanted to your version of tar and use it so that your untarring user gets ownership. there is no way anyone could package up a zope distribution to make the ownerships suitable for all possible users out there. i think common sense is, as always, a better guide than expecting that things will magically be perfect. jens ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Another mystery for you ;-)
Steve Alexander wrote: Do you know if objects in PARENTS are acquisition wrapped? I'm pretty sure that they are. They are indeed, in fact, pretty much everything is :( The only way to check if o is in PARENTS appears to be: if o.aq_base in map (lambda o : o.aq_base,PARENTS): ..nice... :/ Two questions: 1. Is there a better way of doing the above? 2. Is there any case where a Zope object isn't going to have a .aq_base attribute? cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Aquisition, in, == and is
Chris Withers wrote: Steve Alexander wrote: Do you know if objects in PARENTS are acquisition wrapped? I'm pretty sure that they are. They are indeed, in fact, pretty much everything is :( The only way to check if o is in PARENTS appears to be: if o.aq_base in map (lambda o : o.aq_base,PARENTS): Hmm, is there anyway the Acquisition ExtensionClass(right thing? I'm not too hot here ;-) could be altered such that, if r1 and r2 are two different acquisition wrappers for the same object that: r1 == r2 and r1 in [r2,x,y] would return true? It might be best to leave (r1 is r2) returning false as it does now so that you can actually tell if things aren't what you expected ;-) Any ideas? cheers, Chris PS: This question is still worrying me :( 2. Is there any case where a Zope object isn't going to have a .aq_base attribute? ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] External Method Missery
Steve Alexander wrote: Chris Withers wrote: I have an external method called navTree (dtml-tree was too broken to fix in the time frame :( ) with a spec as follows: def navTree(self,start): It's called in some DTML as: dtml-var "nav_tree(PARENTS[-2])" which is fine, unless I call it with the following: dtml-var "nav_tree(start=PARENTS[-2])" in which case I get: TypeError: not enough arguments; expected 2, got 0 So, in the first case, you're not getting the current context passed in, but you are getting it in the second case. ... Looks like it is assumed that the first non-keyword argument should be passed as the client (ie "self"). So, you can fix your exception by giving "start" a default value: def navTree(self,start=''): However, you'll have to always use the keyword form of calling it: dtml-var "nav_tree(start=PARENTS[-2])" Or otherwise, provide a client for it: dtml-var "nav_tree(this(), PARENTS[-2])" As for why this is the case... I have other things to do this morning, so I won't go rooting around in the DTML source just now. [ Although, it sure is tempting :-) ] The problem is near the bottom of ExternalMethod.py. The PythonMethod product is based partly on ExternalMethod, so I'm now familiar with the invocation mechanism. Here's the logic: ExternalMethod sets up func_* attributes so it can masquerade as a function. The trick works well enough to convince ZPublisher's mapply() to pass in a "self" argument as the first argument when needed. However, if you invoke the method directly (as you're doing here), mapply is not part of the mechanism. So you're supposed to provide the "self" argument manually. This is nonintuitive IMHO. BUT if you don't provide the "self" argument, and ExternalMethod can see that the method signature includes "self" as the first argument, ExternalMethod will try to call the method again with the self argument prepended. So if you have arguments with defaults or use variable argument lists, that last algorithm falls to pieces. The solution is to always provide the "self" argument. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] External Method Missery
Chris Withers wrote: Shane Hathaway wrote: that last algorithm falls to pieces. The solution is to always provide the "self" argument. When calling or in the signature of your external method? Both. Declare it like this: def external_method(self, ...other args...): Use it like this: dtml-var "external_method(this(),...other args..." ? -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] External Method Missery
Steve Alexander wrote: Both. def external_method(self, ...other args...): dtml-var "external_method(this(),...other args..." ? I'll go with this advice since I still can't make heads or tails which of the two Shane thinks I need to do ;-) Of course, it's not documented like this. I think the docs say just make sure the def has self as the first argument... Can someone from DC pick up the Issue I dropped in the collector relating to this and solve the problem in some sensible way ;-) cheers, Chris PS: Doing both proved to be an extremely bad idea :( Suddenly I'm getting lots of key errors and the like. I'm going back to what I was doing: -self argument first in def -call with dtml-var "nav_tree(PARENTS[-2])" ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] zope and UNIX permissions
The other file (pcgi.soc) is a unix domain socket... it gets created when you run "python w_pcgi" as a Zope install command from the source distribution. I'm not sure of the danger of having this get created 777. It might be worthwhile to look into what could be done to it. Well, other than zope not responding over pcgi if it isn't 777? I just tried this out of curiousity. No response through pcgi. Hmmm... thanks for trying it. This doesn't seem much of a risk, does it? ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: ZPatterns: Errors in triggered methods + patch
Steve Alexander wrote: Latest ZPatterns release. Zope 2.2b4. If I raise an error in an external method that is called by a GenericTrigger, I sometimes get a strange log message: various bits snipped I've put the call to each Agent's "change observed" event in a try-except block. This makes my Zope instance happier when I do stupid things in external methods, and has the additional advantage of insulating other Agents from one particular Agent's problems. Of course, a patch that made a suitable log entry would be better than what I just posted to the list, which just writes the execption and traceback to stderr. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns -- trigger add events not working
It could cause a problem if the object is added after any other sort of change from the point of view of the Agent. The Agent would view it as having been added, when in fact it is actually merely changed. I have not, however, been able to think of any scenario where this condition could occur unless the DataManager containing the Agent was itself being reconfigured during the same transaction as the other events, which is an "all bets are off, hold onto your butts" type proposition anyhow. My guess is that your patch will probably work fine. I've checked it in locally and will incorporate it into a release soon. At 04:09 PM 7/12/00 +0100, Steve Alexander wrote: Steve Alexander wrote: "Phillip J. Eby" wrote: This would explain why you only get a change event, since if add happens after change, it is ignored. I'm curious how the change event is getting called first, since... Oh. I'll bet I know what it is. It's probably that manage_afterAdd is being called later in the ObjectManager code than it used to be, and/or Zope is trying to set an _owner attribute on the newly added object. Crap. This is going to take some rethinking to find another way to trap the Zope "add" event. :( Looks like you're right -- manage_setLocalRoles. I have patched the _objectAdding method of class Agent in Agents.py: ... I'm not sure whether this will have any nasty side-effects though. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Beginning Zope User
Help! I downloaded a product and uploaded it to my directory, but I don't know how to unzip it. I'm using NT. Whenever I load WinZip it will only let me unzip it to local places on the hard disk but nowhere on the Zope directory itself. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope and UNIX permissions
Chris McDonough wrote: The other file (pcgi.soc) is a unix domain socket... it gets created when you run "python w_pcgi" as a Zope install command from the source distribution. I'm not sure of the danger of having this get created 777. It might be worthwhile to look into what could be done to it. Well, other than zope not responding over pcgi if it isn't 777? I just tried this out of curiousity. No response through pcgi. Hmmm... thanks for trying it. This doesn't seem much of a risk, does it? Not that I can see off-hand. It is only a socket, a means for communicating with Zope. The 'risk' would only lie in Zope's Security mechanisms. ;-) The only possible risk would be a DoS type manuever if random user could rewrite the pcgi.soc socket. You could control this through var directory permissions, will try this out and report back. Bill -- "Linux: the operating system with a CLUE... Command Line User Environment". seen in a posting on comp.software.testing ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] zope and UNIX permissions
Hmmm... thanks for trying it. This doesn't seem much of a risk, does it? Not that I can see off-hand. It is only a socket, a means for communicating with Zope. The 'risk' would only lie in Zope's Security mechanisms. ;-) The only possible risk would be a DoS type manuever if random user could rewrite the pcgi.soc socket. You could control this through var directory permissions, will try this out and report back. You're the coolest! Thanks.. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns: missing docstring in getItem()
At 11:05 PM 7/12/00 +0100, Steve Alexander wrote: ZPatterns 0.4.0a4 The file "version" reports it to be "ZPatterns-0-4-0a1". That gave me a shock! I thought for a moment that I'd been working on an obsolete edition :-) Specialists.py, line 28, method getItem() needs a docstring. Changes checked in. I should be releasing an alpha5 tomorrow. I had hoped to finish my work on proxy roles, ZClass plugins, and maybe even my local-roles stuff first and make it a "beta" release, but real life has been very much in the way of that sort of thing this week. :( ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
