Tim Peters wrote:
If they have the .pyd files, they can run Zope and fix problems
they find in the .py files.
They have the .pyd files now. I'm keeping them up to date, and Max M wrote
a clear howto (which references the .pyd Zip files on zope.org):
[EMAIL PROTECTED] wrote:
More important is the second point: Having such a tool would bring a
HUGE amount of value added to Zope. Mega, super huge.
Sounds like the opportunity for a commercial tool.
It's not NEEDED, but it makes life a LOT easier, and so would give any company
with it
Dieter Maurer wrote:
An incredibly old problem. I wrote at least 2 threads about it
(one with Andreas Tille with about 10 messages).
Please search the mailing list archives ([EMAIL PROTECTED]), for details...
I tried:
http://www.google.com/search?q=site%3Alists.zope.org+dieter+andreas+zsql+-jung
Jim Fulton wrote:
We'll also have a top-level ZConfig project directory. The trunk
of the ZConfig Python package will be in ZConfig/trunk/src/ZConfig.
If we create a tag T1 of ZConfig, then the Python package for that tag
will be in ZConfig/tags/T1/src/ZConfig.
The /src/ in the above paths seems
Lennart Regebro wrote:
Well... Non-issue it is not. But it makes it much less of an issue. It
would still be nice to have server-side configurations of defalts, though.
Yeah, but from what Jim said, that's something the svn guys are aiming to do.
I guess the best thing would be to hassle/help
(cc'ing this to zope-dev in case this is of interest to them too)
Robin Becker wrote:
Chris Withers wrote:
Tim Peters wrote:
.
Cool :-)
Glad to find this one is a non-issue!
Chris
I hacked cvs2svn.py and seem to be getting it to look up the b tag in
place of the mime-types stuff which
Dieter Maurer wrote:
True. But if they are not planned to be fixed at all, then they should
be closed.
You risk to get less bug reports in the collector...
Filing a (good) bug report takes quite a bit of time.
When you have gotten rejections for several bug reports
(that took you
Ken Manheimer wrote:
Done. The piece you were missing is that the categories are actually
states in the collector_issue_workflow. I added a Wontfix state and a
refuse transition (bringing to a total of three the transitions by which
issues are dodged:), and hooked them into the existing
Chris Withers wrote:
Ken Manheimer wrote:
Done. The piece you were missing is that the categories are actually
states in the collector_issue_workflow. I added a Wontfix state and
a refuse transition (bringing to a total of three the transitions by
which issues are dodged:), and hooked them
--On Donnerstag, 6. Mai 2004 12:37 Uhr +0100 Chris Withers
[EMAIL PROTECTED] wrote:
Ken Manheimer wrote:
Done. The piece you were missing is that the categories are actually
states in the collector_issue_workflow. I added a Wontfix state and a
refuse transition (bringing to a total of three
Chris Withers wrote:
Jim Fulton wrote:
...
Now, when we set up the Zope 3 repository, we will create the ZConfig
package in Zope 3 by copying a *tag* from the ZConfig project:
svn copy svn+ssh://svn.zope.org/repos/ZConfig/tags/T1/src/ZConfig \
Well, I suspect the interest in this type of tool might be big enough
to allow for the open Source model to apply in an efficient manner ?
Depends on the skills required to bring it to life.
I've started using Eclipse lately, and I just love it, I've combined
PyDT/PyDEV + Subclipse + XMLBuddy
On Thu, 6 May 2004, Chris Withers wrote:
Chris Withers wrote:
Yay! Does this mean we have a fully functional wont fix state now?
It does appear to, woohoo!
Can we change the action name from Refuse to Won't Fix? I took a while to
find it...
All the actions are verbs, won't fix is
On Thu, 6 May 2004, Andreas Jung wrote:
--On Donnerstag, 6. Mai 2004 12:37 Uhr +0100 Chris Withers
[EMAIL PROTECTED] wrote:
Ken Manheimer wrote:
Done. The piece you were missing is that the categories are actually
states in the collector_issue_workflow. I added a Wontfix state and
From: Ken Manheimer [EMAIL PROTECTED]
All the actions are verbs, won't fix is not a verb. Can you suggest a
verb the more clearly indicates the result is won't fix?
Tough one...
Live with
Ignore
Keep this bug as is
Zenify
Featurize (as in This is not a bug, it's a feature)
Shove under
On Thu, 6 May 2004 10:45:03 -0400
Tim Peters [EMAIL PROTECTED] wrote:
[..]
On the Python bug tracker, I don't close vague bug reports instantly.
Instead I add a note, saying that unless more information is added,
the bug will be closed a month later. It's rare that more info gets
added then,
On Thu, 2004-05-06 at 11:56, Lennart Regebro wrote:
From: Ken Manheimer [EMAIL PROTECTED]
All the actions are verbs, won't fix is not a verb. Can you suggest a
verb the more clearly indicates the result is won't fix?
Tough one...
Live with
Ignore
Keep this bug as is
Zenify
On Thu, May 06, 2004 at 04:56:42PM +0200, Lennart Regebro wrote:
Featurize (as in This is not a bug, it's a feature)
That's my favorite bug-closing technique!
Closed works pretty well for that one, though in order
to really justify it I feel compelled to add comments,
docstrings, and/or help
hi
a call a method with this path:
/poll/question/answer/testMethod
in my poll class i defined a method which returns self.getId()
but it shows me always my poll ID not the expected answer id i
would like to access the id's like context.getId() does when working in
the ZMI (i am new to
Or maybe Deny as a action? Sounds less angry than reject and refuse.
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
Ken Manheimer wrote:
All the actions are verbs, won't fix is not a verb.
How about 'bikeshed'
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
No, that's not the problem;
in THEORY that's what is happening, but in reality there is no way that
this is the case;
We just unrolled a registration system with participation rates at or
around 100 to 200 participants per month;
At any given time, monitoring the session data container, there
Hi all,
Has anybody used ESI with zope ? I know that ESI support was added to
squid and the project was funded by Zope corporation. But I could not
find much information on the project after that. We are planing to
experiment with ESI for one of our projects and if required implement a
On Thu, 06 May 2004 12:09:18 -0300
Leonardo Rochael Almeida [EMAIL PROTECTED] wrote:
On Thu, 2004-05-06 at 11:56, Lennart Regebro wrote:
From: Ken Manheimer [EMAIL PROTECTED]
All the actions are verbs, won't fix is not a verb. Can you
suggest a verb the more clearly indicates the result
[Ken Manheimer]
All the actions are verbs, won't fix is not a verb. Can you
suggest a verb the more clearly indicates the result is won't
fix?
Sorry, I got lost on the first sentence: what difference does it make to
anything whether they're verbs, adjectives, a mix, ...? They're all just
I have used Squid 3's ESI with Zope... it works pretty well. There is
no support built in to Zope to generate ESI tags; you will either need
to include them in your templates or build a layer of indirection (maybe
through ZPT macros?) that knows to either render the full page or insert
ESI tags
On Thu, 6 May 2004, Lennart Regebro wrote:
From: Ken Manheimer [EMAIL PROTECTED]
All the actions are verbs, won't fix is not a verb. Can you suggest a
verb the more clearly indicates the result is won't fix?
Tough one...
Live with
Ignore
Keep this bug as is
Zenify
Featurize (as
On Thu, 6 May 2004, Leonardo Rochael Almeida wrote:
On Thu, 2004-05-06 at 11:56, Lennart Regebro wrote:
From: Ken Manheimer [EMAIL PROTECTED]
All the actions are verbs, won't fix is not a verb. Can you suggest a
verb the more clearly indicates the result is won't fix?
Tough one...
On Thu, 6 May 2004, Lennart Regebro wrote:
Or maybe Deny as a action? Sounds less angry than reject and refuse.
What's being denied - the request to fix the bug, or the validity of the
bug report? Refuse suggests only that we are refusing to fix the bug,
there's no implication that the bug
I've submitted two patches to the python patch collector
http://sourceforge.net/tracker/index.php?func=detailaid=949332group_id=5470atid=305470
is something that should probably work with any pthreads based Unix
implementation. It simply unblocks
the type of signals that are normally
Hi,
I'm doing some stuff using Zope as an XML-RPC server, and have come
across a rather interesting bug.
If the method doesn't exist on the Zope server, Zope returns an
xmlrpclib.Fault with a faultCode= -1.
This completely trips out my XML-RPC client which was rather expecting
an
I reported this a few month ago with a patch and was told that it'll be
applied 'soon':
http://collector.zope.org/Zope/1175
IMHO the xml-rpc error handling is a mess. You can't define your own
standard_error_message like method, sometimes it returns html code, sets
the status code to 200 even if
On 7/05/2004, at 5:15 AM, Kris Erickson wrote:
No, that's not the problem;
in THEORY that's what is happening, but in reality there is no way
that this is the case;
We just unrolled a registration system with participation rates at or
around 100 to 200 participants per month;
At any given time,
Michael Dunstan wrote:
On 7/05/2004, at 5:15 AM, Kris Erickson wrote:
No, that's not the problem;
in THEORY that's what is happening, but in reality there is no way
that this is the case;
We just unrolled a registration system with participation rates at or
around 100 to 200 participants per
On 7/05/2004, at 4:39 PM, Tres Seaver wrote:
Michael Dunstan wrote:
On 7/05/2004, at 5:15 AM, Kris Erickson wrote:
No, that's not the problem;
in THEORY that's what is happening, but in reality there is no way
that this is the case;
We just unrolled a registration system with participation rates
35 matches
Mail list logo