Team Chat Logs

May 20, 2010

2010 4
Mo Tu We Th Fr Sa Su
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
<< <   > >>

[00:28:02.244766]<macmaN>hrrrrrr
[00:28:11.925469]<macmaN>morning is early
[00:48:46.795654]<kirean>macmaN: as always ;-)
[02:20:33.197765]<tobago>my trac is running with tracd on port 8000. then i tried to use the same trac to run it with apache2. that is what i furthermore did: http://gist.github.com/407386
[02:20:40.486394]<tobago>but it fails.
[02:23:22.698850]<kirean>tobago: http://tinyurl.com/39tecen
[02:40:55.607368]<tobago>kirean, it helped: chmod 755 /var/trac/cgi-bin/*
[02:41:01.230644]<tobago>kirean, thanks a lot.
[03:17:42.598260]<tobago>kirean, then i tried to set the admin permissions: http://gist.github.com/407427 i reading the http://trac.edgewall.org/wiki/TracCgi#AddingAuthentication, it should work (but it does not).
[03:51:19.284598]<kirean>tobago: pastebin you apache config
[03:51:26.739994]<kirean>s/you/your
[03:51:26.752534]<evil_twin>kirean meant: tobago: pastebin your apache config
[03:59:13.703576]<heavenquake>hello, I'm running trac 0.11.1 and I can see in TracReports that the feature is/was being phased out by that time, intended to be replaced with Queries. How far is this outphasing process in the current Trac version?
[04:00:49.359726]<kirean>heavenquake: I don't think it will be completly removed since you can do more magic when having reports
[04:01:04.059475]<kirean>heavenquake: but use queries if possible instead of reporst
[04:01:12.474738]<kirean>s/reporst/reports
[04:01:12.521153]<evil_twin>kirean meant: heavenquake: but use queries if possible instead of reports
[04:02:17.277655]<heavenquake>kirean, the thing is that I would like to save a custom query (being far more intuitive and much less work than an sql report) in the reports list when clicking View Tickets
[04:02:31.311395]<heavenquake>I can't do that, at least not in 11.1
[04:02:41.358233]<heavenquake>as far as I know
[04:09:36.722836]<kirean>heavenquake: if not in 11.1, you sure can in newer releases
[04:10:44.994838]<heavenquake>kirean, this is what the internal wikipage on TracQuery says on my trac install: "While Trac does not yet allow saving a named query and somehow making it available in a navigable list, you can save references to queries in Wiki content, as described below. "
[04:11:05.504975]<heavenquake>is this feature added in newer versions?
[04:16:33.380773]<kirean>heavenquake: hmm, I just did
[04:16:33.564866]<kirean>run custom query, press save query and it's in the list of available reports
[04:17:38.805359]<heavenquake>that button isn't here, so that's bound to be an improvement in newer versions. what version are you running?
[04:18:33.643550]<kirean>latest 0.11
[04:18:39.366838]<kirean>maybe this have info: http://trac.edgewall.org/wiki/ChangeLog#a0.11.xReleases
[04:18:48.661735]<kirean>(I don't have time to look)
[04:18:54.932960]<kirean>need to run soon
[04:19:20.757497]<heavenquake>alright, thanks
[04:19:35.115692]<heavenquake>what are the implications of upgrading? is there a risk of data loss?
[04:20:07.168773]<kirean>heavenquake: hmm: http://trac.edgewall.org/wiki/0.11/TracQuery#SavingQueries
[04:20:20.390595]<kirean>and http://trac.edgewall.org/wiki/TracQuery#SavingQueries
[04:20:35.296418]<kirean>heavenquake: I'm guessing documentation for 0.11 isn't updated
[04:21:14.476358]<goshawk>how do i access a the webadmin of my trac project?
[04:21:46.670385]<kirean>heavenquake: but someone like osimons might give you a correct answer on that
[04:22:06.877514]<kirean>heavenquake: are you TRAC_ADMIN?
[04:23:01.938580]<heavenquake>kirean, I don't think I am currently, but I'm root on the server, so I can make myself that instantly
[04:23:09.688555]<goshawk>solved, nevermindf
[04:23:22.401105]<kirean>heavenquake: try that
[04:23:34.384249]<heavenquake>kirean, what for?
[04:23:55.558007]<kirean>heavenquake: it sounds reasonable to be some sort of admin to save reports/queries
[04:24:37.326989]<kirean>or maybe REPORT_ADMIN is enough
[04:24:47.250391]<heavenquake>kirean, actually, you're right. it gives me the save-button
[04:25:09.058601]<heavenquake>I'd guess that particular button is REPORT_CREATE
[04:25:12.456188]<kirean>heavenquake: excellent.. wierd that the docs are outdated
[04:25:22.680571]<heavenquake>thanks a lot :)
[04:25:47.626978]<kirean>heavenquake: np, have fun
[04:50:20.779746]<tobago>kirean, i already pasted my httpd.conf: http://gist.github.com/407427
[05:09:59.174178]<larsivi>I'm upgrading from the multirepo branch to trunk - but how should I do that in practice? it appears that it still wish to use the contents of the old egg
[05:10:04.127801]<larsivi>I'm using mod_wsgi
[06:02:28.779656]<beefcube>i have set the following in my trac.ini
[06:02:31.735857]<beefcube>log_file = log/trac.log
[06:02:31.921750]<beefcube>log_level = DEBUG
[06:02:31.935484]<beefcube>log_type = none
[06:03:15.146045]<beefcube>why isn't it logging to log/trac.log when started as a daemon?
[06:04:36.101083]<beefcube>nvm
[06:07:59.719870]<osimons>beasty: "nvm" == "log_type = file" perhaps? :-)
[06:08:44.153583]<osimons>oops. beefcube ^^ ... for you, not beasty (sorry)... tab-completion-amateurish-mistake...
[06:09:15.541786]<beefcube>osimons: i wish, still not logging after changing that :(
[06:09:36.404578]<osimons>permissions? can the webserver write to the dir/file?
[06:10:24.422965]<beefcube>yes
[06:12:23.150881]<osimons>this is usually always config mistake or permission error. i'd double check again. what if you to "tracd --port=8888 /path/to/env" - does it then log when you access this temp server?
[06:14:44.732888]<beefcube>ls -l preamble/preamble_trac/ (the env)
[06:14:49.535033]<beefcube>drwxr-xr-x 2 ovb ovb 4096 2010-05-07 06:22 log
[06:19:09.862439]<beefcube>nope, doesn't log with a temp server just created with tracd run as the same user that ran trac-admin
[06:19:31.445640]<beefcube>same log config
[06:20:39.642142]<osimons>hmmf...
[06:51:12.428605]<beefcube>time to fill some mail server space..
[06:52:25.692954]<heavenquake>beefcube, yeah, space is awful
[06:53:38.783603]<francky06l>Hello all, just installed trac and I do not see the browse button (for seeing the repo) .. Must be something I miss, but do not know where
[06:57:01.389072]*retracile grunts something spiteful about mornings.
[07:20:48.308240]<francky06l>well seems either easy or unknown problem .. btw it;s on windows ..
[07:23:58.362052]<osimons>@logging
[07:23:58.377012]<evil_twin>logging is http://trac.edgewall.org/wiki/TracLogging <-- Enable debug logging to file, ensure your environments log/ directory is writeable by your web server user, check for errors.
[07:24:13.067297]<osimons>francky06l: ^^ for you
[07:30:42.620076]<francky06l>evil_twin, osimons thanks I give a try, I will be back :-)
[07:35:01.132233]<francky06l>Seems it's binding .. but what to laod then ?
[07:35:08.629270]<francky06l>2010-05-20 16:28:14,190 Trac[svn_fs] INFO: Failed to load Subversion bindings
[07:35:10.146954]<francky06l>Traceback (most recent call last):
[07:35:11.612734]<francky06l> File "C:\Python25\lib\site-packages\trac\versioncontrol\svn_fs.py", line 265, in __init__
[07:35:13.107757]<francky06l> _import_svn()
[07:35:14.613107]<francky06l> File "C:\Python25\lib\site-packages\trac\versioncontrol\svn_fs.py", line 68, in _import_svn
[07:35:16.103399]<francky06l> from svn import fs, repos, core, delta
[07:35:18.154816]<francky06l> File "C:\Python25\lib\site-packages\svn\fs.py", line 19, in <module>
[07:35:20.178759]<francky06l> from libsvn.fs import *
[07:35:22.045079]<francky06l> File "C:\Python25\lib\site-packages\libsvn\fs.py", line 5, in <module>
[07:35:24.242790]<francky06l> import _fs
[07:35:26.173673]<francky06l>ImportError: DLL load failed: The specified procedure could not be found.
[07:39:08.799488]<osimons>@paste
[07:39:08.813879]<evil_twin>paste is http://paste.lisp.org/new/trac
[07:39:41.041225]<osimons>francky06l: ^^ next time :-) anyway, see the TracSubversion page to make sure that you get the right bindings and install them correctly
[07:40:33.197639]<francky06l>osimons: but that match my Apache version and Python ...
[07:40:38.536990]<osimons>you should have the bindings for python2.5 installed - they are downloadable from subversion project for windows, and should be next to the main subversion
[07:41:10.556289]<osimons>francky06l: right - so you installed the svn bindings for python2.5 and apache2.2 (or whatever)?
[07:41:27.383288]<francky06l>yes
[07:41:38.749686]<osimons>@wiki TracSubversion
[07:41:38.758336]<evil_twin>http://trac.edgewall.org/wiki/TracSubversion
[07:42:09.233256]<osimons>^^ check there to see if there is anything to test or double check. it is obvious that python can't load the bindings, so something wrong somewhere.
[07:44:10.444674]<osimons>there may be some relevant parts there for windows users about dll's. that said, i've used the installer for windows for years without issues - don't use it anymore, but never had any particular problems with earlier versions
[08:05:17.285953]<beasty>osimons: np ;)
[08:17:08.563561]<francky06l>osimons: thanks I will check all this again ...
[09:29:24.297068]<francky06l>osimons: I have tried almost all packages and I still get error .. There a bunch of packages for the python binfings .. (many time for same version etc ..) ..
[09:33:40.397703]<francky06l>osimons: I eventually got it working .... Thanks for all
[09:37:25.159176]<srl295>folks, good going on 0.12b1 - smooth upgrade from 0.10 so far on the test system. Quick question if I wanted to add a plugin to the new optional IRepositoryObserver interface, would it make sense to put that in a separate class so that on trac v.11 that class could just be disabled? My plugin may run in v11 and v12 for a little while.
[09:58:43.506125]<macmaN>why not?
[10:04:29.917588]<osimons>srl295: yes. use optional feature of setuptools to exclude the module if requirement is not met. not in theory a problem for the interface itself (it will just not be called for 0.11), but there will likely be errors for various imports and so on that your component would need from Trac 0.12+
[10:05:43.286975]<srl295>osimons: thanks. hoping to not need a split. it'll be interesting, though.
[10:06:11.232364]<osimons>srl295: very easy to do, actually. you decide.
[10:07:02.239306]<srl295>A fork is easy enough to do. I'm just trying to keep the Spaghetti down. :)
[10:07:24.384968]<osimons>srl295: examples from my blog plugin: http://trac-hacks.org/browser/fullblogplugin/0.11/setup.py - .spamfilter and .tags will only be enabled if spamfilterplugin and/or tagsplugin of correct versions are available
[10:08:18.568193]<srl295>oh! perfect
[10:08:19.342782]<srl295>thanks
[10:08:56.599330]<srl295>ttyl.
[11:07:42.938112]<srl295>0.11 had env.py:get_repository(self, authname=None), 0.12 has env.py:get_repository(self, reponame=None, authname=None). So calls to env.get_repository(req.authname) now fail because arg 1 became reponame. A backwards compatible fix to my plugin is to use env.get_repository(authname=req.authname). Is this python bext practice to use names? is this an API regression?
[11:36:51.541973]<srl295>s/API regression/unintended breaking API change/
[11:36:51.825369]<evil_twin>srl295 meant: 0.11 had env.py:get_repository(self, authname=None), 0.12 has env.py:get_repository(self, reponame=None, authname=None). So calls to env.get_repository(req.authname) now fail because arg 1 became reponame. A backwards compatible fix to my plugin is to use env.get_repository(authname=req.authname). Is this python bext practice to use names? is this an unintended
[11:36:56.827925]<evil_twin> breaking API change?
[11:38:30.258418]<srl295>haha... exactly.
[11:40:33.663662]<osimons>srl295: the changes between 0.11 (single) and 0.12 (multirepos) are so great that things better break rather than fail silently....
[11:41:43.569745]<osimons>srl295: still, always good practice to use names for kwargs, and not depend on their placement as if they were args...
[11:52:01.795200]<srl295>osimons: it's not a bug, is what you are saying.. is there a way to require kwargs? Actually in this case I sholdn't have been passing req.authname because that was the default anyways. Then I'm only broken in not supporting multirepos : )
[11:54:26.181258]<osimons>srl295: yeah. things will break in unknown ways - or if it works anyway, you will be stuck with default repos only (ie. 0.11-like behaviour for main repos)
[12:01:28.193735]<srl295>osimons: 0.11-like behavior is fine for now.
[12:45:22.841269]<rapha>Hi all!
[12:45:37.541414]<rapha>Is there any way to make reports reorderable? A plugin or else?
[12:49:37.742144]<rts>rapha: what do you mean by reorderable? you can always order the reports by editing the reports and then ordering by the order that you want, incl. also grouping
[12:50:48.541553]<rapha>rts: I mean, make them drag-and-drop'able. I.e. if I want to see report #7 higher up in the list as report #1, I just drag it there.
[12:51:27.537459]<rts>rapha: yep, you can, by implementing such a feature by yourself ;)
[12:54:47.604165]<rapha>oh
[12:54:58.442182]<rapha>would that be difficult to do? could you teach me how to do it?
[12:55:24.949477]<rapha>(I do know a bit of HTML and jQuery, but almost none Python)
[12:55:30.570000]<rapha>no*
[12:55:57.190256]<rts>rapha: teaching is difficult as it is self-learning that will benefit you the most
[12:56:55.846606]<rapha>that's why i never get to participate in opensource projects i guess
[12:57:19.290433]<rapha>everything i know is self-taught, but that doesn't work so well for other people's work. at least not for me.
[12:57:50.033472]<rapha>maybe "teaching" is the wrong word anyway. if i tried to do this, would you mentor me?
[13:00:21.239647]<rts>rapha: perhaps having a look at jquery examples on the official jquery site would point you the way. other than that, I must say, that I cannot help you out with it, since it is a trial and error experience, most of the time... especially when dissecting the generated html from trac, which might actually need to be reordered first in order to make it work with such a drag and drop list...
[13:02:01.482986]<rapha>Hmm. Maybe I should ask more specialized questions. Like, what file would you look at first - what file of the Trac source, that is? (I'm quite confident I can hack the jQuery together if I know where to put it)
[13:03:22.408082]<rts>rapha: well, see ticket/templates/report_index or something like that, and btw see also the documentation on genshi for filtering and reordering the generated contents to your likings/requirements.
[13:04:19.857695]<rapha>ah perfect, thanks :-)
[13:04:23.946737]*rapha svn ups
[13:04:37.700172]<rts>rapha: for a starter, you might also want to look at https://axn-software.de/chrome/site/site.html and the source of it to get into basic genshi templating
[13:07:23.786735]<rapha>hmm
[13:07:29.709115]<rapha>that asks me for a username and password?
[13:12:43.928510]<rts>rapha: really? or does it require you to accept the self-assigned certificate?
[13:13:21.107925]<rapha>i did accept that
[13:13:36.779079]<rapha>even the root directory on that domain asks me for username and password
[13:15:06.909880]<rts>rapha: odd, since only on login you are required to pass your username and password...
[13:15:45.797431]<rts>rapha: ups, sorry, damn vservers...
[13:16:26.306346]<rts>rapha: it is https://www.axn-software.de/chrome/site/site.html
[13:16:55.523268]<rts>rapha: the current url rewrite for just axn... does not work anymore since enabling the webdav on that site...
[13:17:53.303553]<rapha>well, i have a real-metal server and that doesn't make the web server configuration any less error-prone ;)
[13:18:32.140504]<rapha>is that site supposed to already show me sourcecode while just looking at it in the browser or is that some kind of problem?
[13:41:58.821369]<rts>rapha: actually, no, you will have to either download it or view the sources...
[13:46:05.089684]<rapha>rts: because it *does* show some source while I'm just looking it in the browser. So maybe it's broken?
[13:46:42.223956]<rts>rapha: genshi is based on html/xhtml, so what you see is actually the browser's intepretation of that source...
[13:46:58.435221]<rts>s/intepretation/interpretation/
[13:46:58.444811]<evil_twin>rts meant: rapha: genshi is based on html/xhtml, so what you see is actually the browser's interpretation of that source...
[13:55:17.875098]<rapha>rts: i realize that, but am I supposed to see " *
[13:55:19.568578]<rapha>${select( '//div[ @id="main" ]' )} "
[13:55:28.776613]<rapha>without actually looking at the source?
[13:56:03.208397]<rts>rapha: come on, these are plain TEXT nodes for xml/html/xhtml
[13:56:04.894285]<rapha>evil_twin: er ... you just copied what he said - ?
[13:56:04.908849]<evil_twin>nothing known about er ... you just copied what he said -
[13:56:12.984131]<rapha>rofl
[13:56:15.828254]<rapha>it's a bot
[13:56:45.283963]<rts>^^
[13:56:58.892513]<rapha>rts: in that case, a simple "nono, it's supposed to be like that" would have sufficed ;-)
[13:59:14.941008]<rts>rapha: well, basically the template + css will reorganize the generated contents of the site so that it matches the suboptimal design being shown when visiting the site... still working on it, but you might get a clue about what you need to do when implementing drag+drop for custom reports/standard reports
[14:00:03.406816]<srl295>Component manager question.. I'm looking at http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture - I had always been puzzled as to how some of my classes inherited the 'env' value and some didn't. But, I realized that I was creating my own component manager in the absence of knowing where to get one ( compmgr = ComponentManager() .. my_comp = MyComponent(comp_mgr ) ) . But it seems, and I just noticed this pattern now, that when one component
[14:00:03.630429]<srl295> wants to create another, it ought to do something like.. my_other_comp = MyOtherComp(self.compmgr)
[14:00:14.010941]<rts>rapha: and, besides that you might want to have a look at the actual database schema, i don't think that reports/custom reports have an ordering field of some sort, so you might need to file a patch against the current trac trunk as an enhancement request
[14:00:30.326883]<rapha>rts: they have to have - they're numbered
[14:01:14.364585]<rts>rapha: is it the primary key that represents the number, if so, reordering primary keys is a no-no
[14:02:21.260570]<rts>srl295: if you inherited from Component, then you will automatically get the env field set on your instance, see Environment which is the main component manager in the system
[14:02:48.086288]<rts>srl295: if not, then you will not get the env field set on your component instances
[14:03:16.529674]<srl295>rts: MyOtherComponent does inherit from Component, BUT if I create it using a new empty ComponentManager() it won't get Environment
[14:04:02.010255]<srl295>[ 'get' may not be the right word here]
[14:04:32.057856]<rts>srl295: hm, have a look at core.Component then and how it is instantiated...
[14:05:43.024871]<rts>srl295: besides, instantiation MyComponent(emptyCompMgr()) will pass in the empty comp mgr as the environment, so that might just be your problem...
[14:06:04.087136]<rapha>rts: k will have to take a look at the schema then
[14:07:02.897370]<srl295>rts: Right, the empty comp manager is the problem. I'm wondering if the documentation I cited ought to say something like, components instantiating other components probably want to use the same component manager..
[14:08:16.785125]<srl295>rts: .env is initialized by env.py, component_activated but only if the component manager has the Environment component activated.. my empty one didn't have Environment activated, so that wasn't called.
[14:08:16.970253]<rts>srl295: overlooked your second sentence, yes, you are right, you will always have to reinstantiate new instances of components using the component manager assigned to your component as self.env or self.compmgr
[14:08:54.622077]<rts>srl295: ah, so you are implemeting your own component model then?
[14:09:07.813524]<srl295>rts: I'm not trying to! I'm just trying to have one plugin call another.
[14:10:41.396900]<rts>srl295: but then this should be rather easy, does your other plugin expose a public api, like "OtherPluginSystem" or something like that? then it should be easy to instantiate that using the self.env of your component, which is actually also the central component manager in the trac universe
[14:10:41.583319]<srl295>rts: and wondering why I have to pass env, log, etc to my sub-plugin. (I have a plugin that manages ticket<->*revision mapping, and it's called by a plugin to do code reviews, etc)
[14:11:30.419674]<srl295>rts: yes, I can instantiate it using self.env , or self.compmgr. My point is that I think the documentation for the component system should mention something about using self.compmgr
[14:12:01.181324]<srl295>rts: sorry for being confusing. I solved the issue, just want to make sure I understand before filing a bug
[14:12:12.682107]<rts>srl295: feel free to add it then... however, env and compmgr are actually the same for now, i think, as previously stated
[14:13:07.768144]<rts>s/feel free to add it then/feel free to add it then, to the documentation i mean/
[14:13:07.779059]<evil_twin>rts meant: srl295: feel free to add it then, to the documentation i mean... however, env and compmgr are actually the same for now, i think, as previously stated
[14:14:43.070858]<rts>srl295: as you well may know, currently only rblank and cboos are maintaining all of the project, along with the translators... so additional help..., if you are not already an active committer ;)
[14:15:56.379739]<rts>srl295: i for my part am only learning python and for this i use the trac project's sources *g ...
[14:16:19.115231]<srl295>trying to help when I can. I manage and am involve with other open source projects which use trac extensively. so i understand from both ends of things :)
[14:19:18.166527]<rts>srl295: coming back to your point of having to pass in env, log etc. to your sub-plugin. so you are actually not deriving from Component? since when you derive from Component, then everything will be set up automatically, see ComponentManager in core, and Environment in env, which derives from ComponentManager
[14:20:21.720327]<osimons>srl295: say you have MyComp1(Component) and MyComp2(Component). If inside MyComp1 you want to refer and call MyComp2, you would do MyComp2(self.env).the_method() - ie. "get the component as instantiated by current environment (and managed by the env's comp_mgr)"
[14:21:04.296892]<rts>osimons: yes, so it is, but actually all components are also singletons maintained by ComponentManager
[14:21:44.491870]<osimons>right - so you need to get the reference to the one managed by your env (and its componentmanager)
[14:21:45.791089]<rts>osimons: so when trying to __new__ an existing component it would return the already existing instance, or if that does not exist, it will create a new singleton instance from it
[14:22:09.306660]<osimons>rts: right - what i said.
[14:22:21.680807]<rts>osimons: sure, just wanted to make sure
[14:23:36.663880]<srl295>osimons: Right, I just wanted to see that this is documented as a suggestion: >> " ie. get the component as instantiated by current environment (and managed by the env's comp_mgr)"
[14:24:15.365313]<rts>srl295: erm, the env is actually the compmrg
[14:25:29.808765]<rts>srl295: class Environment(Component, ComponentManager):
[14:25:33.073464]<srl295>right
[14:26:25.527385]<rts>srl295: imo, the current documentation on t.e.o. is rather abstract and does not provide implementation specific details
[14:26:41.769727]<osimons>right. the env has env.compmgr but it is pointing to self
[14:27:18.647677]<rts>srl295: but it states that the env will always be bound to a component when being instantiated, and, afaik also that there is a compmrg field associated with each instance
[14:28:49.932914]<rts>srl295: or does it not?
[14:29:03.261889]<srl295>osimons: from the point of view of core.py ( TracDev/ComponentArchitecture ) it seems like it can simply say, a component could instantiate another by MyComp2(self.compmgr).the_method()
[14:29:20.296921]<srl295>rts: the env is only bound to a component when the Environment component is present :)
[14:29:29.039693]<osimons>correct. and if you in interpreter do; from trac.env import Environment and instantiate env1 and env2, they are in every way different
[14:30:19.027372]<osimons>inside trac code we use open_environment() instead, and that function looksup a cache and fetches any pre-existing env instead of making a new one
[14:30:34.354196]<srl295>osimons: any objection to modifying ComponentArchitecture to note this about components instantiating others?
[14:30:43.769472]<osimons>- so that in a given process there will only be one copy of a give environment
[14:31:40.630912]<osimons>srl295: that page was the orgiginal proposal made by chris, and i think it should not be turned into a developers guide - we should make other pages for that
[14:32:17.199166]<osimons>like that http://trac.edgewall.org/wiki/TracDev/PluginDevelopment page, i suppose
[14:33:12.487571]<osimons>srl295: still, i think you are complicating something that really is a non-issue - just subclass Component and call implements() on the interfaces you implement and be done with it...
[14:33:13.566849]<srl295>osimons: So, it's not really 'documentation about the component architecture and how to use it' either.
[14:35:23.310156]<rts>osimons: currently working on establishing a developer documentation for the various extension point interfaces... see plugin development page for more info, and if you, as a person who has developed multiple plugins in the past would like to contribute on it... well just do it then ;)
[14:37:05.566689]<osimons>srl295: i suppose the above clarification could be added to the ComponentArchitecture page if you feel for it. however, it is also what it says there when it says: "Remember that components follow the singleton pattern, but component managers are not."
[14:39:16.783278]<osimons>however, that whole page is theory until you get to the ComponentArchitecture#HowTracUsesComponents section at the bottom, where comp_mgr gets "renamed" to env and things start to look like they do in trac code
[14:40:42.820933]<osimons>rts: i've seen the page, and applaud the effort to get the docs gathered. as soon as we have that though, we should put it into the actual Trac source in repos - i hope that is what you are planning? Then we can just extract it as needed.
[14:42:40.645599]<rts>osimons: thanks, however, i think that the documentation should be a common effort, so it must reside in the wiki, and, if it ever gets integrated as a devhelp system into a given trac release, then it should be extracted from t.e.o. i think
[14:43:10.919579]<rts>osimons: as for integrating it into the current sources as source level comments, i would rather think not
[14:45:25.544480]<osimons>rts: if you get it into the running code, something like developerplugin could then extract all available interfaces and present it - including plugins, and for the exact version you are running now.
[14:46:01.512955]<srl295>osimons: right, that was exactly the sentence which tipped me off to the issue. Updated... http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture#ComponentsinstantiatingotherComponents
[14:47:05.040855]<rts>osimons: that should not be too difficult, but gathering information on what derives from Interface in order to find out about both existing extension points I think is rather complicated, or is it not?
[14:48:15.744275]<srl295>rts: actually there's an auto generated list of what derives from Interface somewhere..
[14:48:34.662420]<rts>srl295: like i said, the original developers of the component system, i wonder if they are still alive and prospering, had something else in mind when originally developing the component object model...
[14:49:01.709948]<osimons>developerplugin already does this
[14:49:09.080762]<osimons>(just slim on docs...)
[14:50:04.575183]<osimons>rts: let me show you - 3 lines of interactive python...:
[14:50:12.199039]<rts>;)
[14:50:20.189107]<osimons>>>> from trac.env import Environment
[14:50:31.798845]<osimons>>>> myenv = Environment('/path/to/your/env')
[14:50:41.322432]<osimons>>>> print myenv.__metaclass__._registry
[14:51:02.578143]<osimons>the output should be quite self-explanatory...
[14:51:30.641063]<rts>will give it a shot, but i think that it will just return the components in the system, or will it not?
[14:51:52.725281]<osimons>rts: no.
[14:52:22.005334]<osimons>it is a dictionary of all available interfaces (classes) and names of all classes that implement each.
[14:52:58.578144]<osimons>it is what gets looked up when you say that my_providers = ExtensionPoint(IMyInterface)
[14:53:14.200995]<rts>great stuff
[14:53:14.610579]<srl295>This is what I was looking for: http://trac-hacks.org/wiki/TracDeveloperPlugin
[14:53:21.519413]<osimons>=> it returns the classes and then you ask for them - as above Class1(self.env).the_method()
[14:53:54.189089]<osimons>srl295: right - what i meant above with developerplugin (without the proper casing :-)
[14:54:16.018624]<rts>so basically, if at source level everything is documented correctly, one could dynamically generate sort of wiki based markup documentation on the fly
[14:54:23.669086]<osimons>yes
[14:54:30.793293]<srl295>osimons: I meant, 'this is what you were referring to, that I was referencing'
[14:54:59.299759]<osimons>srl295: :-) ah. ok. whatever :-)
[14:55:35.281182]<osimons>rts: as once you have the registry, and the classes, you can (as developerplugin) just inspect the methods and inspect the docs
[14:56:37.121735]<osimons>rts: that said, it is much easier to do initial collecting using the wiki so that is why i'm all for your initiative.
[14:57:38.135117]*srl295 muses .. someday trac will be my login shell .. and power our family photo album ..
[14:58:04.017756]<rts>osimons: and at the package level then, say myplugin.__init__, you would provide documentation that then would automatically be extended by the system so that it provides for deeper linking, say individual interfaces and components...
[14:58:44.755536]<rts>something similar to what javadoc already provides for but embedded into the wiki then?
[14:58:59.293085]<osimons>the component architecture already tracks all this, so yes, it is just a matter of inspecting it all
[14:59:30.980915]<osimons>rts: or, a "make api_docs" command that compiles static HTML docs using sphinx or similar
[15:00:18.468108]<rts>who is the owner of the developerplugin then, maybe he or she would like to reiterate over it, providing source level documentation, provided that we ever get the new help system up and running...
[15:00:59.315316]<osimons>rts: well, chris and noah primarily, but i've also got commit rights to it
[15:01:32.515113]<osimons>ah. it was alec that made the first version some time ago.
[15:01:49.078076]<rts>osimons: so how about getting newhelp running first and then using the helpprovider extension point for providing additional developer documentation to the system then?
[15:03:06.018532]<osimons>rts: collecting the docs, making examples and developer guides is the tough part....
[15:03:39.659912]<osimons>rts: i'd say targeting this for developerplugin would make sense to me - then we can move it later if we want to
[15:10:20.366064]<beefcube>can someone else confirm that file logging is broken with debian lenny/squeeze packages?
[15:12:00.232178]<rts>damn connection loss
[15:13:10.928693]<rts>lost current discussion while it stalled... where were we? still at discussing source level documentation to be presented in the wiki, or so i believe
[15:13:34.193396]<beefcube>i've tried this after apt-get install trac, on both debian lenny/squeeze packages:
[15:13:36.836238]<beefcube>logging]
[15:13:37.021687]<beefcube> log_file = log/trac.log
[15:13:37.034944]<beefcube> log_level = DEBUG
[15:13:46.292078]<beefcube>log_type = file
[15:14:08.688488]<beefcube>tracd is being run with the same use that created the env, and tracd will still not log to file
[15:14:14.969027]<beefcube>user*
[15:14:52.738623]<rts>beefcube: check the permissions on the directory and the user/group assigned to the service running the trac instance
[15:15:49.076809]<beefcube>rts: i'm assuming that is the user that executes tracd? it is the same that created the env with trac-admin
[15:16:21.720108]<rts>beefcube: then it should log to that directory unless tracd was started by a different user
[15:16:49.238691]<beefcube>rts: very well, I can only conclude this is a bug with debian lenny/sqeeze packages or whatever
[15:17:21.496336]<rts>it is log_file = trac.log
[15:18:07.552244]<beefcube>i've tried it with that, same problem, no file is created or logged to, touching file doesn't change that
[15:18:41.064926]<rts>who said that: and if we fail, we will try again...
[15:19:27.698041]<beefcube>rts: bush?
[15:20:48.132017]<rts>nah, they just adopted ;)
[15:22:15.931073]<rts>beefcube: so after restarting, does it log now as expected?
[15:22:24.811564]<beefcube>rts: no
[15:22:53.527684]<rts>[logging]
[15:22:53.711907]<rts>log_file = trac.log
[15:22:53.725345]<rts>log_level = DEBUG
[15:22:53.738212]<rts>log_type = file
[15:23:13.420320]<rts>did you enter all of the above shebang under [logging]?
[15:24:10.237321]<rts>because above i see that your logging] misses the introducing [
[15:24:57.412014]<beefcube>yes, i did, its correct
[15:25:23.447941]<beefcube>i've reproduced this "bug" with two different debian versions of trac under the same conditions
[15:26:10.840910]<rts>weird, because for every version of ubuntu i have tried so far, it willl always log with the above settings
[15:29:55.814869]<rts>beefcube: i do not know the python distribution that the current or past debian distributions are using, but what i know is that debian is far from being so-called stable...
[15:36:13.314895]<ende>Where can I change the default link color (from red to , say, purple) ?
[15:36:17.192706]<ende>do I have to go into the css ?
[15:36:33.238383]<ende>or is there an option to set in some config file/
[15:53:11.787024]<rts>ende: say, you have a website, and a lot of css and html, where would you first look for configuring the colors to say geocities like looks...
[15:53:43.126579]<rts>s/say geocities/say have a geocities/
[15:53:43.136361]<evil_twin>rts meant: ende: say, you have a website, and a lot of css and html, where would you first look for configuring the colors to say have a geocities like looks...
[15:56:54.134440]<rts>see http://wonder-tonic.com/geocitiesizer/ for how your site would feel in purple... :D
[16:01:52.543528]<rts>gn8
[17:16:13.161206]<protorom>Hi People, I'm new to trac and just wondering if the "Ticket status by [....]" panel on the right of the milestone page is also available for users, ie: display little bars to show the number of tickets owned by the logged in user grouped by priority, component, severity, milestone etc.? (e.g.: http://trac.edgewall.org/milestone/0.12.1?by=component but for the logged in user)
[17:28:00.825815]<protorom>2:30 am... I'll check in tomorrow in case someone is kind enough to suggest something. Cheers and thanks in advance!
[22:10:54.249151]<kirean>hmm, is teo down?
[22:43:45.816656]<vtorri>hey
[22:44:09.979595]<vtorri>a guy has authentified in our trac wiki
[22:44:26.999025]<vtorri>all the authentified persons can edit the wiki
[22:44:39.077563]<vtorri>though that guy has the following problem:
[22:44:41.995859]<vtorri>http://i.imgur.com/XISFN.png
[22:44:54.468591]<vtorri>does someone know what the problem is ?
[22:49:41.262478]<vtorri>just a note : we use trac 0.11.7
[23:49:05.679227]<osimons>vtorri: i think that was one of the things fixed ~6 months ago, see http://trac-hacks.org/log/accountmanagerplugin/0.11 and in particular [7161] i guess. update your installed version if you don't have the latest
[23:50:07.973715]<osimons>and, if you have the latest from 0.11 branch and problem persists, then check open tickets for the plugin http://trac-hacks.org/query?status=!closed&component=AccountManagerPlugin and create a new ticket if you can't find the issue mentioned there
[23:50:50.458369]<vtorri>osimons: so it's not in a trac release yet ?
[23:51:19.747816]<osimons>acct_mgr = AccountManagerPlugin (http://trac-hacks.org/wiki/AccountManagerPlugin)