From noreply at sourceforge.net Thu May 1 07:47:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu May 1 07:47:22 2003 Subject: [Moin-devel] [ moin-Bugs-730805 ] Poor performance on SystemInfo macro (thus, RecentChanges) Message-ID: Bugs item #730805, was opened at 2003-05-01 10:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=730805&group_id=8482 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Hagner (chagner) Assigned to: Nobody/Anonymous (nobody) Summary: Poor performance on SystemInfo macro (thus, RecentChanges) Initial Comment: We've been using our wiki for about a year and a half. The event log has obviously gotten quite large (~24MB). As a result, the RecentChanges page has gotten slower and slower. After looking into the SystemInfo macro (used at the top of the RecentChanges page), I saw that the entire event log file is read line-by-line (and each line is fully parsed! ugh) simply so that the SystemInfo macro can report the number of entries. Can you make this more efficient/practical? ie.. add a numEvents( ) method to eventlog.py that more efficiently provides this info. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=730805&group_id=8482 From noreply at sourceforge.net Fri May 2 03:59:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri May 2 03:59:54 2003 Subject: [Moin-devel] [ moin-Bugs-730805 ] Poor performance on SystemInfo macro (thus, RecentChanges) Message-ID: Bugs item #730805, was opened at 2003-05-01 16:46 Message generated for change (Comment added) made by jhermann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=730805&group_id=8482 Category: None Group: None >Status: Closed >Resolution: Later Priority: 5 Submitted By: Chris Hagner (chagner) Assigned to: Nobody/Anonymous (nobody) Summary: Poor performance on SystemInfo macro (thus, RecentChanges) Initial Comment: We've been using our wiki for about a year and a half. The event log has obviously gotten quite large (~24MB). As a result, the RecentChanges page has gotten slower and slower. After looking into the SystemInfo macro (used at the top of the RecentChanges page), I saw that the entire event log file is read line-by-line (and each line is fully parsed! ugh) simply so that the SystemInfo macro can report the number of entries. Can you make this more efficient/practical? ie.. add a numEvents( ) method to eventlog.py that more efficiently provides this info. Thanks. ---------------------------------------------------------------------- >Comment By: J?rgen Hermann (jhermann) Date: 2003-05-02 12:52 Message: Logged In: YES user_id=39128 You have to rotate or delete the event.log on a regular basis. There'll be no immediate resolution. RC is influenced by editlog, not event.log. If you have many edits, that has to be rotated, too (don't delete it). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=730805&group_id=8482 From noreply at sourceforge.net Fri May 2 04:23:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri May 2 04:23:01 2003 Subject: [Moin-devel] [ moin-Bugs-730805 ] Poor performance on SystemInfo macro (thus, RecentChanges) Message-ID: Bugs item #730805, was opened at 2003-05-01 16:46 Message generated for change (Comment added) made by jhermann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=730805&group_id=8482 Category: None Group: None Status: Closed Resolution: Later Priority: 5 Submitted By: Chris Hagner (chagner) Assigned to: Nobody/Anonymous (nobody) Summary: Poor performance on SystemInfo macro (thus, RecentChanges) Initial Comment: We've been using our wiki for about a year and a half. The event log has obviously gotten quite large (~24MB). As a result, the RecentChanges page has gotten slower and slower. After looking into the SystemInfo macro (used at the top of the RecentChanges page), I saw that the entire event log file is read line-by-line (and each line is fully parsed! ugh) simply so that the SystemInfo macro can report the number of entries. Can you make this more efficient/practical? ie.. add a numEvents( ) method to eventlog.py that more efficiently provides this info. Thanks. ---------------------------------------------------------------------- >Comment By: J?rgen Hermann (jhermann) Date: 2003-05-02 13:16 Message: Logged In: YES user_id=39128 Do you have the SystemInfo macro still remaining on the RC page?! Remove it, it's long gone from the master RC page for this exact reason. ---------------------------------------------------------------------- Comment By: J?rgen Hermann (jhermann) Date: 2003-05-02 12:52 Message: Logged In: YES user_id=39128 You have to rotate or delete the event.log on a regular basis. There'll be no immediate resolution. RC is influenced by editlog, not event.log. If you have many edits, that has to be rotated, too (don't delete it). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=730805&group_id=8482 From noreply at sourceforge.net Tue May 13 00:46:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue May 13 00:46:10 2003 Subject: [Moin-devel] [ moin-Patches-736885 ] Identify users using client certificates Message-ID: Patches item #736885, was opened at 2003-05-13 09:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=308482&aid=736885&group_id=8482 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. L?wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Identify users using client certificates Initial Comment: This patch allows to identifiy Moin users using SSL client certificates. Specifically, it uses the common name and the email address from the cerificate's subject's distinguished name. Cookies and Moin user ids are still used, and finding users works like this 1. If there is a cookie, use that 2. If there is no cookie, iterate over all users, and try to find one with the same email address or where the X.509 common name is the same as the Moin user name. 3. If no user is found, but either the email address or the common name is set, create a new user. This patch works only with Apache mod_ssl, as it relies on the environment variables SSL_CLIENT_S_DN* being set. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=308482&aid=736885&group_id=8482 From noreply at sourceforge.net Mon May 19 14:21:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon May 19 14:21:06 2003 Subject: [Moin-devel] [ moin-Bugs-740110 ] hardcoded values Message-ID: Bugs item #740110, was opened at 2003-05-19 17:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=740110&group_id=8482 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Drucker (placain) Assigned to: Nobody/Anonymous (nobody) Summary: hardcoded values Initial Comment: There still exist many places where things like 'FrontPage' are hardcoded instead of using their proper config values (in that case, page_front_page). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=740110&group_id=8482 From dona at lovemenu.com Tue May 27 04:53:11 2003 From: dona at lovemenu.com (dona at lovemenu.com) Date: Tue May 27 04:53:11 2003 Subject: [Moin-devel] =?euc-kr?B?o6ixpLDto6m1pcDMxq4sILnMxsMgLSC4uLOywMcgsaTA5Q==?= Message-ID: .. ?????? [click to see ] "?? ???? ??? ???? ?? ??? ???" "??? ?? ??? ???." "? ?? ??? ??? ????? ?????" "? ? ??? ??????, ????? ???? ???..." ???? * ? ????? ????? ??? ???? ???? ??[???], [???], [???], ???[???]? ??? ????? ?? ??? ???? ?? ???? ???? ??? ???? ??? ??? ????? ??, ??, ??, ????? ????? ??? ???? ???? ????? ? ? ?? ??? ??? ???. ??????? www.mygal.co.kr ???. ??? - ? ??? ??? ?? ?? ????? ?????? ? ?? ???. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgd-karolinali at algonet.se Thu May 29 04:13:02 2003 From: pgd-karolinali at algonet.se (Karolina Lindqvist) Date: Thu May 29 04:13:02 2003 Subject: [Moin-devel] case insensitive title index suggestion Message-ID: <200305291312.22652.pgd-karolinali@algonet.se> I have pages with start both with and upper case initial and a lower case. That causes the title index to have two groups for each letter, one for the upper case version and one for the lower case. A nice feature would to make the title index case-insensitive. As a stopgap, I changed the sort() call in _macro_TitleIndex() to use the following caseinsensitive_sort() function, which I found on the net, and it (+ one letter = letter.upper()) does the job def caseinsensitive_sort(list): tuplesList = [(x.upper(), x) for x in list] tuplesList.sort() return [x[1] for x in tuplesList] This is supposedly faster than using a compare function to sort(). Karolina From magnus at thinkware.se Thu May 29 17:00:04 2003 From: magnus at thinkware.se (Magnus =?iso-8859-1?Q?Lyck=E5?=) Date: Thu May 29 17:00:04 2003 Subject: [Moin-devel] case insensitive title index suggestion In-Reply-To: <200305291312.22652.pgd-karolinali@algonet.se> Message-ID: <5.2.1.1.0.20030530015112.00b81e10@www.thinkware.se> At 13:12 2003-05-29 +0200, Karolina Lindqvist wrote: >I have pages with start both with and upper case initial and a lower case. >That causes the title index to have two groups for each letter, one for the >upper case version and one for the lower case. A nice feature would to make >the title index case-insensitive. > >As a stopgap, I changed the sort() call in _macro_TitleIndex() to use the >following caseinsensitive_sort() function, which I found on the net, and it >(+ one letter = letter.upper()) does the job > >def caseinsensitive_sort(list): > tuplesList = [(x.upper(), x) for x in list] > tuplesList.sort() > return [x[1] for x in tuplesList] > >This is supposedly faster than using a compare function to sort(). Yes, using l.sort(some_python_function) is slow, since it the fast C-based sort function has to call the Python function over and over again. But your sort won't do the right thing, even it its better than a plain sort. >>> l = ['Hej', 'allan', '?ke', '?sten', '?rling'] >>> l.sort() >>> for n in l: print n, ... Hej allan ?rling ?sten ?ke >>> l.sort(lambda x, y: cmp(x.upper(), y.upper())) >>> for n in l: print n, ... allan Hej ?rling ?ke ?sten >>> At least 'a' came before 'H' now, but '?' should come before '?' in Sweden. >>> import locale >>> locale.setlocale(locale.LC_ALL, '') 'Swedish_Sweden.1252' >>> l.sort(locale.strcoll) >>> for n in l: print n, ... allan Hej ?ke ?rling ?sten The schwartzian transform is still useful, but the locale aware version would be (untested): import locale locale.setlocale(locale.LC_ALL, '') ... def locale_aware_sort(list): tuplesList = [(locale.strxfrm(x), x) for x in list] tuplesList.sort() return [x[1] for x in tuplesList] -- Magnus Lycka (It's really Lyckå), magnus at thinkware.se Thinkware AB, Sweden, www.thinkware.se I code Python ~ The shortest path from thought to working program From pgd-karolinali at algonet.se Thu May 29 22:57:07 2003 From: pgd-karolinali at algonet.se (Karolina Lindqvist) Date: Thu May 29 22:57:07 2003 Subject: [Moin-devel] case insensitive title index suggestion In-Reply-To: <5.2.1.1.0.20030530015112.00b81e10@www.thinkware.se> References: <5.2.1.1.0.20030530015112.00b81e10@www.thinkware.se> Message-ID: <200305300756.39239.pgd-karolinali@algonet.se> fredagen den 30 maj 2003 02.02 skrev Magnus Lyck?: > Yes, using l.sort(some_python_function) is slow, since it the fast > C-based sort function has to call the Python function over and over > again. But your sort won't do the right thing, even it its better > than a plain sort. I tried your version, and it works. thank you! Now my indexes are in right national order too. I just needed to make one modification. Since the cgi script has no national locale, i changed to: locale.setlocale(locale.LC_COLLATE, "sv_SE") I can do that, since all my wiki pages are in Swedish and a non Swedish-speaker can't read them anyway. Otherwise some more intelligent decision about the locale would have to be done. So, I have put the following in wikiutils.py: import locale locale.setlocale(locale.LC_COLLATE, "sv_SE") def locale_aware_sort(list): tuplesList = [(locale.strxfrm(x), x) for x in list] tuplesList.sort() return [x[1] for x in tuplesList] And whenever I need the national sort, I can call it with wikiutils.local_aware_sort(). There are some places here and there in Moin that benefits from this. Karolina From 0ihevsth at yahoo.com Thu May 29 23:28:03 2003 From: 0ihevsth at yahoo.com (Ali Nicholson) Date: Thu May 29 23:28:03 2003 Subject: [Moin-devel] DONETTA'S pics hgyicuqx Message-ID: <66wusq$5q32bz-g5@o1lg8> An HTML attachment was scrubbed... URL: