From mlm@acm.org Mon Oct 1 00:19:47 2001 From: mlm@acm.org (Mitchell L Model) Date: Sun, 30 Sep 2001 19:19:47 -0400 Subject: [Zope-dev] compiling Zope 2.4.1 on Mac OS 10.1 Message-ID: --============_-1210230503==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Trouble compiling Zope 2.4.1 on Mac OS 10.1: installed a fresh 10.1 that I just got from Apple downloaded the Zope 2.4.1 src tried 'python wo_pcgi' with both a Python 2.2a4 I just made and with my previous Python 2.1, both with and without sudo Whatever I do, it breaks in the same place. Here's the end of the output: sed -f sedscript ./Makefile.pre.in >Makefile.pre /usr/local/lib/python2.1/config/makesetup \ -m Makefile.pre -c /usr/local/lib/python2.1/config/config.c.in Setup -n /usr/local/lib/py\ thon2.1/config/Setup.config /usr/local/lib/python2.1/config/Setup.local /usr/local/lib/python2.1/co\ nfig/Setup make -f Makefile do-it-again /usr/local/lib/python2.1/config/makesetup \ -m Makefile.pre -c /usr/local/lib/python2.1/config/config.c.in Setup -n /usr/local/lib/py\ thon2.1/config/Setup.config /usr/local/lib/python2.1/config/Setup.local /usr/local/lib/python2.1/co\ nfig/Setup make cc -g -O2 -Wall -Wstrict-prototypes -I/usr/local/include/python2.1 -I/usr/local/include/python2.1 \ -DHAVE_CONFIG_H -I../Components/ExtensionClass/src -c ././../Components/ExtensionClass/src/Extensi\ onClass.c -o ./ExtensionClass.o In file included from /usr/local/include/python2.1/pyport.h:84, from /usr/local/include/python2.1/Python.h:54, from ././../Components/ExtensionClass/src/ExtensionClass.h:114, from ././../Components/ExtensionClass/src/ExtensionClass.c:61: /usr/include/math.h:191: warning: function declaration isn't a prototype cc -bundle -undefined suppress ./ExtensionClass.o -o ./ExtensionClass.so /usr/bin/ld: -undefined error must be used when -twolevel_namespace is in effect make: *** [ExtensionClass.so] Error 1 Traceback (most recent call last): File "wo_pcgi.py", line 117, in ? File "wo_pcgi.py", line 105, in main File "/usr/local/src/Zope-2.4.1-src/inst/build_extensions.py", line 102, in ? make('lib','python') File "/usr/local/src/Zope-2.4.1-src/inst/do.py", line 135, in make do('make') File "/usr/local/src/Zope-2.4.1-src/inst/do.py", line 104, in do if i and picky: raise SystemError, i SystemError: 512 The 'two-level namespace' business is a change from the OX X developer tools version 10.0 to 10.1. Anyone know what's going on here and how to fix it? -- --- Mitchell --============_-1210230503==_ma============ Content-Type: text/html; charset="us-ascii" compiling Zope 2.4.1 on Mac OS 10.1
Trouble compiling Zope 2.4.1 on Mac OS 10.1:

installed a fresh 10.1 that I just got from Apple

downloaded the Zope 2.4.1 src

tried 'python wo_pcgi' with both a Python 2.2a4 I just made and with my previous Python 2.1, both with and without sudo

Whatever I do, it breaks in the same place.  Here's the end of the output:

sed -f sedscript ./Makefile.pre.in >Makefile.pre
/usr/local/lib/python2.1/config/makesetup \
         -m Makefile.pre -c /usr/local/lib/python2.1/config/config.c.in Setup -n  /usr/local/lib/py\
thon2.1/config/Setup.config /usr/local/lib/python2.1/config/Setup.local /usr/local/lib/python2.1/co\
nfig/Setup
make -f Makefile do-it-again
/usr/local/lib/python2.1/config/makesetup \
         -m Makefile.pre -c /usr/local/lib/python2.1/config/config.c.in Setup -n  /usr/local/lib/py\
thon2.1/config/Setup.config /usr/local/lib/python2.1/config/Setup.local /usr/local/lib/python2.1/co\
nfig/Setup
make
cc  -g -O2 -Wall -Wstrict-prototypes -I/usr/local/include/python2.1 -I/usr/local/include/python2.1 \
-DHAVE_CONFIG_H  -I../Components/ExtensionClass/src -c ././../Components/ExtensionClass/src/Extensi\
onClass.c -o ./ExtensionClass.o
In file included from /usr/local/include/python2.1/pyport.h:84,
                 from /usr/local/include/python2.1/Python.h:54,
                 from ././../Components/ExtensionClass/src/ExtensionClass.h:114,
                 from ././../Components/ExtensionClass/src/ExtensionClass.c:61:
/usr/include/math.h:191: warning: function declaration isn't a prototype
cc  -bundle -undefined suppress  ./ExtensionClass.o   -o ./ExtensionClass.so
/usr/bin/ld: -undefined error must be used when -twolevel_namespace is in effect
make: *** [ExtensionClass.so] Error 1
Traceback (most recent call last):
  File "wo_pcgi.py", line 117, in ?
  File "wo_pcgi.py", line 105, in main
  File "/usr/local/src/Zope-2.4.1-src/inst/build_extensions.py", line 102, in ?
    make('lib','python')
  File "/usr/local/src/Zope-2.4.1-src/inst/do.py", line 135, in make
    do('make')
  File "/usr/local/src/Zope-2.4.1-src/inst/do.py", line 104, in do
    if i and picky: raise SystemError, i
SystemError: 512

The 'two-level namespace' business is a change from the OX X developer tools version 10.0 to 10.1.

Anyone know what's going on here and how to fix it?
--

    --- Mitchell
--============_-1210230503==_ma============-- From richard@bizarsoftware.com.au Mon Oct 1 00:41:32 2001 From: richard@bizarsoftware.com.au (Richard Jones) Date: Mon, 1 Oct 2001 09:41:32 +1000 Subject: [Zope-dev] Zope on Windows/Mac OS X: BatteriesIncludedDistribution In-Reply-To: <3BB46773.1090505@zope.com> References: <0109270924220F.13278@ike> <3BB46773.1090505@zope.com> Message-ID: <01100109413219.13278@ike> On Friday 28 September 2001 22:05, Paul Everitt wrote: > Whew, what a proposal and what a good sign! > > As several have noted, there are quite a few proposals in the fishbowl > that deal with different aspects of the problems. There's also a draft > proposal that we had here in ZC that expands on the items. Finally, > there appear to be a few pieces of software (yours, zctl, zopectl, etc.) > that try to address aspects. > > I suggest that we all spend some time trying to revisit all the > proposals, obsolete the ones that are covered elsewhere, and try to find > the common ground. There is a dorman zope-packagers mailing list we > could hijack for these purposes: > > http://lists.zope.org/pipermail/zope-packagers/ > > I think, with all the various efforts, it is time to agree on some > standards regarding where configuration data lives and how it looks. OK, I've joined that list. I did not realise the worm can was this big :) Richard From joe@iuveno-net.de Mon Oct 1 09:06:04 2001 From: joe@iuveno-net.de (Joachim Werner) Date: Mon, 1 Oct 2001 10:06:04 +0200 Subject: [Zope-dev] [Bug] DateTime(string) uses GMT as timezone References: <15287.32138.623859.290077@lindm.dm> <3BB789E3.8090302@cat-box.net> Message-ID: <003101c14a4f$eba4c340$1d00a8c0@iuvenonet.home> Hi! Stephan Richter has started to re-implement DateTime using mxDateTime a couple of weeks ago. That should fix all the various problems with DateTime. At Zope Corporation, Andreas Jung took care of that. So if you complain loud enough, I guess the fix could go into the 2.5 release. It just might be hard to be backward-compatible with all the errors, but maybe there could be something like a legacy mode you can activate if you need it ... ;-) Joachim ----- Original Message ----- From: "Steve Alexander" To: "Dieter Maurer" Cc: Sent: Sunday, September 30, 2001 11:08 PM Subject: Re: [Zope-dev] [Bug] DateTime(string) uses GMT as timezone > Dieter Maurer wrote: > > > Unfortunately > > > > DateTime(year,month,day) != DateTime("%d-%d-%d" % (year,month,day)) > > > > The former uses the local timezone (which I think is right) > > while the latter uses GMT+0 (which seems not right). > > > > Thinks are quite bad, as the latter is used to convert > > ":date" form values into DateTime objects. > > > See also here: > > http://lists.zope.org/pipermail/zope-dev/2001-August/012974.html > > ---- > > I get different times from a string, depending whether I use '-' or '/' > as a date delimiter. > > >>> from DateTime.DateTime import DateTime > >>> DateTime('2001-08-20').pCommonZ() > 'Aug. 20, 2001 12:00 am GMT+0' > >>> DateTime('2001/08/20').pCommonZ() > 'Aug. 20, 2001 12:00 am GMT+1' > >>> > > I find the difference a tad surprising. > > Is this a bug or a feature? > > If it's a bug, I'll work on a fix. > > I'm guessing this is a feature; perhaps using the '-' delimiter suggests > I'm trying to use ISO formatting. > > I'm running this in a GMT+1 timezone btw. > > Zope latest from CVS, Python 2.1. > ---- > > I never got a reply as to whether it was a bug or a feature, so I didn't > work on a fix. > > -- > Steve Alexander > Software Engineer > Cat-Box limited > > > > _______________________________________________ > Zope-Dev maillist - Zope-Dev@zope.org > 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 ) > > From tdickenson@geminidataloggers.com Mon Oct 1 11:08:54 2001 From: tdickenson@geminidataloggers.com (Toby Dickenson) Date: Mon, 01 Oct 2001 11:08:54 +0100 Subject: [Zope-dev] syslog Message-ID: <7qfgrtgfk47sorgevhai6cjtrvjo1ks9hd@4ax.com> I am looking to configure my Zope to use syslog for the first time. I see that 2.4 uses the same environment variables to control whether syslog is used for access logs and event logs. This seems like a bad idea to me; the two log sources have completely different purposes, and I dont think it is possible to separate the two using syslog rules. Am I missing something? Toby Dickenson tdickenson@geminidataloggers.com From tdickenson@geminidataloggers.com Mon Oct 1 11:41:20 2001 From: tdickenson@geminidataloggers.com (Toby Dickenson) Date: Mon, 01 Oct 2001 11:41:20 +0100 Subject: [Zope-dev] DISCUSS: Community checkins for CVS In-Reply-To: <3BB07821.4060004@zope.com> References: <20010925132504.A5609@vet.uu.nl> <3BB07821.4060004@zope.com> Message-ID: On Tue, 25 Sep 2001 08:27:13 -0400, Paul Everitt wrote: >Martijn Faassen wrote: > > >>> http://dev.zope.org/CVS/Contributor.pdf >>> >>=20 >> This says 'you must indicate your agreement to the term below'; = shouldn't >> it be 'terms'? > > >Uhh...well...yes! I'll make the change. I'm waiting for news back from= =20 >the lawyer about provisions for handling patches. I'll then post a new=20 >rev of the materials. > >Does anyone think this is close enough that I can go ahead and get the=20 >bootstrap group (under ten, selected by us) going? I'd like to avoid=20 >making them sign and mail an agreement, then do it again if there's=20 >substantive changes. Yes, I think it is close enough to get started. Toby Dickenson tdickenson@geminidataloggers.com From Thomas_Janke@prisma-edv.de Mon Oct 1 12:50:25 2001 From: Thomas_Janke@prisma-edv.de (Thomas_Janke@prisma-edv.de) Date: Mon, 1 Oct 2001 13:50:25 +0200 Subject: [Zope-dev] Stored Procedures with Sybase and the Sybase DA Message-ID: Hello, Does anybody know of any development going on regarding Sybase and stored procedures? Christopher Petrilli declared them a future goal, but I urgently need them by now. So if anybody has a workarround, please let me know. Yours Thomas PS: Do reply directly to my address since I'm not a member of this mailing list. Thanks From pje@telecommunity.com Mon Oct 1 13:25:10 2001 From: pje@telecommunity.com (Phillip J. Eby) Date: Mon, 01 Oct 2001 07:25:10 -0500 Subject: [Zope-dev] Stored Procedures with Sybase and the Sybase DA In-Reply-To: Message-ID: <5.1.0.14.0.20011001071723.0304f230@telecommunity.com> At 01:50 PM 10/1/01 +0200, Thomas_Janke@prisma-edv.de wrote: >Does anybody know of any development going on regarding Sybase and stored >procedures? Christopher Petrilli declared them a future goal, but I urgently >need them by now. So if anybody has a workarround, please let me know. Ty did some work on this for Zope 2.2 which you can find at: http://cvs.eby-sarna.com/ZProducts/SybaseStoredProcedure/ There's no docs to speak of. Feel free to use it if you can get it to work. I think that to get this to work, we also had to patch the Sybase DA to handle status result codes, but that patch might have been incorporated into Zope. I'm not positive about any of this. :( All I can tell you is that the code above is in actual use in a production application that needed stored-procedure support. Note that it does not support returning SELECT results from procedures; only non-negative status returns. It assumes a negative status is an error, and if it's one of the standard Sybase status error codes (e.g. -3 for a deadlock), it throws a "SybaseProcError" with an explanation and the original query text. The return value from calling a StoredProcedure object is always an integer 0 or greater, unless the status return is negative, in which case an exception is raised. From dario@ita.chalmers.se Mon Oct 1 14:06:44 2001 From: dario@ita.chalmers.se (=?iso-8859-1?Q?Dario_Lopez-K=E4sten?=) Date: Mon, 1 Oct 2001 15:06:44 +0200 Subject: [Zope-dev] Problems with Oracle DA and Dates Message-ID: <00e901c14a79$ec235000$33de1081@ita.chalmers.se> (I apologise in advance for the crosspost, but I think this is a valid question on both the zope-db and zope-dev lists. If you disagree, flame away, and I'll never do it again. oh, btw: flame in private mail, please) Hello! We have run into a showstopper problem here where it seems (we're not sur= e yet) that there is a severe problem using dates returned from the Oracle = DA adapter. Other possible culprits include LocalFS, Transparent Folder, Formulator and the source release of Zope 2.4.1. The problem is that Zope either dies, core dumps and dies, or slows down = to a crawl. We are using the Zope 2.4.1 release, with Transparent folders and LocalFS= , latest, and a sligthly modified Formulator. There are about 2-6 people working and developing in it during all hours = of the day (24 hours). Unfortunately nothing shows up in any of the logs, so they are of little use; I don't even have a traceback so display. We *think* we found someti= gn pointing at LocalFS in one of the coredumps, but we are lowly non-unix programmers, and have no idea if this is accurate info or not. It could j= ust be un-collected garabage memory. Is anybody noticing anything similar, or if you have any opinion on what might be going on, please reply; we are in DS mode here (we are having a prototype presentation during two weeks, starting tomorrow) and are feeli= ng a bit desperate. Sincerely, /dario - -------------------------------------------------------------------- Dario Lopez-K=E4sten Systems Developer Chalmers Univ. of Technology dario@ita.chalmers.se ICQ will yield no hits IT Systems & Services From c.duncan@nlada.org Mon Oct 1 14:31:47 2001 From: c.duncan@nlada.org (Casey Duncan) Date: Mon, 1 Oct 2001 09:31:47 -0400 Subject: [Zope-dev] KeyError on UnIndex.keyForDocument In-Reply-To: <3BB62F3D.8070701@digicool.com> References: <9p1jsg$2ui$1@dev.in.nuxeo.com> <3BB62F3D.8070701@digicool.com> Message-ID: On Saturday 29 September 2001 04:29 pm, Chris McDonough allegedly wrote: > Yeah, I could see this error being raised if you had just added an index > to use as the sort index and it didn't have all objects indexed within > it yet... > > And yes, if this is what it is, it's a bug. But it's structural and not > operational... we need to think a bit about what it means to add an > unpopulated index to an existing catalog. Currently you just need to > know that you must reindex the catalog. > > - C What would the reaction be to changing this behavior. I have written some code that automatically populates the index when it is added. I personally think that reindexing every index just to populate one is grossly inefficient. I wrote this single index update because of the DocumentLibrary product which performs real-time document format conversions when documents are indexed. With a catalog of more than 100 MSWord documents, It is glacial to update the entire catalog. Although I have not put this code into a DocumentLibrary release yet, I would prefer to see it put directly into the catalog. Whaddya think? /---------------------------------------------------\ Casey Duncan, Sr. Web Developer National Legal Aid and Defender Association c.duncan@nlada.org \---------------------------------------------------/ From chrism@zope.com Mon Oct 1 14:55:06 2001 From: chrism@zope.com (Chris McDonough) Date: Mon, 1 Oct 2001 09:55:06 -0400 Subject: [Zope-dev] KeyError on UnIndex.keyForDocument References: <9p1jsg$2ui$1@dev.in.nuxeo.com> <3BB62F3D.8070701@digicool.com> <200110011330.f91DUAX06585@smtp.zope.com> Message-ID: <002001c14a80$ad95f5c0$8e17a8c0@kurtz> > What would the reaction be to changing this behavior. I have written some > code that automatically populates the index when it is added. I personally > think that reindexing every index just to populate one is grossly inefficient. I think populating only one index on add is a great idea... the main issue is backwards-compatibility... but that shouldn't be too hard to maintain. From pje@telecommunity.com Mon Oct 1 15:01:21 2001 From: pje@telecommunity.com (Phillip J. Eby) Date: Mon, 01 Oct 2001 09:01:21 -0500 Subject: [Zope-dev] Stored Procedures with Sybase and the Sybase DA In-Reply-To: Message-ID: <5.1.0.14.0.20011001085939.05969b50@telecommunity.com> At 03:33 PM 10/1/01 +0200, Thomas_Janke@prisma-edv.de wrote: >I use the newest version of the Sybase DA, but it doesn't seem to work. >Can you >help me finding the appropriate patches, etc? Are they available anywhere in >that CVS-tree?` I don't think so. Ty was going to submit them to ZC for inclusion; I don't know if he did or not. It had to do with a Sybase discriminator code that the existing DA didn't handle. From brian.lloyd@zope.com Mon Oct 1 15:30:29 2001 From: brian.lloyd@zope.com (Brian Lloyd) Date: Mon, 1 Oct 2001 10:30:29 -0400 Subject: [Zope-dev] Web Services for Zope In-Reply-To: <200109280515.f8S5FJD222718@pimout3-int.prodigy.net> Message-ID: > i've been very curious, what the plan is for attacking the no > magic problem > described on the wiki. my understanding is this isn't possible without > altering the publishing process. i guess i was curious if the > component based > publisher that was talked about at ipc9 was ever going to see the > light of > day or if there was another strategy that would work as well. I think that components will ultimately be the answer to this. You would basically create a "SOAP publishing component" (or one might be provided but not necessarily activated by default) and associate it with interfaces supported by the objects that you want to publish via SOAP. I encourage people interested in this to be sure to pay attention to the ongoing component architecture work at: http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ ...and be sure to provide any feedback you have. There is enough detail there now that developers should be able to start getting an idea of how such a thing would work - or at least start asking more detailed questions about the grey areas :) Brian Lloyd brian@zope.com Software Engineer 540.361.1716 Zope Corporation http://www.zope.com From matt@zope.com Mon Oct 1 15:12:02 2001 From: matt@zope.com (Matthew T. Kromer) Date: Mon, 01 Oct 2001 10:12:02 -0400 Subject: [Zope-dev] compiling Zope 2.4.1 on Mac OS 10.1 References: Message-ID: <3BB879B2.40407@zope.com> Mitchell L Model wrote: > Trouble compiling Zope 2.4.1 on Mac OS 10.1: > > tried 'python wo_pcgi' with both a Python 2.2a4 I just made and > with my previous Python 2.1, both with and without sudo > > cc -bundle -undefined suppress ./ExtensionClass.o -o > ./ExtensionClass.so > > /usr/bin/ld: -undefined error must be used when > -twolevel_namespace is in effect > > [...] > > > The 'two-level namespace' business is a change from the OX X developer > tools version 10.0 to 10.1. > > > Anyone know what's going on here and how to fix it? > Well, besides the obvious that MacOS 10.1 is only hot-off-the-shelves for a few hours, the problem is that the dynamic loader under Darwin used a flat namespace to load ALL shared libraries into (does Windows do the same? I dont know) whereas most Unixes load each shared library with its own namespace [which is a bit of a technical abstraction and hand waving]. It sure looks to me like Apple is trying to fix the namespace collision problems with dyld, with that -twolevel_namespace (which sounds like a funky namespace munger). My best guess at noodling the error message is that it means "your library must use the symbol 'undefined error'" when the loader goes to load a name from the library and it is not present. It may be that there is something like a interrogation call to the library -- "do you have member X?" -- rather than what I'm used to, which is the loader looking in the library's table of contents. I suspect, but dont know, that it has to do with how Objective C methods get bound dynamically. Thats not a very helpful response, but until I go to an Apple store to get OS 10.1, I can't see it in action or read the docs. From chrism@zope.com Mon Oct 1 14:06:26 2001 From: chrism@zope.com (Chris McDonough) Date: Mon, 01 Oct 2001 09:06:26 -0400 Subject: [Zope-dev] syslog References: <7qfgrtgfk47sorgevhai6cjtrvjo1ks9hd@4ax.com> Message-ID: <3BB86A52.1090706@digicool.com> I'll admit that I don't know. The ZLogger module makes some noise about syslog, but I dont even know if and when that module is used (as opposed to the zLOG module). Have you verified this by trying it? Toby Dickenson wrote: > I am looking to configure my Zope to use syslog for the first time. > > I see that 2.4 uses the same environment variables to control whether > syslog is used for access logs and event logs. This seems like a bad > idea to me; the two log sources have completely different purposes, > and I dont think it is possible to separate the two using syslog > rules. > > Am I missing something? > > Toby Dickenson > tdickenson@geminidataloggers.com > > _______________________________________________ > Zope-Dev maillist - Zope-Dev@zope.org > 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 ) > -- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones" From tdickenson@geminidataloggers.com Mon Oct 1 16:14:47 2001 From: tdickenson@geminidataloggers.com (Toby Dickenson) Date: Mon, 1 Oct 2001 16:14:47 +0100 Subject: [Zope-dev] syslog Message-ID: <9FC702711D39D3118D4900902778ADC83248B7@jupiter.internal.geminidataloggers.com> > I'll admit that I don't know. The ZLogger module makes some > noise about > syslog, but I dont even know if and when that module is used > (as opposed > to the zLOG module). It is actually always used unless Zope is started read-only. Its not easy to follow *how* this happens - and I am still not sure *why* its done this way. As for the how: ZLogger starts out with a from zLog import *, it then sets up the list of standard logger objects, and defines the log_write function. Later, z2.py transplants the log_write function from ZLogger into zLOG, where it is used by the implementation of zLOG.LOG (the usual logging API) > Have you verified this by trying it? Definitely yes - my syslog filled up with access log information. A question for all syslog users; is it ever useful to send access logs to syslog? (I can't think of good reason, but my syslog zen quotient is still low). Is anyone else even using syslog? Anyway, for anyone else interested, below a patch so that the configuration of access-syslog uses different environment variables to event-syslog. Index: z2.py =================================================================== RCS file: /home/cvs/development/external/Zope2/z2.py,v retrieving revision 1.14 diff -c -2 -r1.14 z2.py *** z2.py 10 Sep 2001 15:32:28 -0000 1.14 --- z2.py 1 Oct 2001 14:35:43 -0000 *************** *** 635,646 **** if READ_ONLY: lg = logger.file_logger('-') # log to stdout ! elif os.environ.has_key('ZSYSLOG'): ! lg = logger.syslog_logger(os.environ['ZSYSLOG']) ! if os.environ.has_key("ZSYSLOG_FACILITY"): ! lg = logger.syslog_logger(os.environ['ZSYSLOG'],facility=os.environ['ZSYSLOG_FACI LITY']) else: ! lg = logger.syslog_logger(os.environ['ZSYSLOG']) ! elif os.environ.has_key('ZSYSLOG_SERVER'): ! (addr, port) = string.split(os.environ['ZSYSLOG_SERVER'], ':') lg = logger.syslog_logger((addr, int(port))) else: --- 635,646 ---- if READ_ONLY: lg = logger.file_logger('-') # log to stdout ! elif os.environ.has_key('ZSYSLOG_ACCESS'): ! lg = logger.syslog_logger(os.environ['ZSYSLOG_ACCESS']) ! if os.environ.has_key("ZSYSLOG_ACCESS_FACILITY"): ! lg = logger.syslog_logger(os.environ['ZSYSLOG_ACCESS'],facility=os.environ['ZSYSL OG_FACILITY']) else: ! lg = logger.syslog_logger(os.environ['ZSYSLOG_ACCESS']) ! elif os.environ.has_key('ZSYSLOG_ACCESS_SERVER'): ! (addr, port) = string.split(os.environ['ZSYSLOG_ACCESS_SERVER'], ':') lg = logger.syslog_logger((addr, int(port))) else: From tdickenson@geminidataloggers.com Mon Oct 1 17:10:22 2001 From: tdickenson@geminidataloggers.com (Toby Dickenson) Date: Mon, 01 Oct 2001 17:10:22 +0100 Subject: [Zope-dev] DISCUSS: Community checkins for CVS In-Reply-To: References: Message-ID: On Thu, 20 Sep 2001 16:13:57 -0400 (Eastern Daylight Time), Paul Everitt wrote: >So, let's begin what I'm sure will be a lively and illuminating >discussion. :^) A question about "Joint Ownership".... The ZPL currently includes a no-liability clause. If one half-owner were to make the source available under a different license without such a clause, would the other half-owner be liable too? Toby Dickenson tdickenson@geminidataloggers.com From alet@unice.fr Mon Oct 1 19:53:00 2001 From: alet@unice.fr (Jerome Alet) Date: Mon, 1 Oct 2001 20:53:00 +0200 Subject: [Zope-dev] syslog In-Reply-To: <9FC702711D39D3118D4900902778ADC83248B7@jupiter.internal.geminidataloggers.com>; from tdickenson@geminidataloggers.com on Mon, Oct 01, 2001 at 04:14:47PM +0100 References: <9FC702711D39D3118D4900902778ADC83248B7@jupiter.internal.geminidataloggers.com> Message-ID: <20011001205259.A572@nordine.ateur> On Mon, Oct 01, 2001 at 04:14:47PM +0100, Toby Dickenson wrote: > > A question for all syslog users; is it ever useful to send access logs to > syslog? (I can't think of good reason, but my syslog zen quotient is still > low). Is anyone else even using syslog? It may prove to be useful when you want to do remote logging: you send all to the local syslog which in fact forwards it to a remote syslog server. hth. Jerome Alet From joe@iuveno-net.de Mon Oct 1 20:08:32 2001 From: joe@iuveno-net.de (Joachim Werner) Date: Mon, 1 Oct 2001 21:08:32 +0200 Subject: [Zope-dev] somehow OT: How do I get a tar file containing the ".dtml" files only? Message-ID: <000d01c14aac$77185c00$1d00a8c0@iuvenonet.home> Hi! I am working on internationalizing a Zope 2.4.1 instance with ZBabel and providing a set of patches for Zope 2.4.1. My idea was that things would become much easier if I had a tarball that just contains all *.dtml files and the folder structure for them, so I can distribute the tarball as a patch that can be applied to a plain 2.4.1 instance. Do we have any Unix/Linux/GNU experts on the list who know how to write that as a shell command? I am sure that with tar and grep and some pipes or so it is possible, I am just too dumb to find out the right syntax ... Cheers Joachim From matt@zope.com Mon Oct 1 20:42:28 2001 From: matt@zope.com (Matthew T. Kromer) Date: Mon, 01 Oct 2001 15:42:28 -0400 Subject: [Zope-dev] somehow OT: How do I get a tar file containing the ".dtml" files only? References: <000d01c14aac$77185c00$1d00a8c0@iuvenonet.home> Message-ID: <3BB8C724.4090200@zope.com> Joachim Werner wrote: >Hi! > >I am working on internationalizing a Zope 2.4.1 instance with ZBabel and >providing a set of patches for Zope 2.4.1. My idea was that things would >become much easier if I had a tarball that just contains all *.dtml files >and the folder structure for them, so I can distribute the tarball as a >patch that can be applied to a plain 2.4.1 instance. > >Do we have any Unix/Linux/GNU experts on the list who know how to write that >as a shell command? I am sure that with tar and grep and some pipes or so it >is possible, I am just too dumb to find out the right syntax ... > >Cheers > >Joachim > So you want something like a find . -name '*.dtml' which doesn't show directories? Well, what you could do to create the tarball is something like: find . -name '*.dtml' | tar -T - -cvf dtml.tar which uses -T on gnu tar to read the filenames from stdin. > From joe@iuveno-net.de Mon Oct 1 20:49:09 2001 From: joe@iuveno-net.de (Joachim Werner) Date: Mon, 1 Oct 2001 21:49:09 +0200 Subject: [Zope-dev] Attribute error: extends ... Message-ID: <001601c14ab2$24928220$1d00a8c0@iuvenonet.home> Hi! Has anybody also had that with a Zope 2.4.1 instance (Linux)? It happens not only with Metapublisher (as in the example), but seems to occur quite randomly. It might be a problem with my local install, but even if it is, it should not happen (as I just have some custom Products installed) ... Cheers Joachim _____________ Error Type: AttributeError Error Value: extends Traceback (innermost last): File /home/ftp/root/kue-projekt/kue_9080/lib/python/ZPublisher/Publish.py, line 223, in publish_module File /home/ftp/root/kue-projekt/kue_9080/lib/python/ZPublisher/Publish.py, line 187, in publish File /home/ftp/root/kue-projekt/kue_9080/lib/python/Zope/__init__.py, line 226, in zpublisher_exception_hook File /home/ftp/root/kue-projekt/kue_9080/lib/python/ZPublisher/Publish.py, line 171, in publish File /home/ftp/root/kue-projekt/kue_9080/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: manage_addMetaPublisher) File /home/ftp/root/kue-projekt/kue_9080/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: manage_addMetaPublisher) File /usr/local/zope/skkoeln240/lib/python/Products/MetaPublisher/MetaPublisher.p y, line 247, in manage_addMetaPublisher File /usr/local/zope/skkoeln240/lib/python/Products/MetaPublisher/MetaPublisher.p y, line 108, in __init__ (Object: SupportManageHandler) File /home/ftp/root/kue-projekt/kue_9080/lib/python/Products/ZCatalog/ZCatalog.py , line 124, in manage_addZCatalog (Object: SupportManageHandler) File /home/ftp/root/kue-projekt/kue_9080/lib/python/Products/ZCatalog/ZCatalog.py , line 256, in __init__ (Object: LockableItem) File /home/ftp/root/kue-projekt/kue_9080/lib/python/Products/ZCatalog/ZCatalog.py , line 815, in addIndex (Object: LockableItem) File /home/ftp/root/kue-projekt/kue_9080/lib/python/OFS/ObjectManager.py, line 247, in all_meta_types (Object: LockableItem) AttributeError: (see above) From jens@zope.com Mon Oct 1 20:58:47 2001 From: jens@zope.com (Jens Vagelpohl) Date: Mon, 1 Oct 2001 15:58:47 -0400 Subject: [Zope-dev] compiling Zope 2.4.1 on Mac OS 10.1 In-Reply-To: Message-ID: i think i found a working solution. since my knowledge of compilers and=20= linkers isn't the greatest i'll just explain what i did. trying to compile python2.1.1 on OS X 10.1 failed for me displaying the=20= very same error. searching through apple's discussion i found the=20 following link: http://fink.sourceforge.net/doc/porting/shared.php it explains that some linker/compiler default options have changed. in=20= order to get python compiled and running i edited the toplevel Makefile=20= after running ./configure and edited the lines starting with LDSHARED = and=20 BLDSHARED, this is what they look like now in my setup: LDSHARED=3D $(CC) $(LDFLAGS) -bundle -flat_namespace -undefined = suppress BLDSHARED=3D $(CC) $(LDFLAGS) -bundle -flat_namespace -undefined = suppress notice the "-flat_namespace" switch, this gets rid of the new default=20 "twolevel_namespace" that complains about "undefined warning". running "make" was now successful and i was able to compile and run Zope = 2. 4.1. you will probably have to recompile your python to set that = switch=20 under 10.1. i only did some light testing, no guarantees and before using this in=20 production you might want to read up on those compiler/linker options... jens On Sunday, September 30, 2001, at 07:19 , Mitchell L Model wrote: > Trouble compiling Zope 2.4.1 on Mac OS 10.1: > > installed a fresh 10.1 that I just got from Apple > > > > downloaded the Zope 2.4.1 src > > > > tried 'python wo_pcgi' with both a Python 2.2a4 I just made and with = my=20 > previous Python 2.1, both with and without sudo > > > > Whatever I do, it breaks in the same place.=A0 Here's the end of the = output: > > sed -f sedscript ./Makefile.pre.in >Makefile.pre > > /usr/local/lib/python2.1/config/makesetup \ > > =A0=A0=A0=A0=A0=A0=A0=A0 -m Makefile.pre -c = /usr/local/lib/python2.1/config/config.c.in=20 > Setup -n=A0 /usr/local/lib/py\ > > thon2.1/config/Setup.config = /usr/local/lib/python2.1/config/Setup.local=20 > /usr/local/lib/python2.1/co\ > > nfig/Setup > > make -f Makefile do-it-again > > /usr/local/lib/python2.1/config/makesetup \ > > =A0=A0=A0=A0=A0=A0=A0=A0 -m Makefile.pre -c = /usr/local/lib/python2.1/config/config.c.in=20 > Setup -n=A0 /usr/local/lib/py\ > > thon2.1/config/Setup.config = /usr/local/lib/python2.1/config/Setup.local=20 > /usr/local/lib/python2.1/co\ > > nfig/Setup > > make > > cc=A0 -g -O2 -Wall -Wstrict-prototypes -I/usr/local/include/python2.1=20= > -I/usr/local/include/python2.1 \ > > -DHAVE_CONFIG_H=A0 -I../Components/ExtensionClass/src -c = ././../Components/ > ExtensionClass/src/Extensi\ > > onClass.c -o ./ExtensionClass.o > > In file included from /usr/local/include/python2.1/pyport.h:84, > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 from = /usr/local/include/python2.1/Python.h:54, > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 from = ././../Components/ExtensionClass/src/ExtensionClass. > h:114, > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 from = ././../Components/ExtensionClass/src/ExtensionClass. > c:61: > > /usr/include/math.h:191: warning: function declaration isn't a = prototype > > cc=A0 -bundle -undefined suppress=A0 ./ExtensionClass.o=A0=A0 -o = ./ExtensionClass. > so > > /usr/bin/ld: -undefined error must be used when -twolevel_namespace is = in=20 > effect > > make: *** [ExtensionClass.so] Error 1 > > Traceback (most recent call last): > > =A0 File "wo_pcgi.py", line 117, in ? > > =A0 File "wo_pcgi.py", line 105, in main > > =A0 File "/usr/local/src/Zope-2.4.1-src/inst/build_extensions.py", = line 102, > in ? > > =A0=A0=A0 make('lib','python') > > =A0 File "/usr/local/src/Zope-2.4.1-src/inst/do.py", line 135, in make > > =A0=A0=A0 do('make') > > =A0 File "/usr/local/src/Zope-2.4.1-src/inst/do.py", line 104, in do > > =A0=A0=A0 if i and picky: raise SystemError, i > > SystemError: 512 > > > The 'two-level namespace' business is a change from the OX X developer=20= > tools version 10.0 to 10.1. > > Anyone know what's going on here and how to fix it? > > -- > > > =A0=A0=A0 --- Mitchell From brian.lloyd@zope.com Mon Oct 1 22:51:33 2001 From: brian.lloyd@zope.com (Brian Lloyd) Date: Mon, 1 Oct 2001 17:51:33 -0400 Subject: [Zope-dev] 2.5 roadmap and schedule? In-Reply-To: <1001635436.23085.421.camel@fiawol> Message-ID: > The current roadmap for Zope 2.5 sets an alpha release date for sometime > in september, but is that still likely? > > Michael Bernstein. Since today is Oct. 1, I would say... no :^) The "roadmap" serves as a high-level way for me to relay the basic plan for the next release to those in the community who don't pay day-to-day attention to zope-dev or zope-coders. It is also sometimes wrong, since I have to make a best-guess at dates based on circumstances that sometimes change without much notice. The dates are based on my best guesses at what resources will be available when, and sometimes those get pre-empted by things like customer engagements, etc. Hopefully my guesses will be less wrong as the community gets more actively involved. That will expand the resource pool which should help - but this will be a learning process. Brian Lloyd brian@zope.com Software Engineer 540.361.1716 Zope Corporation http://www.zope.com From webmaven@lvcm.com Mon Oct 1 23:23:43 2001 From: webmaven@lvcm.com (Michael R. Bernstein) Date: 01 Oct 2001 15:23:43 -0700 Subject: [Zope-dev] 2.5 roadmap and schedule? In-Reply-To: References: Message-ID: <1001975025.31639.838.camel@fiawol> On Mon, 2001-10-01 at 14:51, Brian Lloyd wrote: > > The current roadmap for Zope 2.5 sets an alpha release date for sometime > > in september, but is that still likely? > > > > Michael Bernstein. > > Since today is Oct. 1, I would say... no :^) > > The "roadmap" serves as a high-level way for me to relay > the basic plan for the next release to those in the community > who don't pay day-to-day attention to zope-dev or zope-coders. > > It is also sometimes wrong, since I have to make a best-guess > at dates based on circumstances that sometimes change without > much notice. The dates are based on my best guesses at what > resources will be available when, and sometimes those get > pre-empted by things like customer engagements, etc. > > Hopefully my guesses will be less wrong as the community gets > more actively involved. That will expand the resource pool > which should help - but this will be a learning process. >From my POV, I don't mind that you guess wrong, it's just that the guesses aren't updated when it becomes apparent that they *are* wrong. It would be nice if the plan for the next release could be updated every two weeks or so. So, what is your current best guess estimate for the alpha release of Zope 2.5? Michael. From mlm@acm.org Tue Oct 2 03:43:40 2001 From: mlm@acm.org (Mitchell L Model) Date: Mon, 1 Oct 2001 22:43:40 -0400 Subject: [Zope-dev] compiling Zope 2.4.1 on Mac OS 10.1 In-Reply-To: References: Message-ID: At 3:58 PM -0400 10/1/01, Jens Vagelpohl wrote: >i think i found a working solution. since my knowledge of compilers >and linkers isn't the greatest i'll just explain what i did. > >trying to compile python2.1.1 on OS X 10.1 failed for me displaying >the very same error. searching through apple's discussion i found >the following link: > >http://fink.sourceforge.net/doc/porting/shared.php > >it explains that some linker/compiler default options have changed. >in order to get python compiled and running i edited the toplevel >Makefile after running ./configure and edited the lines starting >with LDSHARED and BLDSHARED, this is what they look like now in my >setup: > >LDSHARED= $(CC) $(LDFLAGS) -bundle -flat_namespace -undefined suppress >BLDSHARED= $(CC) $(LDFLAGS) -bundle -flat_namespace -undefined suppress > >notice the "-flat_namespace" switch, this gets rid of the new >default "twolevel_namespace" that complains about "undefined >warning". > >running "make" was now successful and i was able to compile and run Zope 2. >4.1. you will probably have to recompile your python to set that >switch under 10.1. > >i only did some light testing, no guarantees and before using this >in production you might want to read up on those compiler/linker >options... > >jens > > > >On Sunday, September 30, 2001, at 07:19 , Mitchell L Model wrote: > >>Trouble compiling Zope 2.4.1 on Mac OS 10.1: >> <...> Wonderful! Thanks!! Great information. Having said that, and having spent a couple of hours experimenting, let me try to clarify things a bit: 1. Python 2.2a4 defaults to --with-dylib, so you don't need that when making Python 2.2a4 as you did for 2.1. 2. Likewise, you don't need to set OPT the way the 2.1 README says for Mac OS 10. 3. Similarly, the Python2.2a4 configure.in knows to add -flat_namespace to Makefile.pre and therefore Makefile. 4. Both 2.1 and 2.2a4 correctly specify -undefined suppress. So, whereas I did need to fix the Python 2.1 Makefile to build it, I didn't need to fix the Python 2.2a4 Makefile to build it. (I guess I didn't try building Python 2.1 yesterday, or I would have realized the problem wasn't in Zope, but in Python, as you discovered.) From my experience this evening, I'm surprised that fixing the Python Makefile would allow you to compile Zope. It turns out that the zope configuration process uses the Makefile.pre.in installed in (typically) /usr/local/lib/python2.{1,2}/config. It also turns out that although Python 2.2a4 correctly adds -flat_namespace to Makefile.pre and Makefile, it doesn't add it to Makefile.pre.in! So for both 2.1 and 2.2 I had to add: LDSHARED= $(CC) $(LDFLAGS) -flat_namespace -undefined suppress to Makefile.pre.in, either in the Python src directory before doing 'make install' or in the /usr/local/lib/python2.{1,2}/config after doing the install. I'll report this problem to the Python developers. Thanks for you hints and your careful reading of the fink documentation on shared libraries. (fink is a fabulous resource!) -- --- Mitchell From timhoffman@cams.wa.gov.au Tue Oct 2 04:41:10 2001 From: timhoffman@cams.wa.gov.au (Tim Hoffman) Date: Tue, 02 Oct 2001 11:41:10 +0800 Subject: [Zope-dev] Read only ZEO References: <3BB68B7A.5040303@cams.wa.gov.au> <15287.38380.952597.887038@lindm.dm> Message-ID: <3BB93756.6080508@cams.wa.gov.au> HI Dieter I had a look at z2.py (it's actually -r) so any way I tried (not too successfully). I have zeo running with 2.4.1 I have a zss and 2 zeo clients. One running without -r switch and one running with -r In z2.py the -r switch is documented as follows -r Run ZServer is read-only mode. ZServer won't write anything to disk. No log files, no pid files, nothing. This means that you can't do a lot of stuff like use PCGI, and zdaemon. ZServer will log hits to STDOUT and zLOG will log to STDERR. Well when running a zeo client with -r switch results in no log files being written and the log is written to STDOUT, but the ZEO client is definately not in readonly mode ie I can create and modify documents. (It probably means it can;t cache to disk ;-) I need to track down where READ_ONLY flag is used. There isn't an occurrance with the ZEO code, so unless the READ_ONLY capability is implemented higher up in the transaction service, thenI think it isn't going to work. This document http://www.amk.ca/zodb/zodb-zeo.html which is linked to on the Zeo Product page actually mentions using Zeo client in readonly mode. I wonder if anyone has actually done it? Tim Dieter Maurer wrote: >Tim Hoffman writes: > > In some of the overview documents discussing ZEO, there is reference > > to a ZEO client potentially mounted a ZSS in read only mode. (I want > > to have some ZEO's in read/write as well) >When you start Zope with the "-R" option (I think, look at >"z2.py"!), it is in read-only mode. > > > I have been trying to work out how this might be achieved > > but have pretty much drawn a blank, has anyone done this I > > have any idea how I might go about doing such a thing. >There is a patch at > > > >which allows Zope to be started with a read only storage. > >Maybe, you can adapt it for ZEO. > > >Dieter > From jens@zope.com Tue Oct 2 12:30:00 2001 From: jens@zope.com (Jens Vagelpohl) Date: Tue, 2 Oct 2001 07:30:00 -0400 Subject: [Zope-dev] compiling Zope 2.4.1 on Mac OS 10.1 In-Reply-To: Message-ID: mitchell, since python 2.2 is not yet officially supported i stuck with 2.1. we haven't done any extensive testing using 2.2 yet and there might still be some side effects. jens On Monday, October 1, 2001, at 10:43 , Mitchell L Model wrote: > <...> > > Wonderful! Thanks!! Great information. > > Having said that, and having spent a couple of hours experimenting, let > me try to clarify things a bit: > > 1. Python 2.2a4 defaults to --with-dylib, so you don't need that when > making Python 2.2a4 as you did for 2.1. > > 2. Likewise, you don't need to set OPT the way the 2.1 README says for > Mac OS 10. > > 3. Similarly, the Python2.2a4 configure.in knows to add -flat_namespace > to Makefile.pre and therefore Makefile. > > 4. Both 2.1 and 2.2a4 correctly specify -undefined suppress. > > So, whereas I did need to fix the Python 2.1 Makefile to build it, I didn' > t need to fix the Python 2.2a4 Makefile to build it. (I guess I didn't > try building Python 2.1 yesterday, or I would have realized the problem > wasn't in Zope, but in Python, as you discovered.) > > From my experience this evening, I'm surprised that fixing the Python > Makefile would allow you to compile Zope. It turns out that the zope > configuration process uses the Makefile.pre.in installed in (typically) > /usr/local/lib/python2.{1,2}/config. It also turns out that although > Python 2.2a4 correctly adds -flat_namespace to Makefile.pre and Makefile, > it doesn't add it to Makefile.pre.in! So for both 2.1 and 2.2 I had to > add: > > LDSHARED= $(CC) $(LDFLAGS) -flat_namespace -undefined suppress > > to Makefile.pre.in, either in the Python src directory before doing 'make > install' or in the /usr/local/lib/python2.{1,2}/config after doing the > install. > > I'll report this problem to the Python developers. Thanks for you hints > and your careful reading of the fink documentation on shared libraries. > (fink is a fabulous resource!) > > -- > --- Mitchell From chrism@zope.com Tue Oct 2 12:54:49 2001 From: chrism@zope.com (Chris McDonough) Date: Tue, 2 Oct 2001 07:54:49 -0400 Subject: [Zope-dev] Read only ZEO References: <3BB68B7A.5040303@cams.wa.gov.au> <15287.38380.952597.887038@lindm.dm> <3BB93756.6080508@cams.wa.gov.au> Message-ID: <00fa01c14b39$0d985270$6501a8c0@kurtz> You may want to ask these questions on the zodb-dev list instead of on here... more likely to get the answers in a timely way.. ----- Original Message ----- From: "Tim Hoffman" To: "Dieter Maurer" Cc: Sent: Monday, October 01, 2001 11:41 PM Subject: Re: [Zope-dev] Read only ZEO > HI Dieter > > I had a look at z2.py (it's actually -r) so any way I tried (not too > successfully). > > I have zeo running with 2.4.1 I have a zss and 2 zeo clients. > One running without -r switch and one running with -r > > In z2.py the -r switch is documented as follows > > -r > > Run ZServer is read-only mode. ZServer won't write anything to disk. > No log files, no pid files, nothing. This means that you can't do a > lot of stuff like use PCGI, and zdaemon. ZServer will log hits to > STDOUT and zLOG will log to STDERR. > > Well when running a zeo client with -r switch results in no log files > being written > and the log is written to STDOUT, but the ZEO client is definately not > in readonly mode > ie I can create and modify documents. (It probably means it can;t cache > to disk ;-) > > I need to track down where READ_ONLY flag is used. There isn't an > occurrance > with the ZEO code, so unless the READ_ONLY capability is implemented > higher up > in the transaction service, thenI think it isn't going to work. > > This document http://www.amk.ca/zodb/zodb-zeo.html which is linked to on > the Zeo Product page > actually mentions using Zeo client in readonly mode. I wonder if anyone > has actually done it? > > Tim > > > Dieter Maurer wrote: > > >Tim Hoffman writes: > > > In some of the overview documents discussing ZEO, there is reference > > > to a ZEO client potentially mounted a ZSS in read only mode. (I want > > > to have some ZEO's in read/write as well) > >When you start Zope with the "-R" option (I think, look at > >"z2.py"!), it is in read-only mode. > > > > > I have been trying to work out how this might be achieved > > > but have pretty much drawn a blank, has anyone done this I > > > have any idea how I might go about doing such a thing. > >There is a patch at > > > > > > > >which allows Zope to be started with a read only storage. > > > >Maybe, you can adapt it for ZEO. > > > > > >Dieter > > > > > > > _______________________________________________ > Zope-Dev maillist - Zope-Dev@zope.org > 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 ) > From jziniti@speakeasy.org Tue Oct 2 16:46:14 2001 From: jziniti@speakeasy.org (John Ziniti) Date: Tue, 02 Oct 2001 11:46:14 -0400 Subject: [Zope-dev] file descriptors on Solaris Message-ID: <3BB9E146.2070401@speakeasy.org> I am running into a problem where Zope is trying to open too many file descriptors (256) in order to process a POST. I'm not sure how to phrase this question, but my reading has suggested that this limit may be set by the FILE struct in /usr/incldue/stdio.h. Does anyone know if this is used in Python/Zope? My first impression was that this problem would be easy to solve -- just up the number of FD's, but now, I'm not so sure. Any suggestions? Here's a traceback -- but I don't think it's much help Traceback (innermost last): File /u05/ilocal/opt/Zope-2.4.0-src/lib/python/ZPublisher/Publish.py, line 223, in publish_module File /u05/ilocal/opt/Zope-2.4.0-src/lib/python/ZPublisher/Publish.py, line 187, in publish File /u05/ilocal/opt/Zope-2.4.0-src/lib/python/Zope/__init__.py, line 226, in zpublisher_exception_hook (Object: ApplicationDefaultPermissions) File /u05/ilocal/opt/Zope-2.4.0-src/lib/python/ZPublisher/Publish.py, line 136, in publish File /u05/ilocal/opt/Zope-2.4.0-src/lib/python/ZPublisher/HTTPRequest.py, line 405, in processInputs File /ilocal/lib/python2.1/cgi.py, line 517, in __init__ File /ilocal/lib/python2.1/cgi.py, line 606, in read_multi File /ilocal/lib/python2.1/cgi.py, line 519, in __init__ File /ilocal/lib/python2.1/cgi.py, line 616, in read_single File /ilocal/lib/python2.1/cgi.py, line 636, in read_lines File /ilocal/lib/python2.1/cgi.py, line 723, in make_file File /ilocal/opt/Zope-2.4.0-src/lib/python/tempfile.py, line 155, in TemporaryFile OSError: [Errno 2] No such file or directory From Andreas Jung" Message-ID: <003a01c14b5a$e638b360$256a97ac@ajung> There is always a hard limit of filedescriptors (based on the kernel configuration). But usually you can change the number of descriptors using "limit descriptors xxxx" under tcsh/csh. Under Bash I think you must call "ulimit". Andreas ----- Original Message ----- From: "John Ziniti" To: Sent: Tuesday, October 02, 2001 11:46 Subject: [Zope-dev] file descriptors on Solaris > I am running into a problem where Zope is trying to open too many > file descriptors (256) in order to process a POST. > > I'm not sure how to phrase this question, but my reading has suggested > that this limit may be set by the FILE struct in /usr/incldue/stdio.h. > > Does anyone know if this is used in Python/Zope? > > My first impression was that this problem would be easy to solve -- > just up the number of FD's, but now, I'm not so sure. Any > suggestions? > > Here's a traceback -- but I don't think it's much help > > Traceback (innermost last): > File /u05/ilocal/opt/Zope-2.4.0-src/lib/python/ZPublisher/Publish.py, line 223, in publish_module > File /u05/ilocal/opt/Zope-2.4.0-src/lib/python/ZPublisher/Publish.py, line 187, in publish > File /u05/ilocal/opt/Zope-2.4.0-src/lib/python/Zope/__init__.py, line 226, in zpublisher_exception_hook > (Object: ApplicationDefaultPermissions) > File /u05/ilocal/opt/Zope-2.4.0-src/lib/python/ZPublisher/Publish.py, line 136, in publish > File /u05/ilocal/opt/Zope-2.4.0-src/lib/python/ZPublisher/HTTPRequest.py, line 405, in processInputs > File /ilocal/lib/python2.1/cgi.py, line 517, in __init__ > File /ilocal/lib/python2.1/cgi.py, line 606, in read_multi > File /ilocal/lib/python2.1/cgi.py, line 519, in __init__ > File /ilocal/lib/python2.1/cgi.py, line 616, in read_single > File /ilocal/lib/python2.1/cgi.py, line 636, in read_lines > File /ilocal/lib/python2.1/cgi.py, line 723, in make_file > File /ilocal/opt/Zope-2.4.0-src/lib/python/tempfile.py, line 155, in TemporaryFile > OSError: [Errno 2] No such file or directory > > > > > _______________________________________________ > Zope-Dev maillist - Zope-Dev@zope.org > 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 ) > From jziniti@speakeasy.org Tue Oct 2 17:01:59 2001 From: jziniti@speakeasy.org (John Ziniti) Date: Tue, 02 Oct 2001 12:01:59 -0400 Subject: [Zope-dev] file descriptors on Solaris References: <3BB9E146.2070401@speakeasy.org> <003a01c14b5a$e638b360$256a97ac@ajung> Message-ID: <3BB9E4F7.7010403@speakeasy.org> :( I was hoping against hope that this wouldn't be the answer ... I think that the hard limit onSolaris must be 256, because ulimit -n 200 seems to have the appropriate effect of making Zope complain about "too many open files" ... but anything higher than 256 gets a "File not found" ... Let's try this from another angle ... why does Zope need to open so many files just to process a *large-but-not-really-large* POST? Can I change something about the way the form is set up (I use a lot of ":records") to circumvent the problem? Andreas Jung wrote: >There is always a hard limit of filedescriptors (based on the kernel >configuration). But usually you can change the number of descriptors >using "limit descriptors xxxx" under tcsh/csh. Under Bash I think you >must call "ulimit". > >Andreas >----- Original Message ----- >From: "John Ziniti" >To: >Sent: Tuesday, October 02, 2001 11:46 >Subject: [Zope-dev] file descriptors on Solaris > > >>I am running into a problem where Zope is trying to open too many >>file descriptors (256) in order to process a POST. >> >>I'm not sure how to phrase this question, but my reading has suggested >>that this limit may be set by the FILE struct in /usr/incldue/stdio.h. >> >>Does anyone know if this is used in Python/Zope? >> >>My first impression was that this problem would be easy to solve -- >>just up the number of FD's, but now, I'm not so sure. Any >>suggestions? >> >>Here's a traceback -- but I don't think it's much help >> >>Traceback (innermost last): >> File /u05/ilocal/opt/Zope-2.4.0-src/lib/python/ZPublisher/Publish.py, >> >line 223, in publish_module > >> File /u05/ilocal/opt/Zope-2.4.0-src/lib/python/ZPublisher/Publish.py, >> >line 187, in publish > >> File /u05/ilocal/opt/Zope-2.4.0-src/lib/python/Zope/__init__.py, line >> >226, in zpublisher_exception_hook > >> (Object: ApplicationDefaultPermissions) >> File /u05/ilocal/opt/Zope-2.4.0-src/lib/python/ZPublisher/Publish.py, >> >line 136, in publish > >> File >> >/u05/ilocal/opt/Zope-2.4.0-src/lib/python/ZPublisher/HTTPRequest.py, line >405, in processInputs > >> File /ilocal/lib/python2.1/cgi.py, line 517, in __init__ >> File /ilocal/lib/python2.1/cgi.py, line 606, in read_multi >> File /ilocal/lib/python2.1/cgi.py, line 519, in __init__ >> File /ilocal/lib/python2.1/cgi.py, line 616, in read_single >> File /ilocal/lib/python2.1/cgi.py, line 636, in read_lines >> File /ilocal/lib/python2.1/cgi.py, line 723, in make_file >> File /ilocal/opt/Zope-2.4.0-src/lib/python/tempfile.py, line 155, in >> >TemporaryFile > >>OSError: [Errno 2] No such file or directory >> >> >> >> >>_______________________________________________ >>Zope-Dev maillist - Zope-Dev@zope.org >>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 ) >> > > > From Andreas Jung" <003a01c14b5a$e638b360$256a97ac@ajung> <3BB9E4F7.7010403@speakeasy.org> Message-ID: <006e01c14b5c$cd0955a0$256a97ac@ajung> ----- Original Message ----- From: "John Ziniti" To: Sent: Tuesday, October 02, 2001 12:01 Subject: Re: [Zope-dev] file descriptors on Solaris > :( I was hoping against hope that this wouldn't be the answer ... > > I think that the hard limit onSolaris must be 256, because ulimit -n 200 > seems to have the appropriate effect of making Zope complain about > "too many open files" ... but anything higher than 256 gets > a "File not found" ... Just ask your administrator to increase the number of file descriptors. Usually this requires *only* a reboot of the machine :-) Andreas From jziniti@speakeasy.org Tue Oct 2 18:05:35 2001 From: jziniti@speakeasy.org (John Ziniti) Date: Tue, 02 Oct 2001 13:05:35 -0400 Subject: [Zope-dev] file descriptors on Solaris References: <3BB9E146.2070401@speakeasy.org> <003a01c14b5a$e638b360$256a97ac@ajung> <3BB9E4F7.7010403@speakeasy.org> <006e01c14b5c$cd0955a0$256a97ac@ajung> Message-ID: <3BB9F3DF.3080308@speakeasy.org> Yeah ... something tells me it's a little more complicated than that. Any advice on the other front? If I can reduce the number of files Zope needs to process this request, I'd grumpily agree to do that, is Zope opening a file for every ? Will using help? Thanks. Andreas Jung wrote: >----- Original Message ----- >From: "John Ziniti" >To: >Sent: Tuesday, October 02, 2001 12:01 >Subject: Re: [Zope-dev] file descriptors on Solaris > > >>:( I was hoping against hope that this wouldn't be the answer ... >> >>I think that the hard limit onSolaris must be 256, because ulimit -n 200 >>seems to have the appropriate effect of making Zope complain about >>"too many open files" ... but anything higher than 256 gets >>a "File not found" ... >> > >Just ask your administrator to increase the number of file descriptors. >Usually this requires *only* a reboot of the machine :-) > >Andreas > > >_______________________________________________ >Zope-Dev maillist - Zope-Dev@zope.org >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 ) > > From =?ISO-8859-1?B?R2VpciBC5mtob2x0?= Tue Oct 2 19:49:31 2001 From: =?ISO-8859-1?B?R2VpciBC5mtob2x0?= (=?ISO-8859-1?B?R2VpciBC5mtob2x0?=) Date: Tue, 2 Oct 2001 20:49:31 +0200 Subject: [Zope-dev] Problems with Oracle DA and Dates In-Reply-To: <00e901c14a79$ec235000$33de1081@ita.chalmers.se> References: <00e901c14a79$ec235000$33de1081@ita.chalmers.se> Message-ID: <576980086.20011002204931@funcom.com> Hello Dario, Just noticed behaviour similar to this a couple of days ago , but haven't had the time to file a report on it.. - We managed to narrow it down a bit , tho' : In our installation ; Zope silently restarted , quite quickly , and almost unnoticeable to our editors. This was triggered either when we passed one of the oracle-date-objects returned by DCO2 to DateTime(), or when we believed them to be DateTime objects and tried to run DateTime methods on them... I was in a production environment , so i had to fix the errors before going to work on narrowing down the bug. Selecting your dates as strings with TO_CHAR(datefield) in your SQL will be a safeguard against the restarting/crashing/whatever_bad_things_might_happen , but will give you boring strings instead of date-objects.. -ok , it is a stopgap, but my Zope stopped restarting every 2 minutes... Hoop we can get this fixed before the final is released.. :-) Monday, October 01, 2001, 15:06:44, you wrote: DLK> (I apologise in advance for the crosspost, but I think this is a valid DLK> question on both the zope-db and zope-dev lists. If you disagree, flame DLK> away, and I'll never do it again. oh, btw: flame in private mail, please) DLK> Hello! DLK> We have run into a showstopper problem here where it seems (we're not sure DLK> yet) that there is a severe problem using dates returned from the Oracle DA DLK> adapter. Other possible culprits include LocalFS, Transparent Folder, DLK> Formulator and the source release of Zope 2.4.1. DLK> The problem is that Zope either dies, core dumps and dies, or slows down to DLK> a crawl. DLK> We are using the Zope 2.4.1 release, with Transparent folders and LocalFS, DLK> latest, and a sligthly modified Formulator. DLK> There are about 2-6 people working and developing in it during all hours of DLK> the day (24 hours). DLK> Unfortunately nothing shows up in any of the logs, so they are of little DLK> use; I don't even have a traceback so display. We *think* we found sometign DLK> pointing at LocalFS in one of the coredumps, but we are lowly non-unix DLK> programmers, and have no idea if this is accurate info or not. It could just DLK> be un-collected garabage memory. DLK> Is anybody noticing anything similar, or if you have any opinion on what DLK> might be going on, please reply; we are in DS mode here (we are having a DLK> prototype presentation during two weeks, starting tomorrow) and are feeling DLK> a bit desperate. DLK> Sincerely, DLK> /dario -- Geir Bækholt web-developer/zopatista geirh@funcom.com funcom oslo | webdev-team From jziniti@speakeasy.org Tue Oct 2 19:50:32 2001 From: jziniti@speakeasy.org (John Ziniti) Date: Tue, 02 Oct 2001 14:50:32 -0400 Subject: [Zope-dev] file descriptors on Solaris [SUMMARY] References: <3BB9E146.2070401@speakeasy.org> <003a01c14b5a$e638b360$256a97ac@ajung> <3BB9E4F7.7010403@speakeasy.org> <006e01c14b5c$cd0955a0$256a97ac@ajung> <3BB9F3DF.3080308@speakeasy.org> Message-ID: <3BBA0C78.8030009@speakeasy.org> I'd just like to summarize for the list some additional findings, questions and clarifications. DIAGNOSIS: It appears that this only happens when the form is specified with "enctype=multipart/form-data". In that case, Zope (or, more accurately, the cgi module), tries to create temporary file for each form , no matter what type the input has ... (I think but I can't be 100% sure about that). This seems a little weird. Why do we have to open a file for each "part" just because it *may* contain a file? PROGNOSIS: The problem (on Solaris) is not very easy to fix, since it lies in the system-wide definition of a file descriptor, which uses only one byte to store the fd value (i.e., anything higher than 256 is meaningless, and truncated??). Changing this struct is not easy. The problem is not that Zope is exceeding the *allowed* number of FD's (usually policed by the shell), but that Zope is exceeding the *meaningful* number of FD's. This sucks. :-) SUMMARY: If you're planning on using large forms in Zope on Solaris (version??), you'll have to move your file uploads to another page, since specifying "multipart/form-data" causes cgi.py to open a tempfile.TemporaryFile for each input on the form, which causes problems if the number of inputs is greater than the file descriptor address space. From brian.lloyd@zope.com Tue Oct 2 20:14:59 2001 From: brian.lloyd@zope.com (Brian Lloyd) Date: Tue, 2 Oct 2001 15:14:59 -0400 Subject: [Zope-dev] 2.5 roadmap and schedule? In-Reply-To: <1001975025.31639.838.camel@fiawol> Message-ID: > >From my POV, I don't mind that you guess wrong, it's just that the > guesses aren't updated when it becomes apparent that they *are* wrong. > > It would be nice if the plan for the next release could be updated every > two weeks or so. I will try to be better about that. Unfortunately, the planning and resource mgmt tools that we use internally are totally disconnected from the online large-grained version of the plan that I have to maintain by hand. > So, what is your current best guess estimate for the alpha release of > Zope 2.5? I've updated the plan to reflect my best guess at this point of 15 Oct. for a1. Brian Lloyd brian@zope.com Software Engineer 540.361.1716 Zope Corporation http://www.zope.com From Andreas Jung" <003a01c14b5a$e638b360$256a97ac@ajung> <3BB9E4F7.7010403@speakeasy.org> <006e01c14b5c$cd0955a0$256a97ac@ajung> <3BB9F3DF.3080308@speakeasy.org> <3BBA0C78.8030009@speakeasy.org> Message-ID: <022801c14b75$463c5360$256a97ac@ajung> ----- Original Message ----- From: "John Ziniti" To: Sent: Tuesday, October 02, 2001 14:50 Subject: Re: [Zope-dev] file descriptors on Solaris [SUMMARY] > > PROGNOSIS: > The problem (on Solaris) is not very easy to fix, since it lies in the > system-wide definition of a file descriptor, which uses only one byte > to store the fd value (i.e., anything higher than 256 is meaningless, > and truncated??). Changing this struct is not easy. The problem is > not that Zope is exceeding the *allowed* number of FD's (usually > policed by the shell), but that Zope is exceeding the *meaningful* > number of FD's. This sucks. :-) This is nonsense. Solaris allows of course to use more than 256 FDs. I don't know how they are stored inside the kernel but I have been using Solaris in projects where we used 1024 FDs and more. Zope does not increase the number of allowed FDs (resource module) but inherits the settings from the environment where Zope gets started. The number of FDs are set in Solaris in /etc/system: set rlim_fd_max = 4096 set rlim_fd_cur = 1024 Solaris 7+ allows up to 65536 FDs. Cheers, Andreas From chrisw@nipltd.com Tue Oct 2 20:13:58 2001 From: chrisw@nipltd.com (Chris Withers) Date: Tue, 2 Oct 2001 20:13:58 +0100 Subject: [Zope-dev] RFC: two "enterprise zope" proposals References: <3BB62412.5010004@digicool.com> Message-ID: <005101c14b76$6b8fe0e0$8cfd7ad5@withers> > http://dev.zope.org/Wikis/DevSite/Proposals/ToleratingHangsAndLeaks > > ... another proposal for extending Zope with a mode where it would > restart itself every so often or as it determines its in a > pathological state. This one would be cool. cheers, Chris From jziniti@speakeasy.org Tue Oct 2 20:57:09 2001 From: jziniti@speakeasy.org (John Ziniti) Date: Tue, 02 Oct 2001 15:57:09 -0400 Subject: [Zope-dev] file descriptors on Solaris [SUMMARY] References: <3BB9E146.2070401@speakeasy.org> <003a01c14b5a$e638b360$256a97ac@ajung> <3BB9E4F7.7010403@speakeasy.org> <006e01c14b5c$cd0955a0$256a97ac@ajung> <3BB9F3DF.3080308@speakeasy.org> <3BBA0C78.8030009@speakeasy.org> <022801c14b75$463c5360$256a97ac@ajung> Message-ID: <3BBA1C15.60001@speakeasy.org> > > > >This is nonsense. Solaris allows of course to use more than 256 FDs. >I don't know how they are stored inside the kernel but I have been using >Solaris in projects where we used 1024 FDs and more. Zope does not >increase the number of allowed FDs (resource module) but inherits >the settings from the environment where Zope gets started. > >The number of FDs are set in Solaris in /etc/system: > >set rlim_fd_max = 4096 >set rlim_fd_cur = 1024 > >Solaris 7+ allows up to 65536 FDs. > Solaris is definitely not my area of expertise, but to the best of my UNIX-hunting-around- looking-for-the-answer ability, that's all I can find. If Zope is started in a shell with $ ulimit -n 200 and I POST the offending form, I get a "too many open files" error. But if ulimit -n 512, then I get "No such file or directory" when $ZOPE/lib/python/tempfile.py tries to fdopen a file descriptor higher than 255 (line 155). my /etc/system doesn't have anything other than some shm settings. Can you create a form:
and tell me if you get the OSError? From Andreas Jung" <003a01c14b5a$e638b360$256a97ac@ajung> <3BB9E4F7.7010403@speakeasy.org> <006e01c14b5c$cd0955a0$256a97ac@ajung> <3BB9F3DF.3080308@speakeasy.org> <3BBA0C78.8030009@speakeasy.org> <022801c14b75$463c5360$256a97ac@ajung> <3BBA1C15.60001@speakeasy.org> Message-ID: <010301c14b7e$04825f60$3e17a8c0@digicool.com> ----- Original Message ----- From: "John Ziniti" To: "Andreas Jung" ; Sent: Tuesday, October 02, 2001 15:57 Subject: Re: [Zope-dev] file descriptors on Solaris [SUMMARY] > > > > > > > >This is nonsense. Solaris allows of course to use more than 256 FDs. > >I don't know how they are stored inside the kernel but I have been using > >Solaris in projects where we used 1024 FDs and more. Zope does not > >increase the number of allowed FDs (resource module) but inherits > >the settings from the environment where Zope gets started. > > > >The number of FDs are set in Solaris in /etc/system: > > > >set rlim_fd_max = 4096 > >set rlim_fd_cur = 1024 > > > >Solaris 7+ allows up to 65536 FDs. > > > Solaris is definitely not my area of expertise, but to the best of my > UNIX-hunting-around- > looking-for-the-answer ability, that's all I can find. If Zope is > started in a shell with > $ ulimit -n 200 > and I POST the offending form, I get a "too many open files" error. But > if ulimit -n 512, > then I get "No such file or directory" when $ZOPE/lib/python/tempfile.py > tries to fdopen a > file descriptor higher than 255 (line 155). > > my /etc/system doesn't have anything other than some shm settings. When u dont have the settings then you are using the default settings (maybe 256). Modify the settings according to your needs. > Can you create a form: > >
> > > value=""> > >
I am running Linux here with 1024 FDs. Andreas From matt@zope.com Tue Oct 2 21:55:09 2001 From: matt@zope.com (Matthew T. Kromer) Date: Tue, 02 Oct 2001 16:55:09 -0400 Subject: [Zope-dev] Problems with Oracle DA and Dates References: <00e901c14a79$ec235000$33de1081@ita.chalmers.se> <576980086.20011002204931@funcom.com> Message-ID: <3BBA29AD.6060002@zope.com> Geir B=E6kholt wrote: >Hello Dario,=20 > >Just noticed behaviour similar to this a couple of days ago , but >haven't had the time to file a report on it.. - We managed to narrow >it down a bit , tho' : > >In our installation ; Zope silently restarted , quite quickly , and >almost unnoticeable to our editors. >This was triggered either when we passed one of the >oracle-date-objects returned by DCO2 to DateTime(), or when we >believed them to be DateTime objects and tried to run DateTime methods >on them... > >I was in a production environment , so i had to fix the errors before >going to work on narrowing down the bug. Selecting your dates as >strings with TO_CHAR(datefield) in your SQL will be a safeguard >against the restarting/crashing/whatever_bad_things_might_happen , but >will give you boring strings instead of date-objects.. -ok , it is a >stopgap, but my Zope stopped restarting every 2 minutes... > >Hoop we can get this fixed before the final is released.. >:-) > So what you REALLY want is the ZOracleDA to promote the weakling=20 dco2.DateTime objects to full Zope DateTime objects. Aha! I think that's doable in short order. From k_vertigo@yahoo.com Tue Oct 2 15:05:21 2001 From: k_vertigo@yahoo.com (kapil thangavelu) Date: Tue, 2 Oct 2001 07:05:21 -0700 Subject: [Zope-dev] [ann] developer tools Message-ID: <200110022056.NAA04684@anteroom.its.caltech.edu> Developer Tools release ExtSearch/ExtIndex - Allows FS search from zope, integrates with swish++, includes a pluggable index and standalone version EventChannel - simple publish/subscribe system for zope with different channels and filters. SQLEngine - loads up sql methods from the fs, and provides a container for them, currently hardcoded to openacs's query xml syntax, but those who llike snakes should have no problem adjusting to other formats. License: GPL documentation on these varies, most integrate with the help system to provide documentation. download: http://www.zope.org/Members/k_vertigo cheers kapil thangavelu From matt@zope.com Tue Oct 2 22:17:17 2001 From: matt@zope.com (Matthew T. Kromer) Date: Tue, 02 Oct 2001 17:17:17 -0400 Subject: [Zope-dev] Problems with Oracle DA and Dates References: <00e901c14a79$ec235000$33de1081@ita.chalmers.se> <576980086.20011002204931@funcom.com> <3BBA29AD.6060002@zope.com> Message-ID: <3BBA2EDD.9050005@zope.com> Matthew T. Kromer wrote: > Geir B=E6kholt wrote: > >> Hello Dario, >> Just noticed behaviour similar to this a couple of days ago , but >> haven't had the time to file a report on it.. - We managed to narrow >> it down a bit , tho' : >> >> In our installation ; Zope silently restarted , quite quickly , and >> almost unnoticeable to our editors. >> This was triggered either when we passed one of the >> oracle-date-objects returned by DCO2 to DateTime(), or when we >> believed them to be DateTime objects and tried to run DateTime methods >> on them... >> > So what you REALLY want is the ZOracleDA to promote the weakling=20 > dco2.DateTime objects to full Zope DateTime objects. > > Aha! > > I think that's doable in short order.=20 In fact, here's the simple patch (only the last bit is really necessary,=20 but as long as I was looking at it I tweaked the listtype to be a=20 pseudo-constant as an argument. I've checked it in to CVS too :) Index: db.py =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs-repository/Products/DCOracle2/db.py,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- db.py 14 Sep 2001 15:11:19 -0000 1.8 +++ db.py 2 Oct 2001 21:13:58 -0000 1.9 @@ -83,8 +83,8 @@ # ########################################################################= ###### =20 -'''$Id: db.py,v 1.8 2001/09/14 15:11:19 matt Exp $''' -__version__=3D'$Revision: 1.8 $'[11:-2] +'''$Id: db.py,v 1.9 2001/10/02 21:13:58 matt Exp $''' +__version__=3D'$Revision: 1.9 $'[11:-2] =20 import DCOracle2, DateTime #DCOracle.dbi.dbiDate=3DDateTime.DateTime @@ -230,12 +230,14 @@ # # Do we get tuples back in results? should just be lists # - def _lobConvert(self, result): + def _lobConvert(self, result, listtype=3Dtype([])): for i in xrange(len(result)): t =3D type(result[i]) - if t =3D=3D type([]): self._lobConvert(result[i]) + if t =3D=3D listtype: self._lobConvert(result[i]) elif t =3D=3D DCOracle2.dco2.LobLocatorType: result[i] =3D LobLocator(result[i]) + elif t =3D=3D DCOracle2.dco2.OracleDateType: + result[i] =3D DateTime.DateTime(float(result[i])) =20 # Added for ChrisM (11/13/2000 MTK) def commit_sub(self, *arg, **kw): From richard@bizarsoftware.com.au Tue Oct 2 23:54:14 2001 From: richard@bizarsoftware.com.au (Richard Jones) Date: Wed, 3 Oct 2001 08:54:14 +1000 Subject: [Zope-dev] file descriptors on Solaris [SUMMARY] In-Reply-To: <3BBA0C78.8030009@speakeasy.org> References: <3BB9E146.2070401@speakeasy.org> <3BB9F3DF.3080308@speakeasy.org> <3BBA0C78.8030009@speakeasy.org> Message-ID: <01100308541401.01465@ike> On Wednesday 03 October 2001 04:50, John Ziniti wrote: > DIAGNOSIS: > It appears that this only happens when the form is specified with > "enctype=multipart/form-data". In that case, Zope (or, more accurately, > the cgi module), tries to create temporary file for each form , > no matter what type the input has ... (I think but I can't be 100% > sure about that). This seems a little weird. Why do we have to open > a file for each "part" just because it *may* contain a file? This is a bug in python's cgi module that has been patched (but not in python 2.1.1). There's a patch on sourceforge for it in any case. http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=231249 No fiddling with max open files required. Richard From mlm@acm.org Wed Oct 3 05:44:11 2001 From: mlm@acm.org (Mitchell L Model) Date: Wed, 3 Oct 2001 00:44:11 -0400 Subject: [Zope-dev] compiling Zope 2.4.1 on Mac OS 10.1 Message-ID: False alarm for Python2.2a4. It does work It seems I was either hallucinating or had screwed something up. After discussions with Guido, after which I understood a lot better what was supposed to be happening and why, I started over, and this time it worked. With the updates for OS 10.1 in Python 2.2a4, all I had to do to make both Python and Zope was: cd Python2.2a4 configure --with-suffix=.exe make sudo make install cd Zope python wo_pcgi.py That's all. Just that one configure flag, and no global variables set. Very, very nice. What a delight to have a just released MacOS treated with respect by multi-platform software! By the way, Guido said that the Makefile.pre.in mechanism installed in python2.2/lib/config is for a deprecated third-party build mechanism, replaced by distutils. He suggests that Zope should maybeswitch to distutils. -- --- Mitchell From s.rowatt@astracon.com.au Wed Oct 3 05:54:33 2001 From: s.rowatt@astracon.com.au (Shane Rowatt) Date: Wed, 3 Oct 2001 14:54:33 +1000 Subject: [Zope-dev] ZCatalog: path & summary indices not generated Message-ID: Zope Version: 2.4.1 on linux. When I tried to add a ZCatalog followed by finding objects to index using the default indices provided (path, summary, id, title etc), the 'path' and 'summary' indices are never generated. The 'summary' index is always an empty string and the 'path' index is 'None'. To get around the 'summary' not being indexed for DTMLMethod and DTMLDocument objects I had to add the following method to DTMLMethod.py: def summary(self): "Support for searching - the document's contents are searched." raw = self.read() stripped_raw = re.sub("<.*>", "", raw) n=min(200, len(stripped_raw)) return stripped_raw[:n] which basically strips out anything between '<' and '>' tags which should strip most of the DTML and HTML tags out to give a half decent 200 character summary. Unfortunately I tried the same with the 'path' index by adding the following to DTMLMethod.py def getPath(self): "Get path" return getPath(self) def path(self): "Get path" return join(self.getPhysicalPath(), "/") but the 'path' index only works it is a FieldIndex. When it's a PathIndex I get the value of None for all cataloged items. Surely someone else has come across these problems before using this basic catalog stuff?? Shane Rowatt Astracon Inc. From mj@zope.com Wed Oct 3 06:21:31 2001 From: mj@zope.com (Martijn Pieters) Date: Wed, 3 Oct 2001 01:21:31 -0400 Subject: [Zope-dev] compiling Zope 2.4.1 on Mac OS 10.1 In-Reply-To: References: Message-ID: <20011003012128.A13617@zope.com> On Wed, Oct 03, 2001 at 12:44:11AM -0400, Mitchell L Model wrote: > False alarm for Python2.2a4. It does work > > It seems I was either hallucinating or had screwed something up. > After discussions with Guido, after which I understood a lot better > what was supposed to be happening and why, I started over, and this > time it worked. With the updates for OS 10.1 in Python 2.2a4, all I > had to do to make both Python and Zope was: > > cd Python2.2a4 > configure --with-suffix=.exe > make > sudo make install > > cd Zope > python wo_pcgi.py > > That's all. Just that one configure flag, and no global variables > set. Very, very nice. What a delight to have a just released MacOS > treated with respect by multi-platform software! Note that we have just identified some Zope tests that fail when running under Python 2.2, but not under 2.1. We are still investigating as to what causes this. -- Martijn Pieters | Software Engineer mailto:mj@zope.com | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ --------------------------------------------- From tdickenson@geminidataloggers.com Wed Oct 3 09:59:29 2001 From: tdickenson@geminidataloggers.com (Toby Dickenson) Date: Wed, 03 Oct 2001 09:59:29 +0100 Subject: [Zope-dev] syslog In-Reply-To: <20011001205259.A572@nordine.ateur> References: <9FC702711D39D3118D4900902778ADC83248B7@jupiter.internal.geminidataloggers.com> <20011001205259.A572@nordine.ateur> Message-ID: <1oklrtgdrnuvlt8k8e0n7ok2oggh2bjdi4@4ax.com> On Mon, 1 Oct 2001 20:53:00 +0200, Jerome Alet wrote: >On Mon, Oct 01, 2001 at 04:14:47PM +0100, Toby Dickenson wrote: >>=20 >> A question for all syslog users; is it ever useful to send access logs= to >> syslog? (I can't think of good reason, but my syslog zen quotient is = still >> low). Is anyone else even using syslog? > >It may prove to be useful when you want to do remote logging: you >send all to the local syslog which in fact forwards it to a remote=20 >syslog server. I understand the interest for remote logging of events - thats what I am using syslog for. Does the same apply to access logs too? (that is, the entries which also get written to var/Z2.log) Toby Dickenson tdickenson@geminidataloggers.com From alet@unice.fr Wed Oct 3 10:16:07 2001 From: alet@unice.fr (Jerome Alet) Date: Wed, 3 Oct 2001 11:16:07 +0200 (MET DST) Subject: [Zope-dev] syslog In-Reply-To: <1oklrtgdrnuvlt8k8e0n7ok2oggh2bjdi4@4ax.com> Message-ID: On Wed, 3 Oct 2001, Toby Dickenson wrote: > On Mon, 1 Oct 2001 20:53:00 +0200, Jerome Alet wrote: > > > >It may prove to be useful when you want to do remote logging: you > >send all to the local syslog which in fact forwards it to a remote > >syslog server. > > I understand the interest for remote logging of events - thats what I > am using syslog for. > > Does the same apply to access logs too? (that is, the entries which > also get written to var/Z2.log) Sorry, I don't know. In fact I don't use syslog with Zope, this was just a general answer. Because Apache is often used in front of Zope, it's probably even better (quicker) to let Apache do the access logging and disable it entirely from Zope. bye, Jerome Alet From bitz@bitdance.com Wed Oct 3 13:00:17 2001 From: bitz@bitdance.com (R. David Murray) Date: Wed, 3 Oct 2001 08:00:17 -0400 (EDT) Subject: [Zope-dev] file descriptors on Solaris In-Reply-To: <3BB9F3DF.3080308@speakeasy.org> Message-ID: <20011003075155.L8313-100000@twirl.bitdance.com> On Tue, 2 Oct 2001, John Ziniti wrote: > Yeah ... something tells me it's a little more complicated than that. Like recompiling the kernel, quite possibly. On FreeBSD there's a sysctl, although you may still have to recompile the kernel in some cases I think; on Linux you can zap a variable in proc. On solaris....who knows . > Any advice on the other front? If I can reduce the number of files > Zope needs to process this request, I'd grumpily agree to do that, > is Zope opening a file for every ? > Will using help? I don't see why zope should need so many file descriptors. But you may have to start tracing code . I have previously noticed a related phenomenon: on FreeBSD when I start zope, *something* tries to open every possible port number using a separate file descriptor. They must then be closed, because after startup only the ports requested are still open. I determined this by running lsof and capturing the output. In this case, it appears to be benign; the only negative consequence is the appearance of the "Too many open file descriptors" message in /var/log/messages. --RDM From Andreas Jung" Message-ID: <007f01c14c08$60dc8a80$3e17a8c0@digicool.com> ----- Original Message ----- From: "Shane Rowatt" To: Sent: Wednesday, October 03, 2001 00:54 Subject: [Zope-dev] ZCatalog: path & summary indices not generated > > Unfortunately I tried the same with the 'path' index by adding the following > to DTMLMethod.py > > def getPath(self): > "Get path" > return getPath(self) > > def path(self): > "Get path" > return join(self.getPhysicalPath(), "/") > > but the 'path' index only works it is a FieldIndex. When it's a PathIndex I > get the value of None for all cataloged items. > Shane, you don't have to provide special path() to your objects. The PathIndex works a bit different from the other indexes because it does not look for an attribute or method with a name equal to the name of your PathIndex. So how do PathIndexes work ? - ZCatalog calls PathIndex.index_object() for all objects to be cataloged. - index_object() determines the physical path the object and indexes this result inside the PathIndex data structure. We have not seen necessity to provide support for a user-defined hook. If you have some use cases let me know. Hope this helps ;-) Andreas From jwashin@vt.edu Wed Oct 3 14:35:40 2001 From: jwashin@vt.edu (Jim Washington) Date: Wed, 03 Oct 2001 09:35:40 -0400 Subject: [Zope-dev] [Fwd: Re: [Zope] Python 2.1 for debian ?] Message-ID: <3BBB142C.20207@vt.edu> Would it be smart to include the python header files in the zope binary=20 distributions? That would seem to solve a few problems for the=20 individuals using them. -- Jim Washington -------- Original Message -------- Subject: Re: [Zope] Python 2.1 for debian ? Date: Wed, 03 Oct 2001 12:51:37 +0000 (GMT) From: Juli=E1n Mu=F1oz Dom=EDnguez To: Jim Washington Thank you very very much ;-) But it is not possible to compile extensions with zope binary distributions, because it lacks some headers. Many products requires compiling extensions, so that readdress me to need of Python 2.1 .....=20 From matt@zope.com Wed Oct 3 15:36:35 2001 From: matt@zope.com (Matthew T. Kromer) Date: Wed, 03 Oct 2001 10:36:35 -0400 Subject: [Zope-dev] [Fwd: Re: [Zope] Python 2.1 for debian ?] References: <3BBB142C.20207@vt.edu> Message-ID: <3BBB2273.3010906@zope.com> Jim Washington wrote: > > Would it be smart to include the python header files in the zope > binary distributions? That would seem to solve a few problems for the > individuals using them. > > -- Jim Washington > The next binary release will go out the door with Python headers installed. We've already set it up for the packager to do that. From leo@hiper.com.br Wed Oct 3 15:53:03 2001 From: leo@hiper.com.br (Leonardo Rochael Almeida) Date: Wed, 03 Oct 2001 11:53:03 -0300 Subject: [Zope-dev] [Fwd: Re: [Zope] Python 2.1 for debian ?] References: <3BBB142C.20207@vt.edu> <3BBB2273.3010906@zope.com> Message-ID: <3BBB264F.5010603@hiper.com.br> Matthew T. Kromer wrote: > The next binary release will go out the door with Python headers > installed. We've already set it up for the packager to do that. Does that mean that using the binary Zope bundled python to call setup.py or using the binary Zope bundled Makefile.pre.in will correctly build C modules and install them correctly inside the binary Zope python tree?! Th@t w0u1d b3 'l33t Cheers, Leo From leo@hiper.com.br Wed Oct 3 16:03:22 2001 From: leo@hiper.com.br (Leonardo Rochael Almeida) Date: Wed, 03 Oct 2001 12:03:22 -0300 Subject: [Zope-dev] compiling Zope 2.4.1 on Mac OS 10.1 References: Message-ID: <3BBB28BA.8010404@hiper.com.br> Mitchell L Model wrote: > [...] With the updates for OS 10.1 in Python 2.2a4, all I had to do > to make both Python and Zope was: > > cd Python2.2a4 > configure --with-suffix=.exe > make > sudo make install > > cd Zope > python wo_pcgi.py I don't know if it's just me, but this "--with-suffix=.exe", on an Mac OS (the OS where you weren't suppose to need extensions) is extremely disturbing. :-) Cheers, Leo PS: and I'm not a Mac user, just a Linux user who would like more metadata in his operating system. Maybe I've been in Zope land for too long :-) From jens@zope.com Wed Oct 3 16:17:16 2001 From: jens@zope.com (Jens Vagelpohl) Date: Wed, 3 Oct 2001 11:17:16 -0400 Subject: [Zope-dev] compiling Zope 2.4.1 on Mac OS 10.1 In-Reply-To: <3BBB28BA.8010404@hiper.com.br> Message-ID: well, the actual extension does not matter. you could as well specify something like "--with-suffix=.mary_had_a_little_lamb" if you wanted... for a more technological explanation, when the compile is done the executable is copied into the root of the python source tree. by default the name of the executable is "python". this would not be a problem if it was not for the case insensitivity of the HFS file system used by most OS X users. there is a folder named "Python" in the root of the tree as well. trying to copy "python" into the root will fail because it collides with "Python". the "--with-suffix" will produce a binary with that suffix and that will avoid this collision. jens On Wednesday, October 3, 2001, at 11:03 , Leonardo Rochael Almeida wrote: > > > Mitchell L Model wrote: > >> [...] With the updates for OS 10.1 in Python 2.2a4, all I had to do to >> make both Python and Zope was: >> cd Python2.2a4 >> configure --with-suffix=.exe >> make >> sudo make install >> cd Zope >> python wo_pcgi.py > > > I don't know if it's just me, but this "--with-suffix=.exe", on an Mac OS > (the OS where you weren't suppose to need extensions) is extremely > disturbing. :-) > > Cheers, Leo > > PS: and I'm not a Mac user, just a Linux user who would like more > metadata in his operating system. Maybe I've been in Zope land for too > long :-) > > > _______________________________________________ > Zope-Dev maillist - Zope-Dev@zope.org > 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 ) From johanc@torped.se Wed Oct 3 16:06:24 2001 From: johanc@torped.se (Johan Carlsson) Date: Wed, 3 Oct 2001 17:06:24 +0200 Subject: [Zope-dev] RFC: Date property requiers valid date (no more) Message-ID: <001c01c14c1e$547ea3c0$d7beb5d4@tor.torped.se> Hi, We currently want to use date-properties in the regular property sheet. The current date-property doesn't accept an empty value. We want to be able to submit an empty string and set a NullDate value indicating. Also a NullDate value should return an empty string when the "manage_propertiesForm" is rendered, e.g. showing an empty field. We have currently chosen a empty string "", to represent the NullDate value. (We haven't found any NullDate representation in DateTime and have concluded that it doesn't exist?) Choosing None as the NullDate value would have been preferred but it generates issues with the rendering of "manage_propertiesForm". Question: Is there anything better then an empty string for the NullDate value? Best Regards, Johan Carlsson www.torped.se [Here's our hot-patch] from ZPublisher import Converters def fixedfield2date(v): print "Fixed field2date conversion", fixedfield2date, v from DateTime import DateTime if hasattr(v,'read'): v=v.read() else: v=str(v) if v=='': return v return DateTime(v) Converters.field2date = fixedfield2date Converters.type_converters['date'] = fixedfield2date print "ZPublisher.Converters.field2date patched." From matt@zope.com Wed Oct 3 17:45:02 2001 From: matt@zope.com (Matthew T. Kromer) Date: Wed, 3 Oct 2001 12:45:02 -0400 Subject: [Zope-dev] [Fwd: Re: [Zope] Python 2.1 for debian ?] In-Reply-To: <3BBB264F.5010603@hiper.com.br> Message-ID: On Wednesday, October 3, 2001, at 10:53 AM, Leonardo Rochael Almeida wrote: > > > Matthew T. Kromer wrote: > >> The next binary release will go out the door with Python headers >> installed. We've already set it up for the packager to do that. > > > Does that mean that using the binary Zope bundled python to call > setup.py or using the binary Zope bundled Makefile.pre.in will > correctly build C modules and install them correctly inside the binary > Zope python tree?! Yes, I think at least the first part is true, such that setup.py build will work -- the ability of install to function is dependent on your permissions, of course. From c.duncan@nlada.org Wed Oct 3 13:59:45 2001 From: c.duncan@nlada.org (Casey Duncan) Date: Wed, 3 Oct 2001 08:59:45 -0400 Subject: [Zope-dev] ZCatalog: path & summary indices not generated In-Reply-To: References: Message-ID: On Wednesday 03 October 2001 12:54 am, Shane Rowatt allegedly wrote: > Zope Version: 2.4.1 on linux. > > When I tried to add a ZCatalog followed by finding objects to index using > the default indices provided (path, summary, id, title etc), the 'path' and > 'summary' indices are never generated. The 'summary' index is always an > empty string and the 'path' index is 'None'. Summary is not defined (as you found) for most plain objects. CatalogAware defines it, but unfortunately without stripping tags. You might check out my DTMLDocumentExt code which renders the document and strips the html tags. It is an extension of some code Dieter posted online a while back. You can find it at: http://www.zope.org/Members/Kaivo/DTMLDocumentExt [snip] > > Surely someone else has come across these problems before using this basic > catalog stuff?? Yup 8^) > > Shane Rowatt > Astracon Inc. hth /---------------------------------------------------\ Casey Duncan, Sr. Web Developer National Legal Aid and Defender Association c.duncan@nlada.org \---------------------------------------------------/ From brian.lloyd@zope.com Wed Oct 3 21:29:24 2001 From: brian.lloyd@zope.com (Brian Lloyd) Date: Wed, 3 Oct 2001 16:29:24 -0400 Subject: [Zope-dev] [Fwd: Re: [Zope] Python 2.1 for debian ?] In-Reply-To: <3BBB142C.20207@vt.edu> Message-ID: > Would it be smart to include the python header files in the zope binary > distributions? That would seem to solve a few problems for the > individuals using them. We'll be doing this as of Zope 2.4.2 (early next week, I hope). Brian Lloyd brian@zope.com Software Engineer 540.361.1716 Zope Corporation http://www.zope.com From richard@bizarsoftware.com.au Wed Oct 3 23:56:25 2001 From: richard@bizarsoftware.com.au (Richard Jones) Date: Thu, 4 Oct 2001 08:56:25 +1000 Subject: [Zope-dev] file descriptors on Solaris - IT'S A BUG, PEOPLE! In-Reply-To: <20011003075155.L8313-100000@twirl.bitdance.com> References: <20011003075155.L8313-100000@twirl.bitdance.com> Message-ID: <01100408562504.04291@ike> On Wednesday 03 October 2001 22:00, R. David Murray wrote: > On Tue, 2 Oct 2001, John Ziniti wrote: > > Yeah ... something tells me it's a little more complicated than that. > > Like recompiling the kernel, quite possibly. On FreeBSD there's > a sysctl, although you may still have to recompile the kernel in > some cases I think; on Linux you can zap a variable in proc. On > solaris....who knows . > > > Any advice on the other front? If I can reduce the number of files > > Zope needs to process this request, I'd grumpily agree to do that, > > is Zope opening a file for every ? > > Will using help? > > I don't see why zope should need so many file descriptors. But > you may have to start tracing code . As I mentioned yesterday, this is a _bug_ in cgi.py which is fixable by getting the patch from: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=231249 Richard From norton@alum.mit.edu Thu Oct 4 02:02:26 2001 From: norton@alum.mit.edu (Joseph Wayne Norton) Date: Thu, 04 Oct 2001 10:02:26 +0900 Subject: [Zope-dev] RFC: Date property requiers valid date (no more) In-Reply-To: <001c01c14c1e$547ea3c0$d7beb5d4@tor.torped.se> References: <001c01c14c1e$547ea3c0$d7beb5d4@tor.torped.se> Message-ID: <87n138b4kd.wl@namaste.tokyo.att.ne.jp> Johan - I have done a similiar hotfix by using None - which I think is a better alternative than ''. If you want to see all of the source, download the following Product, http://www.zope.org/Members/natsukashi/Products/CMFPropertyCore, and look inside the file CMFPropertyCore/LinkPropertyManager.py 1) I created my own converter functions and simply call the real function if the value is not none. Here is an excerpt from a file called LinkPropertyManager.py: from OFS.PropertyManager import PropertyManager from ZPublisher import Converters class LinkPropertyManager(PropertyManager): def field2float(v): if not v: return None else: return Converters.field2float(v) def field2int(v): if not v: return None else: return Converters.field2int(v) def field2long(v): if not v: return None else: return Converters.field2long(v) def field2date(v): if not v: return None else: return Converters.field2date(v) def field2link(v): if hasattr(v,'read'): v=v.read() else: v=str(v) return v type_converters = Converters.type_converters type_converters.update({'float' : field2float , 'int' : field2int , 'long' : field2long , 'date' : field2date , 'link' : field2link }) PropertyManager.type_converters = LinkPropertyManager.type_converters 2) Since you are patching the type converter, you might as well patch the manage_propertiesForm. This can be done by hotfixing the OFS.PropertyManager.PropertyManager.manage_propertiesForm value with your own dtml file. Here is a diff between the CMFPropertyCore/dtml/properties.dtml file and zope's properties.dtml file. bash$ diff -c properties.dtml /opt/arseed/tfs-lib/zope/zope-2.4.1/lib/python/OFS/dtml/properties.dtml *** properties.dtml Thu Aug 9 10:41:41 2001 --- /opt/arseed/tfs-lib/zope/zope-2.4.1/lib/python/OFS/dtml/properties.dtml Wed Oct 3 07:49:38 2001 *************** *** 58,74 **** "> "> "> "> CHECKED> --- 58,74 ---- "> "> "> "> CHECKED> *************** *** 77,83 **** value=" ">