World: r3wp

Wait, that last one is not true. I found a dup tested.

No dups if I limit the search to the summary fiields.

Duplicates issue fixed. It was a SQL error : DISTINCT COUNT(id) instead 
of COUNT(DISTINCT id).

I hate when that happens :(

Verified working.

Is the fix for Chrome ok too for you?

Re "block": it should be considered from the user POV. It means that 
the feature is not available because of the bug and that there's 
 no workaround. It's higher than "crash", because a crash can have 
workarounds, giving you access to the feature using other ways.


Example: if "make vector! [4 10]" crashes but not "to-vector [1 2 
3 ...]", it should be marked as "crash", there's a workaround for 
using vector! values. If both were crashing, the issue should be 
marked as "block", because, there would be no way then to use vector! 
datatype.

I haven't noticed any redirect errors since the new version, so tentatively 
yes, it seems fixed.

That's what I thought block should mean. Let's adopt that meaning 
for the next round of reprioritization.

Henrik: "An alternative would be to blank the list when switching 
mode. That perhaps will lead the user to see that an action needs 
to be done to display a list that corresponds with the search query."


Sorry, couldn't fix that in this release, it's much more complicated 
to fix efficiently than I expected first. I should maybe try to clean 
the  result list using Javascript...will see that later.

I don't mind having the list still there.

It's ok. You tried. :-)

What is type=Nuts supposed to mean? It's too fun to get rid of, so 
we should use it :)

Lol. IIRC, it was transfered from AltMe R3 Tracker during the migration 
process. I don't what was the exact meaning in Tracker.

<don't know>

Color changed for following statuses : problem, waiting, and deferred 
(to help distinguish "active" from "suspended" tickets).

The color is quite close to the dismissed/completed color - I had 
to see both next to each other to tell them apart.

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