[Zope-Coders] Signal handling

[Jens Vagelpohl]

i dug a little deeper and it seems that the location where i had stuck the 
checkout (/tmp, which in reality is /private/tmp on OS X) threw the 
mechanisms that try to determine absolute paths for a loop.

App.FindHomes calls a method named realpath inside App.Common to produce a 
path void of symlinks. that one goes into infinite recursion and dies after 
a while.

what threw me was that the error never propagated outward and the import of 
App.FindHomes in z2.py just went by silently without any indication as to 
what had happened.

i am trying again in a different location now.

jens


On Wednesday, June 12, 2002, at 12:47 , Chris McDonough wrote:

> It looks like the import of ZServer above that in turn imports
> App.FindHomes which should declare CLIENT_HOME.
>
> But the import of App.FindHomes is wrapped in a try: except:... if you
> took it out you could see what is going on.  It works over here, so I'm
> not sure what's going on...
>
> -C
>
> On Wed, 2002-06-12 at 00:29, Jens Vagelpohl wrote:
>> thanks for the help. commenting out the line that includes malloc.h allows
>> the compilation to finish.
>>
>> now i'm faced with other problems trying to use the standard start script,
>>   i don't remember having any of those ever before:
>>
>> [statler:/tmp/Zope] jens% ./start -D
>> Traceback (most recent call last):
>>    File "/tmp/Zope/z2.py", line 582, in ?
>>      zdaemon.run(sys.argv, os.path.join(CLIENT_HOME, Zpid),
>> NameError: name 'CLIENT_HOME' is not defined
>>
>> interestingly, this seems to be the first time in the whole module that
>> CLIENT_HOME is referenced anywhere.
>>
>> argh!!!!!  i'm not going to pursue this any further tonight.
>>
>> jens
>>
>>
>>
>> On Wednesday, June 12, 2002, at 12:10 , Tim Peters wrote:
>>
>>> [Jens Vagelpohl]
>>>> yes there is::
>>>>
>>>> [statler:~] jens% locate malloc.h
>>>> /usr/include/objc/malloc.h
>>>> /usr/include/sys/malloc.h
>>>
>>> 1. Are either of those on the standard include path for your compiler?
>>>    Since it can't find it, I bet not <wink>.
>>>
>>> 2. Can you try again after simply deleting the
>>>
>>> #include <malloc.h>
>>>
>>>    line in lib/python/BTrees/sorters.c?  A std-conforming C compiler
>>>    should supply the needed prototypes via the earlier #include of
>>>    stdlib.h.  Including malloc.h is a possibly <wink> bad habit I've
>>>    had since K&R C days.
>>>
>>> sorters.c is relatively new code, which is why this never popped up 
>>> before.
>>
>>
>>
>> _______________________________________________
>> Zope-Coders mailing list
>> Zope-Coders@zope.org
>> http://lists.zope.org/mailman/listinfo/zope-coders
>
>