
There is a problem with Topic regexps.
The regexp entry is compiled in re.VERBOSE mode. This can be good, but also causes problems as the 'help' doesn't mention this. Further, the description says 'Topic keywords, one per line, to match against each message.' The implication is if I put
one two three
in the regexp box, that this topic will match keywords 'one', 'two' or 'three', but actually it matches only 'onetwothree'.
I see several ways to address this.
change the processing of this field to effectively join the lines with '|' - presumably this will break existing multiline entries, but possibly they (at least ones which already contain '|') can be converted.
do 1) as a list or mm_cfg option which defaults to not doing it.
change the description and help for the regexp to correctly reflect what happens.
What do others think?
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On Tue, 2006-05-23 at 08:00 -0700, Mark Sapiro wrote:
I have a hard time imagining that anyone would enter
one two three
and not expect it to match 'one|two|three', so I think I'd opt for 1. I'm not in favor of yet another configuration variable to control this. OTOH, I've never really received much feedback on the whole topics features (thus the dearth of responses to your question ;) so I don't really have a good sense of how people are using this, if they are at all.
I'm not sure the verbose interpretation of the text box is the most useful. The other option is to use some special prefix character at the front of the regexp to indicate whether it should be verbose or not. It would have to be something that is impossible in the first position, and it seems like | would be a good choice. Thus if | were in the first position, you'd interpret that to mean each line should be joined with | but if not, then you interpret the entire regexp as a verbose pattern.
Thoughts? -Barry

At 1:12 PM -0400 2006-05-24, Barry Warsaw wrote:
That's what I would have expected, and I was very surprised to
hear Mark's explanation that this didn't actually happen.
I think the concept is a good one, and on busy lists I would
gladly subscribe to a few topics and leave the rest, but I think it needs some additional work before we can get to the point where I'd actually use it. For one thing, you need a way of explicitly selecting the null topic.
Not understanding what a "verbose pattern" is, I'm not really
fully understanding this concept.
I can say that I think it would be pretty wild to come across a
new twist in variable regexps like this, after twenty or so years of mucking about with Unix, etc....
-- Brad Knowles, <brad@stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
LOPSA member since December 2005. See <http://www.lopsa.org/>.

At 8:33 PM -0700 2006-05-25, Mark Sapiro wrote:
There is currently a user option to receive (or not) all posts which don't match any topic. Is this what you mean?
Yurffhh.
/me removes foot from mouth
Yes.
/me reinserts food
-- Brad Knowles, <brad@stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
LOPSA member since December 2005. See <http://www.lopsa.org/>.

Hi folks,
I'm not sure if this is the right list for this... if so, I apologize, and please let me know where to get support on this.
I'm running Mailman on a linux/cpanel server, and trying to hack together an invite_members script, so I took add_members and made minor changes, mostly changing
mlist.ApprovedAddMember(userdesc, ack, 0)
to
mlist.InviteNewMember(userdesc)
I'm not sure if that's the correct way to call InviteNewMember, but it worked, mostly... the invite emails went out to some test addresses, but when I click the confirmation link I get:
Bug in Mailman version 2.1.6
We're sorry, we hit a bug!
Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs.
There's nothing recent in the error log, so I'm not sure what to do next.
Any help?
-Josh

Joshua Alexander wrote:
I'm not sure if this is the right list for this... if so, I apologize, and please let me know where to get support on this.
I think mailman-users@python.org is the appropriate list.
I'm running Mailman on a linux/cpanel server,
But maybe not. See <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.011.htp>.
Find the right Mailman error log. Look in both mm_cfg.py and Defaults.py for assignment to LOG_DIR (mm_cfg.py takes precedence).
Or edit the scripts/driver file and change
STEALTH_MODE = 1
to
STEALTH_MODE = 0
so the traceback will print on the web page.
Do other web confirmations work?
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Barry Warsaw wrote:
<snip>
I've thought about this some more and what I'm currently thinking is if the topic regexp is multiline, leave it as is in topics, but before compiling it for use, split the lines and then rejoin them with "|", and compile not in VERBOSE mode.
I think this would be the natural interpretation from the existing explanation.
Then, in order to handle existing multiline topic regexps without breaking them, add code to versions.py to test stored_state.data_version and if it's less than the appropriate value, go through topics and convert any multiline regexp to a single line by deleting unescaped whitespace and comments.
This seems to me to be more of a kludge than my idea of converting the old multiline regexps and just dropping verbose mode all together.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 5/25/06 8:29 PM, "Mark Sapiro" <msapiro@value.net> wrote:
I think you need to strip any trailing | characters from the strings in the resulting list before joining with |.
Otherwise, you might build one||two||three Which clearly isn't what is wanted.
Hmmm...I guess I mean "up to one trailing | character"...in case someone really wanted one||two for some really strange reason.
I think this would be the natural interpretation from the existing explanation.
I agree.
When we first installed a Mailman version with topic support, I messed around with it, and it didn't work. Since I didn't care much, I ignored the problem rather than figuring out what I was doing wrong. (This thread has made that obvious, of course.)
--John

John W. Baxter wrote:
I actually don't think that's necessary. My reasoning is that the descriptions imply that multiple lines are joined with "|" without having to explicitly put "|" in the pattern. The changes I intend to put in Mailman 2.2 will include code in versions.py to convert all presumably working multi-line patterns (verbose mode) into a single line equivalent, non-verbose pattern. Thus, an existing topics regexp such as 'one|\ntwo|\nthree' will be converted during the 2.1.x to 2.2 upgrade into 'one|two|three'. Thus the new code in Tagger.py will not see multiple lines and won't change the pattern at all. So the only future multi-line patterns will be new ones and presumably the person creating them will not be motivated to put trailing "|" on the lines and if he/she does anyway, testing should reveal that is wrong. This leads me to the next question. I have written Mailman.Utils.strip_verbose_pattern() to strip comments and whitespace from a verbose pattern and return a single-line, non-verbose equivalent. I think the thing to do with existing topics is the following: --- versions.py (revision 7905) +++ versions.py (working copy) @@ -307,6 +307,16 @@ pass else: l.digest_members[k] = 0 + # + # Convert pre 2.2 topics regexps whice were compiled in verbose mode + # to a single line, non-verbose equivalent. + # + if stored_state.data_version <= 97 and hasattr(stored_state, 'topics')\ + and stored_state.topics: + l.topics = [] + for name, pattern, description, emptyflag in stored_state.topics: + pattern = Utils.strip_verbose_pattern(pattern) + l.topics.append((name, pattern, description, emptyflag)) I'm not 100% comfortable with this for two reasons. The first is that this is apparently the only thing in versions.py which will reference an actual data_version. It seems OK, but I wonder if there is a better way. The other discomfort is list admins may be confused by the fact that their nicely commented, pretty, verbose topic regexp turned into an uncommented, ugly, non-verbose regexp. I actually think this is the least evil way to address this problem, but I'm still not 100% comfortable with it. Thoughts, comments, other ideas? -- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Mark Sapiro wrote:
Testing reveals the above patch is not correct because stored_state is a dictionary, not a list instance, but the logic is correct. -- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I agree that one|two|three makes more sense than onetwothree. I certainly would have expected the former.
On 24-May-06, at 1:12 PM, Barry Warsaw wrote:
Just for the record, linuxchix actually does use the topics on one of our lists (used for courses, so we don't have to set up a new list anytime someone wants to give a few lessons on a subject) and I haven't gotten any complaints from our users aside from the odd "please make sure you've got the right subject tag for this course!" stuff.
Of course, this could mean that no one uses the topic functionality
'cause they'd rather use clever mutt rules to organize their mail. ;)
But I'll assume that the lack of comment on a list that's been running
for years is probably a good sign that the topic parser does its job.
My only problem with the topics came when I had to explain it to users who might not understand regular expressions. Never was terribly satisfied with this one: http://list.org/mailman-member/node30.html
Terri -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin)
iD8DBQFEfH8kYWvHDqWmQaoRAiF8AJ9r+25W9TEZUJ3u00p6SQCdpR7otgCgvanz o0MZkqzjx/zHIMMEFNZcAOo= =ZsSL -----END PGP SIGNATURE-----

On Tue, 2006-05-23 at 08:00 -0700, Mark Sapiro wrote:
I have a hard time imagining that anyone would enter
one two three
and not expect it to match 'one|two|three', so I think I'd opt for 1. I'm not in favor of yet another configuration variable to control this. OTOH, I've never really received much feedback on the whole topics features (thus the dearth of responses to your question ;) so I don't really have a good sense of how people are using this, if they are at all.
I'm not sure the verbose interpretation of the text box is the most useful. The other option is to use some special prefix character at the front of the regexp to indicate whether it should be verbose or not. It would have to be something that is impossible in the first position, and it seems like | would be a good choice. Thus if | were in the first position, you'd interpret that to mean each line should be joined with | but if not, then you interpret the entire regexp as a verbose pattern.
Thoughts? -Barry

At 1:12 PM -0400 2006-05-24, Barry Warsaw wrote:
That's what I would have expected, and I was very surprised to
hear Mark's explanation that this didn't actually happen.
I think the concept is a good one, and on busy lists I would
gladly subscribe to a few topics and leave the rest, but I think it needs some additional work before we can get to the point where I'd actually use it. For one thing, you need a way of explicitly selecting the null topic.
Not understanding what a "verbose pattern" is, I'm not really
fully understanding this concept.
I can say that I think it would be pretty wild to come across a
new twist in variable regexps like this, after twenty or so years of mucking about with Unix, etc....
-- Brad Knowles, <brad@stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
LOPSA member since December 2005. See <http://www.lopsa.org/>.

At 8:33 PM -0700 2006-05-25, Mark Sapiro wrote:
There is currently a user option to receive (or not) all posts which don't match any topic. Is this what you mean?
Yurffhh.
/me removes foot from mouth
Yes.
/me reinserts food
-- Brad Knowles, <brad@stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
LOPSA member since December 2005. See <http://www.lopsa.org/>.

Hi folks,
I'm not sure if this is the right list for this... if so, I apologize, and please let me know where to get support on this.
I'm running Mailman on a linux/cpanel server, and trying to hack together an invite_members script, so I took add_members and made minor changes, mostly changing
mlist.ApprovedAddMember(userdesc, ack, 0)
to
mlist.InviteNewMember(userdesc)
I'm not sure if that's the correct way to call InviteNewMember, but it worked, mostly... the invite emails went out to some test addresses, but when I click the confirmation link I get:
Bug in Mailman version 2.1.6
We're sorry, we hit a bug!
Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs.
There's nothing recent in the error log, so I'm not sure what to do next.
Any help?
-Josh

Joshua Alexander wrote:
I'm not sure if this is the right list for this... if so, I apologize, and please let me know where to get support on this.
I think mailman-users@python.org is the appropriate list.
I'm running Mailman on a linux/cpanel server,
But maybe not. See <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.011.htp>.
Find the right Mailman error log. Look in both mm_cfg.py and Defaults.py for assignment to LOG_DIR (mm_cfg.py takes precedence).
Or edit the scripts/driver file and change
STEALTH_MODE = 1
to
STEALTH_MODE = 0
so the traceback will print on the web page.
Do other web confirmations work?
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Barry Warsaw wrote:
<snip>
I've thought about this some more and what I'm currently thinking is if the topic regexp is multiline, leave it as is in topics, but before compiling it for use, split the lines and then rejoin them with "|", and compile not in VERBOSE mode.
I think this would be the natural interpretation from the existing explanation.
Then, in order to handle existing multiline topic regexps without breaking them, add code to versions.py to test stored_state.data_version and if it's less than the appropriate value, go through topics and convert any multiline regexp to a single line by deleting unescaped whitespace and comments.
This seems to me to be more of a kludge than my idea of converting the old multiline regexps and just dropping verbose mode all together.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 5/25/06 8:29 PM, "Mark Sapiro" <msapiro@value.net> wrote:
I think you need to strip any trailing | characters from the strings in the resulting list before joining with |.
Otherwise, you might build one||two||three Which clearly isn't what is wanted.
Hmmm...I guess I mean "up to one trailing | character"...in case someone really wanted one||two for some really strange reason.
I think this would be the natural interpretation from the existing explanation.
I agree.
When we first installed a Mailman version with topic support, I messed around with it, and it didn't work. Since I didn't care much, I ignored the problem rather than figuring out what I was doing wrong. (This thread has made that obvious, of course.)
--John

John W. Baxter wrote:
I actually don't think that's necessary. My reasoning is that the descriptions imply that multiple lines are joined with "|" without having to explicitly put "|" in the pattern. The changes I intend to put in Mailman 2.2 will include code in versions.py to convert all presumably working multi-line patterns (verbose mode) into a single line equivalent, non-verbose pattern. Thus, an existing topics regexp such as 'one|\ntwo|\nthree' will be converted during the 2.1.x to 2.2 upgrade into 'one|two|three'. Thus the new code in Tagger.py will not see multiple lines and won't change the pattern at all. So the only future multi-line patterns will be new ones and presumably the person creating them will not be motivated to put trailing "|" on the lines and if he/she does anyway, testing should reveal that is wrong. This leads me to the next question. I have written Mailman.Utils.strip_verbose_pattern() to strip comments and whitespace from a verbose pattern and return a single-line, non-verbose equivalent. I think the thing to do with existing topics is the following: --- versions.py (revision 7905) +++ versions.py (working copy) @@ -307,6 +307,16 @@ pass else: l.digest_members[k] = 0 + # + # Convert pre 2.2 topics regexps whice were compiled in verbose mode + # to a single line, non-verbose equivalent. + # + if stored_state.data_version <= 97 and hasattr(stored_state, 'topics')\ + and stored_state.topics: + l.topics = [] + for name, pattern, description, emptyflag in stored_state.topics: + pattern = Utils.strip_verbose_pattern(pattern) + l.topics.append((name, pattern, description, emptyflag)) I'm not 100% comfortable with this for two reasons. The first is that this is apparently the only thing in versions.py which will reference an actual data_version. It seems OK, but I wonder if there is a better way. The other discomfort is list admins may be confused by the fact that their nicely commented, pretty, verbose topic regexp turned into an uncommented, ugly, non-verbose regexp. I actually think this is the least evil way to address this problem, but I'm still not 100% comfortable with it. Thoughts, comments, other ideas? -- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Mark Sapiro wrote:
Testing reveals the above patch is not correct because stored_state is a dictionary, not a list instance, but the logic is correct. -- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I agree that one|two|three makes more sense than onetwothree. I certainly would have expected the former.
On 24-May-06, at 1:12 PM, Barry Warsaw wrote:
Just for the record, linuxchix actually does use the topics on one of our lists (used for courses, so we don't have to set up a new list anytime someone wants to give a few lessons on a subject) and I haven't gotten any complaints from our users aside from the odd "please make sure you've got the right subject tag for this course!" stuff.
Of course, this could mean that no one uses the topic functionality
'cause they'd rather use clever mutt rules to organize their mail. ;)
But I'll assume that the lack of comment on a list that's been running
for years is probably a good sign that the topic parser does its job.
My only problem with the topics came when I had to explain it to users who might not understand regular expressions. Never was terribly satisfied with this one: http://list.org/mailman-member/node30.html
Terri -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin)
iD8DBQFEfH8kYWvHDqWmQaoRAiF8AJ9r+25W9TEZUJ3u00p6SQCdpR7otgCgvanz o0MZkqzjx/zHIMMEFNZcAOo= =ZsSL -----END PGP SIGNATURE-----
participants (6)
-
Barry Warsaw
-
Brad Knowles
-
John W. Baxter
-
Joshua Alexander
-
Mark Sapiro
-
Terri Oda