From mark.scheufele at diasemi.com Wed May 2 05:11:18 2012 From: mark.scheufele at diasemi.com (Mark Scheufele) Date: Wed, 2 May 2012 09:11:18 +0000 Subject: [Moin-user] xapian search: an unhandled win32 exception occured in w3wp.exe In-Reply-To: <1335649971.6006.12.camel@x300.localdomain> References: <39080CC9D403A94F992B5A8183FE77BC6BC2D813@NB-EX-MBX01.diasemi.com> <39080CC9D403A94F992B5A8183FE77BC6BC2DCE1@NB-EX-MBX01.diasemi.com> <1335649971.6006.12.camel@x300.localdomain> Message-ID: <39080CC9D403A94F992B5A8183FE77BC6BC308A8@NB-EX-MBX01.diasemi.com> Hi Thomas, I was now able to track down to code that triggers IIS to throw the unhandled exception. It appears within the _indexingRequest() method of the MoinMoin\search\builtin.py module. I did the following: - inserted a breakpoint into the code using winpdb and restarting the wiki - after updating a page over the web I could step through the lines of _indexingRequest() until a copy of the request object is being made. This causes the exception within IIS def _indexingRequest(self, request): """ Return a new request that can be used for index building. This request uses a security policy that lets the current user read any page. Without this policy some pages will not render, which will create broken pagelinks index. @param request: current request """ import copy from MoinMoin.security import Permissions from MoinMoin.logfile import editlog class SecurityPolicy(Permissions): def read(self, *args, **kw): return True import rpdb2 rpdb2.start_embedded_debugger("""...Removed-password-from-output...""") r = copy.copy(request) <-- IIS exception is caused As already mentioned when I try to update the Xapian index of a page using a standalone script its STDOUT also contains some information regarding an exception. Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in ignored Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in ignored Yet it seems that the standalone script handles the condition more gracefully than if the code is executed as ISAPI application under the command of IIS. There is also one more thing I cannot understand. When I run the standalone script an exception is being reported yet I am not able to catch it. What I mean is when I run: try: index.update_item(page.page_name) except Exception ,e: print "CATCHED excpetion %s" % str(e) I am not able to catch the exception. But STDOUT of the script contains the lines: Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in ignored Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in ignored To me this looks kind of weird as information about an exception is reported yet I am not able to catch it. Currently I am suspecting that the root cause of the issue might be that the mentioned exception (that cannot be catched within python but nonetheless is still there) is propagated to IIS and causing the webserver throwing the unhandled exception message. Apart from this mail I will also file a bugreport at http://moinmo.in/MoinMoinBugs describing my setup and all the observations I have already made. Regards, mark -----Original Message----- From: Thomas Waldmann [mailto:tw-public at gmx.de] Sent: Samstag, 28. April 2012 23:53 To: Mark Scheufele Cc: moin-user at lists.sourceforge.net Subject: Re: [Moin-user] xapian search: an unhandled win32 exception occured in w3wp.exe > 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 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). _______________________________________________________________________________________ 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 mark.scheufele at diasemi.com Wed May 2 08:30:22 2012 From: mark.scheufele at diasemi.com (Mark Scheufele) Date: Wed, 2 May 2012 12:30:22 +0000 Subject: [Moin-user] xapian search: an unhandled win32 exception occurred in w3wp.exe Message-ID: <39080CC9D403A94F992B5A8183FE77BC6BC30938@NB-EX-MBX01.diasemi.com> Hi, I did file a bug at http://moinmo.in/MoinMoinBugs regarding the issue. The page name of the bug is "1.9.3XapianNoIndexUpdateAtPageIfRunningIIS". Would it be possible to rename the page to "1.9.3XapianNoIndexUpdateAtPageChangeIfRunningIIS" to make it a bit more meaningful. Many Thanks, 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 cmac at mit.edu Wed May 2 10:00:34 2012 From: cmac at mit.edu (Christopher MacMinn) Date: Wed, 2 May 2012 10:00:34 -0400 Subject: [Moin-user] Diagnose and fix performance problems? Message-ID: Hello MoinMoin - I used MoinMoin to build a website for my former research group at MIT, and it has worked well for them so far (http://juanesgroup.mit.edu). The servers are internal to MIT and we have limited control over them. As it stands, the website has some performance problems -- sometimes it's quick, and sometimes it takes 10 seconds or more to load a page. I'm looking for suggestions on how to diagnose and fix this sluggishness. It could stem from the servers, from MoinMoin, or from less-than-optimal HTML, CSS, javascript, or Moin configuration that I did myself. Any help would be greatly appreciated -- thanks! Best, Chris MacMinn -------------- next part -------------- An HTML attachment was scrubbed... URL: From tw-public at gmx.de Wed May 2 12:48:09 2012 From: tw-public at gmx.de (Thomas Waldmann) Date: Wed, 02 May 2012 18:48:09 +0200 Subject: [Moin-user] xapian search: an unhandled win32 exception occured in w3wp.exe In-Reply-To: <39080CC9D403A94F992B5A8183FE77BC6BC308A8@NB-EX-MBX01.diasemi.com> References: <39080CC9D403A94F992B5A8183FE77BC6BC2D813@NB-EX-MBX01.diasemi.com> <39080CC9D403A94F992B5A8183FE77BC6BC2DCE1@NB-EX-MBX01.diasemi.com> <1335649971.6006.12.camel@x300.localdomain> <39080CC9D403A94F992B5A8183FE77BC6BC308A8@NB-EX-MBX01.diasemi.com> Message-ID: <1335977289.16337.14.camel@x300.localdomain> > I was now able to track down to code that triggers IIS to throw the unhandled exception. That's interesting, but please let's keep the information on the wiki bug page (noone will dig through the mailing list when trying to fix bugs). > r = copy.copy(request) <-- IIS exception is caused Oops, that's strange. > Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in ignored If you just see that in the log, without the usual traceback, it likely means that there was a (rather simple) error handler that catched it and just logged minimal information. > Yet it seems that the standalone script handles the condition more gracefully than if the code is executed as ISAPI application under the command of IIS. Well, or it does not happen at all there. Maybe the "request" object has something that causes issues with copy in one case, but not in the other? > There is also one more thing I cannot understand. When I run the standalone script an exception is being reported yet I am not able to catch it. If there is a more "inner" error handler that catches it, your handler won't get it. > Apart from this mail I will also file a bugreport at http://moinmo.in/MoinMoinBugs describing my setup and all the observations I have already made. Great! :) From tw-public at gmx.de Wed May 2 12:49:18 2012 From: tw-public at gmx.de (Thomas Waldmann) Date: Wed, 02 May 2012 18:49:18 +0200 Subject: [Moin-user] xapian search: an unhandled win32 exception occurred in w3wp.exe In-Reply-To: <39080CC9D403A94F992B5A8183FE77BC6BC30938@NB-EX-MBX01.diasemi.com> References: <39080CC9D403A94F992B5A8183FE77BC6BC30938@NB-EX-MBX01.diasemi.com> Message-ID: <1335977358.16337.15.camel@x300.localdomain> > I did file a bug at http://moinmo.in/MoinMoinBugs regarding the issue. > The page name of the bug is "1.9.3XapianNoIndexUpdateAtPageIfRunningIIS". > Would it be possible to rename the page to "1.9.3XapianNoIndexUpdateAtPageChangeIfRunningIIS" to make it a bit more meaningful. Sure, just rename it (you need to be logged in). From tw-public at gmx.de Wed May 2 13:03:36 2012 From: tw-public at gmx.de (Thomas Waldmann) Date: Wed, 02 May 2012 19:03:36 +0200 Subject: [Moin-user] Diagnose and fix performance problems? In-Reply-To: References: Message-ID: <1335978216.16337.26.camel@x300.localdomain> Hi Chris, > > I used MoinMoin to build a website for my former research group at > MIT, and it has worked well for them so far > (http://juanesgroup.mit.edu). The servers are internal to MIT and we > have limited control over them. Nicely themed moin 1.9.4. :) > > As it stands, the website has some performance problems -- sometimes > it's quick, and sometimes it takes 10 seconds or more to load a page. > I'm looking for suggestions on how to diagnose and fix this > sluggishness. It could stem from the servers, from MoinMoin, or from > less-than-optimal HTML, CSS, javascript, or Moin configuration that I > did myself. Any help would be greatly appreciated -- thanks! Well, without more infos and without server shell access it is a bit hard to help. Look into web server logs (apache access log / error log), compare times when wiki is fast to times when it is slow. Did you use apache/mod-wsgi or cgi? cgi is slow. Look at machine load (linux: "top") when wiki is fast vs. when wiki is slow. Look which process is eating cpu. Is it when you are doing specific wiki requests? Like after saving? If you can't get it solved, talk to me. Cheers, Thomas From cmac at mit.edu Wed May 2 13:22:35 2012 From: cmac at mit.edu (Christopher MacMinn) Date: Wed, 2 May 2012 13:22:35 -0400 Subject: [Moin-user] Diagnose and fix performance problems? In-Reply-To: <1335978216.16337.26.camel@x300.localdomain> References: <1335978216.16337.26.camel@x300.localdomain> Message-ID: Hi Thomas - Thanks for your reply! >> I used MoinMoin to build a website for my former research group at MIT > > Nicely themed moin 1.9.4. :) Thanks! Our goal was for it to function like a wiki for logged-in users, but to look like a normal webpage to everyone else. >> As it stands, the website has some performance problems -- sometimes >> it's quick, and sometimes it takes 10 seconds or more to load a page. > > Well, without more infos and without server shell access it is a bit > hard to help. > > Look into web server logs (apache access log / error log), compare times > when wiki is fast to times when it is slow. > Look at machine load (linux: "top") when wiki is fast vs. when wiki is > slow. Look which process is eating cpu. I will do that. > Did you use apache/mod-wsgi or cgi? cgi is slow. Our servers do not offer mod_wsgi, so I think we're currently using some sort of WSGI<--> Fast CGI wrapper. Could this be a major cause of the problems? > Is it when you are doing specific wiki requests? Like after saving? It can happen any time, but we're primarily worried about normal page loading rather then page editing. It's ok (though annoying) for it to be slow on our end, but we definitely want to it be fast for everyone else who visits. Thanks much for your help! Best, Chris From tw-public at gmx.de Wed May 2 18:15:31 2012 From: tw-public at gmx.de (Thomas Waldmann) Date: Thu, 03 May 2012 00:15:31 +0200 Subject: [Moin-user] Diagnose and fix performance problems? In-Reply-To: References: <1335978216.16337.26.camel@x300.localdomain> Message-ID: <1335996931.16337.31.camel@x300.localdomain> > > Did you use apache/mod-wsgi or cgi? cgi is slow. > > Our servers do not offer mod_wsgi, so I think we're currently using > some sort of WSGI<--> Fast CGI wrapper. Could this be a major cause of > the problems? Well, I can't tell much about the layers below moin (esp. not for software I do not use myself), but in principle, fastcgi should be of almost same performance as mod-wsgi. A little more software (likely flup) in between moin and web server, but still fast. Plain CGI (not fastcgi) means loading and initializing all the code for each request and terminating after that one request is processed. FastCGI as well as mod-wsgi means long-running processes which are only rarely terminated and restarted and thus is much faster and less overhead. From paul at boddie.org.uk Wed May 2 19:25:10 2012 From: paul at boddie.org.uk (Paul Boddie) Date: Thu, 3 May 2012 01:25:10 +0200 Subject: [Moin-user] Diagnose and fix performance problems? In-Reply-To: <1335996931.16337.31.camel@x300.localdomain> References:

<1335996931.16337.31.camel@x300.localdomain> Message-ID: <201205030125.10735.paul@boddie.org.uk> On Thursday 03 May 2012 00:15:31 Thomas Waldmann wrote: > > > Did you use apache/mod-wsgi or cgi? cgi is slow. > > > > Our servers do not offer mod_wsgi, so I think we're currently using > > some sort of WSGI<--> Fast CGI wrapper. Could this be a major cause of > > the problems? > > Well, I can't tell much about the layers below moin (esp. not for > software I do not use myself), but in principle, fastcgi should be of > almost same performance as mod-wsgi. A little more software (likely > flup) in between moin and web server, but still fast. > > Plain CGI (not fastcgi) means loading and initializing all the code for > each request and terminating after that one request is processed. Although Thomas wrote that CGI is slow, it isn't necessarily super-slow, just slow compared to WSGI. Even then, there are lots of things that can overwhelm the overhead of CGI in terms of performance costs, even if you've switched to WSGI and are convinced that everything should be much faster. The classic example of this is any functionality that makes use of page searching: perhaps long-running processes may be fortunate when scanning pages for, say, category information if it gets cached over time (although the filesystem cache would help for CGI processes, too), but enabling Xapian for Moin 1.x provides significant benefits regardless of the means of deployment. > FastCGI as well as mod-wsgi means long-running processes which are only > rarely terminated and restarted and thus is much faster and less > overhead. Agreed. Still, if things are taking 10 seconds and there isn't some kind of pathological script reloading going on, it may be something other than the deployment technology. I have in the past enabled the timing information to spot bottlenecks, although this merely indicated that searches were slow and that I should enable Xapian support. On your site, the only unusual stuff looks like some banner-related JavaScript and the delightful Google Analytics code. Nothing like fancy but expensive Moin macros as far as I can tell. Paul From cmac at mit.edu Thu May 3 09:40:40 2012 From: cmac at mit.edu (Christopher MacMinn) Date: Thu, 3 May 2012 09:40:40 -0400 Subject: [Moin-user] Diagnose and fix performance problems? In-Reply-To: <1335996931.16337.31.camel@x300.localdomain> References: <1335978216.16337.26.camel@x300.localdomain> <1335996931.16337.31.camel@x300.localdomain> Message-ID: >> > Did you use apache/mod-wsgi or cgi? cgi is slow. >> >> Our servers do not offer mod_wsgi, so I think we're currently using >> some sort of WSGI<--> Fast CGI wrapper. Could this be a major cause of >> the problems? > > Well, I can't tell much about the layers below moin (esp. not for > software I do not use myself), but in principle, fastcgi should be of > almost same performance as mod-wsgi. [?] > > FastCGI as well as mod-wsgi means long-running processes which are only > rarely terminated and restarted and thus is much faster and less > overhead. I guess FastCGI is supposed to be a long-running process in principle; however, I just learned from the folks who administer the servers that our FastCGI processes are automatically terminated after 15 minutes of inactivity and must be relaunched upon the next visit after that. This is definitely one cause of the sluggishness, so we may need to look elsewhere for hosting. I'll keep digging to see if there's anything else strange going on. Thanks again! Best, Chris From cmac at mit.edu Thu May 3 09:47:58 2012 From: cmac at mit.edu (Christopher MacMinn) Date: Thu, 3 May 2012 09:47:58 -0400 Subject: [Moin-user] Diagnose and fix performance problems? In-Reply-To: <201205030125.10735.paul@boddie.org.uk> References:

<1335996931.16337.31.camel@x300.localdomain> <201205030125.10735.paul@boddie.org.uk> Message-ID: >> > > Did you use apache/mod-wsgi or cgi? cgi is slow. >> > >> > Our servers do not offer mod_wsgi, so I think we're currently using >> > some sort of WSGI<--> Fast CGI wrapper. Could this be a major cause of >> > the problems? >> >> Well, I can't tell much about the layers below moin (esp. not for >> software I do not use myself), but in principle, fastcgi should be of >> almost same performance as mod-wsgi. A little more software (likely >> flup) in between moin and web server, but still fast. >> >> Plain CGI (not fastcgi) means loading and initializing all the code for >> each request and terminating after that one request is processed. > > Although Thomas wrote that CGI is slow, it isn't necessarily super-slow, just > slow compared to WSGI. Even then, there are lots of things that can overwhelm > the overhead of CGI in terms of performance costs, even if you've switched to > WSGI and are convinced that everything should be much faster. > > The classic example of this is any functionality that makes use of page > searching: perhaps long-running processes may be fortunate when scanning > pages for, say, category information if it gets cached over time (although > the filesystem cache would help for CGI processes, too), but enabling Xapian > for Moin 1.x provides significant benefits regardless of the means of > deployment. > >> FastCGI as well as mod-wsgi means long-running processes which are only >> rarely terminated and restarted and thus is much faster and less >> overhead. > > Agreed. Still, if things are taking 10 seconds and there isn't some kind of > pathological script reloading going on, it may be something other than the > deployment technology. > > I have in the past enabled the timing information to spot bottlenecks, > although this merely indicated that searches were slow and that I should > enable Xapian support. On your site, the only unusual stuff looks like some > banner-related JavaScript and the delightful Google Analytics code. Nothing > like fancy but expensive Moin macros as far as I can tell. Am I right in thinking that Xapian is strictly for user-initiated searches of the MoinMoin site by entering text in a search box, or does MoinMoin use it somehow under-the-hood? We do not have a site search, so I figured that we had no use for this. Thanks for taking a look, Paul. It's good to know that we're not doing anything blatantly unintelligent. :) Best, Chris From tw-public at gmx.de Thu May 3 18:54:41 2012 From: tw-public at gmx.de (Thomas Waldmann) Date: Fri, 04 May 2012 00:54:41 +0200 Subject: [Moin-user] Diagnose and fix performance problems? In-Reply-To: References: <1335978216.16337.26.camel@x300.localdomain> <1335996931.16337.31.camel@x300.localdomain> Message-ID: <1336085681.30868.14.camel@x300.localdomain> > I guess FastCGI is supposed to be a long-running process in principle; > however, I just learned from the folks who administer the servers that > our FastCGI processes are automatically terminated after 15 minutes of > inactivity and must be relaunched upon the next visit after that. This > is definitely one cause of the sluggishness, That sounds a bit weird. Usually startup of such a process should take less than a second (assuming that the machine is not totally overloaded) and afterwards it should be quick as long as you use it. So I have doubts this really is your problem. From mcs_moinmoin at savigear.com Fri May 4 18:29:00 2012 From: mcs_moinmoin at savigear.com (Matt Savigear) Date: Fri, 04 May 2012 23:29:00 +0100 Subject: [Moin-user] Adding an ID to a parsed HTML entity Message-ID: <4FA4582C.4020800@savigear.com> Hi, I'm trying to find the easiest way to generate a "tree style" table of contents for my MoinMoin instance. What I need is a series of nested accordions or a full on tree with open/close widgets to the left as you would find in a standard folder-type or directory browser. Now, I can easily create nested lists using the default wiki parser, but I'd like to know if there is a way of adding an "id" tag to the top level

I would like to give the user an opportunity to select text. More precisely: program code. Of course I would prefer a button "Copy code" but I don't want a Flash or a Java solution and simple JavaScript solutions seem to work only in Internet Explorer. Anyway, my audience are programmers, selecting the text as a result of a click on a "Hightlight code" button is okay, they can press Crl+C themselves. I found some JavaScript which seems to be doing what I am after. All I need to do is to create a link or a button that executes that piece of JavaScript. I took a naive approach: {{{#!html }}} Unfortunately Moin changes this code into which naturally has no affect at all. What is the right way to do this? My guess is that it cannot be done without some Python code which in turn calls the JavaScript code? Kai From tw at waldmann-edv.de Sat May 12 10:46:18 2012 From: tw at waldmann-edv.de (Thomas Waldmann) Date: Sat, 12 May 2012 16:46:18 +0200 Subject: [Moin-user] Selecting text In-Reply-To: References: Message-ID: <1336833978.17374.4.camel@x300.localdomain> > I took a naive approach: > > {{{#!html > > }}} The html parser removes potentially dangerous stuff, that includes javascript code. You could either use some unsafe html parser (and make sure nobody can use it for dangerous stuff) or just write a macro that emits the stuff you need. From longyongbiao at gmail.com Sat May 12 12:29:32 2012 From: longyongbiao at gmail.com (Yongbiao Long) Date: Sun, 13 May 2012 00:29:32 +0800 Subject: [Moin-user] How to create a batch of accounts quickly Message-ID: Hello, I installed moinmoin on a debian machine. It will be used only in a small group (about 100 person) in campus. I want to create an account for each of them in advance. I have a list email addresses. Can I create accounts given that? I have low security requirements, so the username and password can just be same as the name of their email address. -- Best Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From rb.proj at gmail.com Sat May 12 13:56:49 2012 From: rb.proj at gmail.com (R.Bauer) Date: Sat, 12 May 2012 19:56:49 +0200 Subject: [Moin-user] How to create a batch of accounts quickly In-Reply-To: References: Message-ID: On 12.05.2012 18:29, Yongbiao Long wrote: > Hello, I installed moinmoin on a debian machine. It will be used > only in a small group (about 100 person) in campus. I want to > create an account for each of them in advance. Hi I often use for that purpose: http://hg.moinmo.in/moin/extensions/file/tip/data/plugin/script/account/create_many.py It is an extension for the moin command. > > I have a list email addresses. Can I create accounts given that? > > I have low security requirements, so the username and password > can just be same as the name of their email address. You don't need to know, because the user can just create a recovery token and choose the password he likes. cheers Reimar > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > _______________________________________________ > Moin-user mailing list > Moin-user at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/moin-user From rb.proj at gmail.com Sun May 13 05:05:00 2012 From: rb.proj at gmail.com (Reimar Bauer) Date: Sun, 13 May 2012 11:05:00 +0200 Subject: [Moin-user] Adding an ID to a parsed HTML entity In-Reply-To: <4FA4582C.4020800@savigear.com> References: <4FA4582C.4020800@savigear.com> Message-ID: Am 05.05.2012 00:29, schrieb Matt Savigear: > Hi, > > I'm trying to find the easiest way to generate a "tree style" table of > contents for my MoinMoin instance. What I need is a series of nested > accordions or a full on tree with open/close widgets to the left as you > would find in a standard folder-type or directory browser. Look at the explorer theme on theme market I guess that is a similar idea Reimar > > Now, I can easily create nested lists using the default wiki parser, but > I'd like to know if there is a way of adding an "id" tag to the top > level

Hi, because I'm experiencing some performace issues with my moinmoin wiki, I've tried to enable timing.log feature. I've added "log_timing = True" to my wikiconfig (and my SystemInfo page shows it set), but the timing.log wasn't created. I've tried fresh installation of MoinMoin 1.9.3 on localhost and got same problem, so it seems to me, I've forgot some configuration steps, but only information I can find is one paragraph in 1.5.8 changelog saying I need only set the log_timing variable. MoinMoin version: 1.9.3, Python 2.6.6, System: Debian Sorry, for my english, I know it's terrible, but I hope it's possible to understand. Thanks for help. -- Regards Vojt?ch Trefn? From mark.scheufele at diasemi.com Mon May 21 02:48:39 2012 From: mark.scheufele at diasemi.com (Mark Scheufele) Date: Mon, 21 May 2012 06:48:39 +0000 Subject: [Moin-user] Activate timing.log In-Reply-To: References: Message-ID: <39080CC9D403A94F992B5A8183FE77BC6BC35F01@NB-EX-MBX01.diasemi.com> Hi Vojt?ch, I had to set show_timings=True within wikiconfig.py to enable it ( moinmoin 1.9.3 on windows). BR, mark -----Original Message----- From: Vojt?ch Trefn? [mailto:vojtech.trefny at gmail.com] Sent: Freitag, 18. Mai 2012 20:39 To: moin-user at lists.sourceforge.net Subject: [Moin-user] Activate timing.log Hi, because I'm experiencing some performace issues with my moinmoin wiki, I've tried to enable timing.log feature. I've added "log_timing = True" to my wikiconfig (and my SystemInfo page shows it set), but the timing.log wasn't created. I've tried fresh installation of MoinMoin 1.9.3 on localhost and got same problem, so it seems to me, I've forgot some configuration steps, but only information I can find is one paragraph in 1.5.8 changelog saying I need only set the log_timing variable. MoinMoin version: 1.9.3, Python 2.6.6, System: Debian Sorry, for my english, I know it's terrible, but I hope it's possible to understand. Thanks for help. -- Regards Vojt?ch Trefn? ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Moin-user mailing list Moin-user at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/moin-user _______________________________________________________________________________________ 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 rtatum at spsu.edu Sat May 26 00:53:28 2012 From: rtatum at spsu.edu (Rashad Tatum) Date: Sat, 26 May 2012 00:53:28 -0400 Subject: [Moin-user] Developer Introduction Message-ID: MoinMoin Developers, My name is Rashad Tatum. John Sullivan recently contacted me and requested that I introduce myself to the MoinMoin community. I am currently a senior student at Southern Polytechnic State University studying Computer Science and Mathematics. I have expressed interest in helping with the MoinMoin project. I am particularly interested in helping convert wiki pages to MoinMoin. Please let me know how I may help. Thanks, Rashad -------------- next part -------------- An HTML attachment was scrubbed... URL: From tw-public at gmx.de Sat May 26 13:44:32 2012 From: tw-public at gmx.de (Thomas Waldmann) Date: Sat, 26 May 2012 19:44:32 +0200 Subject: [Moin-user] Developer Introduction In-Reply-To: References: Message-ID: <1338054272.4471.24.camel@x300.localdomain> Hi Rashad, Feel welcome! > I am particularly interested in helping convert wiki pages to > MoinMoin. You mean from confluence wiki to moin wiki? > > Please let me know how I may help. Regarding the confluence-to-moin stuff, I must admit that I am not really up-to-date with it / with its current state. But maybe just join us on #moin-dev IRC channel, there is always lots to do to improve things. :) Cheers, Thomas From chmberg at gmail.com Thu May 31 11:16:26 2012 From: chmberg at gmail.com (Christian Meisenbichler) Date: Thu, 31 May 2012 17:16:26 +0200 Subject: [Moin-user] EventCalendar moin 1.9.3 Message-ID: Hi, I am trying to get the Eventcalendar macro working. I have installed moin from the debian package version 1.9.3. The EventCalendar macro with the patches for 1.9.2 ( http://moinmo.in/4ct10n/show/MacroMarket/EventCalendar?action=show&redirect=ExtensionProposals%2FEventCalendar#v0.99a ) almost works. Almost! Only, the macro ignores all parameters, such on cannot change the view or to another month. Also the events are not updated, unless, one deactivates and reactivates the macro in the life page. (emptying cache doesn't help) I did try to use older versions of moinmoin too, but so far the arguments are ignored in moin 1.9.2 and 1.8.4. Moin 1.8.4 is listed as tested with 0.99a but as far as i can tell it doesn't work too. I really would like to use the macro, but before I try to learn how everything works and try fix it myself, I would rather ask whether someone has any experience with that. Cheers From takeo.katsuki at gmail.com Thu May 31 11:47:40 2012 From: takeo.katsuki at gmail.com (Takeo Katsuki) Date: Thu, 31 May 2012 08:47:40 -0700 Subject: [Moin-user] EventCalendar moin 1.9.3 In-Reply-To: References: Message-ID: Hi, EventCalendar macro is working fine with my MoinMoin 1.9.4, Python 2.6 on an Ubuntu Server. Calendars can be updated by the Delete Cache Action too. So I am not sure why it is not working in your environment, but I don't think it is a simple version issue. Best, Takeo On Thu, May 31, 2012 at 8:16 AM, Christian Meisenbichler wrote: > Hi, > I am trying to get the Eventcalendar macro working. I have installed > moin from the debian package version 1.9.3. The EventCalendar macro > with the patches for 1.9.2 > ( http://moinmo.in/4ct10n/show/MacroMarket/EventCalendar?action=show&redirect=ExtensionProposals%2FEventCalendar#v0.99a > ) > almost works. > Almost! Only, the macro ignores all parameters, such on cannot change > the view or to another month. Also the events are not updated, unless, > one deactivates and reactivates the macro in the life page. (emptying > cache doesn't help) > > I did try to use older versions of moinmoin too, but so far the > arguments are ignored in moin 1.9.2 and 1.8.4. Moin 1.8.4 is listed as > tested with 0.99a but as far as i can tell it doesn't work too. > > I really would like to use the macro, but before I try to learn how > everything works and try fix it myself, I would rather ask whether > someone has any experience with that. > > Cheers > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Moin-user mailing list > Moin-user at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/moin-user