January 2002 - Zope-Dev

New Medical/Healthcare Python/Zope user group - Zopymed
by Jon Edwards 22 Jan '02

22 Jan '02

>From an idea on the Openhealth mailing list, we've setup a new user-group for Zope/Python users involved in the Medical/Healthcare fields (and surrounding fields, such as Education, Research, BioInformatics) ...or ZoPyMed for short! Just a mailing list so far - http://maillist.linuxmednews.org/mailman/listinfo/zopymed - but we can setup an associated website if there is sufficient interest. Short-term, the list is a place to ask questions and share ideas, code, tips and useful-links. Long-term, we might aim to create reusable components/functionality and promote interoperability between different applications. But the "agenda" is very fluid, and open to suggestions! So, if you're using Zope/Python and are involved in Medical/Health-related IT, please join up, introduce yourself, and tell us what you'd like to see from this group! Cheers, Jon Jon Edwards Pricom Ltd www.pricom.co.uk

1 0

Re: Python 2.1.2 does not fix the signal 11 crashing problem !!!!!!!!!!!
by Anthony Baxter 21 Jan '02

21 Jan '02

>>> "Matthew T. Kromer" wrote > 2.4.4 (which should be mostly the equivalent of the Zope-2_4-branch in > our CVS) hasn't been extensively tested. There are a LOT of things that > I'm aware of that _can_ cause crashes, ie in MySQL when the database > object switches threads, it can get unhappy (I think something in MySQL > may have thread-local state). In that case, how about cutting a version which is 2.4.3 + the compiler fixes? Crashes are bad, and it would be very nice to Make Them Go Away. :) Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

2 1

Zope 2.4.4, when?
by Leonardo Rochael Almeida 21 Jan '02

21 Jan '02

Guys, please, We really need 2.4.4 and our client won't accept a CVS version. 2.5 betas won't do it either. What is holding 2.4.4 back? Is there anything you need help with? testing? bugfix? Cheers, Leo -- Ideas don't stay in some minds very long because they don't like solitary confinement.

2 1

REQUEST.AUTHENTICATED_USER question
by vio 21 Jan '02

21 Jan '02

Hi, Does anybody know what is the method call to modify the AUTHENTICATED_USER attribute? I am unable to trace where REQUEST feeds data for its AUTHENTICATED_USER attribute. Some context to my question: I am using a custom method to authenticate users coming to my site. So when the user logs in, he is 'Anonymous User' (from call: AUTHENTICATED_USER.getUserName()). But after his login name and password checked ok, how do I switch his identity in Zope from 'Anonymous User' to his/her new identity? What I am looking for is that next time I call 'REQUEST.AUTHENTICATED_USER.getUserName()' to get the new UserName he just logged in as, not 'Anonymous User' again. Examining CookieCrumbler.py source, this authentication product uses the 'before_publishing_traverse hook' mechanism. But isn't there a simpler way to do this than modifying REQUEST.RESPONSE at each traversal? Sounds like a lot of overhead. Vio

2 1

Re: Python 2.1.2 does not fix the signal 11 crashing problem !!!!!!!!!!!
by Anthony Baxter 21 Jan '02

21 Jan '02

>>> Harald Koschinski wrote > >Which version of Zope? > 2.4.3 > >Does it have the RestrictedCompiler fix? > Good question - next question please :-((( My understanding is that 2.4.3 still has the bug. > I am again a little bit confused - I thought that the problem is only in > the GC module of Python because zope is running without any crashes when > I disable GC. The bug's still there, it's just that the corrupted data is hit much more frequently when GC is on. Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 0

Python 2.1.2 does not fix the signal 11 crashing problem !!!!!!!!!!!
by Harald Koschinski 21 Jan '02

21 Jan '02

Hallo, after switching to python 2.1.2 compiled with GC (intranet:/usr/local/src/Python-2.1.2 # ./configure --without-pymalloc) the crashes are back again :-((((((((((((((((((((((( ------------------------------------------------------------------------------------- 2002-01-04T06:23:51 ERROR(200) zdaemon zdaemon: Fri Jan 4 07:23:51 2002: Aiieee! 9671 exited with error code: 11 2002-01-04T07:25:48 ERROR(200) zdaemon zdaemon: Fri Jan 4 08:25:48 2002: Aiieee! 10107 exited with error code: 11 2002-01-04T07:30:45 ERROR(200) zdaemon zdaemon: Fri Jan 4 08:30:45 2002: Aiieee! 10412 exited with error code: 11 2002-01-21T08:30:43 ERROR(200) zdaemon zdaemon: Mon Jan 21 09:30:43 2002: Aiieee! 6749 exited with error code: 11 ------------------------------------------------------------------------------------- What is the way to finaly fix the problem???? regards Harald Matthew T. Kromer wrote: > Harald Koschinski wrote: > >> same for me, no more crashes - but zope needs very much memory (logo >> :-(() >> >> I will try know python 2.1.2. >> > > > OK -- our Zope 2.5.0 betas 3 and 4 have a binary python in them that > contains the critical ceval.c patch. > >> > > >

1 0

Re: [Zope-dev] Core dumps - How to find out the bug?
by Anthony Baxter 21 Jan '02

21 Jan '02

>>> =?iso-8859-1?Q?Dario_Lopez-K=E4sten?= wrote > I only have core dumps to work from. I include the stack from latest core > dump. > I am using python 2.1.2 (release), Zope2.4.3 release, RedHat Linux 7.2. > Python is compiled --without-pymalloc Hm. The bug report you sent is pretty much exactly what I'd expect when hitting the Python Compiler stacksize bug. I suspect the problem here is that Zope 2.4.3 provides it's own complete copy of the Compiler, so you're not seeing Jeremy's fixes. Possible solutions: - wait for Zope 2.4.4 - upgrade to the current CVS version of the Zope 2.4 branch, Zope-2_4-branch. This contains what will become (hopefully, shortly) 2.4.4. I'm assuming there's a 2.4.4 planned. - upgrade to the current 2.5 beta. > > ----- > #0 0x0806fb77 in subtract_refs (containers=0x80b228c) at > ./Modules/gcmodule.c:170 > #1 0x0806ff74 in collect (young=0x80b228c, old=0x80b2298) at > ./Modules/gcmodule.c:382 > #2 0x080701c2 in collect_generations () at > ./Modules/gcmodule.c:479 Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 0

Core dumps - How to find out the bug?
by Dario Lopez-Kästen 21 Jan '02

21 Jan '02

Hello! I wonder what to do when zope coredumps? I have been given the advice to hook up gdb to zope/python and see what happens, but there are two problems with this: 1) I barely know gdb at all, let alone know how to hook it up to a running process 2) The dumps happen at random (last one happened at 3 in the morning when a co-worker was working from home). I only have core dumps to work from. I include the stack from latest core dump. I am using python 2.1.2 (release), Zope2.4.3 release, RedHat Linux 7.2. Python is compiled --without-pymalloc What can I do more to track this down? Thanks, /dario ----- #0 0x0806fb77 in subtract_refs (containers=0x80b228c) at ./Modules/gcmodule.c:170 #1 0x0806ff74 in collect (young=0x80b228c, old=0x80b2298) at ./Modules/gcmodule.c:382 #2 0x080701c2 in collect_generations () at ./Modules/gcmodule.c:479 #3 0x08070255 in _PyGC_Insert (op=0x8c1dbbc) at ./Modules/gcmodule.c:508 #4 0x0807eb8e in PyMethod_New (func=0x82fa3dc, self=0x8c1d50c, class=0x82f9f14) at Objects/classobject.c:1834 #5 0x0807c74c in instance_getattr2 (inst=0x8c1d50c, name=0x8168e00) at Objects/classobject.c:642 #6 0x0807c67e in instance_getattr1 (inst=0x8c1d50c, name=0x8168e00) at Objects/classobject.c:608 #7 0x0807c789 in instance_getattr (inst=0x8c1d50c, name=0x8168e00) at Objects/classobject.c:656 #8 0x0808d291 in PyObject_GetAttr (v=0x8c1d50c, name=0x8168e00) at Objects/object.c:1052 #9 0x0809b7ba in builtin_hasattr (self=0x0, args=0x8d8cb94) at Python/bltinmodule.c:886 #10 0x08058df1 in call_cfunction (func=0x80c79c8, arg=0x8d8cb94, kw=0x0) at Python/ceval.c:2850 #11 0x080577ac in eval_code2 (co=0x82d91a0, globals=0x82ebd9c, locals=0x0, args=0x8a3a7e0, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:1952 #12 0x080590a3 in call_eval_code2 (func=0x82f9fb4, arg=0x8a3a7d4, kw=0x0) at Python/ceval.c:2971 #13 0x08058ce4 in call_object (func=0x82f9fb4, arg=0x8a3a7d4, kw=0x0) at Python/ceval.c:2810 #14 0x08058f77 in call_method (func=0x82f9fb4, arg=0x80cb8fc, kw=0x0) at Python/ceval.c:2928 #15 0x08058cd1 in call_object (func=0x8b9f2dc, arg=0x80cb8fc, kw=0x0) at Python/ceval.c:2808 #16 0x08058bcb in PyEval_CallObjectWithKeywords (func=0x8b9f2dc, arg=0x80cb8fc, kw=0x0) at Python/ceval.c:2745 #17 0x0807c433 in PyInstance_New (klass=0x82f9f14, arg=0x80cb8fc, kw=0x0) at Objects/classobject.c:489 ------ - -------------------------------------------------------------------- Dario Lopez-Kästen Systems Developer Chalmers Univ. of Technology dario(a)ita.chalmers.se ICQ will yield no hits IT Systems & Services

2 1

ExternalFile released
by Craeg K. Strong 21 Jan '02

21 Jan '02

In case any of you hadn't seen it yet, here is the news item I just posted on zope.org: ExternalFile 0.8 Released (Stable) Created by arielpartners <http://www.zope.org/Members/arielpartners> on 2002/01/17. This is the second public release of our ExternalFile <http://www.zope.org/Members/arielpartners/ExternalFile> product. Why not simply use ExtFile <http://www.zope.org/Members/MacGregor/ExtFile>? Because ExternalFile supports pointing to a file "in situ" like a symbolic link, rather than copying it into some central repository directory. This may not seem like a big deal, until you consider that those files might be stored in a revision control system like CVS. ExternalFile gives you the ability to create a Zope object that points to a file in, for example, a CVS sandbox for its content. This new release adds "workalike" capabilities. ExternalFile can now behave like any of the following: * DTMLDocument * DTMLMethod * Image ExternalFile is usable by itself. It is also the base class for CVSFile, to be released shortly. --Craeg

1 0

Re: [Zope-dev] Security Gurus Wanted
by vio 19 Jan '02

19 Jan '02

* vio <vmilitaru(a)sympatico.ca> [020119 09:56]: > vio wrote: > > Just a word to thank you for your reply. > > But incidently, wouldn't it be a good idea for Globals.InitializeClass() > > to throw an error > > or a warning of some kind for hanging 'security.stuff()' declarations, > > declarations which do not have a related ClassSecurityInfo object AT THE > > CLASS LEVEL? > > That would be a fine idea. Unfortunately, there is no straightforward > way telling that you called methods on the security object in the class > definition. Why not simply check for the keyword 'security.' in the class source ? Anything beginning with that word most probably has something to do with security. But if 'security' is not a reference to a security object, just throw an exception. This would make everything so much simpler. > > When you call Globals.InitializeClass(your_class), it looks for a > ClassSecurityInfo object, and doesn't find one. If I understood correctly, this should be treated like an error: not allow the programmer to have calls to security methods which aren't there, because that's more or less what's happening here. And definitely not be silent about it !!! That's a syntax error or something. So Globals.InitializeClass(your_class) finds the declaration 'security.declareSomething()' inside a class, but 'security' being a reference to a ClassSecurityInfo object AT THE MODULE LEVEL somehow has no effect at the class level (while I wrongly thought that by declaring it at the module level like that, it will behave more or less like a 'global' variable). I wonder what was carried at the class level, but something definitely was, else Python would have thrown something ugly at me. In my opinion, Globals.InitializeClass() should check such calls to security methods, and by all means NOT remain silent if it can not carry out the call because it couldn't find a ClassSecurityInfo object's method. Throw a 'method not found' error or something like that. Silence = 'bad'. I'll even say it's a bug. Vio

3 4