World: r3wp

yes.. now it's fine

Let me know if the word "Stockpile" is the adequat english word in 
"Main" page (I'm not sure about that).

We haven't been using "block" much because there is no consensus 
as to what it should mean. It could be "blocking further development 
in some way" or it could mean "process halts but doesn't crash (usually 
an endless loop)".

When I did a search for "return", I got duplicate entries in the 
results. If it matters, I was on the "Recent Changes" preset beforehand.

I see the duplicate entries too.

Some of the duplicates had the same number as the number of comments.

Good hint, looks like a SQL grouping issue.

Only seems to be dismissed tickets, but not all dismissed tickets. 
Annoying inconsistency.

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