World: r3wp

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

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.