TIP: Must enable 'new' for FreeBSD Python 1.5.2 port to install PythonMethods
I thought I would pass this on to the assembled geniuses since I just found it out. FreeBSD 3.3 stable, running Zope for a while, Python 1.5.2 built long ago, everything working fine. Decided to install the PythonMethods product -- it comes up broken. The error came in zbytecodehacks/opbases.py, line 1: import struct,dis,new because there was no module 'new'. It turns out that in the FreeBSD port of Python 1.5.2 (/usr/ports/lang/python), the Modules/Setup file is substituted with one that turns off Tommy Burnette's 'newmodule'. I have no idea why this should be, or why they didn't make whatever changes they needed as a Patch rather than an absolute overwrite of the file, but however it happened, you need to turn it back on in Modules/Setup and then remake and reinstall. Once I did that, PythonMethods comes up fine and other products (like BannerFolder-0.3) that rely on it, install as well.
On Fri, Feb 18, 2000 at 03:37:18PM -0500, Tom Neff wrote:
because there was no module 'new'. It turns out that in the FreeBSD port of Python 1.5.2 (/usr/ports/lang/python), the Modules/Setup file is substituted with one that turns off Tommy Burnette's 'newmodule'. I have no idea why this should be, or why they didn't make whatever changes they needed as a Patch rather than an absolute overwrite of the file, but however it happened, you need to turn it back on in Modules/Setup and then remake and reinstall. Once I did that, PythonMethods comes up fine and other products (like BannerFolder-0.3) that rely on it, install as well.
As a side note. *Don't* use BannerFolder's counters. You will get the banner copied for each impression :-/ -Petru
Petru Paler wrote:
On Fri, Feb 18, 2000 at 03:37:18PM -0500, Tom Neff wrote:
because there was no module 'new'. It turns out that in the FreeBSD port of Python 1.5.2 (/usr/ports/lang/python), the Modules/Setup file is substituted with one that turns off Tommy Burnette's 'newmodule'. I have no idea why this should be, or why they didn't make whatever changes they needed as a Patch rather than an absolute overwrite of the file, but however it happened, you need to turn it back on in Modules/Setup and then remake and reinstall. Once I did that, PythonMethods comes up fine and other products (like BannerFolder-0.3) that rely on it, install as well.
As a side note. *Don't* use BannerFolder's counters. You will get the banner copied for each impression :-/
What Counters? Are you talking about the hits, views, or remaining_views ? Inguiring minds need to know. :) FWIW, I am in the middle of a 'rewrite' of that product. I am adding the ability to 'weight' banners, view reports, and track click-throughs. Other changes are that it is being written in Python instead of ZClasses. Progress is slow, but existent; no time-frame for release yet, other than 'soon'. Bill -- In flying I have learned that carelessness and overconfidence are usually far more dangerous than deliberately accepted risks. -- Wilbur Wright in a letter to his father, September 1900
On Fri, Feb 18, 2000 at 02:54:13PM -0700, Bill Anderson wrote:
What Counters? Are you talking about the hits, views, or remaining_views ? Inguiring minds need to know. :)
All of them. It's a known, hmm, ``TODO item'' :-) for BannerFolder.
FWIW, I am in the middle of a 'rewrite' of that product. I am adding the ability to 'weight' banners, view reports, and track click-throughs.
This is very good. I was trying to figure out a way to implement weighting.
Other changes are that it is being written in Python instead of ZClasses.
This is _not_ good, please reconsider. ZClasses are the ``new'' and ``right'' way to extend Zope. Restarting the server each time you make a minor modification is bad. ZClasses are more maintanable too. What is important is to abstract out the counters; perhaps, let the BannerFolder decide how they are stored, or use acquisition (because BannerAd objects are often useful outside a BannerFolder - I use one for my ``hosted by GFDigital'' button). Something like calling ``get_counter (this(), _, counter_name)'' and set_counter likewise. So all you have to do is drop a SQLMethod or something in the acquisition path. If you keep it ZClass-based, I'd be glad to make you the official maintainer of the Product for the next few versions (in short, as long as you're interested). []s, |alo +---- -- I am Lalo of deB-org. You will be freed. Resistance is futile. http://www.webcom.com/lalo mailto:lalo@webcom.com pgp key in the web page Debian GNU/Linux --- http://www.debian.org Brazil of Darkness -- http://zope.gf.com.br/BroDar
Lalo Martins wrote:
On Fri, Feb 18, 2000 at 02:54:13PM -0700, Bill Anderson wrote:
What Counters? Are you talking about the hits, views, or remaining_views ? Inguiring minds need to know. :)
All of them. It's a known, hmm, ``TODO item'' :-) for BannerFolder.
FWIW, I am in the middle of a 'rewrite' of that product. I am adding the ability to 'weight' banners, view reports, and track click-throughs.
This is very good. I was trying to figure out a way to implement weighting.
You'd love how simpleand elegant it is (in Python) :) I've also got a new type of banner. Well, actually I made two types, 'local' and 'remote'. Local banners are the stock banner, and remote are the kind you get from other sites. The remote banners are good for where you do't actually store the image, but rather you get 'code' from the remote site, and the code contains the image url.
Other changes are that it is being written in Python instead of ZClasses.
This is _not_ good, please reconsider. ZClasses are the ``new'' and ``right'' way to extend Zope. Restarting the server each time you make a minor modification is bad. ZClasses are more maintanable too.
Well, I am looking at two methods, one would have Base Classes in Python, that the ZClasses would inherit from. The management would all be done inside of Zope. I am implementing a "BannerManager" that would determine the defaults, etc.. One advantage of Python is that it could be independant, as opposed to being dependant on other products. Perhaps the mix of ZClasses and Python would be the best.
What is important is to abstract out the counters; perhaps, let the BannerFolder decide how they are stored, or use acquisition (because BannerAd objects are often useful outside a BannerFolder - I use one for my ``hosted by GFDigital'' button). Something like calling ``get_counter (this(), _, counter_name)'' and set_counter likewise. So all you have to do is drop a SQLMethod or something in the acquisition path.
Hmmm... an interesting thought.
If you keep it ZClass-based, I'd be glad to make you the official maintainer of the Product for the next few versions (in short, as long as you're interested).
Well, I originally started modifying the ZClasses, but found certain issues I haven't been able to get around. Namely the remote banner data interference message I posted earlier. :( If I could get that resolved, I would not mind having an 'interim' where the new features were implemented in the ZClasses. -- In flying I have learned that carelessness and overconfidence are usually far more dangerous than deliberately accepted risks. -- Wilbur Wright in a letter to his father, September 1900
On Fri, Feb 18, 2000 at 04:11:58PM -0700, Bill Anderson wrote:
Well, I am looking at two methods, one would have Base Classes in Python, that the ZClasses would inherit from. The management would all be done inside of Zope. I am implementing a "BannerManager" that would determine the defaults, etc..
One advantage of Python is that it could be independant, as opposed to being dependant on other products. Perhaps the mix of ZClasses and Python would be the best.
It is. Even if it requires frequent Zope restarts during the development of the base class it's faster because you avoid yucky DTML programming. The trick is to be careful when you decide what to do in Python and what to leave to the ZClasses. -Petru
On Fri, Feb 18, 2000 at 10:57:37PM +0200, Petru Paler wrote:
As a side note. *Don't* use BannerFolder's counters. You will get the banner copied for each impression :-/
Not really. ZODB is smarter than that. The set of properties is copied, not the image. (AFAIK) []s, |alo +---- -- I am Lalo of deB-org. You will be freed. Resistance is futile. http://www.webcom.com/lalo mailto:lalo@webcom.com pgp key in the web page Debian GNU/Linux --- http://www.debian.org Brazil of Darkness -- http://zope.gf.com.br/BroDar
Lalo Martins wrote:
On Fri, Feb 18, 2000 at 10:57:37PM +0200, Petru Paler wrote:
As a side note. *Don't* use BannerFolder's counters. You will get the banner copied for each impression :-/
Not really. ZODB is smarter than that. The set of properties is copied, not the image. (AFAIK)
Hmm ... this could explain the moderate growth of my Data.fs. Packing removed the 'older versions' apparently, if this was indeed the cause. I don't suppose there is a way for an object to remove any previous versions programmatically? -- In flying I have learned that carelessness and overconfidence are usually far more dangerous than deliberately accepted risks. -- Wilbur Wright in a letter to his father, September 1900
On Fri, Feb 18, 2000 at 03:58:26PM -0700, Bill Anderson wrote:
Lalo Martins wrote:
On Fri, Feb 18, 2000 at 10:57:37PM +0200, Petru Paler wrote:
As a side note. *Don't* use BannerFolder's counters. You will get the banner copied for each impression :-/
Not really. ZODB is smarter than that. The set of properties is copied, not the image. (AFAIK)
Hmm ... this could explain the moderate growth of my Data.fs.
Packing removed the 'older versions' apparently, if this was indeed the cause.
Yes. As I'm using BannerFolder quite heavily, I acquired the habit of packing weekly. It usually drops size by about 80%, and this considering that I only delete objects older than 7 days.
I don't suppose there is a way for an object to remove any previous versions programmatically?
This is a good question. But even if there isn't, you can program a cron job to pack your database - look for my Zope/Cron Howto. []s, |alo +---- -- I am Lalo of deB-org. You will be freed. Resistance is futile. http://www.webcom.com/lalo mailto:lalo@webcom.com pgp key in the web page Debian GNU/Linux --- http://www.debian.org Brazil of Darkness -- http://zope.gf.com.br/BroDar
Was I just dreaming, or did I see a message from DC saying that, since release 2.1.?, ZODB is automatically packed "in the background". -- Loren ----- Original Message ----- From: Lalo Martins <lalo@hackandroll.org> To: <zope-dev@zope.org> Sent: February 18, 2000 03:08 PM Subject: [Zope-dev] ZODB & packing (Re: [Zope-dev] TIP: Must enable 'new' for FreeBSD Python 1.5.2 port to install PythonMethods)
On Fri, Feb 18, 2000 at 03:58:26PM -0700, Bill Anderson wrote:
Lalo Martins wrote:
On Fri, Feb 18, 2000 at 10:57:37PM +0200, Petru Paler wrote:
As a side note. *Don't* use BannerFolder's counters. You will get
the
banner copied for each impression :-/
Not really. ZODB is smarter than that. The set of properties is copied, not the image. (AFAIK)
Hmm ... this could explain the moderate growth of my Data.fs.
Packing removed the 'older versions' apparently, if this was indeed the cause.
Yes. As I'm using BannerFolder quite heavily, I acquired the habit of packing weekly. It usually drops size by about 80%, and this considering that I only delete objects older than 7 days.
I don't suppose there is a way for an object to remove any previous versions programmatically?
This is a good question.
But even if there isn't, you can program a cron job to pack your database - look for my Zope/Cron Howto.
[]s, |alo +---- -- I am Lalo of deB-org. You will be freed. Resistance is futile.
http://www.webcom.com/lalo mailto:lalo@webcom.com pgp key in the web page
Debian GNU/Linux --- http://www.debian.org Brazil of Darkness -- http://zope.gf.com.br/BroDar
_______________________________________________ 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 )
Loren Stafford wrote:
Was I just dreaming, or did I see a message from DC saying that, since release 2.1.?, ZODB is automatically packed "in the background".
Packed in the background, yes. Packed automatically, no. -- In flying I have learned that carelessness and overconfidence are usually far more dangerous than deliberately accepted risks. -- Wilbur Wright in a letter to his father, September 1900
participants (5)
-
Bill Anderson -
Lalo Martins -
Loren Stafford -
Petru Paler -
Tom Neff