World: r3wp

The complement charset problem is also the inspiration for the FIND/not 
proposal.

Hmmm, no need to add the char #"(00)", it seems...

btw. is there a reason why we can use 'unique on a bitset?

yep, they don't want bitsets acting like true series

Completeness, and to reduce special-casing code.

hmm ok :-)

Wait a minute... UNIQUE on a bitset! means nothing, they already 
contain unique values

Yup, it's a noop. It was deemed more important to eliminate all potential 
test-to-see-if-something-is-a-bitset-and-not-call-unique code.

We're trying to make the functions more polymorphic in R3, to reduce 
special-case code.

Where it makes sense, of course (meaning: we can come up with a rationale).

For example, SELECT and APPEND also work on objects and maps, and 
the set functions also work on typesets.

Steeve, this works too: insert complement charset "^(00)0123456789^(FF)" 
[0 255]

no need for ^(00)

same result with:
insert complement charset "0123456789^(FF)" 255

Interesting. I wondered how the sparse charsets were handled - Carl 
had implied that they were offset (I probably misunderstood).

For 2.7.6.3.1:
Total: 3028 Succeeded: 2959 Failed: 69

For 2.100.55.3.1:
Total: 3155 Succeeded: 3110 Failed: 45

Taking into account that R3 implements more features (more datatypes 
e.g.), I would say, that it already succeeded to "surpass" R2 in 
its core functionality.

(the above are test results)

Is this with Carl's test suite or your own?

it is a test suite I wrote for Carl

(some time ago)

Ladislav, does it look like we can get going with Carl's test suite 
again? Have you studied it?

Carl gave me some requirements how a test suite should work and I 
wrote my implementation of his spec. Carl looked at it and he probably 
felt it was more complicated than what he liked. OTOH, the main difference 
was, that my test suite tries to give useful informations always 
when it is possible and continue with testing.

I think his desire was that most people could write their own tests.

So, it generally doesn't "choke", when encountering "runaway return", 
"runaway throw", "runaway break", etc.

most people could write their own tests
 - yes, that is fulfilled, the test are according to Carl's spec

Did you write the suite before he added the *-of functions? I remember 
he did a lot of work on those right when he wrote his own test suite.

(a block of code, that should evaluate true)

yes, I wrote it before he wrote the reflector functions, so it does 
not contain sufficiently many tests of these

maybe that's the complexity issue, he's talking about, or was the 
discussion recent?

another spec: the tests can be preceded by #issue modifiers, like 
#r3only, meaning, the test is meant just for the r3 interpreter

or #r2only meaning the opposite

is it possible to compile comparison lists?

complexity issue: if you mean the possibility to write tests that 
would check every possible aspect of the functionality, than that 
is probably impossible

compile comparison lists - you mean to compare different interpreter 
versions?

comparison: yes. this would not only be useful during tests, but 
for documentation for users to study legitimate differences in behavior 
between R2 and R3.

when comparing two interpreters, I can generally run all the non-crashing 
tests by both interpreters (a crashing test is a problem, since it 
stops the testing process) and show the differences

of course, this may mean to run R2-specific test by the R3 interpreter 
or vice versa, which may well look crazy, but it is doable

(since the majority of tests is common for all interpreters)

ok

We need to have the test suite and framework be public, in DevBase, 
and to support both R2 and R3 - just saying, not implying that they 
aren't already. By having one common suite of tests with the version-specific 
differences clearly marked, the tests can serve as docmentation of 
the differences between R2 and R3. This can also help point out flaws 
in R2 that we *want* to change, and determine the implications of 
fixing them.

If you want documentation of the differences in behavior between 
the old reflectors and the *-OF ones, start with R2-Forward: I did 
a lot of testing to determine the behavior of the *-OF functions 
so that I could replicate their behavior in R2. I am not able to 
emulate some R3 datatypes in R2, so the behavioral model is not complete.

Eventually I would like to be able to test R2-Forward with the R3 
test suite. There will be whole classes of behavior that can't be 
emulated, but in many cases the compatibility should be pretty good. 
I am also curious about where R2-Forward is incompatible with R2, 
so those incompatibilities can be segregated into modules.

There are numerous bug fixes in R2-Forward, and every one of those 
fixes is a change: No longer bug-for-bug compatible. I am particularly 
interested in which changes would break legacy code.

It's not as bad as it sounds. Many of the fixes were of bugs that 
were so bad that there was little chance that working code could 
have used the functionality involved. Fixing such bugs shouldn't 
break much. The same goes for some native bugs that haven't been 
fixed yet.

I started a deep deep thinking process wich is a heavy task for an 
idiot biain of mine concerning the futur of viva-rebol and where 
i want to lead it.


If you have a little interest for what i'm doing actually you know 
that i'm actually working  on 2 projects viva-rebol and rekini. I'm 
interrested in transforming viva-rebol into a real time collaborative 
project. manager/editor something like wave but done in rebol to 
create rebol application.


The idea that comes to my brain is to mix IRC and vivarebol. IRC 
would be the supplier for sharing real time documents content information 
and viva-rebol will be at the same time manager and the renderer 
that will catalise the informations collected by irc.


Why irc?  first because they have lot of control feature wich can 
allow anyone to join and see an onShared-creation docuiment  or script 
and only look at it without active participation. That can allow 
a hierachy system with master, co-writer and only viewer. and the 
allow the master to select who participate or not to the création.


We saw with area-tc that rebol and VID and the dialect concept was 
really feat to handle uncomon text handling  at light speed so the 
appears clear for me that this is the next step to go.


Some people will say to me "but it's more important to have an advanced 
rich text editor tool"  which i answer that boring to do and in the 
result the gain in notority for rebol is close to 0. So instead of 
 clonning MS-Word using VID I prefere move to the next step wich 
I hope will lead us to make people see all the potential of rebol.


It took me looooooooooong time (6 years in fact) to see how to merge 
all the interresting part of rebol to make a big project wich we 
could be all be proud of and show all the interesting part of rebol.


Our comminuty is small and working together to make advance the projects 
is obvious if we want our project to be recognised in some way. If 
we all work on our sides on our own project achieving a high quality 
for those projects is hard.  So externally we only show to the world 
project that looks more like teasers than completed project and that 
not a good thing for rebol promotion. We can say all we want about 
the way rebol is done by Carl but us as community which goal is to 
spread rebol world wide we have a part of reponsability in that too.

I think proposing a collaborative real time tool for making rebol 
script is a good idea as a leading project to make every one acquiere 
or show high level skills. That's in my opinion more productive than 
having Gurus explaining to stupid morons like me things during weeks 
with no concrete result to it.  Sooooooooooo I propose to KEEP IT 
SIMPLE. Instead of explaining me the solution take half of the time 
you normally use to answer me to edit my script make the changes 
and then ofcourse we can have a nice chat on why you used that and 
not this and that will make my level progress a lot. And most important 
of all the problem and my project will be solved and working.

ofcourse if that tool allow 10  personne to build from white page 
a rebol script that can allow them to write a documentation allowing 
them to see how are feeled each part of the documents by the contributors 
and make comment on those parts on real time.

this project that will start as a commuty oriented project can then 
be retaken as it by compagnies to speed the way they work. and not 
only for rebol scripting porpose.

another motivation for basing the data exchange part on irc is that 
their is a lot of irc server all around and using them is really 
easy stuff. That's in my opinion faster than making a web oriented 
tools then convince the hoster to allow us to install rebol on his 
web server etc...