- Zope - Zope lists

Re: [Zope] - database transfer
by Jim Fulton 08 Dec '98

08 Dec '98

David Ascher wrote: > > Is it easy to take the DB from a Zope server and plop it into another Zope > server? I'm not talking about load-sharing, but staging of servers -- I > tend to do my web management on a local machine, and have a periodic job > upload the files into the less-easily configured 'public' server. Can I > just tar the var/ directory and misc. external methods and move that over, The short answer is yes. You'll need to be careful to shutdown the app before moving the files over. It might be nice to have a tool that makes this easier, or even allows it to be done without shutting down. If you want to pursue this, I'd be happy to help you get started. > or are there other dependencies? Well, of course, both sites need to have the same products and other Python modules installed. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

1 0

Re: [Zope] - Win32 package install
by Jim Fulton 08 Dec '98

08 Dec '98

Mark Millikan wrote: > > Tried to install/run Zope 1.9b1: > > Following the instructions in 'win32_zope_19b1_tar.gz' works, except: > > The win32 binaries download contained a 'zlib.pyd' library and did not > contain a 'cPickleCache.pyd' library. > > Using the the following version of python: > > Python 1.5.1 (#0, Apr 13 1998, 20:22:04) [MSC 32 bit (Intel)] on win32 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > > Executing 'python serve.py' brings up an error message 'The procedure entry > point PySequence_Contains could not be located in the dynamic link library > python15.dll' - does this indicate a need for 1.5.2? > > Mark Millikan Note that we plan to make a fully self-contained wise-automated win32 binary release on Friday. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

1 0

Re: [Zope] - Problem with ExternalMethod
by Jim Fulton 08 Dec '98

08 Dec '98

A.M. Kuchling wrote: > > I'm trying to figure out how to create a function that can be turned > into an ExternalMethod. The module name is AMK.Tester, and the > function name is test1. > > The steps I followed were: > > 1) Create an AMK/Extensions directory in the Products/ directory. > 2) Create Tester.py in the AMK/Extensions directory, and put a test() > function in it. > 3) Encrypt the .py file to produce a .pyp file with a little program. > 4) Attempting to create the ExternalMethod object gets a traceback: > > Traceback (innermost last): > File /home/opt/zope/lib/python/ZPublisher/Publish.py, line 861, in publish_module > File /home/opt/zope/lib/python/ZPublisher/Publish.py, line 583, in publish > (Info: /manage_addExternalMethod) > File /home/opt/zope/lib/python/Products/ExternalMethod/ExternalMethod.py, line 125, in manage_addExternalMethod > (Object: ApplicationDefaultPermissions) > File /home/opt/zope/lib/python/Products/ExternalMethod/ExternalMethod.py, line 167, in __init__ > (Object: Item) > File /home/opt/zope/lib/python/Products/ExternalMethod/ExternalMethod.py, line 186, in manage_edit > (Object: Item) > File /home/opt/zope/lib/python/Products/ExternalMethod/ExternalMethod.py, line 206, in getFunction > (Object: Item) > File /home/opt/zope/lib/python/App/Extensions.py, line 104, in __cmp__ > AttributeError: 'None' object has no attribute 'co_argcount' > > Looking at the code in ExternalMethod.py, the ExternalMethod class > attribute func_code is set to None. When .getFunction() is called, > self.func_code is None, so the comparison in the following line fails: > if func_code != self.func_code: self.func_code=func_code > > The FuncCode.__cmp__ method is: > def __cmp__(self,other): > return cmp((self.co_argcount, self.co_varnames), > (other.co_argcount, other.co_varnames)) > > other is None, so the AttributeError results. I don't see what the > problem is, unless some external thing is expected to set the > .func_code attribute. Or are there more things that I need to define > in my package directory? The problem is that in Python 1.4, errors in cmp were ignored and caused an effective enequality. In Python 1.5 cmp is handled differently, which is a good thing, and I failed to test ExternalMethod with it, which is a bad thing. :| The next release will have following __cmp__ function, which seems to solve the problem: def __cmp__(self,other): if other is None: return 1 try: return cmp((self.co_argcount, self.co_varnames), (other.co_argcount, other.co_varnames)) except: return 1 -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

2 1

RE: [Zope] - newbie PCGI problems
by Jeff Bauer 08 Dec '98

08 Dec '98

> Reading your "Sacrificial Virgin" email: so on Solaris is it > necessary to have the UNION_SEMUN macro in pcgi.h? No, that email was mistakenly based on the pre-release. The UNION_SEMUN problem was fixed prior to general release. >> The Rewrite directives for Apache normally go in >> httpd.conf. Actually the Rewrite directives should only >> affect authorization, so if you are denied access *after* >> the user name and password dialog appears, everything >> else with PCGI is probably working. > Cool. I added em, but it didn't seem to help much. They won't help much the first time. You've got to stare at them long and hard and squint your eyes up funny. Seriously, the main thing is to check your path settings and that you're using the absolute path. [ Peter performs invasive surgery on Publisher.py ... ] > Okay, changed that back... actually, to be totally safe, > I scrubbed everything and reinstalled Zope > ... > and tried again-- got the authentication screen. Still > can't authenticate. >> The pcgi_publisher.py module is actually trying to import >> publish_module from ZPublisher. > Yea-- Can't seem to get around this... > <cringe> > Potential stupid question: Shouldn't there be a ZPublisher > module somewhere? > </cringe> Not a stupid question at all, it's using the new import package mechanism in Python 1.5: Zope-1.9b1-src/ lib/ python/ ZPublisher/ __init__.py "from Publish import publish_module" Publish.py def publish_module(): ... > NOW, the ../cgi-bin/pcgifile.py?filename=.../Zope.cgi thing > gives me > PCGI info file: /export/home/pulintz/Zope-1.9b1-src/Zope.cgi > PCGI wrapper: /export/home/pulintz/Zope-1.9b1-src/pcgi/pcgi-wrapper > PCGI_SOCKET_FILE write permission error: > /export/home/pulintz/Zope-1.9b1-src/var/pcgi.soc > status: FAILURE Hmm ... pcgifile.py is pretty explicit that it can't write to your pcgi.soc socket. Any possibility you left an earlier LRP running? Feel free to disagree with pcgifile.py's interpretation of events, just send me a patch if you do ;-) Also, since you mention that you're just getting started with Apache, a couple other things worth mentioning. 1) Your Apache cgi processes are probably running as user 'nobody', so it may not be obvious that you have a file or directory it can't properly access. 2) You can try to create /tmp/var on the server's local filesystem and chmod 0777 it. Then change Zope.cgi parameters to reflect the new var position. Again, I'm only suggesting this because there may be an Apache issue you're not aware of or don't want to spend time tracking down just yet. Here's a sidetrack that won't really help you solve your problem, but may give you some confidence that pcgi is working (or not). Grab the pcgitest and pcgitime.py files and put them in your Apache cgi-bin directory. Edit the pcgitime info file to match your settings and try: http://.../cgi-bin/pcgitest/getTime You should get a timestamped response. See the notes at http://starship.skyport.net/crew/jbauer/persistcgi/howto/ for further information. Good luck, Jeff Bauer Rubicon, Inc.

1 0

Re: [Zope] - HELP problems
by Jim Fulton 08 Dec '98

08 Dec '98

Christopher G. Petrilli wrote: > > Gang, > > I just started playing with the reelease---the right one this time--and > noticed that if I click "help" tab, then it opens a new window, but > never actually loads anything... is this the righ behaviour? :-) No. It's not the behavior I get either. What version of Python are you using? > I went looking and everything seems to be there, but it doesn't seem to > be "linked" in, and being new and all to Zope, can someone explain how I > make it work? It works for me. Are you still having the problem? If so, could you provide a URL to your site? Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

2 1

Re: [Zope] - Misc questions & Suggestions
by Jim Fulton 08 Dec '98

08 Dec '98

David Ascher wrote: > (snip) > 5) I think I may have found a bug (and a fix!). I was trying to add an > External Method. I did the following: (patch snipped) I posted a similar change earlier. The fix will be included in the next release. > 6) Is there a way to make Zope *reload* the Python module from disk w/o > restarting Zope? Other's have mentioned how ExternalMethods are reloaded. It is also theoretically possible to get other modules reloaded. It involves some careful handling of database objects so that the changes have an effect. There's some machinery in ExternalMethod to attempt this. It's been a while since I tried it and can't say at this point how well it works. > 7) I assume that the current mechanism of adding modules in "Extensions" > folders for external methods and adding modules in lib/python for > things that need to be imported will be revised to be more scalable, > right? That's not really the current approach. Unfortunately, the current approach is not documented. Generally, new modules should go in Product packages or Shared packages. Note that I said *packages*. Zope is very package-centric. All new modules (excluding extentions, like ExternalMethods, should be in packages. The Products package is for packages that provide meta data telling Zope how to fold products into the Zope menus and security system. Shared packages are for packages that may be shared between multiple products. This is hard to see right now, because there aren't any shared packages in the release, and we are still in the process of converting our products to use this scheme. Note that the Shared package will be subdivided by organization. For example, when Z SQL Methods (formally known as Aqueduct) is released, it will be layed out as follows: lib python Products ZSQLMethods ZGadflyDA Shared DC ZRDB where ZSQLMethods provides the ability to add SQL methods, ZGadflyDA provides access to Gadfly databases, and ZRDB provides code shared by these and other products that deal with relational data. > This approach seems to view code completely unlike data, which > is sort of strange coming from the Zope Way -- but I can understand > that it hasn't been a problem in the past since only the Principia > developers were probably adding Python code. Still, I want automatic > version control of external methods just like version control of my > HTML documents! There are pros and cons with storing Python code in the database. This is an issue worthy of further consideration, although I won't have the bandwidth fow quite a while. I don't think it has *that* much to do with who is doing development. I think that the package scheme we're using should go a long way toward organizing modules. (snip) Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

1 0

Re: [Zope] - Misc questions & Suggestions
by Jim Fulton 08 Dec '98

08 Dec '98

"Andrew M. Kuchling" wrote: > > Paul Everitt writes: > >Mike wrote: > >> Litteraly cron? Why not use the Scheduler package? > >> Was that what > >> it was designed for? > > > >Errm, yes, but we never finished it :^) We wanted to have a cron-like > > Bugger; I wanted to use the Scheduler for my slashdot package. > So how do you do timed events now? We use cron. :| We shelved Sheduler a while back because: - It wasn't critical to the projects we were working on, - At the time, threads were problematic on some platforms we did care about (and Scheduler was threads based), - We were planning to add concurrency application-wide and we expected the scheduler design to be significantly affected. We plan to revisit Scheduler in a big way after Zope 2.0 is releases, however, if anyone wants to make progress on Scheduler now, I'd be happy to provide advice and review. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

1 0

Re: [Zope] - zope jitterbug
by Dinu C. Gherman 08 Dec '98

08 Dec '98

-----Original Message----- From: Paul Everitt <Paul(a)digicool.com> To: Alan Wostenberg <awostenb(a)baan.com>; zope(a)zope.org <zope(a)zope.org> Date: Tuesday, December 08, 1998 4:17 PM Subject: RE: [Zope] - zope jitterbug > http://www.digicool.com/site/Collector/ > >The biggest problem we had in doing the Collector was requirements. We >never had the discipline to write down what we wanted it to do! Thus, I >think the first requirement for "Zitterbug" would be to focus on the >early part of the software lifecycle. I don't know anything about Jitterbug or something like that, but in my company we use an IBM dinosaur software called CMVC, Conf. Mgmt. Version Control, something long given up by IBM even... This calls for a remark that, based on daily experience, I'd expect users of such a system not only to deal with requirements, too, but also with a sound versioning concept, especially if you are to roll- out new or customer-specific versions on an almost daily basis as we do. It seems to me that a really good tool here would be a well-balanced combination of concepts from at least three key areas: versioning, database and development environment. So far I've seen no such animal in the Python world, but I'd love to be proven wrong, ASAP. ;-) Dinu --- Dinu C. Gherman LHS International AG : http://www.lhsgroup.com 8050 Zurich : http://www.zurich.ch Switzerland : mobile://49.172.3060751

1 0

- Installation problem
by Dennis Scott 08 Dec '98

08 Dec '98

I downloaded Zope and followed the INSTALL.txt directions. The installation stops at the following: rm -f *.so *.sl so_locations VERSION=`/usr/bin/python -c "import sys; print sys.version[:3]"`; \ installdir=`/usr/bin/python -c "import sys; print sys.prefix"`; \ exec_installdir=`/usr/bin/python -c "import sys; print sys.exec_prefix"`; \ make -f ./Makefile.pre.in VPATH=. srcdir=. \ VERSION=$VERSION \ installdir=$installdir \ exec_installdir=$exec_installdir \ Makefile make[1]: Entering directory `/usr/local/src/Zope-1.9b1-src/lib/python' make[1]: *** No rule to make target `/usr/lib/python1.5/config/Makefile', needed by `sedscript'. Stop. make[1]: Leaving directory `/usr/local/src/Zope-1.9b1-src/lib/python' make: *** [boot] Error 2 Traceback (innermost last): File "wo_pcgi.py", line 100, in ? File "/usr/local/src/Zope-1.9b1-src/build_extensions.py", line 96, in ? make('lib','python') File "/usr/local/src/Zope-1.9b1-src/do.py", line 105, in make do('make -f Makefile.pre.in boot PYTHON=%s' % sys.executable) File "/usr/local/src/Zope-1.9b1-src/do.py", line 97, in do if i and picky: raise SystemError, i SystemError: 512 I am using Python 1.5.1 on Redhat Linux 5.2. Thanks Dennis Scott themenace(a)mindless.com

3 3

RE: [Zope] - zope jitterbug
by Paul Everitt 08 Dec '98

08 Dec '98

Alan wrote: > I'm unfamiliar with Zope. Would it be an adequate tool to > build an internet > based bug tracking system: a clone of jitterbug (see > http://samba.anu.edu.au/jitterbug/ or > http://www.gnome.org/cgi-bin/bugs > )Would such a project be meaured in days, weeks, or months? Thanks! Yes, it would be a really good system for doing that. We build one over at: http://www.digicool.com/site/Collector/ based on our Tabula product that runs in Zope. The biggest problem we had in doing the Collector was requirements. We never had the discipline to write down what we wanted it to do! Thus, I think the first requirement for "Zitterbug" would be to focus on the early part of the software lifecycle. --Paul

1 0