Re: [Zope-dev] Zope on Windows/Mac OS X:BatteriesIncludedDistribution

[Michael R. Bernstein]

On Fri, 2001-09-28 at 05:05, Paul Everitt wrote:
> 
> I think, with all the various efforts, it is time to agree on some 
> standards regarding where configuration data lives and how it looks.

I remember that Eric Raymond had created a new language specifically for
describing software configuration options, and that he implemented the
new language using Python:

http://www.tuxedo.org/~esr/cml2/

This may not be appropriate for Zope configuration, but I thought I'd
bring it up.

HTH,

Michael Berrnstein.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] Z SQL Methods appear broken in 2.4.x

[Jens Vagelpohl]

joe,

please do not cross-post your messages to several zope lists. (see the 
zope list footer...)

i cannot reproduce the error on a 2.4.1-based site...

jens


On Friday, September 28, 2001, at 03:56 , Joseph J Wolff wrote:

> It appears that Z SQL Methods are broken in 2.4.x.
>
> Specifically, the type=string in a  is broken -
>
> a simple ZSQL query such as:
>
> select id, cost, name
> from choices
> where name = 
>
> results in the following error:
>
> exceptions.NameError: global name 'string' is not defined
>
> It's broken on 2.4.0 and 2.4.1, and works fine on 2.2.5, 2.3.0, and 2.3.2 
> -
> in fact, it's in production on our 2.2.5.
>
> Integer parameters work fine.
>
> It's hard to believe that no one else has run into this, and that the 
> stable
> 2.4.x branch has gotten this far without anyone noticing this - I've even
> tried it on 2 different servers running Zope 2.4 (2.4.1 on FreeBSD 4.0, 
> our
> production web server, and 2.4.0 on FreeBSD 4.3, our dev server)
>
> Any ideas?
>
> Regards,
> joe
>

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

[Zope-dev] Re: [Zope] Z SQL Methods appear broken in 2.4.x

[Andreas Jung]

This works for me (Zope 2.4 branch, ZMysqlDA). Do you have
a traceback ?

Andreas
- Original Message -
From: "Joseph J Wolff" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, September 28, 2001 15:56
Subject: [Zope] Z SQL Methods appear broken in 2.4.x


> It appears that Z SQL Methods are broken in 2.4.x.
>
> Specifically, the type=string in a  is broken -
>
> a simple ZSQL query such as:
>
> select id, cost, name
> from choices
> where name = 
>
> results in the following error:
>
> exceptions.NameError: global name 'string' is not defined
>
> It's broken on 2.4.0 and 2.4.1, and works fine on 2.2.5, 2.3.0, and
2.3.2 -
> in fact, it's in production on our 2.2.5.
>
> Integer parameters work fine.
>
> It's hard to believe that no one else has run into this, and that the
stable
> 2.4.x branch has gotten this far without anyone noticing this - I've even
> tried it on 2 different servers running Zope 2.4 (2.4.1 on FreeBSD 4.0,
our
> production web server, and 2.4.0 on FreeBSD 4.3, our dev server)
>
> Any ideas?
>
> Regards,
> joe
>
> Joseph J Wolff
> eRacks Open Source Rackmount Systems
> www.eracks.com
> [EMAIL PROTECTED]
>
>
>
> ___
> Zope maillist  -  [EMAIL PROTECTED]
> http://lists.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists -
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope-dev )
>


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] Re: [DISCUSS] Committer agreement not even handedand threadening

[Michael R. Bernstein]

On Fri, 2001-09-28 at 08:32, Paul Everitt wrote:
>
> Dieter Maurer wrote:
> 
> > Paul Everitt writes:
> >  
> > 
> > The "Committer Agreement" does not seem to be even handed:
> > 
> >The committer transfers rights immediately and indefinitely
> >to Zope Corporation (the contributions become a gift to
> >Zope Corporation).
>
> This is an inaccurate representation.  Transfer means you lose the 
> rights and we gain the rights.  Under joint ownership, both have rights. 
>   I think this point was abundantly clear, so I'm surprised to see you 
> portray this as a gift.

Hmm. So, the copyright to the contributed code is held jointly? or does
the contibutor simply grant a non-exclusive license to Zope Corp
(including the right to relicense)?

> >The agreement states explicitly that no rights are transfered
> >to the committer.
> 
> Because they never lost any rights.

This is correct. The contributor gets access to the entire source code
under the ZPL anyway, even without making a contribution. No additional
rights need be asigned from ZC to the contributor, IMO.
 
> >This is not a problem in itself. However
> > 
> >   My intention to contribute would be to strengthen
> >   the Open Source Movement. A statement that
> >   the supported code base (Zope) will remain open source
> >   and that committers will be able to use it (indefinitely)
> >   under terms comparable to the current ZPL would
> >   help to let the agreement to appear more balanced
> 
> 
> I don't think it's really feasible to 100% guarantee things in the 
> future.  Rather, the agreement states that current code, and any 
> contribution, will be available under the ZPL.  Nothing can be 
> retracted.  If someone comes along and gives us one trillion dollars to 
> stop releasing our work as open source, two things would happen:
> 
> 1) First, we'd take the money. :^)
> 
> 2) Second, all the existing code has to remain available under the ZPL. 
>   We just wouldn't do _new_ things under a ZPL.
> 
> This is part of the safety of joint ownership.  If you don't like what 
> we do in the future, you still have rights on your contribution

This prospect (of future ZC code being non-ZPL), while remote, is why I
beleive that it is important that the ZPL be GPL-compatible.

In that scenario (and I stress again that I think it is unlikely), where
future ZC development was proprietary and unavailable to the community,
it's important that it be possible for the community to respond by
making subsequent community contributed code GPL, and therefore
unavailable to proprietary vendors (trhis includes the hypothetical evil
mirror-universe ZC, who will all have beards).

Unless the ZPL is GPL-compatible (at least), this will not be possible,
as it is currently not possible to create GPL licensed products that
subclass ZPL'd Zope classes.

I am *not* advocating that the opening of the CVS repository be held up
for this, I just want to make sure that the goal of making the ZPL GPL
compatible remains on the agenda.

> > The "Commitrer Agreement" is quite threadening:
> > 
> >A committer takes over a considerable risk (complete warranty
> >and indemnification with respect to intellectual rights infringement).
> 
> Yes.  You can't make the risk disappear.  Someone has to bear the risk. 
>   It makes zero sense for ZC to bear the risk of what goes on in someone 
> else's brain.  Even in the scenario of carelessness, a case will have to 
> be made regarding what you knew and when you knew it.

This is another area where I agree with Paul. Publishers frequently
require authors to sign a 'warants and represents' clause that has the
same effect. *Good* publishers still cover legal costs for unsuccessful
lawsuits, so that the author isn't left hung out to dry when someone
files a 'slapsuit'.

I think the same standard should be applied here.

> >Otherwise, commiting anything might easily ruin an individual.
> 
> 
> Instead, you'd prefer that it ruin ZC?  Or are you asserting that 
> somehow we could make it so that nobody would be held accountable?

The contributor should be held accountable in the event of a
*successful* lawsuit. but it isn't reasonable to expect an individual to
have to defend against frivolous lawsuits from large corporations.

> >Especially with the strange US Patent Laws (where almost
> >everything (such as presenting information in a popup window
> >or integrating a Web Frontend with a baking oven) can
> >be patented) and incredibly high damages amounts
> >(5 billion for a smoker who got cancer) assigned in US courts.
> 
> Unfortunately that's the jurisdiction in which we operate.

Thankfuly, our legal jurisdiction also has provisions for countersuing
those who engage in underhanded legal tactics (such as slapsuits) for
legal costs and damages, but a large corporation can still bankrupt an
individual, making that option 

[Zope-dev] Z SQL Methods appear broken in 2.4.x

[Joseph J Wolff]

It appears that Z SQL Methods are broken in 2.4.x.

Specifically, the type=string in a  is broken -

a simple ZSQL query such as:

select id, cost, name
from choices
where name = 

results in the following error:

exceptions.NameError: global name 'string' is not defined

It's broken on 2.4.0 and 2.4.1, and works fine on 2.2.5, 2.3.0, and 2.3.2 -
in fact, it's in production on our 2.2.5.

Integer parameters work fine.

It's hard to believe that no one else has run into this, and that the stable
2.4.x branch has gotten this far without anyone noticing this - I've even
tried it on 2 different servers running Zope 2.4 (2.4.1 on FreeBSD 4.0, our
production web server, and 2.4.0 on FreeBSD 4.3, our dev server)

Any ideas?

Regards,
joe

Joseph J Wolff
eRacks Open Source Rackmount Systems
www.eracks.com
[EMAIL PROTECTED]



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] how to accept an arbitrary parameter/anti-NIMDA script

[Florent Guillaume]

You can use a **kw argument in a Python Script.

Florent Guillaume
Nuxeo

marc lindahl  <[EMAIL PROTECTED]> wrote:
> I'm looking at how to get this anti-NIMDA script to work in zope (
> http://pc.xs4all.nl/default.ida)
> 
> The thing is, it's called with a parameter (trying to cause a buffer
> overflow).   For example:
> 
> 
> /default.ida?XXX
> 
> 
> X%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%
> u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u%u00=a
> 
> 
> That site has a default.ida which will pass back a perlscript that turns off
> that particular machine's virus under certain cases... sounds like a good
> thing.  But how can I get an object called default.ida to accept anything
> passed after the "?" and what kind of object (python script?) should it be?
> 
> 
> ___
> Zope-Dev maillist  -  [EMAIL PROTECTED]
> 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 )
> 


-- 
Florent Guillaume, Nuxeo SARL (Paris, France)
+33 1 40 33 79 87  http://nuxeo.com  mailto:[EMAIL PROTECTED]

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

[Zope-dev] Zope 2.5: User limit for Local Security Role assignment list

[Matthew T. Kromer]

One of the things Zope 2.5 is going to do is limit the answers that are 
available from a user folder when presenting the local role dialog; this 
will prevent humongous lists from displaying and instead show a simple 
text box where a user ID can be typed.

However, for existing user folders, this poses a question of:  what's 
the reasonable number of users to list without having to go adjust a 
property on the folder?

The revised implementation will let you tune how many users to display 
before putting up an input box; but currently I've just defaulted it to 
'old behavior' -- ie show all the possible users.  Maybe a better thing 
to do would be to define a  default of 250 or so.  This would probably 
be large enough to not impact most sites, yet small enough to make it 
meaningful for those sites that do have enormous user folders.

It is also worth pointing out that local role assignment code doesn't 
enforce that the users for whom it has local roles exist in any current 
database; it is possible to grant rights to nonexistent users.  Before 
the ability to enter a name in directly was available, you would have 
had to explicitly change the form values manually -- but this exposes 
the problem.  I dont think it poses a problem (ie I dont believe Zope 
has ever tried to define a mechanism whereby objects are notified that a 
user for whom they have permissions has been deleted.)



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

[Zope-dev] how to accept an arbitrary parameter/anti-NIMDA script

[marc lindahl]

I'm looking at how to get this anti-NIMDA script to work in zope (
http://pc.xs4all.nl/default.ida)

The thing is, it's called with a parameter (trying to cause a buffer
overflow).   For example:


/default.ida?XXX


X%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%
u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u%u00=a


That site has a default.ida which will pass back a perlscript that turns off
that particular machine's virus under certain cases... sounds like a good
thing.  But how can I get an object called default.ida to accept anything
passed after the "?" and what kind of object (python script?) should it be?


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

[Zope-dev] Re: [DISCUSS] Committer agreement not even handed and threadening

[Paul Everitt]

Dieter Maurer wrote:

> Paul Everitt writes:
>  
> 
> The "Committer Agreement" does not seem to be even handed:
> 
>The committer transfers rights immediately and indefinitely
>to Zope Corporation (the contributions become a gift to
>Zope Corporation).


This is an inaccurate representation.  Transfer means you lose the 
rights and we gain the rights.  Under joint ownership, both have rights. 
  I think this point was abundantly clear, so I'm surprised to see you 
portray this as a gift.

>The agreement states explicitly that no rights are transfered
>to the committer.


Because they never lost any rights.


>This is not a problem in itself. However
> 
>   My intention to contribute would be to strengthen
>   the Open Source Movement. A statement that
>   the supported code base (Zope) will remain open source
>   and that committers will be able to use it (indefinitely)
>   under terms comparable to the current ZPL would
>   help to let the agreement to appear more balanced


I don't think it's really feasible to 100% guarantee things in the 
future.  Rather, the agreement states that current code, and any 
contribution, will be available under the ZPL.  Nothing can be 
retracted.  If someone comes along and gives us one trillion dollars to 
stop releasing our work as open source, two things would happen:

1) First, we'd take the money. :^)

2) Second, all the existing code has to remain available under the ZPL. 
  We just wouldn't do _new_ things under a ZPL.


This is part of the safety of joint ownership.  If you don't like what 
we do in the future, you still have rights on your contribution.


> The "Commitrer Agreement" is quite threadening:
> 
>A committer takes over a considerable risk (complete warranty
>and indemnification with respect to intellectual rights infringement).


Yes.  You can't make the risk disappear.  Someone has to bear the risk. 
  It makes zero sense for ZC to bear the risk of what goes on in someone 
else's brain.  Even in the scenario of carelessness, a case will have to 
be made regarding what you knew and when you knew it.


>The risk is far higher than that of a (german) employee.
>German employment law recognizes that
> 
>  *  all people make (sometimes) errors
>  *  coping with isolated errors is far easier for
> a larger community (the big employer) than
>   a single individual.
> 
>Therefore, it uses the term "Fahrlässigkeit" (carelessness).
>An employee has to take all care to not make errors during
>his work. If something bad happens due to slight
>carelessness (leicht fahrlässig), then this is
>a general risk which has to be taken by the employer.
>If serious carelessness (grob fahrlässig) was the cause,
>then the employee has to take the consequences for himself.

 >

>We should have something similar for the committer agreement
>(not restricted to intellectual property rights!).

 >

>Maybe something like an insurance for slight carelessness
>cases...


Unfortunately we'd have to be the insurer. :^(


>Otherwise, commiting anything might easily ruin an individual.


Instead, you'd prefer that it ruin ZC?  Or are you asserting that 
somehow we could make it so that nobody would be held accountable?


>Especially with the strange US Patent Laws (where almost
>everything (such as presenting information in a popup window
>or integrating a Web Frontend with a baking oven) can
>be patented) and incredibly high damages amounts
>(5 billion for a smoker who got cancer) assigned in US courts.


Unfortunately that's the jurisdiction in which we operate.


--Paul



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] testing types in PythonScripts

[Florent Guillaume]

Python Script has a same_type(x,y) function.

Florent Guillaume
Nuxeo


Steve Alexander  <[EMAIL PROTECTED]> wrote:
> I have a variable, f.
> 
> The value of f might be a list, or it might be a string.
> 
> I want to do different things to f depending what type it is.
> 
> How do I check its type from a PythonScript?
> 
> 
> I can't use type(), as this opens up a security hole with Extension 
> Classes, where the type is the class.
> 
> I can't import types, as that seems to be restricted.
> 
> 
> I suggest that either one or both of the following be altered:
> 
>   * The types module is allowed to be imported into restricted stuff.
> 
>   * A safe version of type() is put into the restricted global namespace.
> 
> 
> I seem to recall a discussion of this a few months ago, where someone 
> (Evan?) proposed a safe version of type(). I guess this got lost in the 
> conversion to RestrictedPython with Zope 2.4.
> 
> 
> Oh yeah... an ugly workaround is to try to append to f and see if you 
> get and AttributeError.
> 
> --
> Steve Alexander
> Software Engineer
> Cat-Box limited
> 
> 
> ___
> Zope-Dev maillist  -  [EMAIL PROTECTED]
> 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 )
> 


-- 
Florent Guillaume, Nuxeo SARL (Paris, France)
+33 1 40 33 79 87  http://nuxeo.com  mailto:[EMAIL PROTECTED]

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] Zope on Windows/Mac OS X: BatteriesIncludedDistribution

[Paul Everitt]

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.

--Paul

Richard Jones wrote:

> I've just created the follwing fishbowl proposal:
> 
>   http://dev.zope.org/Wikis/DevSite/Proposals/BatteriesIncludedDistribution
> 
> Please read and comment.
> 
> 
> Richard
> 
> ___
> Zope-Dev maillist  -  [EMAIL PROTECTED]
> 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 )
> 




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

[Zope-dev] testing types in PythonScripts

[Steve Alexander]

I have a variable, f.

The value of f might be a list, or it might be a string.

I want to do different things to f depending what type it is.

How do I check its type from a PythonScript?


I can't use type(), as this opens up a security hole with Extension 
Classes, where the type is the class.

I can't import types, as that seems to be restricted.


I suggest that either one or both of the following be altered:

  * The types module is allowed to be imported into restricted stuff.

  * A safe version of type() is put into the restricted global namespace.


I seem to recall a discussion of this a few months ago, where someone 
(Evan?) proposed a safe version of type(). I guess this got lost in the 
conversion to RestrictedPython with Zope 2.4.


Oh yeah... an ugly workaround is to try to append to f and see if you 
get and AttributeError.

--
Steve Alexander
Software Engineer
Cat-Box limited


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] KeyError on UnIndex.keyForDocument

[Florent Guillaume]

I had something like that. It turned out that I was doing a catalog
query, sorting on an index that didn't exist on some of the objects.
I made sure the index existed on all my objects.
But still I'd be inclined to consider this a bug.

Florent Guillaume
Nuxeo


Morten W. Petersen <[EMAIL PROTECTED]> wrote:
> Hia,
> 
> While trying to reindex an entire catalog an error is raised, which looks
> like this:
> 
> Traceback (innermost last):
>   File
> /home/morten/zope_instances/usr2/local/Zope-bcr/lib/python/ZPublisher/Publish.py,
> line 223, in publish_module
>   File
> /home/morten/zope_instances/usr2/local/Zope-bcr/lib/python/ZPublisher/Publish.py,
> line 187, in publish
>   File
> /home/morten/zope_instances/usr2/local/Zope-bcr/lib/python/Zope/__init__.py,
> line 221, in zpublisher_exception_hook
> (Object: api)
>   File
> /home/morten/zope_instances/usr2/local/Zope-bcr/lib/python/ZPublisher/Publish.py,
> line 171, in publish
>   File
> /home/morten/zope_instances/usr2/local/Zope-bcr/lib/python/ZPublisher/mapply.py,
> line 160, in mapply
> (Object: update_instances)
>   File
> /home/morten/zope_instances/usr2/local/Zope-bcr/lib/python/ZPublisher/Publish.py,
> line 112, in call_object
> (Object: update_instances)
>   File
> 
>/home/morten/zope_instances/usr2/local/Zope-bcr/lib/python/Products/WarpFramework/catalog.py,
> line 438, in update_instances
> (Object: api)
>   File
> 
>/home/morten/zope_instances/usr2/local/Zope-bcr/lib/python/Products/WarpFramework/catalog.py,
> line 195, in __call__
> (Object: Traversable)
>   File
> 
>/home/morten/zope_instances/usr2/local/Zope-bcr/lib/python/Products/ZCatalog/ZCatalog.py,
> line 535, in searchResults
> (Object: Traversable)
>   File
> 
>/home/morten/zope_instances/usr2/local/Zope-bcr/lib/python/Products/ZCatalog/Catalog.py,
> line 666, in searchResults
>   File
> 
>/home/morten/zope_instances/usr2/local/Zope-bcr/lib/python/Products/ZCatalog/Catalog.py,
> line 614, in _indexedSearch
>   File
> /home/morten/zope_instances/usr2/local/Zope-bcr/lib/python/SearchIndex/UnIndex.py,
> line 453, in keyForDocument
> KeyError: (see above)
> 
> 
> Any clues?
> 
> Thanks a whole bunch,
> 
> Morten
> 
> 
> ___
> Zope-Dev maillist  -  [EMAIL PROTECTED]
> 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 )
> 


-- 
Florent Guillaume, Nuxeo SARL (Paris, France)
+33 1 40 33 79 87  http://nuxeo.com  mailto:[EMAIL PROTECTED]

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

[Zope-dev] python 2 Win32 binary for LocalFS

[kent sin]

Does anyone have the win32wnet.pyd work with python2?

Can someone upgrade the localfs product? Or are there
better replacement available?

Rgs,

Kent Sin

__
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

SV: [Zope-dev] Web Services for Zope

[Magnus Heino (Rivermen)]

> Well... the status is that I'm trying to work on it on an 
> as-possible basis :) The problem is that it hasn't been very 
> possible for the last few weeks.
> 
> If you just need to generate WSDL and you're willing to live 
> on the bleeding edge and use some code that might still change 
> a lot in the future to get the job done, let me know and I'll 
> be happy to send you a snapshot of what I have...

Why don't you put into the public CVS instead?

/Magnus

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )