World: r3wp

Yeah, already tried with IE8. I got the same behavior, plus layout 
bugs in the file upload submit button.

Plus saving the password worked; that was nice.

Layout bugs with IE: known issue, need to curecode it to not forget 
it again.

I found a post on the exact model IE8 uses to change its rendering 
mode. http://blogs.msdn.com/ie/archive/2010/03/02/how-ie8-determines-document-mode.aspx

Can't find anything wrong in the database, I'll give a look at your 
session data in memory, can you post me your public IP address privately 
please?

#1513: issue was an empty "description" field that was blocking the 
changes. I'm investigating how this mandatory field could have been 
skipped during ticket creation.

Code examples lose all indentation and look ugly, eg:
  http://www.curecode.org/rebol3/ticket.rsp?id=1529&cursor=3


Would it be possible to add even the lightest of lightweight markup 
codes so we could specify <pre> for code examples?

Or for code examples to be pre by default, with the appropriate style 
sheet to make them have horizontal scrolling as needed of course?

Never mind, Sunanda, I just got that you meant code examples in the 
comments, not in the example code section. Agreed.

Sorry -- should have been clearer. "examples" is ambiguous in this 
context.

Sunanda: you can use tabs now to indent your code, they will be rendered 
as 4 spaces. Inserting <pre> tags is possible, I'm making a quick 
try at adding it right now.

Thanks.

Is tab the best choice? It's not easy/obvious how to type a tab in 
a webpage; though it's a good choice if you assume we are cutting'n'pasting 
from a text editor.

Right, the purpose was better support cut&pasting from a text editor.

Btw, HTML tags are allowed in comments. ;-)

Now, that's good!

But <pre> rendering doesn't look that good due to <br> tags insertion. 
I need to make the view encoding rules smarter.

Can you use 4 spaces directly to indent your code?

You mean in my own text editor?

No, I mean in code submissions in CureCode comments (rather than 
the example code section). I often type the code directly in the 
text field, and can't use tabs there because they are used for navigation.

I'm talking about output processing by CureCode itself.

Basically the same thing as "you can use tabs now to indent your 
code" but with spaces.

Ok, so your proposing to encode every 4 spaces sequences so that 
they are taken in account by the browser?

I don't know. Accepting pre tags in the input (with no attributes) 
would work too, I guess. I just know that I never post code from 
a text editor into CureCode comments. Instead, it is always written 
directly or copied from the console. In neither case are there tabs 
- all spaces.

Maybe you want to have <code> tags.

What tags are currently acceptible in the input for comments, with 
what restrictions?

I've got a weird bug in 0.9.8. I don't know if this has been fixed: 
When first selecting Main and then very quickly selecting Add Ticket, 
I get the Main page when selecting the Add Ticket page every time. 
It won't stop.

Could be a cache issue with Chrome... in the mouse over the add ticket 
link it shows add-ticket.rsp, but it loads index.rsp instead, when 
clicking on it.

One enhancement request - a check box, which would allow me to receive 
comments to particular bugs, or even state-changes, so that I am 
informed, that some bug got fixed. Would anyone else find it usefull?

yes, that would be pretty nice

an RSS feed per bug

Doc, could you make the Change Log page sort in numeric order based 
on the ticket number?

Brian - your selfless? func was added as a native :-)

Yay!

>> c: repeat i 1 ['i]
== i

>> selfless? 'i
== false

>> selfless? c
== true

Nevertheless, this is where the native SELFLESS? differs from the 
mezzanine one:

>> d: repeat self 1 ['self]
== self

>> selfless? d
== true

(and now, the question is, whether this behaviour is more useful, 
than the one of the mezzanine function.)

It surely is harder to document...

I wasn't aware SELFLESS? took a word argument at all. It works consistently 
with object arguments. We may have to report this.

>> d: repeat self 1 ['self]
== self

>> selfless? bind? d
== true

(the same result)

I do not see it as a bug, necessarily, it would be much harder to 
implement it this way as a mezzanine

Just tested, and the native works correctly in all cases, object 
and word. Your first test was correct too, since the 'i tested was 
a different 'i.

yes, I know that

, while the last test result differs from the result of the mezzanine

And it's the same as the mezzanine behavior, at least in my tests. 
In which case do you find the mezzanine to be different?

>> mezz-selfless? d
== false

>> mezz-selfless? bind? d
== false

How did you create d?

see above

selfless? bind? d == true looks good to me.