| Version 1 (modified by , 10 years ago) ( diff ) |
|---|
Trac Ticket Queries
Table of Contents
In addition to reports, Trac provides support for custom ticket queries, used to display lists of tickets meeting a specified set of criteria.
To configure and execute a custom query, switch to the View Tickets module from the navigation bar, and select the Custom Query link.
Filters
When you first go to the query page the default filter will display tickets relevant to you:
- If logged in then all open tickets it will display open tickets assigned to you.
- If not logged in but you have specified a name or email address in the preferences then it will display all open tickets where your email (or name if email not defined) is in the CC list.
- If not logged and no name/email defined in the preferences then all open issues are displayed.
Current filters can be removed by clicking the button to the left with the minus sign on the label. New filters are added from the pulldown lists at the bottom corners of the filters box ('And' conditions on the left, 'Or' conditions on the right). Filters with either a text box or a pulldown menu of options can be added multiple times to perform an or of the criteria.
You can use the fields just below the filters box to group the results based on a field, or display the full description for each ticket.
Once you've edited your filters click the Update button to refresh your results.
Navigating Tickets
Clicking on one of the query results will take you to that ticket. You can navigate through the results by clicking the Next Ticket or Previous Ticket links just below the main menu bar, or click the Back to Query link to return to the query page.
You can safely edit any of the tickets and continue to navigate through the results using the Next/Previous/Back to Query links after saving your results. When you return to the query any tickets which were edited will be displayed with italicized text. If one of the tickets was edited such that it no longer matches the query criteria the text will also be greyed. Lastly, if a new ticket matching the query criteria has been created, it will be shown in bold.
The query results can be refreshed and cleared of these status indicators by clicking the Update button again.
Saving Queries
Trac allows you to save the query as a named query accessible from the reports module. To save a query ensure that you have Updated the view and then click the Save query button displayed beneath the results. You can also save references to queries in Wiki content, as described below.
Note: one way to easily build queries like the ones below, you can build and test the queries in the Custom report module and when ready - click Save query. This will build the query string for you. All you need to do is remove the extra line breaks.
Note: you must have the REPORT_CREATE permission in order to save queries to the list of default reports. The Save query button will only appear if you are logged in as a user that has been granted this permission. If your account does not have permission to create reports, you can still use the methods below to save a query.
Using TracLinks
You may want to save some queries so that you can come back to them later. You can do this by making a link to the query from any Wiki page.
[query:status=new|assigned|reopened&version=1.0 Active tickets against 1.0]
Which is displayed as:
This uses a very simple query language to specify the criteria (see Query Language).
Alternatively, you can copy the query string of a query and paste that into the Wiki link, including the leading ? character:
[query:?status=new&status=assigned&status=reopened&group=owner Assigned tickets by owner]
Which is displayed as:
Using the [[TicketQuery]] Macro
The TicketQuery macro lets you display lists of tickets matching certain criteria anywhere you can use WikiFormatting.
Example:
[[TicketQuery(version=0.6|0.7&resolution=duplicate)]]
This is displayed as:
No results
Just like the query: wiki links, the parameter of this macro expects a query string formatted according to the rules of the simple ticket query language. This also allows displaying the link and description of a single ticket:
[[TicketQuery(id=123)]]
This is displayed as:
- #123
- meter_signal crashes when nfaults > 1.
A more compact representation without the ticket summaries is also available:
[[TicketQuery(version=0.6|0.7&resolution=duplicate, compact)]]
This is displayed as:
No results
Finally, if you wish to receive only the number of defects that match the query, use the count parameter.
[[TicketQuery(version=0.6|0.7&resolution=duplicate, count)]]
This is displayed as:
Customizing the table format
You can also customize the columns displayed in the table format (format=table) by using col=<field> - you can specify multiple fields and what order they are displayed by placing pipes (|) between the columns like below:
[[TicketQuery(max=3,status=closed,order=id,desc=1,format=table,col=resolution|summary|owner|reporter)]]
This is displayed as:
Results (1 - 3 of 283)
Full rows
In table format you can also have full rows by using rows=<field> like below:
[[TicketQuery(max=3,status=closed,order=id,desc=1,format=table,col=resolution|summary|owner|reporter,rows=description)]]
This is displayed as:
Results (1 - 3 of 283)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #393 | fixed | absentee_listener_ has a temp_segment leak | ||
| Description |
While developing an exec_com to test dump_segment and ring_zero_dump, I checked on status of temporary segments in my process directory. My current stack shows only an interrupted emacs editing session. ts -bf quit condition: 234|13340 pl1_signal_$pl1_signal_from_ops_|776 (bound_library_1_|13712) 234|12320 lisp_fault_handler_$ioc|1265 (bound_lisp_intrprtr_|17521) 234|12240 lisp_subr_tv_$..lisp..|2652 (bound_lisp_intrprtr_|2652) 234|11760 lisp|1076 (bound_lisp_intrprtr_|35014) 234|11460 lisp$lisp|244 (bound_lisp_intrprtr_|34162) 234|11360 forward_command_|70 (bound_multics_emacs_|136514) 234|10260 emacs$emacs|2401 (bound_multics_emacs_|141121) 234|10140 emacs_tv_$emacs|37 (bound_emacs_full_|37) 234|5340 command_processor_$read_list|10312 (bound_multics_bce_|10312) 234|4360 command_processor_$complex_command_processor|2543 (bound_multics_bce_|2543) 234|3420 command_processor_$command_processor_|1227 (bound_multics_bce_|1227) 234|2700 abbrev$abbrev_processor|6105 (bound_command_loop_|14103) 234|2400 listen_$listen_|554 (bound_command_loop_|34522) 234|2000 initialize_process_$initialize_process_|704 (bound_process_init_|704) However, past usage in my process shows 57 temp segments in existence, and only 6 are free. The majority of them were claimed by ec_input_ operations. list_temp_segments
57 Segments, 6 Free
!BBBKbcHFWxfwjm.temp.0305 command_processor_
!BBBKbcHFXHQmDB.temp.0362 emacs
!BBBKbcHFXHWDLw.temp.0363 emacs
!BBBKbcHFXQKWkm.temp.0433 emacs
!BBBKbcHFXQKdqf.temp.0434 emacs
!BBBKbcHFXQQQJQ.temp.0440 emacs
!BBBKbcHFcglBfc.temp.0446 command_processor_
!BBBKbcHFcgzxdl.temp.0454 command_processor_
!BBBKbcHFchBGJp.temp.0455 command_processor_
!BBBKbcHFlpHmpB.temp.0457 ec_input_ (area)
!BBBKbcHKLmmBGD.temp.0477 ec_input_ (area)
!BBBKbcHKPddDbh.temp.0500 ec_input_ (area)
!BBBKbcHKXgkmXL.temp.0501 ec_input_ (area)
!BBBKbcHKhNnXgh.temp.0502 ec_input_ (area)
!BBBKbcHKjQFcQd.temp.0503 ec_input_ (area)
!BBBKbcHKmpMGcn.temp.0504 ec_input_ (area)
!BBBKbcHKwWbkBW.temp.0505 ec_input_ (area)
!BBBKbcHLHNqJkP.temp.0506 ec_input_ (area)
!BBBKbcHLHPLQnn.temp.0507 ec_input_ (area)
!BBBKbcHLHPLckF.temp.0510 ec_input_ (area)
!BBBKbcHLKqFlCh.temp.0511 ec_input_ (area)
!BBBKbcHLPCJbqp.temp.0512 ec_input_ (area)
!BBBKbcHLgXlKfK.temp.0565 ec_input_ (area)
!BBBKbcHLqdwQNd.temp.0566 ec_input_ (area)
!BBBKbcHLqfNBMP.temp.0570 ec_input_ (area)
!BBBKbcHMLDggcb.temp.0571 ec_input_ (area)
!BBBKbcHMcGgMgg.temp.0572 ec_input_ (area)
!BBBKbcHNQMKqkQ.temp.0573 ec_input_ (area)
!BBBKbcHNZhbKXd.temp.0574 ec_input_ (area)
!BBBKbcHNZhgHjJ.temp.0575 ec_input_ (area)
!BBBKbcHNbzlfqj.temp.0576 ec_input_ (area)
!BBBKbcHNbzqQFd.temp.0577 ec_input_ (area)
!BBBKbcHNhfZpxl.temp.0600 ec_input_ (area)
!BBBKbcHNhffjCx.temp.0601 ec_input_ (area)
!BBBKbcHNlznBFG.temp.0602 ec_input_ (area)
!BBBKbcHNlzwpKn.temp.0603 ec_input_ (area)
!BBBKbcHNpCHmNb.temp.0604 ec_input_ (area)
!BBBKbcHNpCPGCl.temp.0605 ec_input_ (area)
!BBBKbcHPGWJCbh.temp.0606 ec_input_ (area)
!BBBKbcHPGWNCQW.temp.0607 ec_input_ (area)
!BBBKbcHPJJFzxB.temp.0610 ec_input_ (area)
!BBBKbcHPJJKzpG.temp.0611 ec_input_ (area)
!BBBKbcHPMbmlQf.temp.0612 ec_input_ (area)
!BBBKbcHPMbwqnn.temp.0613 ec_input_ (area)
!BBBKbcHPPNqQCD.temp.0614 ec_input_ (area)
!BBBKbcHPPPBWHh.temp.0615 ec_input_ (area)
!BBBKbcHPccZcpJ.temp.0616 ec_input_ (area)
!BBBKbcHPccflDz.temp.0617 ring_zero_dump.1 (ring_zero_dump
!BBBKbcHQBdpnJK.temp.0624 ring_zero_dump.1 (ring_zero_dump
!BBBKbcHQgKCwQD.temp.0626 emacs
!BBBKbcHWnjHwKP.temp.0625 ring_zero_dump.1 (ring_zero_dump
ls [pd]>*.temp.* -records -dtem
Segments = 59, Records = 70.
06/21/26 10:47 1 !BBBKbcHFWxfwjm.temp.0305
06/21/26 10:47 1 !BBBKbcHFWzDFBB.temp.mail_system
06/21/26 10:47 3 !BBBKbcHFWzDZJW.temp.mail_system
06/21/26 10:47 1 !BBBKbcHFXHQmDB.temp.0362
06/21/26 10:47 1 !BBBKbcHFXHWDLw.temp.0363
06/21/26 10:47 1 !BBBKbcHFXQKWkm.temp.0433
06/21/26 10:47 1 !BBBKbcHFXQKdqf.temp.0434
06/21/26 10:47 2 !BBBKbcHFXQQQJQ.temp.0440
06/21/26 10:49 1 !BBBKbcHFcglBfc.temp.0446
06/21/26 10:49 1 !BBBKbcHFcgzxdl.temp.0454
06/21/26 10:49 1 !BBBKbcHFchBGJp.temp.0455
06/21/26 11:56 1 !BBBKbcHFlpHmpB.temp.0457
06/21/26 11:57 1 !BBBKbcHKLmmBGD.temp.0477
06/21/26 11:59 1 !BBBKbcHKPddDbh.temp.0500
06/21/26 12:03 1 !BBBKbcHKXgkmXL.temp.0501
06/21/26 12:03 1 !BBBKbcHKhNnXgh.temp.0502
06/21/26 12:05 1 !BBBKbcHKjQFcQd.temp.0503
06/21/26 12:07 1 !BBBKbcHKmpMGcn.temp.0504
06/21/26 12:12 1 !BBBKbcHKwWbkBW.temp.0505
06/21/26 12:13 1 !BBBKbcHLHNqJkP.temp.0506
06/21/26 12:15 1 !BBBKbcHLHPLQnn.temp.0507
06/21/26 12:20 1 !BBBKbcHLHPLckF.temp.0510
06/21/26 12:21 1 !BBBKbcHLKqFlCh.temp.0511
06/21/26 12:23 1 !BBBKbcHLPCJbqp.temp.0512
06/21/26 12:25 1 !BBBKbcHLgXlKfK.temp.0565
06/21/26 12:31 1 !BBBKbcHLqdwQNd.temp.0566
06/21/26 12:32 1 !BBBKbcHLqfNBMP.temp.0570
06/21/26 12:36 1 !BBBKbcHMLDggcb.temp.0571
06/21/26 12:52 1 !BBBKbcHMcGgMgg.temp.0572
06/21/26 12:53 1 !BBBKbcHNQMKqkQ.temp.0573
06/21/26 12:53 1 !BBBKbcHNZhbKXd.temp.0574
06/21/26 12:54 1 !BBBKbcHNZhgHjJ.temp.0575
06/21/26 12:54 1 !BBBKbcHNbzlfqj.temp.0576
06/21/26 12:57 1 !BBBKbcHNbzqQFd.temp.0577
06/21/26 12:57 1 !BBBKbcHNhfZpxl.temp.0600
06/21/26 12:59 1 !BBBKbcHNhffjCx.temp.0601
06/21/26 12:59 1 !BBBKbcHNlznBFG.temp.0602
06/21/26 13:00 1 !BBBKbcHNlzwpKn.temp.0603
06/21/26 13:00 1 !BBBKbcHNpCHmNb.temp.0604
06/21/26 13:05 1 !BBBKbcHNpCPGCl.temp.0605
06/21/26 13:05 1 !BBBKbcHPGWJCbh.temp.0606
06/21/26 13:06 1 !BBBKbcHPGWNCQW.temp.0607
06/21/26 13:06 1 !BBBKbcHPJJFzxB.temp.0610
06/21/26 13:08 1 !BBBKbcHPJJKzpG.temp.0611
06/21/26 13:08 1 !BBBKbcHPMbmlQf.temp.0612
06/21/26 13:09 1 !BBBKbcHPMbwqnn.temp.0613
06/21/26 13:09 1 !BBBKbcHPPNqQCD.temp.0614
06/21/26 13:12 1 !BBBKbcHPPPBWHh.temp.0615
06/21/26 13:12 1 !BBBKbcHPccZcpJ.temp.0616
06/21/26 13:12 2 !BBBKbcHPccflDz.temp.0617
06/21/26 13:21 2 !BBBKbcHQBdpnJK.temp.0624
06/21/26 13:32 13 !BBBKbcHQgKCwQD.temp.0626
06/21/26 13:53 1 !BBBKbcHWnjHwKP.temp.0625
06/21/26 13:54 0 !BBBKbcHWqwCdKj.temp.0627
06/21/26 14:14 0 !BBBKbcHZBblQlQ.temp.0632
06/21/26 14:14 0 !BBBKbcHZBblhmp.temp.0634
06/21/26 14:14 0 !BBBKbcHZBblpnZ.temp.0635
06/21/26 14:14 0 !BBBKbcHZBbwMxW.temp.0637
06/21/26 14:25 0 !BBBKbcHZdwmzKC.temp.0647
I suspect that:
I have only the above proof of this suspicion at the moment, but I feel this temp segment releasing error should be documented. While temp segment sizes in the process directory are small (usually 1 page long), the leak could cause the process to eventually run out of available segment numbers. The highest user process segment number allowed is segno 1777_o = 1023_d (limited by the size of user process dseg: 2 pages with each SDW in the array occupying 2 words). |
|||
| #389 | fixed | Add virtual_ptr (vptr) Command/AF interface for invoking cv_ptr_ subroutine from an exec_com | ||
| Description |
When writing an exec_com, it is often necessary to initiate a segment to locate particular data (rather than initiating it to invoke a particular command, AF, subroutine, etc). This ticket suggests adding a new virtual_ptr (vptr) command/AF that will invoke the cv_ptr_ subroutine to initiate a particular data segment within the current process; and return or display a SEGNO|OFFSET virtual_ptr value locating that data segment, and a particular entrypoint_name or offset within that segment. The suggested interface for the virtual_ptr (vptr) command/AF is shown below. 2025-12-10 virtual_pointer, vptr
Syntax as a command: vptr VIRTUAL_PTR {-ctl_args}
Syntax as an active function: [ vptr VIRTUAL_PTR {-ctl_args} ]
Function: Converts a VIRTUAL_PTR string to a pointer value by
initiating the referenced segment will a null reference name. A
VIRTUAL_PTR string is a pathname, reference_name or segment number,
with an optional offset (a number of words or bits) or an
entrypoint_name. Then vptr displays or returns a character
representation of the virtual pointer which locates the data bit within
the referenced segment as shown below.
Control_args given Displayed or Returned Pointer
------------------- ---------------------------------------
-ring segno|wordno(bit_offset)[ring_number]
-no_ring -bit segno|wordno(bit_offset)
-bit segno|wordno(bit_offset)
-no_bit segno|wordno
If neither -bit nor -no_bit is given, a bit_offset component is
displayed or returned only when the given bit_offset value is nonzero.
If neither -ring nor -no_ring is given, a ring_number component is
displayed or returned only when ring_number < ring-of-execution in
which the virtual_pointer command or active function is called.
This normalized representation is useful when creating an abbreviation
or exec_com that examines contents of the location identified by the
virtual pointer.
Upon completion of the abbreviation or exec_com, the virtual_pointer
command may be called a second time with an identical VIRTUAL_PTR
argument and the -terminate control argument. This terminates any
segment initiated by the earlier call to vptr.
Arguments:
VIRTUAL_PTR
Character string representation of a pointer. Format is one of
those described in the "List of virtual pointer formats" section
below.
Control arguments (output):
-bit
Include a decimal bit_offset number in the returned result.
-nonzero_bit, -nzbit
Include a decimal bit_offset number in the returned result if it is
nonzero. (default)
-no_bit, -nbit
Exclude any bit number from the returned result.
-null
Return a null pointer value as the word: null
-no_null, -nnull
Return a null pointer value as a segno and wordno: -1|1
(default)
-ring
Always include a ring number in the returned result.
-no_ring, -nring
Never include a ring number in the returned result.
Control arguments (termination):
These control arguments may only be given when invoking
virtual_pointer as a command.
-terminate, -tm
Terminate the segment referenced by the given VIRTUAL_PTR
representation in the current ring of the user's process.
For details, see the: "Notes on terminating the segment" section
below.
-no_terminate, -ntm
Do not terminate the segment referenced by the given VIRTUAL_PTR
representation. (default)
List of virtual pointer components:
segno
segment number of a segment known to the process. It is an octal
number from 0 to 7777 inclusive; or one of the null pointer segment
numbers (-1 or 77777 or 777777).
ref_name
reference name for a segment. It has the format of a PL/1
identifier up to 32 characters in length. See "Notes" below.
path
absolute or relative pathname of a segment or multi-segment file
(MSF). It may also use the archive convention (path::component) to
select one archive component.
entry_pt
named location within an object segment; or an object MSF
(multi-segment object file). It is a PL1 identifier from 1 to 256
characters in length. The name designates the location of a word
somewhere within the object file. See "Notes" below.
W
octal word offset from the beginning of the segment. It may have a
value from 0 to 777777 inclusive.
B
decimal bit offset within the selected word of a segment. It may
have a value from 0 to 35 inclusive.
R, r
effective ring number of a pointer to a segment. A program
executing in any ring <= R may reference through that pointer to
locate a selected data word or bit. R or r is an octal digit from
0 to 7 inclusive. Any ring number must appear after the W word
number or the entry_pt name of the virtual pointer. See the section
"Notes on ring number" for more details.
List of virtual pointer formats:
The VIRTUAL_PTR argument must follow one of the formats listed
below.
segno|W(B)[R]
points to octal word W, decimal bit B within that word, of the
segment whose octal segment number is segno. R gives a desired ring
number to be used in the pointer.
segno|W(B)
same as segno|W(B)[r] where r is the current ring in which vptr
was invoked.
segno|W
same as segno|W(0)[r].
segno|, segno
same as segno|0(0)[r].
segno|entry_pt[R]
points to the word located by entry point entry_pt in the object
file whose octal segment number is segno. For an object MSF, segno
must identify component 0 in which all definitions are stored. If
entry_pt locates a word in some other component of that object MSF,
that component's segno will be returned in the resultant
VIRTUAL_PTR. R gives a desired ring number to be used in the
resultant pointer.
segno|entry_pt
same as segno|entry_pt[r] where r is the current ring in which vptr
was invoked.
-name segno|...,
-nm segno|...
treat a segment identifier which looks like a segment number as an
entryname. The ... may be any of the OFFSET formats shown earlier.
Search for a segment with that entryname using linker search paths,
and make that segment known to the user process.
ref_name$entry_pt[R]
points to word located by entry point entry_pt in an object file
whose reference name is ref_name. R gives the desired ring number
to be used in the pointer.
ref_name$entry_pt
same as ref_name$entry_pt[r] where r is the current ring in which
vptr was invoked.
ref_name$W(B)[R]
points to octal word W, decimal bit B of segment or MSF whose
reference name is ref_name. If ref_name is a reference name on a
multisegment file (a reference name on component 0 of the MSF), the
word and bit offsets are applied within component 0. R gives the
desired ring number to be used in the pointer.
ref_name$W(B)
same as ref_name$W(B)[r] where r is the current ring in which vptr
was invoked.
ref_name$W
same as ref_name$W(0)[r].
ref_name$
same as ref_name$0(0)[r].
-name ref_name$...,
-nm ref_name$...
treat a segment identifier which looks like a reference name as an
entryname. The ... may be any of the OFFSET formats shown earlier.
Search for a segment with that entryname using linker search paths,
and make that segment known to the user process.
path|W(B)[R]
points to octal word W, decimal bit B of segment or MSF identified
by absolute or relative pathname path. If the path given identifies
a multisegment file, the offset given is in component 0 of the MSF.
path may be an absolute or relative pathname, or it may be an
archive pathname (path::component) identifying one archive
component. R gives the desired ring number to be used in the
pointer.
path|W(B)
same as path|W(B)[r] where r is the current ring in which vptr was
invoked.
path|W
same as path|W(0)[r].
path|, path
same as path|0(0)[r].
path|entry_pt[R]
points to word identified by entry point entry_pt in the object file
(segment or MSF) identified by path. R gives the desired ring
number to be used in the pointer.
path|entry_pt
same as path|entry_pt[r] where r is the current ring in which vptr
was invoked.
dir>entry$entry_pt
points to word identified by entry point entry_pt in the object file
identified by pathname dir>entry.
<dir>entry$entry_pt
points to word identified by entry point entry_pt in the object file
identified by pathname <dir>entry.
<entry$entry_pt
points to word identified by entry point entry_pt in the object file
identified by pathname <entry.
List of input null pointer formats:
In the VIRTUAL_PTR input, a null pointer is represented by one of
the virtual pointer representations:
-1|1
-1
77777|1
77777
777777|1
777777
null
null()
List of output null pointer formats:
In the displayed or returned output, a null pointer is represented
in one of two formats:
null (if -null control is given)
-1|1 (default)
Notes:
If VIRTUAL_PTR begins with a pathname, either a relative and an
absolute pathname may be given. Archive pathnames are supported.
A ref_name or entry_pt must be in the form of a PL1 <identifier>.
<identifier> ::= <letter>[<letter>|<digit>|_]...
<letter> ::= A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|Y|Z|
a|b|c|d|e|f|g|h|i|j|k|l|m|n|o|p|q|r|s|t|u|v|w|x|y|z
<digit>: ::= 0|1|2|3|4|5|6|7|8|9
A ref_name <identifier> may not be longer than 32 characters. An
entry_pt <identifier> may not be longer than 256 characters. Thus, a
VIRTUAL_PTR with the format ref_name$entry_pt may not be longer than
289 characters.
Notes on terminating the segment:
The segment identified by a pathname is initiated with a null
reference name to make it known to the process address space. This
assigns a segment number which can be displayed in the virtual_pointer
result.
When operation on that pathname is complete, invoke the vptr command
with that same VIRTUAL_PTR (starting with a pathname) and the
-terminate control to reduce the null reference name counter for the
segment. If the counter reaches zero and the segment has no real
reference names in the process, it will be removed from the process
address space.
A vptr -terminate operation will not attempt to terminate a null
pointer or a ring-0 segment. It will silently fail to terminate an
inner-ring segment.
Notes on ring number:
The vptr command converts a VIRTUAL_PTR to a result:
- A segment number of the segment containing the data item located
by the pointer.
- A word number locating the start of the data item within the
segment;
- A bit offset number of the first bit of data within that word;
- A ring number in which that was initiated in order to construct
the pointer.
This result is displayed or returned as a character representation:
segno|W(B)[R]
The R ring number is usually displayed by tools like ring_zero_dump
(rzd) if displaying a pointer in an inner-ring data segment. Such
tools usually do not display R if it is greater than the current ring
number.
A null pointer value always has a ring number of 0. This permits a
pointer set to null() to be passed to another ring of execution while
having a binary content that matches the null() built-in function.
The pointer value returned by the cv_ptr_ function must have its ring
number R >= current ring of execution (the number of the protection
ring in which the caller of cv_ptr_ is executing) unless a null pointer
is returned. If its input VIRTUAL_PTR has R < current ring, the
pointer display or returned has an effective ring set by the hardware
to the ring of execution of the caller of cv_ptr_.
|
|||
| #383 | fixed | Info seg privileged>admin_util.info seems to end prematurely | ||
| Description |
The last line of the info seg (>doc>privileged>admin_util.info) reads:
which ends part of the way through a sentence. |
|||
Query Language
query: TracLinks and the [[TicketQuery]] macro both use a mini “query language” for specifying query filters. Basically, the filters are separated by ampersands (&). Each filter then consists of the ticket field name, an operator, and one or more values. More than one value are separated by a pipe (|), meaning that the filter matches any of the values. To include a literal & or | in a value, escape the character with a backslash (\).
The available operators are:
= | the field content exactly matches one of the values |
~= | the field content contains one or more of the values |
^= | the field content starts with one of the values |
$= | the field content ends with one of the values |
All of these operators can also be negated:
!= | the field content matches none of the values |
!~= | the field content does not contain any of the values |
!^= | the field content does not start with any of the values |
!$= | the field content does not end with any of the values |
The date fields created and modified can be constrained by using the = operator and specifying a value containing two dates separated by two dots (..). Either end of the date range can be left empty, meaning that the corresponding end of the range is open. The date parser understands a few natural date specifications like "3 weeks ago", "last month" and "now", as well as Bugzilla-style date specifications like "1d", "2w", "3m" or "4y" for 1 day, 2 weeks, 3 months and 4 years, respectively. Spaces in date specifications can be left out to avoid having to quote the query string.
created=2007-01-01..2008-01-01 | query tickets created in 2007 |
created=lastmonth..thismonth | query tickets created during the previous month |
modified=1weekago.. | query tickets that have been modified in the last week |
modified=..30daysago | query tickets that have been inactive for the last 30 days |
See also: TracTickets, TracReports, TracGuide
