From manfred.lotz at arcor.de  Sun Apr  8 00:33:05 2012
From: manfred.lotz at arcor.de (Manfred Lotz)
Date: Sun, 8 Apr 2012 06:33:05 +0200
Subject: [Moin-user] Load statistics
Message-ID: <20120408063305.55c6a634@arcor.com>

Hi there,
On http://moinmo.in there is a load statistics at the bottom of the
page like this:

Page.execute = 0.047s getACL = 0.003s init = 0.001s load_multi_cfg =
0.000s run = 0.141s send_page = 0.107s send_page_content = 0.048s total = 0.141s


How can this be activated?

-- 
Manfred





From reuterru at arcor.de  Sun Apr  8 02:37:17 2012
From: reuterru at arcor.de (Rudolf Reuter)
Date: Sun, 08 Apr 2012 08:37:17 +0200
Subject: [Moin-user] Load statistics
In-Reply-To: <20120408063305.55c6a634@arcor.com>
References: <20120408063305.55c6a634@arcor.com>
Message-ID: <4F81321D.3090404@arcor.de>

Hello Manfred,

in wikiconfig.py add:
     show_timings = True

Regards, Rudolf

Am 08.04.12 06:33, schrieb Manfred Lotz:
> Hi there,
> On http://moinmo.in there is a load statistics at the bottom of the
> page like this:
>
> Page.execute = 0.047s getACL = 0.003s init = 0.001s load_multi_cfg =
> 0.000s run = 0.141s send_page = 0.107s send_page_content = 0.048s total = 0.141s
>
>
> How can this be activated?
>




From manfred.lotz at arcor.de  Sun Apr  8 05:42:20 2012
From: manfred.lotz at arcor.de (Manfred Lotz)
Date: Sun, 8 Apr 2012 11:42:20 +0200
Subject: [Moin-user] Load statistics
References: <20120408063305.55c6a634@arcor.com>
	<4F81321D.3090404@arcor.de>
Message-ID: <20120408114220.281ddad6@arcor.com>

On Sun, 08 Apr 2012 08:37:17 +0200
Rudolf Reuter <reuterru at arcor.de> wrote:

> Hello Manfred,
> 
> in wikiconfig.py add:
>      show_timings = True
> 

Thanks, Rudolf. That did it nicely.

-- 
Manfred





From manfred.lotz at arcor.de  Sun Apr  8 12:43:53 2012
From: manfred.lotz at arcor.de (Manfred Lotz)
Date: Sun, 8 Apr 2012 18:43:53 +0200
Subject: [Moin-user] How to list subpages
Message-ID: <20120408184353.47d6d787@arcor.com>

Hi all,
Is there a way to list all subpages of a specific page?


-- 
Manfred





From rb.proj at gmail.com  Sun Apr  8 13:54:22 2012
From: rb.proj at gmail.com (Reimar Bauer)
Date: Sun, 08 Apr 2012 19:54:22 +0200
Subject: [Moin-user] How to list subpages
In-Reply-To: <20120408184353.47d6d787@arcor.com>
References: <20120408184353.47d6d787@arcor.com>
Message-ID: <jlsjce$rc9$1@dough.gmane.org>

Am 08.04.2012 18:43, schrieb Manfred Lotz:
> Hi all,
> Is there a way to list all subpages of a specific page?
> 
> 

yes,

see PageList or ListPages or FullSearch

cheers
Reimar




From steve at einval.com  Sun Apr 15 15:44:34 2012
From: steve at einval.com (Steve McIntyre)
Date: Sun, 15 Apr 2012 20:44:34 +0100
Subject: [Moin-user]  Very slow page saving caused by notifications
Message-ID: <20120415194434.GO21276@einval.com>

Hi,

I've posted a bug at

  http://moinmo.in/MoinMoinBugs/SubscribedPagesPerformanceProblem

Quick summary:

On a site with a large number of registered users
(e.g. wiki.debian.org), saving a page taks a very long time. With a
large number of users, the design of the page subscription system
doesn't scale well. Saving a page works well, but moin then scans all
the user data files looking for the subscribed_pages data. With
thousands of users registered, this can take a very long time; we're
seeing > 90 seconds on a wiki with more than 10,000 users.

This area needs fixing in some way - maybe add a cache in front of the
user lookup here, or store the subscribed_pages information
differently. I might be able to help with coding this, but I'd want to
see what other people think first in terms of a design.

What do people think?

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...




From paul at boddie.org.uk  Sun Apr 15 16:18:07 2012
From: paul at boddie.org.uk (Paul Boddie)
Date: Sun, 15 Apr 2012 22:18:07 +0200
Subject: [Moin-user] Very slow page saving caused by notifications
In-Reply-To: <20120415194434.GO21276@einval.com>
References: <20120415194434.GO21276@einval.com>
Message-ID: <201204152218.07808.paul@boddie.org.uk>

On Sunday 15 April 2012 21:44:34 Steve McIntyre wrote:
>
> I've posted a bug at
>
>   http://moinmo.in/MoinMoinBugs/SubscribedPagesPerformanceProblem
>
> Quick summary:
>
> On a site with a large number of registered users
> (e.g. wiki.debian.org), saving a page taks a very long time. With a
> large number of users, the design of the page subscription system
> doesn't scale well. Saving a page works well, but moin then scans all
> the user data files looking for the subscribed_pages data. With
> thousands of users registered, this can take a very long time; we're
> seeing > 90 seconds on a wiki with more than 10,000 users.

I can see that the offending code is in MoinMoin/Page.py, specifically the 
getSubscribers method of the Page class. This looks like a classic case of 
needing to "invert" the way the data is stored so that it can be queried more 
efficiently - it's a bit like comparing the standard text search 
functionality with Xapian-based searching, where the former relies on 
scanning pages sequentially (pages yield terms), whereas the latter employs 
such "inverted" storage of queryable information (terms yield pages).

> This area needs fixing in some way - maybe add a cache in front of the
> user lookup here, or store the subscribed_pages information
> differently. I might be able to help with coding this, but I'd want to
> see what other people think first in terms of a design.
>
> What do people think?

I'd be inclined to index the subscription information so that there's a more 
efficiently queryable structure (pages yielding subscribers) that can be used 
in preference to the existing approach. Having subscriptions amend the index 
when created would eliminate any need for periodic reindexing, and I think 
you could implement this by having an event handler that can handle the 
SubscribedToPageEvent type of event.

There are probably other areas of Moin that could benefit from Xapian-based 
indexing, but this certainly looks like a good application of it.

Paul



From steve at einval.com  Sun Apr 15 16:56:06 2012
From: steve at einval.com (Steve McIntyre)
Date: Sun, 15 Apr 2012 21:56:06 +0100
Subject: [Moin-user] Very slow page saving caused by notifications
In-Reply-To: <201204152218.07808.paul@boddie.org.uk>
References: <20120415194434.GO21276@einval.com>
	<201204152218.07808.paul@boddie.org.uk>
Message-ID: <20120415205606.GP21276@einval.com>

On Sun, Apr 15, 2012 at 10:18:07PM +0200, Paul Boddie wrote:
>On Sunday 15 April 2012 21:44:34 Steve McIntyre wrote:
>>
>> I've posted a bug at
>>
>>   http://moinmo.in/MoinMoinBugs/SubscribedPagesPerformanceProblem
>>
>> Quick summary:
>>
>> On a site with a large number of registered users
>> (e.g. wiki.debian.org), saving a page taks a very long time. With a
>> large number of users, the design of the page subscription system
>> doesn't scale well. Saving a page works well, but moin then scans all
>> the user data files looking for the subscribed_pages data. With
>> thousands of users registered, this can take a very long time; we're
>> seeing > 90 seconds on a wiki with more than 10,000 users.
>
>I can see that the offending code is in MoinMoin/Page.py, specifically the 
>getSubscribers method of the Page class. This looks like a classic case of 
>needing to "invert" the way the data is stored so that it can be queried more 
>efficiently - it's a bit like comparing the standard text search 
>functionality with Xapian-based searching, where the former relies on 
>scanning pages sequentially (pages yield terms), whereas the latter employs 
>such "inverted" storage of queryable information (terms yield pages).

Yup, exactly.

>> This area needs fixing in some way - maybe add a cache in front of the
>> user lookup here, or store the subscribed_pages information
>> differently. I might be able to help with coding this, but I'd want to
>> see what other people think first in terms of a design.
>>
>> What do people think?
>
>I'd be inclined to index the subscription information so that there's a more 
>efficiently queryable structure (pages yielding subscribers) that can be used 
>in preference to the existing approach. Having subscriptions amend the index 
>when created would eliminate any need for periodic reindexing, and I think 
>you could implement this by having an event handler that can handle the 
>SubscribedToPageEvent type of event.

OK, I'll have a play at that now and see if I can get it working.

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
  Getting a SCSI chain working is perfectly simple if you remember that there
  must be exactly three terminations: one on one end of the cable, one on the
  far end, and the goat, terminated over the SCSI chain with a silver-handled
  knife whilst burning *black* candles. --- Anthony DeBoer




From steve at einval.com  Sun Apr 15 17:12:18 2012
From: steve at einval.com (Steve McIntyre)
Date: Sun, 15 Apr 2012 22:12:18 +0100
Subject: [Moin-user] Very slow page saving caused by notifications
In-Reply-To: <20120415205606.GP21276@einval.com>
References: <20120415194434.GO21276@einval.com>
	<201204152218.07808.paul@boddie.org.uk>
	<20120415205606.GP21276@einval.com>
Message-ID: <20120415211206.GQ21276@einval.com>

Ah, I see there's a similar bug already (with a patch) in

http://moinmo.in/MoinMoinBugs/GetSubscribersSlow

which adds a cache.

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/




From paul at boddie.org.uk  Sun Apr 15 18:23:25 2012
From: paul at boddie.org.uk (Paul Boddie)
Date: Mon, 16 Apr 2012 00:23:25 +0200
Subject: [Moin-user] Very slow page saving caused by notifications
In-Reply-To: <20120415211206.GQ21276@einval.com>
References: <20120415194434.GO21276@einval.com>
	<20120415205606.GP21276@einval.com>
	<20120415211206.GQ21276@einval.com>
Message-ID: <201204160023.25409.paul@boddie.org.uk>

On Sunday 15 April 2012 23:12:18 Steve McIntyre wrote:
> Ah, I see there's a similar bug already (with a patch) in
>
> http://moinmo.in/MoinMoinBugs/GetSubscribersSlow
>
> which adds a cache.

I suppose that a cache would perform just as well as a more sophisticated 
approach, given that one would effectively be storing the same correspondence 
of page to subscriber list in the cache. I think that the patch to user.py is 
perhaps less than desirable, though, given that an event handler could 
probably do the same work handling UserCreatedEvent and SubscribedToPageEvent 
instances. Then again, if you're already patching Page.py, patching another 
core module probably isn't too disruptive.

Paul



From tw-public at gmx.de  Sun Apr 22 08:27:16 2012
From: tw-public at gmx.de (Thomas Waldmann)
Date: Sun, 22 Apr 2012 14:27:16 +0200
Subject: [Moin-user] Very slow page saving caused by notifications
In-Reply-To: <201204152218.07808.paul@boddie.org.uk>
References: <20120415194434.GO21276@einval.com>
	<201204152218.07808.paul@boddie.org.uk>
Message-ID: <1335097636.27679.20.camel@x300.localdomain>

> There are probably other areas of Moin that could benefit from Xapian-based 
> indexing, but this certainly looks like a good application of it.

Some notes:

search / indexing
=================

xapian is not a requirement for moin 1.9, but an option. thus, there is
alternative code in moin (for searching) so it works if you do not have
xapian.

xapian is a binary dependency - you either need a package or a compiler.

due to the 2 distinct codes (indexed vs. non-indexed) for searching with
and without xapian, there are some fundamental differences in how one
can use it and what one can expect from it.

in moin 2, we have replaced xapian by whoosh (which is pure-python, so
we were able to just REQUIRE it). this will fix quite some of the issues
we have seen in moin 1.x relating to indexing, queries and search.

i have done a few benchmarks and whoosh was surprisingly fast (not as
fast as xapian sometimes, but also not much slower).

in moin2, we use whoosh for all sorts of internal lookups as well as for
the search you can do from the UI.

all stuff (users, pages, attachments) in moin2 is stored into typed
items/revisions (which have metadata and data) and metadata and
(filtered) data gets indexed.

that makes life much easier for the developers as there is less and
simpler code now.

caching
=======
sometimes stuff can be accelerated by adding a cache. but if you have a
cache, you always have to make sure it is consistent with the real data.

i had a quick look at the subscribed users caching patch and I suspect
that might not be the case there.





From steve at einval.com  Mon Apr 23 09:11:47 2012
From: steve at einval.com (Steve McIntyre)
Date: Mon, 23 Apr 2012 14:11:47 +0100
Subject: [Moin-user] Very slow page saving caused by notifications
In-Reply-To: <1335097636.27679.20.camel@x300.localdomain>
References: <20120415194434.GO21276@einval.com>
	<201204152218.07808.paul@boddie.org.uk>
	<1335097636.27679.20.camel@x300.localdomain>
Message-ID: <20120423131147.GA13696@einval.com>

On Sun, Apr 22, 2012 at 02:27:16PM +0200, Thomas Waldmann wrote:
...
>all stuff (users, pages, attachments) in moin2 is stored into typed
>items/revisions (which have metadata and data) and metadata and
>(filtered) data gets indexed.
>
>that makes life much easier for the developers as there is less and
>simpler code now.

Cool, I look forwards to seeing it!

>caching
>=======
>sometimes stuff can be accelerated by adding a cache. but if you have a
>cache, you always have to make sure it is consistent with the real data.
>
>i had a quick look at the subscribed users caching patch and I suspect
>that might not be the case there.

Hmmm. It seems to work fine for me in testing, but it's possible that
testing hasn't exercised all paths yet. Any suggestions on where to
check?

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
"I've only once written 'SQL is my bitch' in a comment. But that code 
 is in use on a military site..." -- Simon Booth




From paul at boddie.org.uk  Mon Apr 23 12:11:16 2012
From: paul at boddie.org.uk (Paul Boddie)
Date: Mon, 23 Apr 2012 18:11:16 +0200
Subject: [Moin-user] Very slow page saving caused by notifications
In-Reply-To: <20120423131147.GA13696@einval.com>
References: <20120415194434.GO21276@einval.com>
	<1335097636.27679.20.camel@x300.localdomain>
	<20120423131147.GA13696@einval.com>
Message-ID: <201204231811.16520.paul@boddie.org.uk>

On Monday 23 April 2012 15:11:47 Steve McIntyre wrote:
> On Sun, Apr 22, 2012 at 02:27:16PM +0200, Thomas Waldmann wrote:
>
> >caching
> >=======
> >sometimes stuff can be accelerated by adding a cache. but if you have a
> >cache, you always have to make sure it is consistent with the real data.
> >
> >i had a quick look at the subscribed users caching patch and I suspect
> >that might not be the case there.
>
> Hmmm. It seems to work fine for me in testing, but it's possible that
> testing hasn't exercised all paths yet. Any suggestions on where to
> check?

I had the impression that the cache was updated when a user saves their 
profile but not when the user subscribes or unsubscribes using the 
appropriate action, but I may have missed something.

Paul

P.S. My note about Xapian (that Thomas responded to) was more about general 
content indexing, of which caching can be regarded as something of a special 
case, than Xapian specifically - it just happens to be the only serious Moin 
1.x option in this area beyond the built-in Moin functionality - although 
there certainly are a lot of applications of caching once you start looking 
for them.



From zbynek.winkler at gmail.com  Mon Apr 23 12:06:33 2012
From: zbynek.winkler at gmail.com (Zbynek Winkler)
Date: Mon, 23 Apr 2012 18:06:33 +0200
Subject: [Moin-user] Patches to moin-2.0
Message-ID: <CAEQmf3FpTxkY0iaSxNDKXhweYAr=xVP-9ZgdS=VwHniuypxVYw@mail.gmail.com>

Hello.
I have added some issues to the issue tracker for moin-2.0 recently. And
while I also added patches to the ones I was able to deal with, I was
wondering if there is maybe a better way to help. Shall I create a patch
queue on bitbucket? It seems better than forking since there are a lot of
little things with no relation to each other and having 10 different forks
seems strange. What it the preferred way to cooperate, get feedback etc.?
Zbyn?k
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/moin-user/attachments/20120423/44195724/attachment.html>

From mark.scheufele at diasemi.com  Tue Apr 24 12:19:50 2012
From: mark.scheufele at diasemi.com (Mark Scheufele)
Date: Tue, 24 Apr 2012 16:19:50 +0000
Subject: [Moin-user] xapian search: an unhandled win32 exception occured in
	w3wp.exe
Message-ID: <39080CC9D403A94F992B5A8183FE77BC6BC2D813@NB-EX-MBX01.diasemi.com>

Hi Moin Users,

I have enabled the xapian based search on our wiki system. I was able to build the index and I am also able to query the index just fine. Yet when I try to update a page I get a pop message that an unhandled win32 exception occurred in w3wp.exe (IIS).

When I look at the eventlog I can see the following error details:

Exception code: 0xc00000fd
Fault offset: 0x00019dcf
Faulting process id: 0xec
Faulting application start time: 0x01cd223181c9c430
Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
Faulting module path: C:\Windows\system32\python26.dll

After confirming the popup the change will be saved, yet the xapian index has not been updated (timestamp of index files did not change and searching for the change not come up with a result).

I had a look at the MoinMoin xapian events (MoinMoin\events\xapian_index.py) and found out that in case of a page update the following code is carried out:

def handle_changed(event):
    """Updates Xapian index when a page is changed"""

    request = event.request

    if request.cfg.xapian_search:
        index = _get_index(request)
        if index and index.exists():
            index.update_item(event.page.page_name)

I wrote a little script to call index.update_item(event.page.page_name). Running this script updates the xapian index yet following exception occurs:

Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in <type 'exceptions.AttributeError'> ignored
Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in <type 'exceptions.AttributeError'> ignored

sys.path.append("c:\moin")

from MoinMoin.web import contexts
from MoinMoin.Page import Page

class ScriptContext(contexts.AllContext):
	"""
	added REMOTE_USER to wsgi environ
	"""
	def __init__(self, user, url=None, pagename=''):
		if url is None:
			url='http://localhost:0/' # just some somehow valid dummy URL
		environ=contexts.create_environ(base_url=url) # XXX not sure about base_url, but makes "make underlay" work
		environ['HTTP_USER_AGENT']='CLI/Script'
		environ['wsgi.input']=sys.stdin
		environ['REMOTE_USER']=user
		request=contexts.Request(environ)
		super(ScriptContext, self).__init__(request)
		from MoinMoin import wsgiapp
		wsgiapp.init(self)

def _get_index(request):
	try:
		from MoinMoin.search.Xapian import XapianIndex
		return XapianIndex(request)
	except ImportError:
		pass

if __name__ == '__main__':
	request=ScriptContext("mscheufe")
	if request.cfg.xapian_search:
		index=_get_index(request)
		if index and index.exists():
			page=Page(request,"SANDBOX/fred2/test")
			index.update_item(page.page_name)

It someone could give me a hint how to get the xapian based search running on a windows system with the following spec:

- moin 1.9.3
- python 2.6.6
- xapian bindings for Python from here http://www.flax.co.uk/xapian/128/xapian-python-bindings%20for%20Python%202.4.4%20-1.2.8.win32.exe
- IIS 7.5 running moin using isapi_wsgi

Best Regards,

mark
_______________________________________________________________________________________

Dialog Semiconductor GmbH
Neue Str. 95
D-73230 Kirchheim
Managing Directors: Dr. Jalal Bagherli, Jean-Michel Richard
Chairman of the Supervisory Board: Gregorio Reyes
Commercial register: Amtsgericht Stuttgart: HRB 231181
UST-ID-Nr. DE 811121668


Legal Disclaimer: This e-mail communication (and any attachment/s) is confidential and 
contains proprietary information, some or all of which may be legally privileged. It is 
intended solely for the use of the individual or entity to which it is addressed. Access 
to this email by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, distribution or any action taken or omitted to be taken in reliance
on it, is prohibited and may be unlawful.

Please consider the environment before printing this e-mail



From steve at einval.com  Wed Apr 25 10:29:04 2012
From: steve at einval.com (Steve McIntyre)
Date: Wed, 25 Apr 2012 15:29:04 +0100
Subject: [Moin-user] Very slow page saving caused by notifications
In-Reply-To: <201204231811.16520.paul@boddie.org.uk>
References: <20120415194434.GO21276@einval.com>
	<1335097636.27679.20.camel@x300.localdomain>
	<20120423131147.GA13696@einval.com>
	<201204231811.16520.paul@boddie.org.uk>
Message-ID: <20120425142904.GG21276@einval.com>

On Mon, Apr 23, 2012 at 06:11:16PM +0200, Paul Boddie wrote:
>On Monday 23 April 2012 15:11:47 Steve McIntyre wrote:
>> On Sun, Apr 22, 2012 at 02:27:16PM +0200, Thomas Waldmann wrote:
>>
>> >caching
>> >=======
>> >sometimes stuff can be accelerated by adding a cache. but if you have a
>> >cache, you always have to make sure it is consistent with the real data.
>> >
>> >i had a quick look at the subscribed users caching patch and I suspect
>> >that might not be the case there.
>>
>> Hmmm. It seems to work fine for me in testing, but it's possible that
>> testing hasn't exercised all paths yet. Any suggestions on where to
>> check?
>
>I had the impression that the cache was updated when a user saves their 
>profile but not when the user subscribes or unsubscribes using the 
>appropriate action, but I may have missed something.

They still go through the user.save() path in the end, so no problem
there AFAICS.

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
"Since phone messaging became popular, the young generation has lost the
 ability to read or write anything that is longer than one hundred and sixty
 characters."  -- Ignatios Souvatzis




From mark.scheufele at diasemi.com  Wed Apr 25 11:59:53 2012
From: mark.scheufele at diasemi.com (Mark Scheufele)
Date: Wed, 25 Apr 2012 15:59:53 +0000
Subject: [Moin-user] xapian search: an unhandled win32 exception occured
 in	w3wp.exe
In-Reply-To: <39080CC9D403A94F992B5A8183FE77BC6BC2D813@NB-EX-MBX01.diasemi.com>
References: <39080CC9D403A94F992B5A8183FE77BC6BC2D813@NB-EX-MBX01.diasemi.com>
Message-ID: <39080CC9D403A94F992B5A8183FE77BC6BC2DCE1@NB-EX-MBX01.diasemi.com>

Hi Moin users,

is there anybody out there who knows details about the xapian integration into moin? Yesterday I have reported that xapian index is not updated when a page is changed. Instead the webserver (IIS 7.5) reports an unhandled exception.

Today I did further troubleshoot the problem and here are my findings:

- I am able to update the index using a python script and calling the index.update_item(page.page_name) function (see original post for the complete script).

- when I run this script it updates the index, yet it also tells something about the following exception:
  "Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in <type 'exceptions.AttributeError'> ignored"

- the windows eventlog says that the Exception with code: 0xc00000fd has occurred. According to the following article 
  http://msdn.microsoft.com/en-us/library/windows/hardware/ff540620%28v=vs.85%29.aspx the exception is triggered by a stack overflow which might be 
  caused by infinite recursion. This would fit with the RuntimError shown by the standalone script.

- after trying to update a page over the web  a search for content of this page does not show any result. Even page content already searchable prior to the 
   page change cannot the searched anymore.

- When I now run the commandline script for the page I tried to update over the web the moin.log file shows that there is more than one update queued.
  2012-04-25 17:03:17,438 MoinMoin.search.Xapian.indexing DEBUG updated xapian index with 2 queued updates
  The number of queued updates for a page can be increased by trying to update the page over the web several times.

Summary of my findings:

- the index can be updated using the the index.update_item(page.page_name) function within a script, although the script reports the following exception 
  "Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in <type 'exceptions.AttributeError'> ignored".
- updating a page over the web produces:
	- unhandled exception within IIS
	- removes the page content from the xapian index (at least one is not able to search for page content anymore)
	- adds an entry to the update queue

I am really interested in solving the issue. If someone could give me a hint how to further troubleshoot it would be highly appreciated.

BR,
mark
_______________________________________________________________________________________

Dialog Semiconductor GmbH
Neue Str. 95
D-73230 Kirchheim
Managing Directors: Dr. Jalal Bagherli, Jean-Michel Richard
Chairman of the Supervisory Board: Gregorio Reyes
Commercial register: Amtsgericht Stuttgart: HRB 231181
UST-ID-Nr. DE 811121668


Legal Disclaimer: This e-mail communication (and any attachment/s) is confidential and 
contains proprietary information, some or all of which may be legally privileged. It is 
intended solely for the use of the individual or entity to which it is addressed. Access 
to this email by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, distribution or any action taken or omitted to be taken in reliance
on it, is prohibited and may be unlawful.

Please consider the environment before printing this e-mail



From steve at einval.com  Wed Apr 25 13:25:34 2012
From: steve at einval.com (Steve McIntyre)
Date: Wed, 25 Apr 2012 18:25:34 +0100
Subject: [Moin-user] Patch to force email verification of new accounts
Message-ID: <20120425172534.GH21276@einval.com>

Hi,

Just posted a new patch to add a feature I think would be useful:

  http://moinmo.in/MoinMoinPatch/VerifyAccountCreationByEmail

If account creation includes verification of a working email address,
it should hopefully reduce the amount of drive-by spam for wiki
admins.

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"




From manfred.lotz at arcor.de  Thu Apr 26 08:28:26 2012
From: manfred.lotz at arcor.de (Manfred Lotz)
Date: Thu, 26 Apr 2012 14:28:26 +0200
Subject: [Moin-user] Print a page in moinmoin
Message-ID: <20120426142826.4e48a913@arcor.com>

Hi there,
After happily converting my existing wiki to Moinmoin I wanted to print
a page (unfortunately I didn't test it before).

The problem I'm facing is that the print looks like a print of a
presentation page. Instead of a single A4 page I got 4 pages in
landscape.

I want the text to appear on paper as normal text in A4
portrait.


Anything, I can do to get it like I want?

-- 
Manfred





From paul at boddie.org.uk  Thu Apr 26 17:42:52 2012
From: paul at boddie.org.uk (Paul Boddie)
Date: Thu, 26 Apr 2012 23:42:52 +0200
Subject: [Moin-user] Print a page in moinmoin
In-Reply-To: <20120426142826.4e48a913@arcor.com>
References: <20120426142826.4e48a913@arcor.com>
Message-ID: <201204262342.52969.paul@boddie.org.uk>

On Thursday 26 April 2012 14:28:26 Manfred Lotz wrote:
> Hi there,
> After happily converting my existing wiki to Moinmoin I wanted to print
> a page (unfortunately I didn't test it before).
>
> The problem I'm facing is that the print looks like a print of a
> presentation page. Instead of a single A4 page I got 4 pages in
> landscape.

What are your print settings in your browser?

> I want the text to appear on paper as normal text in A4
> portrait.

The print stylesheets - what the browser uses to format pages for printing - 
depend on which theme is being used, but generally they just remove all the 
navigation and "furniture" that you usually see around the page content and 
only preserve the page text, so you should get a fairly plain printout by 
default, but the paper size and orientation are things your browser will be 
in control of, not the stylesheet.

> Anything, I can do to get it like I want?

I recommend checking your print settings and verifying that the paper size is 
A4, that the output is scaled to 100%, and that you have one page per side. 
Firefox is a bit confusing in this respect as you have the print preview 
settings and then the actual printer settings. I recommend tuning the preview 
to look more or less correct and then verifying that, when choosing to 
actually print, you aren't putting more than one page per side or anything 
like that.

Paul



From tw-public at gmx.de  Sat Apr 28 17:40:10 2012
From: tw-public at gmx.de (Thomas Waldmann)
Date: Sat, 28 Apr 2012 23:40:10 +0200
Subject: [Moin-user] Patches to moin-2.0
In-Reply-To: <CAEQmf3FpTxkY0iaSxNDKXhweYAr=xVP-9ZgdS=VwHniuypxVYw@mail.gmail.com>
References: <CAEQmf3FpTxkY0iaSxNDKXhweYAr=xVP-9ZgdS=VwHniuypxVYw@mail.gmail.com>
Message-ID: <1335649210.6006.3.camel@x300.localdomain>



Thanks!

> And while I also added patches to the ones I was able to deal with, I
> was wondering if there is maybe a better way to help. Shall I create a
> patch queue on bitbucket?

You can just clone my moin-2.0 bitbucket repo (which is a mirror of the
official moin/2.0 repo), update your clone with changesets and send me a
pull request there.

> It seems better than forking since there are a lot of little things
> with no relation to each other and having 10 different forks seems
> strange.

Well, maybe just do one thing after the other. :)

> What it the preferred way to cooperate, get feedback etc.?

If you'ld like code review, use http://codereview.appspot.com/ and for
quicker communication join us on #moin-dev on IRC.






From tw-public at gmx.de  Sat Apr 28 17:52:51 2012
From: tw-public at gmx.de (Thomas Waldmann)
Date: Sat, 28 Apr 2012 23:52:51 +0200
Subject: [Moin-user] xapian search: an unhandled win32 exception occured
 in	w3wp.exe
In-Reply-To: <39080CC9D403A94F992B5A8183FE77BC6BC2DCE1@NB-EX-MBX01.diasemi.com>
References: <39080CC9D403A94F992B5A8183FE77BC6BC2D813@NB-EX-MBX01.diasemi.com>
	<39080CC9D403A94F992B5A8183FE77BC6BC2DCE1@NB-EX-MBX01.diasemi.com>
Message-ID: <1335649971.6006.12.camel@x300.localdomain>


> is there anybody out there who knows details about the xapian integration into moin?

While I didn't do changes recently, I worked quite a bit on that code
some time ago.

>  Yesterday I have reported that xapian index is not updated when a page is changed. Instead the webserver (IIS 7.5) reports an unhandled exception.

I can't help you with IIS specific issues, I never used it (nor would I
ever use it).

>   "Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in <type 'exceptions.AttributeError'> ignored"

IIRC, i had a look at that a while ago and somehow I got the impression
that it is a harmless python bug and can be ignored.

> - after trying to update a page over the web  a search for content of this page does not show any result. Even page content already searchable prior to the 
>    page change cannot the searched anymore.

Hmm, that's strange.

> - When I now run the commandline script for the page I tried to update over the web the moin.log file shows that there is more than one update queued.
>   2012-04-25 17:03:17,438 MoinMoin.search.Xapian.indexing DEBUG updated xapian index with 2 queued updates
>   The number of queued updates for a page can be increased by trying to update the page over the web several times.

Sounds like it never processes (empties) the queue.


> I am really interested in solving the issue. If someone could give me a hint how to further troubleshoot it would be highly appreciated.

Well, if you want to help debugging this / determining the
circumstances, trying this comes to mind:
 * maybe use a more recent python 2.x version
 * try without IIS (try to reproduce with standalone server or apache2 +
mod-wsgi)
 * try a later / different xapian version
 * can you reproduce on moinmo.in site?

Please also file a bug report about this on the wiki (see MoinMoinBugs
page) and provide all details the template asks for (and everything else
you could find out).






From tw-public at gmx.de  Sat Apr 28 17:54:50 2012
From: tw-public at gmx.de (Thomas Waldmann)
Date: Sat, 28 Apr 2012 23:54:50 +0200
Subject: [Moin-user] Very slow page saving caused by notifications
In-Reply-To: <20120423131147.GA13696@einval.com>
References: <20120415194434.GO21276@einval.com>
	<201204152218.07808.paul@boddie.org.uk>
	<1335097636.27679.20.camel@x300.localdomain>
	<20120423131147.GA13696@einval.com>
Message-ID: <1335650090.6006.13.camel@x300.localdomain>

> >i had a quick look at the subscribed users caching patch and I suspect
> >that might not be the case there.
> 
> Hmmm. It seems to work fine for me in testing, but it's possible that
> testing hasn't exercised all paths yet. Any suggestions on where to
> check?

Check for race conditions / multi-threading/processing issues. What
happens if 2 cache updates happen at about the same time?




From steve at einval.com  Sat Apr 28 18:26:51 2012
From: steve at einval.com (Steve McIntyre)
Date: Sat, 28 Apr 2012 23:26:51 +0100
Subject: [Moin-user] Very slow page saving caused by notifications
In-Reply-To: <1335650090.6006.13.camel@x300.localdomain>
References: <20120415194434.GO21276@einval.com>
	<201204152218.07808.paul@boddie.org.uk>
	<1335097636.27679.20.camel@x300.localdomain>
	<20120423131147.GA13696@einval.com>
	<1335650090.6006.13.camel@x300.localdomain>
Message-ID: <20120428222651.GT21276@einval.com>

On Sat, Apr 28, 2012 at 11:54:50PM +0200, Thomas Waldmann wrote:
>> >i had a quick look at the subscribed users caching patch and I suspect
>> >that might not be the case there.
>> 
>> Hmmm. It seems to work fine for me in testing, but it's possible that
>> testing hasn't exercised all paths yet. Any suggestions on where to
>> check?
>
>Check for race conditions / multi-threading/processing issues. What
>happens if 2 cache updates happen at about the same time?

Hmmm, OK. I naively assumed that the cache layer might handle locking
itself, that's a shame.

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews




From steve at einval.com  Sun Apr 29 14:30:30 2012
From: steve at einval.com (Steve McIntyre)
Date: Sun, 29 Apr 2012 19:30:30 +0100
Subject: [Moin-user] Very slow page saving caused by notifications
In-Reply-To: <20120428222651.GT21276@einval.com>
References: <20120415194434.GO21276@einval.com>
	<201204152218.07808.paul@boddie.org.uk>
	<1335097636.27679.20.camel@x300.localdomain>
	<20120423131147.GA13696@einval.com>
	<1335650090.6006.13.camel@x300.localdomain>
	<20120428222651.GT21276@einval.com>
Message-ID: <20120429183029.GX21276@einval.com>

On Sat, Apr 28, 2012 at 11:26:51PM +0100, Steve McIntyre wrote:
>On Sat, Apr 28, 2012 at 11:54:50PM +0200, Thomas Waldmann wrote:
>>> >i had a quick look at the subscribed users caching patch and I suspect
>>> >that might not be the case there.
>>> 
>>> Hmmm. It seems to work fine for me in testing, but it's possible that
>>> testing hasn't exercised all paths yet. Any suggestions on where to
>>> check?
>>
>>Check for race conditions / multi-threading/processing issues. What
>>happens if 2 cache updates happen at about the same time?
>
>Hmmm, OK. I naively assumed that the cache layer might handle locking
>itself, that's a shame.

Apologies, misunderstood you last night when I wrote that. I have an
updated patch that I've just attached:

http://moinmo.in/MoinMoinBugs/GetSubscribersSlow?action=AttachFile&do=view&target=subscribercache.patch

which seems to work for me. What do you think?

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
          note stuck to the mini-bar saying "Paul: This fridge and
          fittings are the correct way around and do not need altering"




From manfred.lotz at arcor.de  Mon Apr 30 15:59:40 2012
From: manfred.lotz at arcor.de (Manfred Lotz)
Date: Mon, 30 Apr 2012 21:59:40 +0200
Subject: [Moin-user] Print a page in moinmoin
In-Reply-To: <201204262342.52969.paul@boddie.org.uk>
References: <20120426142826.4e48a913@arcor.com>
	<201204262342.52969.paul@boddie.org.uk>
Message-ID: <20120430215940.6e560eb4@arcor.com>

On Thu, 26 Apr 2012 23:42:52 +0200
Paul Boddie <paul at boddie.org.uk> wrote:

> On Thursday 26 April 2012 14:28:26 Manfred Lotz wrote:
> > Hi there,
> > After happily converting my existing wiki to Moinmoin I wanted to
> > print a page (unfortunately I didn't test it before).
> >
> > The problem I'm facing is that the print looks like a print of a
> > presentation page. Instead of a single A4 page I got 4 pages in
> > landscape.
> 
> What are your print settings in your browser?
> 

I have to admit I'm really confused, because of the following: For some
reasons the wiki is synchronized over two laptops. My user settings
have the same theme sinorca4moin active. If on the one laptop I print
page SomePage say to pdf the pdf printer shows up: A4 and portrait. The
printing results in a single A4 page. On the other laptop printing
SomePage to PDF the settings are: A4 and landscape. If I change it to
portrait the output PDF has 4 pages. The fonts are big like I had tried
to print a powerpoint document in portrait.

Hmm, I just found that print preview on the other laptop was set to 200%
and to landscape. When changing it back to 100% and portrait printing
works fine now on the second laptop as well.

Although solved now, I'm still confused.


-- 
Manfred






From paul at boddie.org.uk  Mon Apr 30 17:21:33 2012
From: paul at boddie.org.uk (Paul Boddie)
Date: Mon, 30 Apr 2012 23:21:33 +0200
Subject: [Moin-user] Print a page in moinmoin
In-Reply-To: <20120430215940.6e560eb4@arcor.com>
References: <20120426142826.4e48a913@arcor.com>
	<201204262342.52969.paul@boddie.org.uk>
	<20120430215940.6e560eb4@arcor.com>
Message-ID: <201204302321.33273.paul@boddie.org.uk>

On Monday 30 April 2012 21:59:40 Manfred Lotz wrote:
>
> I have to admit I'm really confused, because of the following: For some
> reasons the wiki is synchronized over two laptops. My user settings
> have the same theme sinorca4moin active. If on the one laptop I print
> page SomePage say to pdf the pdf printer shows up: A4 and portrait. The
> printing results in a single A4 page. On the other laptop printing
> SomePage to PDF the settings are: A4 and landscape. If I change it to
> portrait the output PDF has 4 pages. The fonts are big like I had tried
> to print a powerpoint document in portrait.
>
> Hmm, I just found that print preview on the other laptop was set to 200%
> and to landscape. When changing it back to 100% and portrait printing
> works fine now on the second laptop as well.
>
> Although solved now, I'm still confused.

I think printing is pretty confused in the browser - or at least in Firefox - 
anyway. I got confused just checking my own settings because I expected to 
see all the different settings in the preview, but there's a layer below that 
in the print dialogue itself. How they interact is anybody's guess!

My solution is to leave the actual print settings on some kind of sane default 
unless I really want to print four pages per side/sheet, and to try and have 
things like paper sizes mostly in agreement. I have also in the past printed 
to PDF to get something that won't be mysteriously rescaled or reformatted 
and then printed that PDF file.

Paul



From manfred.lotz at arcor.de  Mon Apr 30 22:43:55 2012
From: manfred.lotz at arcor.de (Manfred Lotz)
Date: Tue, 1 May 2012 04:43:55 +0200
Subject: [Moin-user] Print a page in moinmoin
In-Reply-To: <201204302321.33273.paul@boddie.org.uk>
References: <20120426142826.4e48a913@arcor.com>
	<201204262342.52969.paul@boddie.org.uk>
	<20120430215940.6e560eb4@arcor.com>
	<201204302321.33273.paul@boddie.org.uk>
Message-ID: <20120501044355.24f65660@arcor.com>

On Mon, 30 Apr 2012 23:21:33 +0200
Paul Boddie <paul at boddie.org.uk> wrote:

> On Monday 30 April 2012 21:59:40 Manfred Lotz wrote:
> >
...
> 
> My solution is to leave the actual print settings on some kind of
> sane default unless I really want to print four pages per side/sheet,
> and to try and have things like paper sizes mostly in agreement. I
> have also in the past printed to PDF to get something that won't be
> mysteriously rescaled or reformatted and then printed that PDF file.
> 

I agree. It seems to be the best not to touch the print settings in the
browser, and if I have special needs to print to a pdf document. Then I
could try whatever I want.



-- 
Thanks,
Manfred