World: r3wp

, 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.

In other word, as `bind? d` is a selfless context which happens to 
contain a 'self word, I'd actually _expect_ `selfless? bind? d` to 
return true.

OK, got it, good point. I'll pt that note in the ticket.

One nice thing to be able to see is a graph of the  resolved issues 
vs the submitted issues

Chris' Google Chart API Dialect may be what you are looking for. 
 http://www.rebol.org/view-script.r?script=charts-api.r

Are there additional comments to #1631?

Comment added.

Could someone add a whole bunch of versions to CureCode for the latest 
host kit? Maybe also add some provisional ones for the next little 
while so that we don't need to do this with every release.

I guess a whole bunch and then some provisional ones is maybe too 
many ;-)

106 was only out for a day before being superceded

I guess you should have been more explicit ... is anyone using alpha 
18?

I was just laughing at myself - what I wrote earlier was a bit redundant.

but whomever added 107 could've added a few more - does it matter 
if some versions won't be used?

might add up to 130Mb!

I like that you give everyone the same treatment. No one escapes 
Graham's cutting comments!

All men are created equal

The latest version is what is shown by default when making a new 
ticket, and most people don't change that default. This means that 
the reviewer has to change the versions to match the currently released 
version. This is why we don't add versions to CureCode that exceed 
the latest version, or at most the version that we are actively working 
on at the moment.

Could someone with sufficient permissions please re-open bug#1665. 
This is cleary a bug which needs to be addressed:

http://www.curecode.org/rebol3/ticket.rsp?id=1665

did you try in A108 ?

if you give me an A108, then i'll try

I don't have it.

so how should i try A108 then :) ?

and the usual path with A108 isn't published... ask henrik or one 
of the others who are working on it.

and as it does not crash the pre-built A107 binaries, I doubt it 
will with A108.

Just curious if you can do a diff on the RT prebuilt binaries and 
the ones you build yourself with the same compiler.

http://www.rebol.net/r3blogs/0339.html


explains, why A108 isn't available yet. I cannot test it either yet

Each day I get an rsp error in the head.rsp file:
** Script Error : Invalid argument: 2 
	** Where: rsp-script 
	** Near:  [foreach [id prj] head sort/skip/compare skip]

I am running Cheyenne and Curecode on a server at home and then have 
another PC as my normal workstation. So each day when I go to Curecode, 
it throws this error. All I have to do to fix it is to go to the 
server, refresh the curecode page from there and it works on the 
remote machine again. 
Anyone else seen this and have a fix?

James: I've never seen such error before. What version of Cheyenne 
are you using?

How does one tell?

p: open http://your-server
print p/locals/header/server

Doc, thanks. It's Cheyenne/0.9.20

James: could you try to delete all the cookies on your remote browser 
when you see that error, then try accessing CureCode server again.

Doc: did you see my email regarding the security issue?

Doc, yes, I will. I think you're on to something. I was thinking 
that it was on the remote side today.
I'll check that tomorrow before I log in. Thanks.

OK, this morning, I went into FF's Cookie browser and searched for 
cookies from my domain where curecode is. There were none.  I went 
to view my curecode page and it was not going to work. I know this 
because the project select shows "none." I then went back to the 
cookies section and there was one for the domain. I deleted that, 
refreshed the curecode page and it worked. 

Now, one thing about my usual usage of curecode and that is during 
any given day, I will end up logging in several times after my sessions 
expire.

Carl: yes, and I produced a new Cheyenne revision to fix all the 
remaining issues regarding running as non-root.

James: looks like a session expiration issue in CureCode, you should 
be redirected to login screen when that happens instead of getting 
an error, I'll see if I can reproduce that tomorrow. Btw, what's 
your CureCode version?

0.9.11 beta. Sometimes I am redirected to the login screen but the 
selection  is none and from there it will go to the rsp error. Thanks. 
Knowing that I can remove that cookie is pretty easy.

Is the CureCode running the R3 tracker a plain 0.9.11? Or has it 
custom modifications?

It's supposed to be 0.9.11, I might have done a few minor patches 
since 0.9.11 public release.

I'm checking my logs to give you a more accurate answer.

Thanks Nenad, "mostly 0.9.11" is already sufficient.

Additions to v0.9.11in production:
- Added the "import account" form in registering page.

Seems that's all the differences.

Great, thanks!

CureCode server upgraded to Cheyenne r104. All is going well.