Matthew Galati | 1 Mar 04:44 2005
Picon

feature request - latex plug-in

Would it be possible to create a plug-in/macro that could display/render 
latex on the wiki - so as to display mathematics?

Thanks,
Matt
Kis Gergely | 1 Mar 09:24 2005
Picon

RE: Ticket #1005: Implemented work hour reporting for tick ets

Hi,

> -----Original Message-----
> From: trac-bounces-DNOXQ1Wj7szh91C2ulQeWdBPR1lH4CV8@public.gmane.org
> [mailto:trac-bounces <at> lists.edgewall.com] On Behalf Of Felix Collins
> Sent: Monday, February 28, 2005 9:57 PM
> To: trac-DNOXQ1Wj7szh91C2ulQeWdBPR1lH4CV8@public.gmane.org
> Subject: Re: [Trac] Ticket #1005: Implemented work hour
> reporting for tickets
>
> Kis Gergely wrote:
> > Hi,
> >
> > I created a patch for the 0.8-stable branch which implements work
> > hour reporting for the tickets. For details look at:
> > http://projects.edgewall.com/trac/ticket/1005
> >
> > What do you think?
>
> Below are my comments (somewhat modified) from
> http://projects.edgewall.com/trac/ticket/710
>
> I've done this very successfully using the custom fields. I use an
> initial estimate field, a current estimate (changed to reflect the
> updated idea of how long the ticket will take) and a cumulative time
> spent. I've even written a sync utility to allow us to
> synchronise with
> an xml gantt chart program for reporting.
How do you specify a cumulative custom field? This was the only thing missing for me.
First, I wanted to implement it with custom fields too.

>
> I don't think this needs a plugin module or anything like
> that as that
> will only restrict the flexibility needed to support multiple
> different
> development processes.  i.e. your patch does not have two estimate
> fields for  "initial" and "current" estimate.
If you need the "initial" estimate, you can get it from the ticket_change table.
But of course I see your point about flexibility.

>
> The only change I'd like to see to trac to support this sort
> of thing is
> some additions to the types of custom fields to support
> Numerics - read
> only, cumulative, read/write etc. And enforcing of numeric
> only input.
> I looked into doing this myself but I wasn't quite confident of
> understanding trac enough to do it.
So in your current version you need to "cumulate" the actual work yourself.
This was the thing I wanted to avoid.

<at> Christopher: What do you think about a patch that adds support for cumulative / numeric
custom fields? Would you apply such patch? Maybe for trac 0.9?


Best Regards,
Gergely

_______________________________________________
Trac mailing list
Trac@...
http://lists.edgewall.com/mailman/listinfo/trac
Sija | 1 Mar 09:38 2005
Picon

Problem with trac on mod_python

[Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler
trac.web.modpython_frontend: Traceback (most recent call last):
[Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler
trac.web.modpython_frontend:   File
"C:\\PROGRA~1\\Python\\Lib\\site-packages\\mod_python\\apache.py", line 299, in
HandlerDispatch\n    result = object(req)
[Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler
trac.web.modpython_frontend:   File
"C:\\PROGRA~1\\Python\\lib\\site-packages\\trac\\web\\modpython_frontend.py",
line 201, in handler\n    send_pretty_error(e, env, mpr)
[Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler
trac.web.modpython_frontend:   File
"C:\\PROGRA~1\\Python\\lib\\site-packages\\trac\\web\\main.py", line 337, in
send_pretty_error\n    if env and env.log:
[Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler
trac.web.modpython_frontend: TypeError: __nonzero__ should return an int

what's wrong ?
Christopher Lenz | 1 Mar 11:18 2005
Picon
Picon

Re: Problem with trac on mod_python

> [Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler
> trac.web.modpython_frontend: Traceback (most recent call last):
> [Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler
> trac.web.modpython_frontend:   File
> "C:\\PROGRA~1\\Python\\Lib\\site-packages\\mod_python\\apache.py", line
> 299, in
> HandlerDispatch\n    result = object(req)
> [Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler
> trac.web.modpython_frontend:   File
> "C:\\PROGRA~1\\Python\\lib\\site-
packages\\trac\\web\\modpython_frontend.py",
> line 201, in handler\n    send_pretty_error(e, env, mpr)
> [Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler
> trac.web.modpython_frontend:   File
> "C:\\PROGRA~1\\Python\\lib\\site-packages\\trac\\web\\main.py", line 
337,
> in
> send_pretty_error\n    if env and env.log:
> [Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler
> trac.web.modpython_frontend: TypeError: __nonzero__ should return an int
> 
> what's wrong ?

Good catch! I've fixed this problem in http://projects.edgewall.com/trac/
changeset/1299.

Note though that this error is hiding a different exception, which will 
probably pop up next after you upgrade :-P

Thanks,
Chris

--

-- 
Christopher Lenz
  cmlenz at gmx.de
  http://www.cmlenz.net/
Sija | 1 Mar 12:24 2005
Picon

Re: Problem with trac on mod_python

Christopher Lenz <cmlenz <at> ...> writes:

> 
> > [Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler
> > trac.web.modpython_frontend: Traceback (most recent call last):
> > [Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler
> > trac.web.modpython_frontend:   File
> > "C:\\PROGRA~1\\Python\\Lib\\site-packages\\mod_python\\apache.py", line
> > 299, in
> > HandlerDispatch\n    result = object(req)
> > [Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler
> > trac.web.modpython_frontend:   File
> > "C:\\PROGRA~1\\Python\\lib\\site-
> packages\\trac\\web\\modpython_frontend.py",
> > line 201, in handler\n    send_pretty_error(e, env, mpr)
> > [Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler
> > trac.web.modpython_frontend:   File
> > "C:\\PROGRA~1\\Python\\lib\\site-packages\\trac\\web\\main.py", line 
> 337,
> > in
> > send_pretty_error\n    if env and env.log:
> > [Tue Mar 01 09:11:21 2005] [error] [client 66.249.64.6] PythonHandler
> > trac.web.modpython_frontend: TypeError: __nonzero__ should return an int
> > 
> > what's wrong ?
> 
> Good catch! I've fixed this problem in http://projects.edgewall.com/trac/
> changeset/1299.
> 
> Note though that this error is hiding a different exception, which will 
> probably pop up next after you upgrade :-P
> 
> Thanks,
> Chris
> 

That's true, this is a real error:

ClearSilver not installed (No module named neo_cgi)
Traceback (most recent call last):
  File "C:\PROGRA~1\Python\lib\site-packages\trac\web\modpython_frontend.py",
line 179, in handler
    dispatch_request(mpr.path_info, mpr, env)
  File "C:\PROGRA~1\Python\lib\site-packages\trac\web\main.py", line 301, in
dispatch_request
    req.hdf = HDFWrapper(loadpaths=[env.get_templates_dir(),
  File "C:\PROGRA~1\Python\lib\site-packages\trac\web\clearsilver.py", line 132,
in __init__
    raise TracError, "ClearSilver not installed (%s)" % e
TracError: ClearSilver not installed (No module named neo_cgi)

I have "neo_cgi.pyd" in "C:\Program Files\Python\Lib\site-packages\trac"
and i don't have problems with ClearSilver before HDFWrapper update.
Mark Rowe | 1 Mar 12:44 2005
Picon

Re: Re: Problem with trac on mod_python


On Mar 2, 2005, at 12:24 AM, Sija wrote:
> That's true, this is a real error:
>
> ClearSilver not installed (No module named neo_cgi)
> Traceback (most recent call last):
>   File 
> "C:\PROGRA~1\Python\lib\site-packages\trac\web\modpython_frontend.py",
> line 179, in handler
>     dispatch_request(mpr.path_info, mpr, env)
>   File "C:\PROGRA~1\Python\lib\site-packages\trac\web\main.py", line 
> 301, in
> dispatch_request
>     req.hdf = HDFWrapper(loadpaths=[env.get_templates_dir(),
>   File "C:\PROGRA~1\Python\lib\site-packages\trac\web\clearsilver.py", 
> line 132,
> in __init__
>     raise TracError, "ClearSilver not installed (%s)" % e
> TracError: ClearSilver not installed (No module named neo_cgi)
>
> I have "neo_cgi.pyd" in "C:\Program 
> Files\Python\Lib\site-packages\trac"
> and i don't have problems with ClearSilver before HDFWrapper update.

The neo_cgi module shouldn't be inside the trac folder, it should be at 
the top level of site-packages (C:\Program 
Files\Python\Lib\site-packages in your case).

Hope this helps,

Mark Rowe
<http://bdash.net.nz/>
Markus Fuchs | 1 Mar 12:56 2005

Re: Re: Problem with trac on mod_python

> ClearSilver not installed (No module named neo_cgi)
> Traceback (most recent call last):
>   File
"C:\PROGRA~1\Python\lib\site-packages\trac\web\modpython_frontend.py",
> line 179, in handler
>     dispatch_request(mpr.path_info, mpr, env)
>   File "C:\PROGRA~1\Python\lib\site-packages\trac\web\main.py", line 301,
in
> dispatch_request
>     req.hdf = HDFWrapper(loadpaths=[env.get_templates_dir(),
>   File "C:\PROGRA~1\Python\lib\site-packages\trac\web\clearsilver.py",
line 132,
> in __init__
>     raise TracError, "ClearSilver not installed (%s)" % e
> TracError: ClearSilver not installed (No module named neo_cgi)
>
> I have "neo_cgi.pyd" in "C:\Program Files\Python\Lib\site-packages\trac"
> and i don't have problems with ClearSilver before HDFWrapper update.

Copying neo_cgi.pyd to "C:\Program Files\Python\Lib\site-packages\trac\web"
should fix the problem.

- Markus
Sija | 1 Mar 13:51 2005
Picon

Re: Problem with trac on mod_python

Markus Fuchs <trac <at> ...> writes:

> 
> Copying neo_cgi.pyd to "C:\Program Files\Python\Lib\site-packages\trac\web"
> should fix the problem.
> 
> - Markus
> 

i tried that, but it didn't work, but it's workin' now, thx :>
Felix Collins | 1 Mar 20:55 2005

Re: Ticket #1005: Implemented work hour reporting for tick ets

>  > some additions to the types of custom fields to support
>  > Numerics - read
>  > only, cumulative, read/write etc. And enforcing of numeric
>  > only input.
>  > I looked into doing this myself but I wasn't quite confident of
>  > understanding trac enough to do it.
> So in your current version you need to "cumulate" the actual work yourself.
> This was the thing I wanted to avoid.

Yeah, I wanted to avoid this sort of thing too.  Luckily we have a small 
team of highly skilled developers so it is not to difficult to enforce 
conventions in the use of the system.  I would prefer the system to 
enforce the business logic.

> 
>  <at> Christopher: What do you think about a patch that adds support for 
> cumulative / numeric
> custom fields? Would you apply such patch? Maybe for trac 0.9?
Please say yes... please say yes!  ;-)  It wouldn't be a major change to 
Trac after all.  It would simply mean extending an already existing 
mechanism.  It would be a backward and forward compatible change that 
would introduce no new dependencies.

While we are at it we could provide support for currency fields 
(including support for specifying the symbol in the ini file) and date 
fields (smart fields that supports entry in multiple formats and detects 
the format used?).  Anyone think of anything else useful?

The "cumulative" field could be implemented as a general "operation" 
field where the operation to be performed on the existing data could be 
specified in the ini file.

The ini file entry for the numeric fields could include specification of 
the precision, read/write status and radix. Trac could enforce this when 
numbers are entered.

I propose the following:

write once - field is only editable when the ticket is created (this 
could be useful for text fields too.

read only - for fields where the value is generated some external way

read write - fully editable field

operation - field is not writable directly but can be modified by way of 
a math. operation (specified in the ini file)

I propose storing it all as strings as I think that is what SQLite does 
anyway. Trac would convert it to strings and simply ignore values in the 
DB that didn't convert back to number correctly.

What about my idea of making the Roadmap page customisable in the same 
way that the ticket reports are?  Any comments?

Regards,
Felix
Jim Cheetham | 1 Mar 21:47 2005

Re: Ticket #1005: Implemented work hour reporting for tick ets

On Wed, 2005-03-02 at 08:55 +1300, Felix Collins wrote:
> operation - field is not writable directly but can be modified by way of 
> a math. operation (specified in the ini file)

Or perhaps, an SQL operation? That probably gives you a certain amount
of math ability, and allows other fields/tables to be consulted.

Basically, it's a type of trigger, implemented in the application
instead of the SQL manager ...

-jim

Gmane