[Trac-dev] Re: Trac 0.11.5rc1 Released

Hello,

Thanks for having completed the rc1 release!
Sorry I couldn't assist yesterday.

A minor suggestion: the final announcement could be made more "attractive":

Jonas Borgström wrote:
> Trac 0.11.5rc1 (Release Candidate 1)
> ====================================
>
> This is the first and hopefully final release candidate for the
> upcoming 0.11.5 release. 0.11.5 (final) is scheduled for release on
> July 7.
>
> Trac 0.11.5rc1 contains a number of bug fixes and minor enhancements.
> The following list contains only a few highlights:
>
>   
Instead of:
>  * Implemented pre-upgrade backup support for PostgreSQL and MySQL.
>  * Implemented pre-upgrade backup support for PostgreSQL and MySQL.
>
>  * More robust diff parsing (#2672)
>  * Avoid intermittent hangs by not calling apr_terminate explicitly.
>   
Have:

 * Fixed serveral Subversion issues (one memory leak, svn 1.6 support)

[Trac-dev] Re: plugin performance issues

Shane Caraveo wrote:
> I've been running through a lot of code looking at performance issues 
> lately, and am wondering if there is a general document for plugin 
> authors that highlights potential/common performance problems and how to 
> avoid them.  I'm not sure if I'm rediscovering common knowledge or not :)

I don't believe that there is a document that contains that info.  Other
than code, there isn't a huge exhaustive document on plugin development

>  From what I've seen so far, IRequestHandler.match_request and 
> ITemplateStreamFilter.filter_stream are two area's where performance can 
> (and is) hurt by plugins doing more than they should.  I'm not certain 
> the issue is those mechanisms specifically, but rather how they get 
> used.  Just one example, not picking on anyone as I have several 
> examples, the timing and estimation plugin is a major user of stream 
> filters, and in some cases more than doubled the request times.

So, not quite sure what one would be doing in match_request to make it
take a long time (permission checks, perhaps?), but StreamFilters will
definitely affect performance, as you have discovered.  This is due to
genshi.  I know that some work was done on making some speed
improvements in this areas (or maybe it was just template includes).
However, it's just an expensive process.

> If there is not such a document, I think it would be useful to try and 
> get one together.  I'd be happy to help with the area's I've figured 
> out, but someone with longer experience working with genshi and trac 
> internals should, at a minimum, validate the information.

[Trac-dev] Re: plugin performance issues

On 7/1/09 5:05 PM, John Hampton wrote:
> Shane Caraveo wrote:

>>    From what I've seen so far, IRequestHandler.match_request and
>> ITemplateStreamFilter.filter_stream are two area's where performance can
>> (and is) hurt by plugins doing more than they should.  I'm not certain
>> the issue is those mechanisms specifically, but rather how they get
>> used.  Just one example, not picking on anyone as I have several
>> examples, the timing and estimation plugin is a major user of stream
>> filters, and in some cases more than doubled the request times.
>
> So, not quite sure what one would be doing in match_request to make it
> take a long time (permission checks, perhaps?),

I've seen permission checks, uncompiled regex matching, and other more 
minor things.  It seems to me anything other than a 
req.path_info.startswith(/mypath) is too much.  I wonder if there would 
be a better mechanism for this.

> but StreamFilters will
> definitely affect performance, as you have discovered.  This is due to
> genshi.  I know that some work was done on making some speed
> improvements in this areas (or maybe it was just template includes).
> However, it's just an expensive process.

There's definitely some improvement in genshi trunk, but it's still 
slow.  I've profiled some basic requests, genshi 5 takes around 25% of 
the request time.  With trunk it's down to probably 20%.  It seems to be 
primarily the xpath matching, but it's hard to tell, combining 

[Trac-dev] time_created in ticket notification email, possible?

Hi,

I'm trying to add the time the ticket was opened to the ticket
notification email. I modify ticket_notify_email.txt, but it looks
like $ticket.time_created is blank. Can I get this information
somewhere?

Thanks.

-- 
Álvaro J. Iradier Muro
Departamento de Desarrollo
alvaro.iradier <at> polartech.es

Polar Technologies
T +34 976 527 952
F +34 976 466 125
www.polartech.es

Antes de imprimir este mensaje, por favor, compruebe que es verdaderamente
necesario. El medioambiente es cosa de todos.

AVISO LEGAL
Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener
información confidencial, siendo para uso exclusivo del destinatario,
quedando prohibida su divulgación, copia o distribución a terceros sin la
autorización expresa del remitente. Si Vd. ha recibido este mensaje
erróneamente, se ruega lo notifique al remitente y proceda a su borrado.
Gracias por su colaboración.

[Trac-dev] POST in wiki web handler

Hi,

is there any reason why the process_request method in WikiModulo does
nothing if method is 'POST' and action is not specified? The current
0.11.4 wiki/web_ui.py code looks like:

131	        if req.method == 'POST':
132	            if action == 'edit':
...
148	            elif action == 'diff':
149	                get_diff_options(req)
150	                req.redirect(req.href.wiki(versioned_page.name,
action='diff',
151	                                           old_version=old_version))
152	        elif action == 'delete':
...
160	        else:
161	            format = req.args.get('format')
162	            if format:
163	                Mimeview(self.env).send_converted(req, 'text/x-trac-wiki',
164	                                                  versioned_page.text,
165	                                                  format,
versioned_page.name)
166	            return self._render_view(req, versioned_page)

We are working in some special macros that show a form in the wiki and
do some processing, but we have to use GET method for those macro
forms, as using GET results in the request not being processed by the
Wiki module, so the macro is not run, and an error being thrown

[Trac-dev] Re: POST in wiki web handler

On Jul 2, 2:50 pm, Álvaro J. Iradier <alvaro.irad... <at> polartech.es>
wrote:
> We are working in some special macros that show a form in the wiki and
> do some processing, but we have to use GET method for those macro
> forms, as using GET results in the request not being processed by the
> Wiki module, so the macro is not run, and an error being thrown
> (Response not started when writing headers).
>
> Would it do any harm just to unindent line number 166, so if method is
> POST, but action is unespecified, fallback to default processing?

As the Zen of Python says, "In the face of ambiguity, refuse the
temptation to guess." There is no 'default' action, and we don't know
if your POST arguments contains what Trac would need to do.

There is a plugin at Trac-Hacks.org that "arranges" POST support for
macros - it is currently used by AddCommentMacro for instance (as a
plugin requirement):

http://trac-hacks.org/wiki/MacroPostPlugin

:::simon

https://www.coderesort.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev+unsubscribe <at> googlegroups.com

[Trac-dev] Re: plugin performance issues

On Wed, Jul 1, 2009 at 8:05 PM, John Hampton<pacopablo <at> pacopablo.com> wrote:
>
> Shane Caraveo wrote:
>> I've been running through a lot of code looking at performance issues
>> lately, and am wondering if there is a general document for plugin
>> authors that highlights potential/common performance problems and how to
>> avoid them.  I'm not sure if I'm rediscovering common knowledge or not :)
>
> I don't believe that there is a document that contains that info.  Other
> than code, there isn't a huge exhaustive document on plugin development
>
>>  From what I've seen so far, IRequestHandler.match_request and
>> ITemplateStreamFilter.filter_stream are two area's where performance can
>> (and is) hurt by plugins doing more than they should.  I'm not certain
>> the issue is those mechanisms specifically, but rather how they get
>> used.  Just one example, not picking on anyone as I have several
>> examples, the timing and estimation plugin is a major user of stream
>> filters, and in some cases more than doubled the request times.
>
> So, not quite sure what one would be doing in match_request to make it
> take a long time (permission checks, perhaps?), but StreamFilters will
> definitely affect performance, as you have discovered.  This is due to
> genshi.  I know that some work was done on making some speed
> improvements in this areas (or maybe it was just template includes).
> However, it's just an expensive process.

Though if handled with care, template stream filters shouldn't kill
you *that* much.  Our batch ticket update plugin, for example, does
quite a number of transformations on report and query pages. But even

[Trac-dev] Some small cleanup patches in the db backends

While looking at the postgres backends, I added some small cleanup 
patches to db backends which are not really bugs.

How do you want to deal with patches like these?
  - Should there always be a bug report?
  - Do you want patches for more or less cosmetic changes at all?

fs

diff -r bde1a821a377 trac/db/postgres_backend.py
--- a/trac/db/postgres_backend.py	Fri Jul 03 12:48:17 2009 +0200
+++ b/trac/db/postgres_backend.py	Fri Jul 03 12:55:12 2009 +0200
 <at>  <at>  -113,20 +113,21  <at>  <at> 
         scheme, db_prop = _parse_db_str(db_url)
         db_prop.setdefault('params', {})
         db_name = os.path.basename(db_prop['path'])
+        db_params = db_prop['params']

         args = [self.pg_dump_path, '-C', '-d', '-x', '-Z', '8']
         if 'user' in db_prop:
             args.extend(['-U', db_prop['user']])
-        if 'host' in db_prop['params']:
-            host = db_prop['params']['host']
+        if 'host' in db_params:
+            host = db_params['host']
         else:
             host = db_prop.get('host', 'localhost')

[Trac-dev] Re: Some small cleanup patches in the db backends

-On [20090703 13:58], Felix Schwarz (felix.schwarz <at> agile42.com) wrote:
>How do you want to deal with patches like these?
>  - Should there always be a bug report?

Given we're making an issue tracker, yes. :)

--

-- 
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
I am not a teacher but an awakener...

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Trac-dev] trac multirepos branch and Hg 1.3