headers
Alec Thomas | 1 Jan 2008 05:14
Gravatar

[Trac-dev] Re: Tags 0.5 released for Trac 0.11


Just a few notes for any plugin authors using Tags:

The 0.5 release is a basic port to Trac 0.11, its API and functionality
remain the same. The implication of this is that it does *not* support
the new security or resource systems in Trac 0.11. There will be no
further development on this version, only bug-fixes.

I have almost finished a complete rewrite that adds these features and
cleans up the internal API and code significantly. This will be released
as Tags 0.6 and will be the "supported" version going forward. This also
removes all the legacy macro support carried over from Muness' original
code: TagIt and ListTags are gone. The remaining macros, TagCloud and
ListTagged, have changed their calling convention:

  TagCloud([query])
  ListTagged([query])

The query syntax has also changed:

  AND: tag1 tag2
  OR: tag1 or tag2
  NOT: -tag1
  In a specific realm: realm:wiki
  Sub-expressions are supported: (tag1 or tag2) and tag3

And the output is visually quite different. The tags module uses the
resource system to render the tagged resources as well as the tags
themselves. What this means is that the display is completely dependent
on how the IResourceManager for a particular resource renders it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonas Borgström | 1 Jan 2008 14:09
Favicon

[Trac-dev] Re: t.e.o upgraded to 0.11 beta1


FYI t.e.o is now running 0.10 again since 0.11 apparently has some 
memory usage issues. Last night the server grinded to a halt when a 
bunch of trac fcgi processes each allocating more than 600MB resident 
memory.

I've not yet identified which pages require this much memory but I would 
not be surprised if it's some of the more expensive versioncontrol 
pages.

As far as I know memory allocated by the python interpreter is almost 
never returned to the operating system so a single memory hungry page 
can case this type of problem when using long running processes such as 
fastcgi and tracd.

As a comparison with Trac 0.10 each trac process on t.e.o never seems to 
allocate more than 100MB. And this server is 64bit so memory usage 
should be even lower on 32bit systems.

Some relevant reading:
http://wingolog.org/archives/2007/11/27/reducing-the-footprint-of- 
python-applications

Cheers,
Jonas

--~--~---------~--~----~------------~-------~--~----~
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
(Continue reading)

Permalink | Reply | 46 comments |
headers
djeffdionne@gmail.com | 1 Jan 2008 14:25
Picon

[Trac-dev] mercurial-plugin-0.11 needs require updated...


The plugin doesn't load in 0.11b1 because of a version conflict,
resulting in "Warning: Can't synchronize with the repository"...  This
changes the version number.

Cheers,
J.

diff -ur mercurial-plugin-0.11/tracext/hg/backend.py mercurial-
plugin-0.11b1/tracext/hg/backend.py
--- mercurial-plugin-0.11/tracext/hg/backend.py	2008-01-02
05:57:07.000000000 +0900
+++ mercurial-plugin-0.11b1/tracext/hg/backend.py	2008-01-02
06:45:48.469314813 +0900
 <at>  <at>  -16,7 +16,7  <at>  <at> 
 import re

 import pkg_resources
-pkg_resources.require('Trac>=0.11dev')
+pkg_resources.require('Trac>=0.11b1')

 from genshi.builder import tag

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
(Continue reading)

Permalink | Reply | 1 comment |
headers
djeffdionne@gmail.com | 1 Jan 2008 15:30
Picon

[Trac-dev] Re: mercurial-plugin-0.11 needs require updated...


Hi all,

With this one, the fix is not obvious to me...

Possibly related to the mercurial plugin (I don't have any svn
repositories so I can't
test), resync doesn't seem to be working correctly...

Osaka:/srv/www/htdocs/trac # trac-admin /srv/www/htdocs/trac resync
Resyncing repository history...
Traceback (most recent call last):
  File "/usr/local/bin/trac-admin", line 8, in <module>
    load_entry_point('Trac==0.11b1', 'console_scripts', 'trac-admin')
()
  File "/usr/local/lib/python2.5/site-packages/Trac-0.11b1-py2.5.egg/
trac/admin/console.py", line 1194, in run
    return admin.onecmd(command)
  File "/usr/local/lib/python2.5/site-packages/Trac-0.11b1-py2.5.egg/
trac/admin/console.py", line 102, in onecmd
    rv = cmd.Cmd.onecmd(self, line) or 0
  File "/usr/lib/python2.5/cmd.py", line 219, in onecmd
    return func(arg)
  File "/usr/local/lib/python2.5/site-packages/Trac-0.11b1-py2.5.egg/
trac/admin/console.py", line 629, in do_resync
    repos = env.get_repository().sync(self._resync_feedback)
TypeError: sync() takes exactly 1 argument (2 given)
Osaka:/srv/www/htdocs/trac # trac-admin /srv/www/htdocs/trac resync
6452
Traceback (most recent call last):
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charlie Woloszynski | 1 Jan 2008 17:22
Picon

[Trac-dev] What is t.e.o


I am looking to migrate to 0.11 on a leopard server, and I saw the  
notes shot t.e.o but I dont know what that is.

Sent from my iPhone

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 1 comment |
headers
Sebastien Douche | 1 Jan 2008 18:09
Picon
Gravatar

[Trac-dev] Re: What is t.e.o


On Jan 1, 2008 5:22 PM, Charlie Woloszynski <cwoloszynski <at> gmail.com> wrote:
> I am looking to migrate to 0.11 on a leopard server, and I saw the
> notes shot t.e.o but I dont know what that is.

Short name of trac.edgewall.org :)

--

-- 
Solution Linux (février)
XPDays FR (mai)
Journée Francophone Python (juin)

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |
headers
Noah Kantrowitz | 1 Jan 2008 22:24
Picon
Favicon

[Trac-dev] Re: t.e.o upgraded to 0.11 beta1


Just as a point of comparison, this is from dev.laptop.org:

   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
22732 www-data  15   0 2625m 2.5g 3548 S    0 32.2 317:02.53 trac.fcgi
15142 www-data  15   0  511m 407m 3536 S    0  5.1  46:46.00 trac.fcgi
23190 www-data  15   0  437m 393m 3524 S    0  4.9  42:09.89 trac.fcgi
19822 www-data  15   0  216m 142m 3516 S    0  1.8  13:06.86 trac.fcgi

--Noah Kantrowitz

On Jan 1, 2008, at 5:09 AM, Jonas Borgström wrote:

>
> FYI t.e.o is now running 0.10 again since 0.11 apparently has some
> memory usage issues. Last night the server grinded to a halt when a
> bunch of trac fcgi processes each allocating more than 600MB resident
> memory.
>
> I've not yet identified which pages require this much memory but I  
> would
> not be surprised if it's some of the more expensive versioncontrol
> pages.
>
> As far as I know memory allocated by the python interpreter is almost
> never returned to the operating system so a single memory hungry page
> can case this type of problem when using long running processes such  
> as
> fastcgi and tracd.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alec Thomas | 2 Jan 2008 05:22
Gravatar

[Trac-dev] add_notice


Hi,

I've been porting plugins to 0.11 for the last couple of days and the
experience has overall been quite pleasant.

Highlights include:

  - add_warning(). Very useful!

    I'd like to propose that we also include an add_notice() function
    before 0.11 is released. This would allow non-warning informational
    messages. Refactor add_warning() to use the general purpose
    add_notice() function. This would be *very* useful for plugins
    wanting to send messages to the user. In its stead, plugins will
    write their own bespoke solutions or use add_warning() (which is
    what I'm currently doing).

    What's the opinion? I'm happy to do the work.

  - The new resource API. Very nice, osimons and I have both used it to
    create resource managers for blog and tags respectively. The utility
    functions are a bit cumbersome, but it's not a huge deal. eg.

      anchor = render_resource_link(self.env,
      Context.from_request(req, resource), resource)

    Maybe this could become:

      anchor = render_resource_link(self.env, req, resource)
(Continue reading)

Permalink | Reply | 8 comments |
headers
Noah Kantrowitz | 2 Jan 2008 05:36
Picon
Favicon

[Trac-dev] Re: add_notice


On Jan 1, 2008, at 8:22 PM, Alec Thomas wrote:

>
> Hi,
>
> I've been porting plugins to 0.11 for the last couple of days and the
> experience has overall been quite pleasant.
>
> Highlights include:
>
>  - add_warning(). Very useful!
>
>    I'd like to propose that we also include an add_notice() function
>    before 0.11 is released. This would allow non-warning informational
>    messages. Refactor add_warning() to use the general purpose
>    add_notice() function. This would be *very* useful for plugins
>    wanting to send messages to the user. In its stead, plugins will
>    write their own bespoke solutions or use add_warning() (which is
>    what I'm currently doing).
>
>    What's the opinion? I'm happy to do the work.

If we want to go in this direction, making something more compatible  
with the standard logging module might be nice.

add_warning(req, msg) -> req.log.warn(msg)

I realize this is almost the exact opposite of the last change, but at  
least it would centralize things. We could even use the logging module
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alec Thomas | 2 Jan 2008 05:59
Gravatar

[Trac-dev] Re: add_notice


On 02/01/2008, Noah Kantrowitz <kantrn <at> rpi.edu> wrote:
> If we want to go in this direction, making something more compatible
> with the standard logging module might be nice.
>
> add_warning(req, msg) -> req.log.warn(msg)
>
> I realize this is almost the exact opposite of the last change, but at
> least it would centralize things. We could even use the logging module
> and just make a new backend (not sure how that works, but I think it
> is possible). Thoughts?

This is a pretty cool idea. It'd be nice to have TracErrors rendered
in-page via req.log.error() as well. My only real concern is that it
might be overkill at this late stage, whereas add_notice() would be a
minor change.

To expand on my original requirements, I have two use-cases (so far) for
this on the new Trac-Hacks:

  - I'll be rendering informational messages about the tags on each hack
    page. eg. A page with the 0.11 tag will have the message:

      "This hack works with Trac 0.11"

    One with "unsupported" will render:

      "This hack is not supported by its author."

    and so-on.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane