World: r3wp

i mean, parsing binaries in R3 works well

Parse of binary (and string to some extent) doesn't work well enough 
on R3 yet. For binaries it's as bad as it is on R2.

i thinl it's better currently, why do you think it's as bad ?

it is better currently than in R2, because you can use the same rules 
to parse a binary or a string of the same content.

No need to have different rules, so no need to wast memory using 
useless conversions  with to binary!/string!

i hope, it will not be discarded with the full port of unicode strings

in R2 string and binary are parsed exactly the same.

(conversation continued in !REBOL3)

When I first go in as anonymous, the filter used is the last one 
I was using (usually "Recent Changes"), but the one displayed in 
the Filter box is the first one ("Most Recent Reports"). I like the 
last-filter-used behavior, and wish the Filter box reflected it.

Ticket #595 has an incorrect comment count in the listings.

I remember having done some comment cleanup on that ticket. I'll 
set the comment counter to the correct value.

It's a counter? Interesting - that explains why only one ticket was 
affected.

The counter is here just for speeding up the main SQL query (saves 
a costly sub-query).

Yes it would. It looks like your management utilities need to modify 
the counter as well :)

I am here not to bring up any bugs, I just want to tell Doc, that 
I like CureCode.

yes its really well designed...

I think a new bug type or severity which indicates a ticket being 
reference for documentation could be usefull.  some tickets start 
out as bugs and become examples of use or help in detailing non-obvious 
cases of some features.


setting a ticket as dismissed and not a bug, clearly means that it 
will be ignored in the long run, and rememebering what tickets are 
usefull and can be included in reference documentation when such 
a time occurs would be usefull... it could even allow us to search 
the bug database directly for strange reactions we might consider 
bugs but were pointed out as features or gotchas.


the "not a bug" severity  is similar, but doesn't relate if the post 
is usefull or not.


bug#928 is an example where this could be applied.  I am sure there 
are others.

Ladislav: a compliment coming from you is always greatly appreciated, 
thank you.

It was my pleasure, Doc

Max: maybe a tagging system for tickets would be a good addtion?

there is a sql problem in %build-db.sql file, when I try to execute 
the statements, the last statement gives an error.

INSERT INTO users: number of column doesn't match the number of values.

can easily be fixed, I guess added some new fields bu the table, 
changed the create sql, but did not change the insert statement.

yes tagging is an even better solution. it could even replace much 
of the current fields, if done associatively, using a two column 
tag -> id  table..

three columns if you want to store the date at which the tag was 
set.

Updating Cheyenne version on CureCode server, all sessions will be 
closed.

Upgrade done.

Doc, could you sort the change log lists by ticket ID? They seem 
to be random now.

BrianH: I'll add that. I'm working on fixing a few UI issues on CureCode 
(mainly on stats page).

I miss very simple graph on the main page, exactly the one showing 
what RT's blog shows - showing completed, opened and waiting tickets. 
Current graphs are nice, but it takes longer time for me to understand 
it. E.g. why are not dismissed tickets part of completed tickets? 
I know that it would mean double categorisation, but then I propose 
dividing table into 3 sections, waiting, opened, closed, or at least 
two sections - opened, closed ... and part of the closed would be 
- complete, dismissed, tested, and their subtotal. What do you think?

I want the more detail - the distinction between dismissed and complete 
matters.

there are graphs in curecode now?

Yeah, check the Main page.

neat. never saw that before.

are they generated with AGG? the fonts are really nice looking.

Probably :)

BrianH: noone wants distinction between dismissed and completed being 
removed, it could be subgrouped. But that way, it is a bit difficult 
to quickly get clear view, of how many tickets are being regarded 
being finished, and with how many tickets there is a chance someone 
will look at them, correct or implement. Simply put - when I looked 
at Carl't graph, it gave me clear status of overall R3 development. 
6 months CureCode status is no clear indication about the concrete 
state of the project.

People still review the completed/dismissed tickets - not as often, 
but it happens.

I agree with Pekr about the need of a simple and global graph.

Graphs are currently generated using Google Charts API.

They look nice :)

Weirdness on http://curecode.org/rebol3/: Twice today I have noticed 
people changing descriptions of tickets after they were reviewed 
or tested, people who don't have admin privileges, afaik. Has there 
been a change to CureCode recently, or have new admins been added?

No changes recently. Can you give me the changed tickets ID?

Hmm, the stats page has been removed a week ago waiting for fixes. 
That's the only change done recently.

I've done a lot of fixes and improvements on the stats page so I'll 
put it back online tomorrow. I've also pulled CureCode out of the 
quirk rendering mode, so a lot of CSS have been changed to keep the 
look as it should be. The result is an improved CSS support for Gecko 
and Webkit, but I gave up on IE8 (can't fix table inner borders).

It looks to me that the only way for proper table border rendering 
in a cross-browser way is replacing them with DIV tags.

I would like to propose some enhancements:


- having to manually always select particular ticket-view category 
and project name in changelog section, becomes kind of denerving, 
once you have to do it several times a day

- hence I propose to extend user-profile settings, where we can preselect 
such things. If it is more complicated effort, I vote to change default 
ticket view from "my tickets" to "most recent reports" one

The default ticket view for anonymous login shows up as Most Recent 
Reports in the dropdown box, but is actually Recent Changes. The 
first thing I check when going in anonymously is Recent Changes, 
but either default would be fine if the dropdown and display matched.

BrianH: Ok, issue fixed in the new version (not yet released).

In case you were curious, the reason I go in anonymously is to check 
to see if there has been any changes. Only if there is something 
that needs some action on my part do I log in.

Pekr: I'm looking at thoses features to see if I can add it easily 
now (or postpone it in a future release).