World: r3wp

It seems to be related to the angle of my monitor. At high angles 
they are the same, at low angles they are different.

I'll see if I can adjust that a little.

The history in view/edit ticket mode shows status changes as "=> 
none 8" for varying numbers, depending on the status. The status 
field in the edit dropdown above is correct.

I'm trying to change ticket 820 from an issue to a bug, but I get 
a server failure.

Did you notice such failure only for that ticket?

Since you can't delete history, I tend to not make such changes unless 
they are necessary.

The failure is consistent though - I've tried multiple times. Changes 
to other fields worked, as long as the issue-to-bug change wasn't 
there.

Issues fixed. It was caused by a conflicting library version from 
another webapp running on the same Cheyenne instance. Should be ok 
now.

Verified fixed. Apparently the failed attempts were partially completed, 
so the history is a little messy on ticket 820 now :(

Let me see that...

Should I cleanup history starting from 27-May-2009 16:02?

...but keeping 19:39 and 19:43 ?

Thanks, that would help. Then I can undo the comment change.

Ok, removing them right now...

Done. Is it ok for you now?

Yup, looks great.

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.