Re: [Zope3-dev] Doctest and Footnotes
On Jul 10, 2006, at 11:44 PM, Benji York wrote: ... I'd like to merge the branch to zope.testing in the next few days. Thoughts/questions? Sounds great. My main concern is the continued forking of doctest. :( I had intended to sync it up with Python 2.5, but I never did. I have no problem with continuing the fork for now. I'd really like to find a way to avoid the fork by either agreeing with Ed Loper and Tim to give docutils a life of it's own independent of Python releases, or find a way to add enhancements like this without forking doctutils. I'll bring this up with Ed and Tim. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The bug fixing problem
On 7/7/06, Julien Anguenot [EMAIL PROTECTED] wrote: Jim Fulton wrote: On Jul 7, 2006, at 9:45 AM, Julien Anguenot wrote: Hi there, Jim Fulton wrote: On Jul 5, 2006, at 5:46 AM, Christian Theune wrote: I'm sitting at EuroPython right now, and a small discussion came up, trying to find out why nobody seems motivated to fix bugs came up. Martijn Fassen noted that the tools we use should be better (I agree on that, especially making it easy to find which bugs need to be urgently fixed for the next release). Obviously that isn't a pure problem on it's own. There are certainly many problems with the current bug trackers, which were written several years ago. Finding out quickly which bugs need to be fixed for the next release isn't one of them. (Although discovering how to do this isn't obvious and could be trivially improved through configuration.) I tried to raise the discussion last year about this topic : http://mail.zope.org/pipermail/zope3-dev/2005-May/014588.html ... but didn't go far. I believe the bug tracker is certainly the most important tool for a project like Zope3. I wasn't suggesting that we couldn't use a better bug tracker. I understood your point. I just wanted to emphasis the fact that the bug tracker tool is more than critical. As a non committer I would like to note that it was easy for me to search if somebody already submitted a bug I found, and submit a new patch, it was also trivial to add the for the bugfix and the test. The only thing which IS still not easy is to find a way to see that patch appear in Zope itself. I marked the bug as bug + bugfix but nobody cares. That is much more discouraging than what I can not do nice wiki links to in my bugreport other bugtracker items or svn sources like it is possible in trac itself. Patrick ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: The bug fixing problem
Jim Fulton wrote: [snip] I would say that there are two bugs in the case you are describing: the one you meant to fix and the one which is the lack of any tests for the module / class / whatever. I would bet that spending your thirty minutes adding minimal tests to such a module is a *higher* value activity than fixing most bugs, because it makes it easier for you (or someone else) to fix that bug and others in that module. Good point. The PyPy project actually works with many tests that are not working. They have an infrastructure where such tests can be in the code and explicitly disabled. In some cases, the bug-reporter may be able to write a test and not fix it. Or, alternatively, the person who goes and tries to fix a bug can write tests but doesn't have time to fix them. In such case it would be nice to be able to add tests that are explicitly disabled and thus does not show up in the normal test run. Only when turning a knob these buggy tests show up, and a bug fixer can then easily go and try to fix them. One danger is that this can be used to temporarily disable tests that *used to work*. Then again, that's not hard to do now either. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The bug fixing problem
Jim Fulton wrote: On Jul 11, 2006, at 8:05 AM, Patrick Gerken wrote: ... As a non committer I would like to note that it was easy for me to search if somebody already submitted a bug I found, and submit a new patch, it was also trivial to add the for the bugfix and the test. The only thing which IS still not easy is to find a way to see that patch appear in Zope itself. I marked the bug as bug + bugfix but nobody cares. That is much more discouraging than what I can not do nice wiki links to in my bugreport other bugtracker items or svn sources like it is possible in trac itself. Well said. There are people who care. A few of us have biin working through the bugs. I wish more people were. (I'm stuck on a fairly hairy one myself.) Regardless of what tool we use, we need to be committed to not letting bug reports languish in the collector. Personally, I'd like to have a feature freeze until we've cleane dup *all* of the outstanding bugs, not just the critical ones. While I'm not against a period of time where we're committed to cleaning out bugs from the tracker, I find myself wondering whether that won't mean an indefinite feature freeze... Will that really get people more motivated to fix bugs? Better information for both developers and bug submitters and a better way to defer bugs for following releases might give us more flexibility and a better ability to select the issues we consider truly important and might increase our collective memory. The other suggestion I made elsewhere is the ability for developers to add breaking tests to the codebase (explicitly marked as such, and not normally run). This might make it easier for people who got halfway fixing a bug to let their knowledge not be lost, and might also make it easier for people to find bugs to fix (that already have tests!). Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The bug fixing problem
Martijn Faassen wrote: The other suggestion I made elsewhere is the ability for developers to add breaking tests to the codebase (explicitly marked as such, and not normally run). +1 -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 2.9 and Zope 3 i18n, more questions...
As an update... Hanno Schlichting wrote: - configurable language negotiation based on a set of registered extractors - extractors: browser language, cookie and URL segment All good... :-) (lemme know when it's ready ;-) ) (maybe member property but this is probably impossible in pure Zope3 right now) Well, this is something that each framework/project will probably do differently, but it'd be nice to be able to register just this rather than having to subclass and if-then-else the negotiation process... - possibility to restrict allowed languages, so one can force sites into English only mode or allow only a subset of available languages. isn't that just a special type of negotiation? - Automatic generation of Gettext mo files from all registered po files on server start or explicit refresh. I actually don't think this is a good idea anymore... the msgfmt tool provides lots of handy debugging info... - if time permits implement a tracker mode (this is the PTS term, Localizer has the same feature) which if turned on, collects and stores all yet untranslated messages. I'm working on this right now... This is the half-hearted implementation of the INegotiator, as it is even mentioned in the interface description. Right now there are two interfaces IUserPreferredLanguages and ILanguageAvailability of whom only the first one is used by the Negotiator, whose responsibility it should be to negotiate between the preferred and available languages. Indeed, I now have a translations class that implements ILanguageAvailability and ITranslationDomain as discussed in the other thread... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Doctest and Footnotes
Benji York wrote: Gary Poster had a really good idea a couple weeks ago: teach doctest about ReST-style footnotes. After some promising discussion on python-dev and Gary's endless begging :) I've merged my branch into zope.testing, I still have some TODO items to finish up in the near future, as well as contemplating an update to the doctest that will ship with Python 2.5. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] soap and ZSI 2.0 patch
Hi all, I recently had reason to check out and use the soap product for Zope3. I needed it to work with the 3.2 HTTPRequest/Response api (setResult instead of self._body or setBody), so I made the changes I saw . I also wanted/needed it to work with the ZSI 2.0rc2 that's out now, so I updated that as well. I've created a branch: svn://svn.zope.org/repos/main/soap/branches/baldtrol-patch-001 which has my updates to soap/publisher.py. All the tests still run just fine, and I used the extant documentation to build my SOAPView, so it seems to need no changes either. I think it was just the publisher. This being my first actual contribution though, I was wondering if someone could go over the publisher.py in the branch, and let me know if it looks alright, maybe offer suggestions if anything doesn't make sense. Thanks for any help! Pete -- All guilt is relative, loyalty counts, and never let your conscience be your guide. - Lucas Buck, American Gothic ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Unused local variable?
Hi. As far as I understand there is really a bug. The code should deal with the situation where msgid is a Message object. What it does right now is to look up a translation for that Message object in the translation domain of the current TranslationDomain (self). The line you mention is part of the code that should make sure that the Message object is looked up in its own domain instead, but as you noticed this never happens. There is even a test for this in tests/test_translationdomain.py testMessageIDTranslateForDifferentDomain but it seems, it doesn't find the problem. Hanno Chris Withers wrote: Hi All, Puzzling as to what this chunk of code: if msgid.domain != self.domain: util = getUtility(ITranslationDomain, msgid.domain) ..from: http://svn.zope.org/Zope3/trunk/src/zope/i18n/translationdomain.py?rev=68771view=auto ...is supposed to do? util isn't used anywhere as far as I can see... ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Unused local variable?
On 7/11/06, Chris Withers [EMAIL PROTECTED] wrote: Puzzling as to what this chunk of code: if msgid.domain != self.domain: util = getUtility(ITranslationDomain, msgid.domain) I don't see it being used either. I suspect those two lines can be removed. :-) -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Every sin is the result of a collaboration. --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] session state issues
Folks,
I have what seems to be an odd problem with persistence of information
in simultaneous sessions.
I keep track of an iterator in an object that is persistent (one
instance per-session). The iterator is updated as the user navigates a
sequence of objects. The iteration seems to work fine for a single user.
If 2 users A and B access the system simultaneously, each users
navigation is occasionally thrown off (ie: the session seems to lose
track of the iterator state). Mysteriously, this doesn't always
happen - most of the time, users can navigate without issue.
What might be going on here? My session object access looks sort of
like this:
session = ISession(self.request)[APP_NAME]
# I checked; session appears to be unique for each user
# initialize per-session hash
if not session.has_key('iterdata'): session['iterdata'] = {}
# store iterator; FolderIterator has a currentId member.
if not session['iterdata'].has_key(uniqueName):
session['iterdata'][uniqueName] = FolderIterator()
return session['iterdata'][uniqueName]
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
