[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
@@ -113,20 +113,21 @@
         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] 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] 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] 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] Trac 0.11.5rc1 Released

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:

 * Implemented pre-upgrade backup support for PostgreSQL and MySQL.
 * Fixed PostgreSQL upgrade issue (#8378)
 * More robust diff parsing (#2672)
 * Avoid intermittent hangs by not calling apr_terminate explicitly.

You can find a more detailed release note at:
http://trac.edgewall.org/wiki/TracDev/ReleaseNotes/0.11

Acknowledgements
================

Many thanks to the growing number of people who have, and continue to,
support the project. Also our thanks to all people providing feedback
and bug reports that helps us make Trac better, easier to use and more
effective.
Without your invaluable help, Trac would not evolve. Thank you all.

Finally, we offer hope that Trac will prove itself useful to like-
minded programmers around the world, and that this release will prove an

[Trac-dev] Real name / nick instead of username

Are there any updates regarding this issue?
Lot of people would love to see real names instead of usernames that
are not easy to remember.

Jan

--~--~---------~--~----~------------~-------~--~----~
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] getting rid of the old svk:merge properties?

Hello,

I'd like to remove the various svk:merge properties scattered in the tree.
It contains out-dated information and AFAIK, no one actively developing 
on Trac still uses svk.

Ok to delete them?

-- Christian

--~--~---------~--~----~------------~-------~--~----~
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] Add a FORM to a specific report

Hi all,

I am trying to add a FORM to a report where user have to insert two
date times
Example:

Choose delivery date between:    DD/MM/YYY       and        DD/MM/
YYYY          Submit

I would like to get those two values and insert them into the sql
query which permits to create the report.

I tryed using this condition in my query :
AND (c10.value between 'date_start' and '.date_end' )   ( c10.value is
my the delivery date)

But it doesn't work.

Please could you help me?????

Thanks,

Zineb
--~--~---------~--~----~------------~-------~--~----~
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] URL hex encoding in Query.to_string()

I asked about this a little while ago in IRC, but it seems pretty dead
right now, so figure I'll ask here too.

When I save a custom query containing a filter such as "summary=~foo",
it's displayed in the save report page as "summary=%7Efoo".  I know
that this is due to Query.to_string() just being a thin wrapper around
Query.get_href().  But I thought that at least this was fixed a long
time ago.  Is this a regression, or was it never fixed?

I simply modified my to_string to wrap the call to self.get_href() in
unicode_unquote().  That solves the problem nicely, and doesn't seem
to have any adverse effects.

You'd think there'd be a ticket addressing this somewhere, but I
couldn't find one.
--~--~---------~--~----~------------~-------~--~----~
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] performance and garbage collection

Hello,
I've been looking into performance and profiling, and noticed the 
gc.collect that happens at the end of every request (in trac.web.main). 
  On my osx dev box, this garbage collection is taking roughly 37% of 
the request time on a simple template, and removing it shows the roughly 
the same percent increase in requests/second (with ab).  I haven't 
tested with more intensive templates (e.g. reports or timeline) where I 
assume it would take less percent, however this is pretty significant.

Removing it unfortunately introduces some issues with the database pool 
and postgres (may be more related to how we're using the database).  It 
also looks like, based on ticket 6614, that it will introduce a number 
of other issues if it is removed.  I haven't fully digested 6614 yet, 
it's pretty lengthy.

I'm just wondering if anyone has any comments or thoughts about this.

Regards,
Shane

--~--~---------~--~----~------------~-------~--~----~
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] NEW BSD license