World: r3wp

What do you think of the subject matter of the bug? Do you think 
it's a good idea?

Is url! part of any-string! ?

Yes. Any series containing characters only.

>> any-string!
== make typeset! [string! binary! file! email! url! tag! issue!]

One of these things is not like the others. The proposal is to remove 
binary! from that set, then add it back to functions that support 
it.

Functions that support series usually support binary!, but usually 
not functions that are specific to strings.

That makes sense to remove it, but there's the string parsing question 
raised by Ladislav. Are we going to have 3 different parsing mode 
in R3 (binary, string, block)? (I wouldn't be shocked by that)

I would whole hardedly welcome explicit binary and string parsing 
differenciation... in fact for some tcp server stuff, I know for 
a fact that if R3 doesn't have binary-specific parsing, its going 
to create a BIG hole in rebol's capabilities, or make it very complicated.

Me too

Especially with the unicode in strings which would cause problems 
with binary parsing.

For example while parsing binary! and I use [1 skip] I want to skip 
1 byte only, not a unicode char which can be on more bytes.

did you test that Oldes ?

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.