- Zope - Zope lists

CHANGING A PROPERTY IN DTML
by Theodore Patrick 12 Feb '99

12 Feb '99

Amos, How do you change a property of a folder in DTML. Assume a folder named ted: Properties of ted folder are: fname = ted lname = patrick mi = e How do you set the ted.fname to Fred from a simple form? Thanks, Theodore E. Patrick Indigo Networks email: tpatrick(a)indigonetworks.com <mailto:tpatrick@indigonetworks.com> phone: 615-777-0070 ext.125

2 1

Could DC _PLEASE_ get rid of the old bobo list?
by The Dragon De Monsyne 12 Feb '99

12 Feb '99

Could the the folks at Digicool PLEASE get rid of the old bobo list, and alias bobo(a)digicool.com to zope(a)zope.org ? The old list is a simple reflector, and it's acting as a SPAM channel. with it redirected, MailMan could catch the spam, and legitimate traffic (presumabally from newbies who got the old address somewhere) would go to the zope list where it really belongs. -Thanx -The Dragon De Monsyne

1 0

help wanted: new PIL GIF encoder needs testing!
by Fredrik Lundh 12 Feb '99

12 Feb '99

(reposted from image-sig(a)python.org) By some odd reason, I wrote a PCX encoder for PIL this weekend. While PCX uses a simple run-length encoding scheme, it still produced files that were much smaller than the "uncompressed by legal reasons" GIF files you get from the current version of PIL. Anyway, when my good friend the mad scientist heard about this, he asked me why I didn't use run-length encoding also for the GIF files (while run-length en- coding often gives smaller files, it's not even remotely similar to the patented LZW algorithm) After some experimentation, I've managed to write a new GIF encoder which uses run-length encoding (this wasn't exactly trivial ;-). this gives files that are typically 30%-50% of the size generated by earlier versions (ranging from exactly the same size as before, down to files that are actually smaller than the corresponding GIF files...) But I need your help in testing this on a larger sample of GIF files and GIF readers. If you have some time to spare, and a PIL 1.0b1 build within reach, you can grab the "patch" from: http://www.pythonware.com/madscientist/gif-990208.zip replace libImaging/Gif.h and libImaging/GifEncode.c with the versions in this file, and rebuild. You can then use the checkgif.py script on a bunch of existing GIF files to make sure it works on your data. If you have some extra time to spare, you could also try loading GIF files generated by this encoder with whatever GIF-reading software you have. Report your findings to me (I'm not on this list). If I don't hear anything at all, or if I only hear positive things, this will go into the next PIL release. Cheers /F fredrik(a)pythonware.com http://www.pythonware.com

1 0

RE: [Zope] Problems with File upload and Zope-1.10.0pr1
by Brian Lloyd 12 Feb '99

12 Feb '99

> Hello Zopistas > > Part 1 > > Trying to upload a plain text file, name Test into Zope (as an object > File), (both Zope-1.9.0 and Zope-1.10.0) results in the > following error: > (Unknown content type) This was a bug -- I've fixed it for 1.10.0 final. > Part 2. > > I have installed Zope 1.10.0 and transfered the old Data.bbb > files in the > var directory. Everything seems to work ok and the old > Document objects > have been succesfully changed to DTML method objects. > > Nevertheless a dtml like: >  > captures only the old Documents and not the new DTML methods or > DTML Documents that I have added. Curiously copies of the old Document > methods are also not shown. Looks like a bug to me. > > Pavlos Waaaa... :( Hopefully there's not a _whole_ lot of that in use. Unfortunately during this transition period you'll need to use:  Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

1 0

RE: [Zope] Name Clashing between Zope and PIL
by Michel Pelletier 12 Feb '99

12 Feb '99

> -----Original Message----- > From: Christian Sonntag [mailto:sonntag@lion-ag.de] > Sent: Thursday, February 11, 1999 3:06 AM > To: Zope Mailing List > Subject: [Zope] Name Clashing between Zope and PIL > > > Hello, > > > There seems to be a name-clashing between zope and PIL > library, namely the > module 'ImageFile'. > Did someone encoutner this problem, and how is the suggested way of > solving it? > Yes, it was discussed on the list a few weeks ago, while we were in the midst of moving-office-hell. I suggest before re-opening this wound we (those of us who are interested) go back and read the relevant discussions so we don't reproduce non-productive discussion. -Michel > Cheers > Christian > > > > _______________________________________________ > Zope maillist - Zope(a)zope.org > http://www.zope.org/mailman/listinfo/zope >

2 1

Re: [Zope] ZServer/anonftp and aside: efs, emacs on NT
by Roman Milner 12 Feb '99

12 Feb '99

>>>>> "PE" == Paul Everitt <paul(a)digicool.com> writes: PE> Hmm, I tinkered around this morning with alpha2. With EFS I PE> was able to loging and create something. Editing it crashed PE> the server, as efs sent a whole bunch of weird FTP commands PE> (to create the backup file with the tilde ending the filename, PE> the rename, etc., and Zope can't handle filenames with a PE> tilde). You can avoid this by having XEmacs put all autosave and backup files in one directory, rather than in cwd. (require 'efs-auto) (setq efs-auto-save 1) (setq auto-save-directory (expand-file-name "~/.autosave/") auto-save-directory-fallback auto-save-directory auto-save-hash-p nil efs-auto-save 1 efs-auto-save-remotely nil auto-save-interval 2000 ) (require 'backup-dir) (setq bkup-backup-directory-info '((t "~/.autosave" ok-create full-path))) It mostly works great for me. It hangs after the save and I have to do C-g - not sure why - it looks like EFS had sent ftp> ls "-dal /index_html" /tmp/efsaIATjC when the hang occured. ^Roman

1 0

RE: [Zope] Acquisition question
by Brian Lloyd 12 Feb '99

12 Feb '99

> Hi, > > Can anybody explain why my dynamically created attributes > can't find their acquired attributes up the hierarchy? > > I have the following code: > > class AcquTest(Acquisition.Implicit): > "the implicitluy aquired one" > __roles__ = None > def __init__(self,color=None): > if color: > self.color = color > def __getitem__(self,attr): > if self.__class__.__dict__.has_key(attr): > return self.__class__.__dict__[attr] > if self.__dict__.has_key(attr): > return self.__dict__[attr] > try: > return self.aq_acquire(attr) > except: > self.__dict__[attr] = AcquTest(attr) > return self.__dict__[attr] > local_html = HTML("<html>Local </html>") > index_html = HTML(""" >  > <br> > """) > > aq = AcquTest('orange') > aq.page_header = HTML('<html><font color="" > size=+3><b>') > aq.page_footer = '</font></html>' > aq.name = 'AQ root object' > > aq.a = AcquTest() > aq.a.b = AcquTest('blue') > aq.a.color= 'green' > ---8<------8<------8<------8<------8<------8<------8<--- > > and when I access it through web as /aq , /aq/a or /aq/a/b > it works as expected (prints orange, green and blue in > respective coluor) > > but when i want to access a new attribute (retrieved from > a database by attr in my real application), then it can't > acquire the other attributes up the hierarchy. > > ie /aq/black does _not_ print black, instead it produces a traceback: > ... > KeyError: page_header > > So obviously acquisition is not working for me here ;( This is because you have effectively defeated acquistion inside your __getitem__ method. One of the best things about acquisition is that it is so black box that you almost never have to think about it - which makes it easy to forget that if you override __getitem__ you may need to manually maintain the acquisition chain. Acquiring objects are actually "wrappers" which wrap an object with its parent in a given context. This wrapping process is usually done for you by the Acquisition machinery which is hooked to the c equivalent of __getattr__. Anytime you get an instance attribute in a way that bypasses that getattr hook, you need to wrap the object yourself to maintain the acquisition chain, using the __of__ method). Here is a modified __getitem__ that should work: def __getitem__(self,attr): # Anytime we get an attr from an __dict__ directly # rather than from a getattr, we need to wrap it # before returning it if self.__class__.__dict__.has_key(attr): return self.__class__.__dict__[attr].__of__(self) if self.__dict__.has_key(attr): return self.__dict__[attr].__of__(self) try: # If we are able to acquire the attr directly via # aq_acquire, we _dont_ need to wrap it - the # aq_acquire method will have taken care of that # for us... return self.aq_acquire(attr) except: self.__dict__[attr] = AcquTest(attr) return self.__dict__[attr].__of__(self) Hope this helps! Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

1 0

Re: [Zope] A couple of technical Zope questions
by Tres Seaver 12 Feb '99

12 Feb '99

Simon Michael gave the "stock" reply: >Stefan Franke <sfranke(a)cdc-group.com> writes: > >> Hello Zopenians .. Zopists .. Zopers..? I've got some questions > >Zopesters/Zopistas. > >:) Me, I like "Zopetistas" better -- it "rings truer," and has some interesting "revolutionary" overtones. :) Tres.

1 0

ZServer/anonftp and aside: efs, emacs on NT
by David Ascher 12 Feb '99

12 Feb '99

I'm playing around with the latest ZServer & Zope distributions. I can ftp into it (cool =) with Netscape and standard ftp. However, if I try to use the latest dired w/ GNU Emacs 20.3.1 on NT, I can't login, and I suspect it's because emacs is confusing Medusa when it comes to line terminations. I'd try anonymous ftp, but if I try to allow FTP access to Anonymous under manage/Security/, I get 'Sorry, an error occurred' and: Traceback (innermost last): File ZPublisher\Publish.py, line 865, in publish_module File ZPublisher\Publish.py, line 577, in publish (Info: manage_changePermissions) File d:\Zope\lib\python\AccessControl\Role.py, line 194, in manage_changePermissions (Object: ApplicationDefaultPermissions) File d:\Zope\lib\python\AccessControl\Permission.py, line 166, in setRoles AttributeError: manage_findOpt In fact, I get that error if I try to change any of the permissions! This is the latest 1.10 distribution and latest ZServer distribution. --david

2 1

RE: [Zope] Better Memeory Management Feature Request
by Michel Pelletier 11 Feb '99

11 Feb '99

> -----Original Message----- > From: Scott Robertson [mailto:sroberts@codeit.com] > > > You are very correct. That's why are first Zope Virtual > Hosting Machine > will have between .5GB-1GB of memory to start with. But it > only took me 5 > minutes to get the process to swell up to 18MB. That means some > industrious/mallicious user could conceivably swell theirs up to 100MB > even the full GB and then nobody else would get to play. > > Thinking a bit more about this, I guess the problem is that each virtual interface on the machine; which is the typical method to do multihosting, must go through its own RewriteRule thus leading to it's own Zope process. Perhaps we can solve the problem a bit with ZServer, maybe different Medusa interfaces could hook into different branches of the same Zope Module, and all of those interfaces then funnelling into the same database. This is obviously not a rigorous examination. Paul and I would like to do a rigorous examination of the memory fluctuations that the zope.org python process goes through throughout the day. Paul told the list that it was 21.4 meg this morning (8am) I told the list that it was 19 some meg a couple hours later, a half hour ago it was at 28(!) meg, and now it's at 31. So all you Linux fellows out there need to suggest a good way for us to track this on a regular basis. We propose a cron job sniffs the /proc filesystem. What kind of information do *you* want to see in this study? *Scripts welcome* -Michel > > --------------------------------------------------- > - Scott Robertson Phone: 714.972.2299 - > - CodeIt Computing Fax: 714.972.2399 - > - http://codeit.com - > --------------------------------------------------- > > > _______________________________________________ > Zope maillist - Zope(a)zope.org > http://www.zope.org/mailman/listinfo/zope >

3 2