World: r3wp

I'm wondering why this garbage is showing up now instead of a few 
weeks ago when I've upgraded the server.

Henrik ... no idea when you've seen this issue?

It only occurs to me after I've been making changes ... not in the 
normal course of events.

hasn't happened since I reported it in March when I was setting the 
response buffer.

Until the other day.

After a quick code and trace.log files inspection : there's no missing 
COPY, it seems related to a complex chain of events preventing the 
RSP output buffer to be CLEARed before re-use. I found a potential 
flaw in response/include, if the included script raises an error 
in a way that's not  catchable by the RSP execution system, it can 
prevent the output buffer from being reset. In trace.log file, I've 
found an error at 00:53 AM from a rejected SMTP connection using 
SEND function (not the new builtin MTA) that could be the trigger 
for this issue.

Probably why I only see when debugging faulty rsp code.

Graham, only during development. Cure was a restart of the server. 
From Doc's post, it seems he knows what to do about it.

CureCode service will be interrupted during a few seconds now in 
order to upgrade the server.

Upgrading also PHP to v5.2.11 on the same server...takes a bit more 
time.

It's amazing how much time it takes to compile PHP...

The number of modules included on the default config is insane.

Stopping Cheyenne...

Restarted. Everything seems ok.

Doc, on the login page, could you add id attributes to the login 
and pass tags? I'm guessing that is why password saving isn't working 
in Chrome. The user name is being remembered by forrm completion 
(which is a separate function in Chrome), but perhaps password saving 
can't find the user name and password without having an id to look 
for. Setting the id for tags the same thing as their names might 
solve that problem.

I was comparing source between CureCode and other sites that work 
with Chrome. The missing id attribute is the only difference seen.

we are over 1000 tickets. Looks good :-)

btw - still waiting for small enhancement, where Changelog section 
would have preselected first item in the list :-)

Pekr, I don't understand your request, the first item is already 
preselected.

BrianH: I'm adding IDs to login page's fields.

Done.

Doc - it is not. Just log-off (start new browser), login back, and 
go to Change-log section. You have to select REBOL 3.0 from drop-down 
menu ...

It's ok here, when I log again with a new fresh browser session, 
the project selector is showing REBOL 3.0 as soon as I'm logged. 
Did you used the "Set current..." button in Profil menu?

If you've never used it, you'll get the default "All Projects" in 
the selector.

Darn, it didn't work again. I'm going to try some more stuff.

CureCode server will be stopped from now during a couple of minutes 
for maintenance.

Maintenance done. Server up again.

I'm thinking about using curecode for a project of mine. Can I install 
it on my server? Can I create a project on curecodes site?

Robert, I use curecode on my Linode. It took about a day to set up 
due to numerous little things, but I can probably help.

1 day... wow. I just thought: Install RSP, call init page, fill-in 
some informaiton. Done. Ok... will think about it.

it's likely that many of those bugs are fixed in 0.9.9. I'm running 
0.9.8. one big problem was to find a rebol version that would run 
on my server, in combination wtih curecode 0.9.8. I decided to go 
for a slightly older version to make that combination easier.

some fixes in curecode also require fixes in cheyenne, etc.

I have a dumb idea: Why not extend Curecode with a client package? 
The client package would be integrated into a program. When a crash 
occurs in your program, a bug report could be sent directly to your 
curecode database. There would be a distinction necessary to identify 
similar reports and gather them under one report.

Good idea. IMO the distinction is to hard to too. Better to add a 
curecode admin function to merge tickets but keep the ticket ID towards 
the customers.

Henrik: I'm doing that for one of our REBOL-based commercial product, 
but sending crash reports to dedicated database table. Creating tickets 
directly could be done without much efforts, but I would avoid mixing 
those automated reports with hand-written ones. Interesting idea 
to think about anyway.

Is there any way how to get code formated in some more readable way 
(at least inside "Example code" field)?

Yes, I could change the font to a monospace one.

Maybe just wrapping the code in <PRE> tag would be enough, didn't 
tested that yet.

I've made a small improvement in the rendering of the "Example code" 
field in view mode (edit mode is unaffected). Let me  know if it's 
better now.

Oldes, I think that you can now remove the <pre> tags from code part 
in ticket  #1369.

Henrik, you can probably identify the crash by the error object and 
then create a checksum from it to avoid duplicates.

My product collects error objects and sends them to my gmail account 
with optional comments from users.  But they're usually easy to fix 
so not worth entering into a database.

And to avoid issues with asking users to setup the smtp details, 
I hard code gmail's smtp server :)

yes, that might be possible.

I'd like to hear your opinion about ticket #1371 where Meijeru is 
asking for ticket submitters to be granted the right to delete their 
own tickets ("Developer" and "Admin" users can delete any ticket). 
This right has been restricted to "Reporter" users to avoid situations 
where comments added by other users, having valuable information 
would risk to be lost due to intentional or unintentional deletion 
by the ticket's owner. Maybe this policy is too restrictive as pointed 
out by Meijeru. What do you think?

agree until the ticket is "touched" by someone else.

So only while the ticket's status remains "submitted" and no comment 
has been added by other users, the owner can delete it. Seems ok 
to me.

I agree with Steeve.

Sounds like a good policy to me.

I agree also.